C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »

hooah: Feb 6, 2006; WTF?

I'm again having trouble using private data members from a class's header file in the same class's .cpp file. I was supplied a completed stats.h and a test cpp file, and need to write stats.cpp. The problem is that I get all sorts of undeclared identifier errors when I use either my_data or my_size (from stats.h) in stats.cpp. I tried including stats.h and stats.cpp separately and together in the test file, which doesn't help (I just sometimes get double the number of errors). I made sure there's a closing }; this time. What else could I be missing?

# ? Jun 13, 2013 17:50

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 20:47

That Turkey Story: Mar 30, 2003

hooah posted:

I'm again having trouble using private data members from a class's header file in the same class's .cpp file. I was supplied a completed stats.h and a test cpp file, and need to write stats.cpp. The problem is that I get all sorts of undeclared identifier errors when I use either my_data or my_size (from stats.h) in stats.cpp. I tried including stats.h and stats.cpp separately and together in the test file, which doesn't help (I just sometimes get double the number of errors). I made sure there's a closing }; this time. What else could I be missing?

Post your actual code and the actual error message. What you've told us doesn't really help. My wild guess is it's probably a static datamember and an undefine reference link error, in which case you need to define your variables.

# ? Jun 13, 2013 17:59

Marta Velasquez: Mar 9, 2013; Good thing I was feeling suicidal this morning...; Fallen Rib

hooah posted:

I'm again having trouble using private data members from a class's header file in the same class's .cpp file. I was supplied a completed stats.h and a test cpp file, and need to write stats.cpp. The problem is that I get all sorts of undeclared identifier errors when I use either my_data or my_size (from stats.h) in stats.cpp. I tried including stats.h and stats.cpp separately and together in the test file, which doesn't help (I just sometimes get double the number of errors). I made sure there's a closing }; this time. What else could I be missing?

It's hard to say anything without code, but one thing that sticks out is that you typically don't #include a cpp file. You should be compiling them both separately and linking them.

Can you post any code?

# ? Jun 13, 2013 18:03

hooah: Feb 6, 2006; WTF?

stats.h
stats.cpp
test program
errors

# ? Jun 13, 2013 18:07

bloodandiron: Jul 21, 2006

You need to include stats:: before all of the function names, not just the constructors (i.e. void stats::sort( )) in the cpp file.

# ? Jun 13, 2013 18:12

raminasi: Jan 25, 2005; a last drink with no ice

Jabor posted:

If your special-snowflake license terms forbid someone from distributing the proprietary library alongside your application without open-sourcing it, there's no way for anyone else to redistribute your application in a usable way without violating the license.

Well maybe our license is further away from the LGPL than I thought, because I don't see any language like that in there. I'm not a professional license reader guy though.

# ? Jun 13, 2013 18:25

hooah: Feb 6, 2006; WTF?

bloodandiron posted:

You need to include stats:: before all of the function names, not just the constructors (i.e. void stats::sort( )) in the cpp file.

that's what I get for copying stuff from the header file. I swear I'll get the hang of class definitions one of these days...

hooah fucked around with this message at 18:56 on Jun 13, 2013

# ? Jun 13, 2013 18:46

hooah: Feb 6, 2006; WTF?

Sorry for the double post, but I seem to be losing my mind. Why would this code only print out a 0?

code:

#include <iostream>
#include <vector>
#include <fstream>

using namespace std;

int main()
{
	ifstream inFile("tests.dat");
	double x;
	int j, n=0;
	vector <double> list(100,0.0);
	while(inFile >> x && n<list.capacity())
	{
		list[n]=x;
		n++;
	}
	for(j=0;j<n;j++);
	{
		cout << list[j] << " " << endl;
	}
	return(0);
}

Here is tests.dat:

code:

 76.0  65.0  93.0  95.5  84.5
 85.0  91.0  76.5  65.0  70.6
 86.0  82.5  68.0  79.5  83.0

# ? Jun 14, 2013 01:29

shrughes: Oct 11, 2008; (call/cc call/cc)

A semicolon.

# ? Jun 14, 2013 01:40

b0lt: Apr 29, 2005

hooah posted:

Sorry for the double post, but I seem to be losing my mind. Why would this code only print out a 0?
code:
	for(j=0;j<n;j++);

Also, you should compile with warnings.

# ? Jun 14, 2013 01:40

shrughes: Oct 11, 2008; (call/cc call/cc)

Also, note that you want to use .size(), not .capacity().

# ? Jun 14, 2013 03:46

wasabimilkshake: Aug 21, 2007; North Carolina votes yes.

It's typically frowned upon to declare multiple local variables on a single line (while initializing some of them):

code:

int j, n=0;

...because in this case, j is left uninitialized, whereas some people might reasonably assume that the above line sets both j and n to zero.

That doesn't make a difference in the sample you posted, because you initialize j later on before using it. But in general, it's a good idea to declare your variables as close as possible to where you use them, and to initialize them at the same time that you declare them. Since j is only used in the body of the for loop, you can declare it like so:

code:

for (int j = 0; j < n; j++)

# ? Jun 14, 2013 04:10

Mr.Radar: Nov 5, 2005; You guys aren't going to believe this, but that guy is our games teacher.

I've got a somewhat :psyduck:

problem with dynamic libraries on Linux and I'm hoping someone can help me. I've an application that directly links a static library and my application additionally links to a .so that also links to the static library. The static library has both externed and static global variables. One of the externed global variables is used as a flag to indicate whether one of the static global variables has been initialized.

On Windows each copy of the static library has its own copy of both variables, but on Linux apparently the externed variables get shared between library copies but the static variables do not. This causes issues when both my application and the .so use the static variable that the externed variable is protecting because both will think they have initialized the static variable when in reality only one copy has (causing a SEGFAULT).

The best way that I can think of to fix this is to make the externed guard variable static and then create an accessor function to it (it is only being set in one file, but it is being read from lots of them). Is there any better way to do this? Particularly, is there any way to make Linux behave like Windows where each copy of the static lib also gets its own copies of its externed global variables? This is some 20 year old legacy code that at least a hundred global variables so there are almost certainly more cases of this kind of problem and I'd really like to solve them all at once rather than wait until we get a bug report for each one (which will probably take the form of "it crashes randomly and we don't know why, fix it" :smithicide:

# ? Jun 14, 2013 21:55

FlapYoJacks: Feb 12, 2009

wasabimilkshake posted:

That doesn't make a difference in the sample you posted, because you initialize j later on before using it. But in general, it's a good idea to declare your variables as close as possible to where you use them, and to initialize them at the same time that you declare them. Since j is only used in the body of the for loop, you can declare it like so:
code:
for (int j = 0; j < n; j++)

Erm, no? Declaring your variables should generally be done well in advance, so that way they have memory assigned to them already. If anything, your variables *should* be in a struct (or object) for code reusability. Why would you declare j over and over and over in different functions if you could just use a single variable in a object or struct that was set at initialization.

Also the code you posted only works with C99 and above, and is dependent on the compiler, it is always safer to declare your variable first, and then use it later on.

# ? Jun 14, 2013 22:11

nielsm: Jun 1, 2009

ratbert90 posted:

Erm, no? Declaring your variables should generally be done well in advance, so that way they have memory assigned to them already. If anything, your variables *should* be in a struct (or object) for code reusability. Why would you declare j over and over and over in different functions if you could just use a single variable in a object or struct that was set at initialization.

Also the code you posted only works with C99 and above, and is dependent on the compiler, it is always safer to declare your variable first, and then use it later on.

That's really terrible advice. Your C++ compiler is confiscated. Please leave all your code at the reception for safe incineration so it will not inflict further damage on the world at large.

# ? Jun 14, 2013 22:27

Cat Plus Plus: Apr 8, 2011

ratbert90 posted:

Erm, no? Declaring your variables should generally be done well in advance, so that way they have memory assigned to them already. If anything, your variables *should* be in a struct (or object) for code reusability. Why would you declare j over and over and over in different functions if you could just use a single variable in a object or struct that was set at initialization.

Also the code you posted only works with C99 and above, and is dependent on the compiler, it is always safer to declare your variable first, and then use it later on.

This is not C code. Also, ugh, no. :cripes:

Neither memory nor code reusability is relevant here. Defining loop indexers "way before" the loop is only done in C89 because of the language restrictions. Not a concern in C++.

# ? Jun 14, 2013 22:28

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

And it was only a concern in C89 because they couldn't decide which scope it would be assigned to.

# ? Jun 14, 2013 22:42

pseudorandom name: May 6, 2007

Mr.Radar posted:

I've got a somewhat problem with dynamic libraries on Linux and I'm hoping someone can help me. I've an application that directly links a static library and my application additionally links to a .so that also links to the static library. The static library has both externed and static global variables. One of the externed global variables is used as a flag to indicate whether one of the static global variables has been initialized.

On Windows each copy of the static library has its own copy of both variables, but on Linux apparently the externed variables get shared between library copies but the static variables do not. This causes issues when both my application and the .so use the static variable that the externed variable is protecting because both will think they have initialized the static variable when in reality only one copy has (causing a SEGFAULT).

The best way that I can think of to fix this is to make the externed guard variable static and then create an accessor function to it (it is only being set in one file, but it is being read from lots of them). Is there any better way to do this? Particularly, is there any way to make Linux behave like Windows where each copy of the static lib also gets its own copies of its externed global variables? This is some 20 year old legacy code that at least a hundred global variables so there are almost certainly more cases of this kind of problem and I'd really like to solve them all at once rather than wait until we get a bug report for each one (which will probably take the form of "it crashes randomly and we don't know why, fix it" ).

the ld manual posted:

`-Bsymbolic' When creating a shared library, bind references to global symbols to the definition within the shared library, if any. Normally, it is possible for a program linked against a shared library to override the definition within the shared library. This option is only meaningful on ELF platforms which support shared libraries.

ELF is weird because it was designed to be an entirely transparent drop-in replacement for standard Unix static linking behavior.

# ? Jun 14, 2013 22:47

Volte: Oct 4, 2004; woosh woosh

ratbert90 posted:

Erm, no? Declaring your variables should generally be done well in advance, so that way they have memory assigned to them already. If anything, your variables *should* be in a struct (or object) for code reusability. Why would you declare j over and over and over in different functions if you could just use a single variable in a object or struct that was set at initialization.

Also the code you posted only works with C99 and above, and is dependent on the compiler, it is always safer to declare your variable first, and then use it later on.

Please tell us where you learned this

# ? Jun 14, 2013 22:51

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

ratbert90 posted:

Erm, no?

Everyone already told you you're wrong, but I thought I'd explain why, since nobody else has mentioned it.

Allocating memory in advance is, as you suggest, a good idea.

But local variables [that are primitives or don't have constructors that allocate more things] are always allocated in advance - it doesn't matter if they go in and out of scope, there's no reallocation there, because local variables are just spaces on the stack, which is a big pre-allocated memory lump.

That's not enough to make your way a bad idea, that just takes away your reason for saying it's a good idea. The reason it's a bad idea is that there's a lot more scope for hard to find errors if you can reuse a variable somewhere outside its intended scope. Declaring variables in the smallest scope that covers their intended use makes accidental reuse of something like that that's been modified into a compile-time error instead of a "what the gently caress is going on here" error. Plus, int banana and int orange whose scopes don't overlap can occupy the same piece of the stack instead of either taking twice as much or confusingly reusing the variable name.

roomforthetuna fucked around with this message at 23:14 on Jun 14, 2013

# ? Jun 14, 2013 23:10

Sang-: Nov 2, 2007

ratbert90 posted:

Erm, no? Declaring your variables should generally be done well in advance, so that way they have memory assigned to them already. If anything, your variables *should* be in a struct (or object) for code reusability. Why would you declare j over and over and over in different functions if you could just use a single variable in a object or struct that was set at initialization.

Also the code you posted only works with C99 and above, and is dependent on the compiler, it is always safer to declare your variable first, and then use it later on.

ints are allocated on the stack anyway, int j = 0; is going to be (at worst) "push 0" where as malloc is much more time consuming :p

1999 was 14 years ago.

# ? Jun 14, 2013 23:12

Spatial: Nov 15, 2007

ratbert90 posted:

Erm, no? Declaring your variables should generally be done well in advance, so that way they have memory assigned to them already. If anything, your variables *should* be in a struct (or object) for code reusability. Why would you declare j over and over and over in different functions if you could just use a single variable in a object or struct that was set at initialization.

Good question! Why would you do that?

Well, one particularly good reason would be the existence of a data structure where all local variables could be represented as offsets from a relative address which moves backwards and forwards with each function call and return.

Such a structure would be profoundly useful. There would be no need for any memory allocations at all. The compiler could simply emit offsets tailored for each function, regardless of their declared location. Why, it could even reuse slots when others are no longer needed!

Constant-time operations, superb cache locality and easy to implement to boot. I call it... the stack!

# ? Jun 14, 2013 23:12

Blotto Skorzany: Nov 7, 2008; He's a PSoC, loose and runnin'
came the whisper from each lip
And he's here to do some business with
the bad ADC on his chip
bad ADC on his chiiiiip

roomforthetuna posted:

Everyone already told you you're wrong, but I thought I'd explain why, since nobody else has mentioned it.

Allocating memory in advance is, as you suggest, a good idea.

But local variables [that are primitives or don't have constructors that allocate more things] are always allocated in advance - it doesn't matter if they go in and out of scope, there's no reallocation there, because local variables are just spaces on the stack, which is a big pre-allocated memory lump.

You probably meant 'POD type' rather than 'primitive', and operations to grow and shrink the stack are not free (the arithmetic on the stack pointer you see at the beginning and end of functions takes cycles, albeit few); ratbert is wrong because the compiler isn't growing and shrinking the stack over and over in the loop (and because his idea of storing "utility variables" in one global struct is zany).

Blotto Skorzany fucked around with this message at 23:19 on Jun 14, 2013

# ? Jun 14, 2013 23:16

Bonfire Lit: Jul 9, 2008; If you're one of the sinners who caused this please unfriend me now.

roomforthetuna posted:

Plus, int banana and int orange whose scopes don't overlap can occupy the same piece of the stack instead of either taking twice as much or confusingly reusing the variable name.

They can use the same space as long as their liveness doesn't overlap, which doesn't have exactly to be the same as their scope (thanks to as-if, since ints don't have a non-trivial dtor).

# ? Jun 15, 2013 00:01

Ciaphas: Nov 20, 2005; > BEWARE, COWARD

Would whoever decided the Oracle C++ Call Interface would not support asynchronous operations, despite the C interface supporting them just fine, please step forward so I can murder them? Thanks.

:mad:

# ? Jun 15, 2013 00:02

Cat Plus Plus: Apr 8, 2011

roomforthetuna posted:

Everyone already told you you're wrong, but I thought I'd explain why, since nobody else has mentioned it.

The reason is "leave worrying about low-level stuff like that to the compiler, worry about semantics".

# ? Jun 15, 2013 00:03

Mr.Radar: Nov 5, 2005; You guys aren't going to believe this, but that guy is our games teacher.

pseudorandom name posted:

ELF is weird because it was designed to be an entirely transparent drop-in replacement for standard Unix static linking behavior.

Thanks. I looked over the man page for ld so many times I have no clue how missed that. I'll give it a try and see if it works.

# ? Jun 15, 2013 00:15

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Otto Skorzeny posted:

You probably meant 'POD type' rather than 'primitive', and operations to grow and shrink the stack are not free (the arithmetic on the stack pointer you see at the beginning and end of functions takes cycles, albeit few); ratbert is wrong because the compiler isn't growing and shrinking the stack over and over in the loop (and because his idea of storing "utility variables" in one global struct is zany).

Yeah, there is no additional operational arithmetic on the stack pointer for declaring a variable in a scope that begins part way into the function though, is what I was getting at (and which is the situation that was being discussed). And yes, POD type is what I meant, I am not good with remembering terms.

And yes, using a global for such things is especially nuts, I pretty much just glossed over that because it was so insane. My reasons for not using variables with wider scope still apply to that though, just even more so.

Also, "grow and shrink the stack" is kind of misleading to someone who is mistakenly worrying about slow memory allocation - what you do at the start of the function isn't really growing the stack, it's just moving a pointer up the pre-allocated space. The contents of the stack have grown, but the stack itself is the same lump of memory it always was. Not that a 'slow' malloc isn't the same kind of thing of course, but malloc has to be concerned about reusing spaces that have been freed, where adjusting the stack pointer has no such concerns. It's not a memory allocation.

# ? Jun 15, 2013 01:35

ExcessBLarg!: Sep 1, 2001

roomforthetuna posted:

Also, "grow and shrink the stack" is kind of misleading to someone who is mistakenly worrying about slow memory allocation - what you do at the start of the function isn't really growing the stack,

Many OSes provide auto-stacks which can grow beyond pre-allocated space via a page fault, much like the heap actually. But unless you're using tons of stack space (which is dangerous anyways), it's not something that happens often.

# ? Jun 15, 2013 02:42

Vinterstum: Jul 30, 2003

Ciaphas posted:

Would whoever decided the Oracle C++ Call Interface would not support asynchronous operations, despite the C interface supporting them just fine, please step forward so I can murder them? Thanks.

OCCI is a terrible, terrible thing and no one should use it ever. So is OCI for that matter, but at least you can build your own nice-ifying wrapper around it. Just not OCCI.

# ? Jun 16, 2013 23:08

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

I've heard good things about IntelliSense. Why can't it seem to complete its own sentences?

quote:

IntelliSense: more than one operator "+" matches these operands:

This was a real error I got. How does this deserve praise?

# ? Jun 17, 2013 07:25

mobby_6kl: Aug 9, 2009; by Fluffdaddy

C++ IntelliSense... is not very good.

# ? Jun 17, 2013 13:18

Rottbott: Jul 27, 2006; DMC

Presumably ctrl+F7 would have provided the rest. I usually disable Intellisense errors in the error list because they are generally a minute behind or irrelevant. It also annoyingly spams spurious errors from files you have open which are disabled on the current platform/config.

# ? Jun 17, 2013 18:18

raminasi: Jan 25, 2005; a last drink with no ice

Yeah, people jerking off over intellisense are talking about c#.

# ? Jun 17, 2013 18:33

bobua: Mar 23, 2003; I'd trade it all for just a little more.

As a person who programs that doesn't know how to program I can confirm that intellisense will pretty much write your program for you in c#.

If it suggested lottery numbers I would not be talking to you poor scrubs right now.

# ? Jun 18, 2013 03:21

Cat Plus Plus: Apr 8, 2011

Visual Assist X supposedly makes C++ IntelliSense much better.

Rottbott posted:

I usually disable Intellisense errors in the error list because they are generally a minute behind or irrelevant. It also annoyingly spams spurious errors from files you have open which are disabled on the current platform/config.

Still more problematic are IS errors that don't really exist in the code.

# ? Jun 18, 2013 10:39

Uncle Kitchener: Nov 18, 2009; BALLSBALLSBALLSBALLS
BALLSBALLSBALLSBALLS
BALLSBALLSBALLSBALLS
BALLSBALLSBALLSBALLS

I would much rather use Visual Assist than IntelliSense. It's the lesser of the two evils.

IntelliSense is a bit better in VS2012, but it's still nothing special.

# ? Jun 18, 2013 16:58

raminasi: Jan 25, 2005; a last drink with no ice

Visual assist X leaked memory like a sieve when I tried it in vs2010 but that was a few years ago and nobody else had that experience anyway, apparently.

# ? Jun 18, 2013 18:48

bobua: Mar 23, 2003; I'd trade it all for just a little more.

When I'm stepping through c++ code in vs2012, is there a way to get it to step through ONLY code I've written, or within a certain file? Just My Code option still steps through an library I'm using:(

# ? Jun 18, 2013 19:57

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 20:47

Zatheria: Apr 30, 2013

I actually quite love using Visual Assist X with VS2010 at work. The two most useful things I've found, aren't directly tied to code completion, but code navigation. Alt+G on a variable goes to the definition, ctrl+shift+O opens a window that you can open files in your project by typing part of the file name. Alt+O toggles between the header and the code.

There might be other addons for Visual Studio that already covers this, and in fact I'm sure Visual Assist does even more, but I've found it most useful simply for navigating a large code base quickly.

# ? Jun 19, 2013 06:43

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

«‹›640 »