oops... the above message is from me!

yet another thing i''ve noticed:

    // from FSWND.Hclass CFSWnd : public CFrameWnd{public:   void Create (char *title)  {    (static_cast<CFrameWnd*> (this))->Create(NULL, __FILE__);  }}    

This is in a header file, and when it is called by a .cpp file, the title of the window is ''fswnd.h''... but maybe this is just a feature of MSVC so that asserts can be traced into inlined functions.

But consider this. InitInstance(), the main member function of CApplication can be defined inside a header. However, the function is called from either a LIB, or i think possibly even a DLL. In this case how can it be inlined???

I dunno, if only that sodding multi-national, $bn company we all know and hate would document their products properly.

quote: Original post by Anonymous Poster

well i don''t agree with -BacksideSnap-... you don''t linker problems if you arrange it properly.

It doesn''t matter how you arrange it... Argggh, I don''t think we''re talking about the same thing. When things get defined multiple times the linker complains, that''s all I''m saying. Say you define a function in a header and include that header in multiple source files within a project. You will get warnings and the thing won''t build. Try it.

-BacksideSnap-

Thats what a #ifndef, #define, #endif group is for.

Nate Miller
http://nate.scuzzy.net

Well, there would still be a linker error if you had more than one cpp file, and some functions weren''t inlined (but in this situation I guess you''re commiting to only have 1).

But with this approach you would never be able to build libs or dlls. I think its extremely useful to use these to separate out large pieces of the code, and to be able to reuse them without recompiling them for every project.

And I can''t believe that this will compile faster for anything but very small projects. If you''re saying that each class gets its own header file, than the compiler will have to compile ALL the source code every time you do a build. Event precompiled headers will only avoid building the first header, but still compile all the rest. Unless you have all the headers included in a separate, master header file, which would avoid compiling the headers, but only if NONE of the headers were changed, which I would think would be very rare. This type of approach would be unworkable on large, multi person projects. It may do a Rebuild All faster, but I can''t imagine it will ever come close using a normal Build approach.

Rock

quote: Original post by Nate

Thats what a #ifndef, #define, #endif group is for.

Nate Miller
http://nate.scuzzy.net

Nope, you will still get a linker error. Try it. I''m taking about definitions, not declarations. I actually got into an argument in some thread about this a while ago... funny how the same topics always come back up. When is your octree thing going to be up, BTW?



-BacksideSnap-

no, not everyone here seem to understand what i''m talking about.

I agree, that if you have a typical project with say, 20 or so cpp files with around another 15 or so headers, yes, keeping classes in their own header is a crap thing to do, for the reason that every time you modify it you have to recompile every module.

I am talking about a different way of organizing your code... in the project there is ONLY ONE CPP FILE (maybe now that this is the 3rd time i''ve said this people will understand). The headers contain all the code, and they are #included into the cpp file to make one module (.obj file) for the project.

I have been experimenting with something like this and I have found it''s incredibly powerful - there is a feature in MSDEV to turn off inlining, so I am no longer concerned about that. About the header inclusion order - i.e. class A being able to see class B, but B not being able to see A - i have found a way around that: nested classes. You can actually have a #include statement within a class definition, so you can arrange the code however you like.

As for #ifdef #endif #ifndef #define and so on, yes it''s true that they are the standard way to go about not re-defining functions hence getting linker errors - but you don''t get linker errors when there is only ONE obj file to link to libraries!!!

I am pleased with the way it''s going with the header class definitions and I think i''m going to carry on like this. Also, by sheer coincidence the compiler rules the Micro$oft put into C++ force you to keep your code tree (because that is what spontaneously happens with nested classes) very very neat. Basically you end up with a very well organized code structure.

An example, is that you can call something like Game::DirectX::DirectDraw::Initialize (640, 480, 32); from almost anywhere in the code. Also, if you include a system header into file A, it is automatically available to all the files which are included into file A. So if you define a macro in the main.cpp file, ALL of the headers which contain the code can access the macro

it''s hard to explain but it''s very useful, and it DOES compile much quicker.

oh bloody hell i''ve done it again... the above message is from me.

(actually it''s cause if you press backspace it takes you to the previous page, and when you go forwards it keeps the message but deletes your username and password)

quote: Original post by -BacksideSnap-
Nope, you will still get a linker error. Try it. I''m taking about definitions, not declarations.

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..




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.

just a quick message - does anyone know how to use:

BEGIN_MESSAGE_MAP (class, baseclass)

where class is a nested class?
what i have tried so far is:

    BEGIN_MESSAGE_MAP (CFSApp::CFSWnd, CFrameWnd)	ON_WM_KEYDOWN ()	ON_WM_KEYUP ()END_MESSAGE_MAP ()    

but this generates a whole slew of compiler errors:

quote:
c:\fs\dev\fsapp.h(37) : error C2327: ''CFSWnd::OnKeyDown'' : member from enclosing class is not a type name, static, or enumerator
c:\fs\dev\fsapp.h(37) : error C2065: ''OnKeyDown'' : undeclared identifier
c:\fs\dev\fsapp.h(37) : error C2440: ''type cast'' : cannot convert from ''int *'' to ''void (__thiscall CWnd::*)(unsigned int,unsigned int,unsigned int)''
There is no context in which this conversion is possible
c:\fs\dev\fsapp.h(38) : error C2327: ''CFSWnd::OnKeyUp'' : member from enclosing class is not a type name, static, or enumerator
c:\fs\dev\fsapp.h(38) : error C2065: ''OnKeyUp'' : undeclared identifier
c:\fs\dev\fsapp.h(38) : error C2440: ''type cast'' : cannot convert from ''int *'' to ''void (__thiscall CWnd::*)(unsigned int,unsigned int,unsigned int)''
There is no context in which this conversion is possible

but CFSWnd::OnKeyUp and OnKeyDown definately exist!