Public

**Helix** · 07-26-2003

Hello world.
How can I make a struct declaration in a C++ source file public? (for use in another C++ source file within the same Win32 DLL project)

**bennyandthejets** · 07-26-2003

Declare it in a header file that is #included by both source files.

**confuted** · 07-26-2003

To elaborate on what benny just said... have your header file look like this

Code:

#ifndef structheader
#define structheader

/* struct definition goes here */

#endif

This avoids the problem of the file being included multiple times.

**Helix** · 07-26-2003

Yeah, I figured that out but there's one little problem left ... I was exporting functions from those source files. Since I changed them into headers the functions no longer get exported - I get "unresolved definitions" or smth like that.
Is it possible to export from .h files (using *.DEF)?

**Korhedron** · 07-26-2003

What do the #ifndef, #define and #endif declarations do ?

**bennyandthejets** · 07-26-2003

Helix, do you mean to say that you placed your function definitions in a header file? Only funtion PROTOTYPES should be in header files. The actual functions should be in the source files.

**HybridM** · 07-26-2003

Korhedron, What they do specifically is, the compiler checks to see if structheader is defined, if it is, then that means the file has been included once already, if structheader is not defined, then the compiler defines it, and includes the stuff in that header.

**Korhedron** · 07-27-2003

STRUCTHEADER, in this case, being a .h file ? Why not include it using #include ?

**bennyandthejets** · 07-27-2003

Korhedron, HybridM is referring to the method of using preprocessor commands to prevent multiple declarations, ie, errors.

Eg:

You have two source files. Each one #includes the same header file, blah.h.
If the compiler runs the header file code twice, the same structures, classes, functions, etcetera, will be declared twice. So, these commands are inserted in the header file to ensure that it will only be run once.

Code:

#ifndef thisHeader //if this header isn't run yet
#define thisHeader //then define it as being run

//declare all your stuff here

#endif

Note that thisHeader can be any unique name.

What happens is, the first time the header is included, the name thisHeader is not defined. Therefore, the name is defined, and all of the structures etc are declared. The next time the header is included, and all subsequent times, it skips everything and goes right to the #endif line.

It's a very good way to organise your code if you have more than one source file.

**Korhedron** · 07-27-2003

I'm not seeing how you'd declare something twice except if you have three sources, in which you include one code, then include that one and the first one in the third code... :P Example :

Code:

// header1.h
void blabla();

Code:

// header2.h
#include "header1.h"
void afunction();

Code:

// header3.h
#include "header2.h"
#include "header1.h"
codehere();

This would mean that header1.h is included twice. Is this what you mean ?

**bennyandthejets** · 07-27-2003

No Korhedron, I mean exactly what I said in my post:

You have two source files. Each one #includes the same header file, blah.h.

A source file is a .cpp.

Eg:

Code:

//main.cpp
#include "main.h"

int main()
{
}

Code:

//clsTree.cpp
#include "clsTree.h"
#include "main.h"
class clsTree
{
};

Code:

//main.h
#ifndef mainHeader
#define mainHeader

int main();
LRESULT CALLBACK WndProc();

#endif

You see what I'm getting at? Both source files (main.cpp and clsTree.cpp) include main.h. Without any preprocessor commands (#ifndef, #endif, #define), all the declarations in main.h would be run twice. With the preprocessor commands in, it can only be run once per compile. Brilliant ey?

**darksaidin** · 07-27-2003

Without any preprocessor commands (#ifndef, #endif, #define), all the declarations in main.h would be run twice. With the preprocessor commands in, it can only be run once per compile. Brilliant ey?

To me it always seemed like nothing more than a workaround for a compiler misconception. However, I admit that my opinion may be a bit biased since I never had to use headers. I think they are a pain.

edit: thanks cat

**Cat** · 07-27-2003

Actually, bennyandthejets, that's half true but you're still mistaken. Each .cpp file is a separate compilation unit -- main.h will be put within main.cpp when main.cpp compiles, but this will happen only once. main.h will also be put into clsTree.cpp when it compiles, but again not more than once.

If duplicate symbols arise that are identically defined, it's the linker's job to merge them. In this case, main.h probably has only function declarations and class definitions, which could be included in other compilation units without a problem anyway. In that one case, the include guards do nothing.

Korhedron, that scenario happens a lot more than you'd think. For example, I was working on a library recently, and most of the headers include headers defining LibObject and LibException, so include guards are critical. And, in any event, your code shouldn't break if someone just #included your header twice.

**Cat** · 07-27-2003

Originally posted by darksaidin
To me it always seemed like nothing more than a workaround for a compiler misconception. However, I admit that my opinion may be a bit biased since I never had to use headers. I think they are a pain.

I got a question, though: In your example code, clsTree.cpp includes main.h . How does main.h know where it's implementations are? Does the compiler search for a file with the same name as main.h but a .cpp extension or how does it work? (I'm not questioning your code, I know it works, I just don't understand how.)

The compiler does nothing of the sort. The compiler goes through each .cpp file. When it finds an #include, it just does the equivalent of copying/pasting the entire .h file into that location in the .cpp file. It then compiles the .CPP file, and produces an .obj file. When some piece of code calls a function that isn't defined in that particular .cpp file, the compiler simply "makes a note of it" and moves on.

The linker happens next. It takes all the .obj files, and all the libraries, and tries to make all the function calls work. E.g. say main.cpp tried to call a method called "bool MyClass:Func1(int)", but that function wasn't in main.cpp. The compiler made a note of this, and it's the linker's job to search for the compiled version of that function (in any of the .obj or library files). If it finds it, it adjusts the compiled code from main.obj so that it jumps to the right address in memory. The linker creates the final .exe if it could find all the functions; otherwise, it gives an "unresolved external" error and terminates.

**HybridM** · 07-27-2003

You should be on the ISO commitee Cat. You seem to know everything!

Thread: Public

Thread Tools

Search Thread

Display

Public

Similar Threads

Reading Process Memory

OOP Question DB Access Wrapper Classes

Linking problems in Visual Studio

Stuck with Structs...

C++ std routines