Those MFC macros tend to barf on anything that''s not REALLY straightforward code. I suspect you could trace the problem if you looked up the definition of those macros in the windows header files.


Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.

quote: Original post by MadKeithV

Can you post an absolutely minimal set of files to generate this error, because I absolutely haven''t a clue what you are talking about..

Damn, again... there was a big ass argument about this before. Anyway, write a header file that defines a function, like:

int function (int i)
{
i++;
return i;
}

now, include this header file in multiple source files and see what happens. That is what I''m referring to.

REMO: Are you putting DECLARE_MESSAGE_MAP () in the class declaration? If so then I don''t know wtf is wrong.



-BacksideSnap-

I just made an example of this in VC++. If anyone still doesn''t beleive me or wants to see what I''m talking about just yell and I''ll send you the example project. And yes, it''s using #ifdef and #define.

-BacksideSnap-

BacksideSnap, about the octree stuff. Not sure when it will be up, I have been busy with work so I can''t really stick a date on it. Hopefully today I can do some more work on the view frustum culling and start adding collision detection.

Nate Miller
http://nate.scuzzy.net

quote: Original post by -BacksideSnap-


REMO: Are you putting DECLARE_MESSAGE_MAP () in the class declaration? If so then I don''t know wtf is wrong.

-BacksideSnap-

Don''t patronize me!

no, MadKeithV is right, it is just micro$oft begin shit again. if anyone is interested, if ever you should want to use a message map on a nested class, the problem lies in that for some reason the ON_WM_x() macros just assume you''re talking about the nearest class to the code, or something like that - you need to modify all the ones you want to use so that you can specify EXACTLY which class it is.

all this has given me a new idea for a programming language - one where the source files are essentially hidden from the programmer by the IDE, and all the user sees is a sort of tree of code stemming from one overall class, so that the programmer is forced to organise his code into a nice, hierarchical tree, much like Java packages but to a larger (or more smaller, i.e. more detailed depending on how you look at it) scale.

Just imagine it, no rogue functions floating around in empty space which are only used once by the next function in the file and can''t be used from anywhere else, COMPLETELY modular code structures and the ability to call anything from anywhere, and incredibly fast code compilation, because eventually all the source code would be arranged into ONE, yes ONE source file.

And NO irritating header files to update every time you want to create a new function.

I will call this language C+=2.

MY GOD, I''VE DONE IT AGAIN
yes that message was from me

What is the argument about?

1. Inlined functions must be defined in each .obj file where they are called, so it makes sense to simply define it once and put it in the header file.

1.a Defining outline functions in multiple .obj files will get you irritating linker errors.

1.b The reason why functions defined in the class definition are automatically inlined is to avoid those irritating linker errors.

2. Big functions in class definitions look terrible and are a real mess to wade through. If you don''t believe me, I can send you some of my source code.

3. Separating .hpp and .cpp files makes the project easier to manage and is invaluable for libraries. Imagine if every time you re-built your library you had to make a copy of the headers, delete all of the function definitions, and then change the dllexport to dllimport. Checking through all the function definitions to find the declarations would kill you.


Some rules of thumb that I use:

1. Define the class in the .hpp file.

2. Define the class functions in the .cpp file.

3. Every header should #include all of the headers necessary for the class definition.

4. Every .cpp file should #include its corresponding header file, plus any extra headers that the class function definitions require.

5. Add a pre-compiled header to the project that contains external class defintions and function prototypes (like headers from a library), which are not subject to change.

6. Oh yeah, use the #if !defined(), #define, #endif method to keep the headers from being included multiple times each .obj file.

The method:


#if !defined(my_header_file_name)
#define my_header_file_name

// #includes, class definitions, function prototypes

#endif // !defined(my_header_file_name)




- null_pointer
Sabre Multimedia

But I think you''re still missing a piece Remo. You have 1 source file, which includes a huge amount of code from all the header files. Your headers are basically what others have in their cpp files. So you are compiling EVERYTHING when you compile your single cpp file. In normal projects, the compiler only compiles things that change, which may just be 1 cpp file, and then relinks it. So it only compiles 1 file, where your''s compiles every file.
There is no way your final 30000 line cpp file (after headers are included) can compile faster than a 400 line source file that is normally rebuilt, except in the rare instance that you rebuild the entire system, in which case your method should be faster.

Rock

I am well aware of that, and i'm not missing the point.

The fact is that the bulk of .obj compilation time is spent on #include <windows.h>, and there are well over 30,000 lines of code in all of that + <stdio/lib.h>, <math.h> etc.

I am not talking about using this approach for libraries, this is for a game. And regardless of what you all say I have found no linker errors, no problems trawling through lots of code (well, no more than in .cpp files), no slower compilation and almost no problems with classes not being able to see each other.

About this last problem, you can't avoid that. It is impossible to have:

    class A{  B m_cVariable;}class B{  A m_cVariable;}    

in absolutely any way, using .CPP and .H or WHATEVER. (actually I would quite like someone to prove me wrong on this, so that i can use it )

ok? so stop telling me about all these problems I am encountering because I haven't encountered a single one!

Edited by - remo on July 28, 2000 4:28:26 AM

Try forward declarations. Not used them, but something like this should work.

class B;class A{      B m_cVariable;}class B{    A m_cVariable;} 

Mike Roberts
aka milo
mlbobs@telocity.com