Sorry C/C++ lovers for the provocative title, I know better than to blame the language for my mistakes.

Anyway, to avoid the "multiple definitions"-errors aswell as the "no definition"-errors for my classes, I tried to add this:


In all my .cpp files in a project. If I only have the definitions in main.cpp I get errors saying they're not defined. The problem is that the preprocessor doesn't seem to care about those instructions, including them in every file, causing the multiple definitions error.

I'm using Dev-C++, by the way.

Is the error happening when the linker runs? If so, that would make sense because every object has these defined, and when the linker runs to link the objects together is were "multiple definitions" will occur.

When you only have them in main (for the not defined error) that typically means that it doesn't about the obj_* types to which you declare. This may mean two things:

1. you have this #ifndef block positioned in the file before the #include's that define the types, or
2. main has no clue (or use) of these declarations?

What are you trying to accomplish -- have one set of these declared globally somewhere? or something else?

Yes, the error occurs during linking and yes, I'd like to have these globally declared. I don't see however how that error makes sense. Only one file ought to have those objects declared unless the preprocessor doesn't keep the definitions when starting to work on another file.

Well, main only uses one of them so far.

EDIT with startling discovery: I tried commenting (/* like this */) the
but the compiler doesn't seem to care about that and preprocesses it anyways. I had to delete the whole part for it not to multiple define again.
Leading to the not defined-error, of course.

I'd strongly recommend rethinking the use of globals, however, there is an easy solution.


...and then in your main:



:davis:

Wow, I learn something new every time I come here, it seems. I didn't even know of that command. It even worked and stuff, thanks!

I am having the same problem, why is using globals so bad. Passing the same variables to every function is not only annoying and difficult to look at, but time consuming especially if you need to change the variable type.

In my program many of the .h files #include each other because they are all related. Isn't there any way to have global variables that they all use with being (*gasp*) global variables?

By the way your extern thing doesn't seem to work at all. I suppose I'll show the includes of my headers. Keep in mind, even though there is a file called globalvariables.cpp, I moved some of the globals into the files they are associated with (the item list must be used with Item.h, so it's declared in that file).









WHY WON'T IT LINK!

I respect your opinion. Here's my opinion: If I have a global variable used in many functions, and I change the variable type, how do I remember which ones use the variable and how do I make sure that I change whatever needs to be changed everywhere it needs to be changed? For me, debugging is more annoying than typing parameters into function calls.

I think that there are some places where globals are appropriate, but the "annoyingness" factor doesn't affect my personal decision to use globals. Your Mileage May Vary.
Variables can be shared among functions in the same source file by declaring them "static" within that file. They will not be visible outside that file. (The good points and bad points of having shared variables are now confined to that source file.) Note that if they are declared static in a header that is included by another file and that other file doesn't have variables with those names, you will have compiler warnings (or, in some cases, maybe even errors, depending on how strictlly you set your compiler flags).

Compilers that enforce current standards will not let you declare a function in a header as extern and then declare it static inside the file itself. You might get away with it, but why would you want to? It's either static or non-static.
The "extern thing" shown in previous examples works as advertised if you follow the rules. If it doesn't work, then it's your "extern thing" that doesn't work, not anyone else's. I give an example that works (for me) in my response to your post in the C++ forum. I show all files in a project, and indicate how to compile and link them. I try to list the rules. If you don't understand the reason for the rules, or you think it should be different, I'm sorry. They are still the rules.

There are other ways to get things to work, but if you start with something that works and you change it and it doesn't work, then you are in a pretty good position: you have a fallback position that works.

My suggestion: start with an example that works. Modify it to meet your needs. Then its: Onward and Upward!

Regards,

Dave

"Laissez les bons temps rouler!"

I don't know how to improve upon what Dave said except maybe to explain some of the reasons why globals should be avoided. However, these are nothing new. One thing that I would like to add is that novices write software that attempts to solve a problem. Experienced programmers try to write software that solves problems, but also fits inside their "tool boxes" so that they have reusable elements of code that accomplish functionality so that they don't have to rewrite the same code over again the next time that they need it.


:davis:

Thanks for posting both of you. I've since learned that's it's not the ifndefs that aren't working because I didn't realize that they actually don't do what I thought they did. I can understand why writing global variables is "bad" but it seems to me to just be a convention thing. If you think about it, why would globals exist if they weren't meant to be used? However I do see your point on reusability, and long compile times (I've seen true programs take upwards of ten minutes per compile). However for what I'm doing, as a novice, a compile takes about 3 seconds, and I doubt I'll be using this code in any other program, as by the time I decide to start any program similar, I would have taken more classes and most likely learned much better ways of doing things.(The program I'm working on actually is in it's second version. The first used primitive arrays, now I have it using vectors and maps. You see what I mean.)

However thank you again for clearing some of that up. I seem to get a lot of criticism for using globals, yet again, for my program, it suits me much better. May it now be said that I never have used globals in any other program I've done, except for test programs in an entry level computer science class.