|
why would you want to read it more than once ?
and the link doesn't care about .h files, are you talking about the compiler ?
'nyway... it's doing exactly what it's supposed to do
the #pragma once ( Microsoft specific ) will tell the compiler that this file can only be read once.
the #ifndef/#define/#endif construct ( portable ) will let the compiler read the file once, and define a symbol, and the next time the file is read, the symbol is defined, so it will not go thrue the rest of the declaration.
what kind of problem are you experiencing ? what do you want to do ?
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
i don't want it to read more than once, thats the problem
the Linker is giving me an error that a function in the .h is defined multiple times.
i thought that both the #pragma and #ifndef/#define/#endif shoudl prevent this, but they are not
|
|
|
|
|
out of curiosity, do you have something after the #ifndef and #define ?
#ifndef _MY_HEADER_H_
#define _MY_HEADER_H_
...
#endif
( I never use #pragma once )
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
yes, i included it in my original post, not sure why it didnt show, but will do again.
the header file is a group of commonly used functions, that i got tired of copying and pasting into all my apps, so i thought i could put them all in a central .h and #include them, hence..
#ifndef CommonFuncs_H
#define CommonFuncs_H
// functions
#endif
|
|
|
|
|
You're getting a linker error, not a compiler error, therefore the preprocessor directives aren't the problem since those are compile-time things.
The error says function foo() is defined multiple times. How could that happen?
a.cpp includes commonfuncs.h and sees the definition (and the code, IIUC) of foo(). Then b.cpp includes commonfuncs.h and sees the definition and code of foo(). Now you have two functions called foo() in your obj files.
Two solutions: 1) make the functions inline 2) move the code to a cpp file, leaving just the prototypes in the header.
--Mike--
Visual C++ MVP 
LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
Come quietly or there will be... trouble.
|
|
|
|
|
1) inline didnt work
2) not sure i did it right. tried it a few ways
i copied the function to a .cpp file of the same name. put just the prototype in the .h, like this?
int myFunction (int a, int b);
tried it once where i #included the .cpp in the .h, and once where i didnt.
also tried it where i put the functions in a .cpp and #included that directly, with no .h
nothing worked
|
|
|
|
|
i feel like it might help if i gave some more background info.
i've built a lot of programs in the past that required a Dialog box where you could plot a time-series, or a series of XY's, etc and zoom in and out, etc...
in the past, i would create a new class within each application, derived from CDialog, and add all the functions to it
after doing this a dozen times, i've gotten tired of all the copying and pasting, and tweaking to whatever the new app required. so i wanted to create an independent class that i could call from any app, without having to re-build each time. i created a file, GraphDialog.h, which looks like this:
class GraphDialog : public CDialog
{
public:
// member variables & functions
};
everything worked great until i wanted to do some callback functions (e.g. WM_LBUTTONDOWN). i created them using ClassView, which created a companion .cpp
the prob, i think, is that the .cpp file #includes the .h, as does MainFrm.h, furthermore, the app.cpp #includes MainFrm.h, so GraphDialog.h ends up getting called 3 times, and i see no way around this
one of the member functions wants to use a commonly used function that i placed in another external .h
when i try to #include that .h from GraphDialog.h that function shows up as multiply defined
thanks!!
|
|
|
|
|
Ok, think about this a bit. The problem is that you are ending up compiling the same function in multiple places, and then trying to link them together. The solution is to not ever have the same function defined twice. So you can do as Mike suggested and put all the functions in one .cpp file, build that, and let the linker reference them that way.
You do not need to #include the function definitions anywhere though. Just compile and link 'em in.
|
|
|
|
|
i'm trying to create an indendent class that i can call from any app, since i've been using these functins over and over again, and re-writing them each time.
i can't see any way to prevent the .h from being called twice, since both MainFrm.h and the associated .cpp file must both reference it.
i tried moving the functions that it calls to a .cpp, and that didnt work. if i did #include, then i get a multiple definition error. if i don't i get an undefined symbol
|
|
|
|
|
werfel wrote: i tried moving the functions that it calls to a .cpp, and that didnt work. if i did #include, then i get a multiple definition error. if i don't i get an undefined symbol
Don't #include the .cpp file. Never #include the .cpp file. If you're gonna #include it, name it .h, but you're not gonna include this, so don't. Compile the cpp file. Link the cpp file. Add the .cpp file to your project, and let DevStudio worry about compiling and linking it. In short, treat it like all your other .cpp files!
|
|
|
|
|
I think he needs to learn about static and/or dynamic libraries. 
--
Pictures[^] from my Japan trip.
|
|
|
|
|
The first thing I would do is (ummm) make sure it's not really defined multiple times. Search the files, Luke...
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
|
The guards prevent compiler to read the header file multiple times, but if you have something defined (as opposed to declared) in a header file which is included from several cpp files, the guards cannot help you with that.
For instance if in your h file you have something like
int add (int a, int b) {return a + b;}
and include it from multiple cpp file, you'll get linker errors. To avoid it in this specific case, you'll need to declare the functionsl inline:
inline int add (int a, int b) {return a + b;}
and it should work fine.
My programming blahblahblah blog. If you ever find anything useful here, please let me know to remove it.
|
|
|
|
|
|
static inline will work, or something is really broken with your code and/or compiler.
Anyway, why do you want to write function bodies in your header files? It's one ingredient in the recipe for code bloat...
--
Pictures[^] from my Japan trip.
|
|
|
|
|
i think you're right that my code is seriously broken. i am entirely self-taught, and this is my first attempt as creating a portable class.
i'm putting a class definition in the header. isn't that where they're supposed to be?
some of the class members are accessing functions that i use for other programs, that i'd be just as happy placing in a .cpp, but i cant make that work either. for one thing, i would then have to #include the .cpp in the .h, which i understand to be a big no-no.
|
|
|
|
|
 werfel wrote: i'm putting a class definition in the header. isn't that where they're supposed to be?
You can do that, but then you'd have to tag the methods with inline, or put the method bodies within the class. It's easiest to do the latter. Kind of like C#:
class X {
void method() {
}
};werfel wrote: i would then have to #include the .cpp in the .h, which i understand to be a big no-no.
Indeed! What you need to investigate is how to create static (.lib) or dynamic libraries (.dll). A good start is learning how to use and create static libraries, since there are less details to keep in mind.
Basically, a library consists of two things: header files and a .lib-file. The header files instructs the compiler at compile time that the classes and functions are available for linking. The .lib file provides the actual code and data for the linker, so that the names referenced in the header file will be bound to the corresponding code and/or data.
One could say that the linker is the part of the compiler toolkit that puts all the pieces together. The pieces are typically .lib and .obj files. The .obj files are produced by the compiler for each compilation unit. In a C++ project, the .cpp files are compilation units. If you have #included code bodies (such as functions, not prototypes) into several .cpp files, the linker will find duplicates of the code. Since the preprocessor is basically a cut'n'paster (#include basically pastes whatever is in the inluded file), the linker can't know that the found duplicates are the same. It will have to refuse linking. This is the linker error you got.
--
Pictures[^] from my Japan trip.
-- modified at 14:59 Sunday 18th December, 2005
|
|
|
|
|
I have created a simple media player for .wav files and want to add a scroll bar to speed up or slow down audio as it is being played. (By up to max +5% and -5% only). Any ideas on how I can achieve this in c++ or vb.net? Any help would be much appreciated.
Hedphoniks
|
|
|
|
|
Hello All, I am working in C++ (6.0) for the first time. I am a C#/VB.NET web developer so I feel well over my head.
I got the sample Hello World sample windows app to work, but I need to basically do the same thing only I am writing a DLL instead of an executable. Essentially, I am trying to write a plug-in for another application.
Any sample code, good starting urls would be greatly appreciated. If you evern need help in the ASP.NET world, I will kindly return the favor.
-James
___________________________
J A M E S C O L E M A N
Practice Director, Microsoft
AGENCY.COM
jcoleman@agency.com
http://www.agency.com
|
|
|
|
|
Is it just me, or does this seem like overkill to detect an empty string...
if( strcmp( szPossiblyEmptyString, "" ) == 0 )
No shirt, no shoes, no brains, no service.
|
|
|
|
|
Yes, I usually do
if (!(*szPossiblyEmptyString) )
But this maybe not very readable.
Igor Green
http://www.grigsoft.com/ - files and folders comparison tools
|
|
|
|
|
if (szPossiblyEmptyString [0] == 0)
That works fine for testing for an empty string. If you also want to test for a NULL pointer
if (pszString == NULL || pszString [0] == 0)
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote: if (pszString == NULL || pszString [0] == 0)
That's a good habit, in case one has to work with BSTR strings.
--
Pictures[^] from my Japan trip.
|
|
|
|
|
Definitely superfluous. 
"Take only what you need and leave the land as you found it." - Native American Proverb
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
