What is the best way to have your project set up for a large project (and a few Qs)

Started by
13 comments, last by skilofreak 22 years, 1 month ago
I am working on making making a first step toward a game, and i need to know what the best way to set up you project as. the way im doing it now i am excluding all cpp files from the build except for my one with the main in it, and doing #ifndefs in the h file then before the #endif including the cpp file. (currently all the files are in my project as well) like so:

#ifndef _DEBUG_H_
#define _DEBUG_H_

//class

#include "Debug.cpp"
#endif
 
and currently then i include the .h file from the cpp file (im not sure if i needed to do that). also do i need #ifndef in my cpp files too? i think the way im doing it will work, but im getting an odd error that say basiclly "constructors cant return a value" my prototype is in my .h under public: DebugClass(); and my implamintation is in the cpp:

DebugClass::DebugClass()
{ //error points here  but i bet the problem is on the line 
  //above

  //one line of code (not a return) here
}
 
im guessing that the way im setting up the project is the problem so any help would be appriciated. also (just out of curiousity), I was wondering if fstream is different in the win32 envirnment than in the conolse (i just want to output to a file, but it didnt have the open() function). Is there anywhere online where i can learn howto use the win32 project version if there is one?
Advertisement
quote:Original post by skilofreak
I am working on making making a first step toward a game, and i need to know what the best way to set up you project as.

That''s subjective.

quote:
the way im doing it now i am excluding all cpp files from the build except for my one with the main in it, and doing #ifndefs in the h file then before the #endif including the cpp file.
(currently all the files are in my project as well)

You mean include guards.

quote:
#ifndef _DEBUG_H_

Drop the leading underscore - it''s illegal.

quote:
and currently then i include the .h file from the cpp file (im not sure if i needed to do that). also do i need #ifndef in my cpp files too?

It depends on whether you are #include''ing cpp files. I''d guess not.

quote:
i think the way im doing it will work, but im getting an odd error that say basiclly "constructors cant return a value"

Nothing odd about that, it means what it says.

quote:
DebugClass::DebugClass()
{ //error points here but i bet the problem is on the line
//above

//one line of code (not a return) here
}

Are you sure you don''t have a missing semicolon before the ctor?

quote:
also (just out of curiousity), I was wondering if fstream is different in the win32 envirnment than in the conolse (i just want to output to a file, but it didnt have the open() function).

No, no difference. What do you mean, it doesn''t have the open() function? Of course it does!
quote:Original post by SabreMan
That''s subjective.


well its more of a utility to test an idea out i have for when i actually start working on the game, so yes it is a the beginings of a game in a way.

quote:
You mean include guards.

sure if thats what you want to call them, i didnt want to use a generic term to make sure anyone could see the code I was using

quote:
Drop the leading underscore - it''s illegal.

well if you mean the first one, its perfectly valid (thats used in almost every include ive ever seen). if you mean the last one, that was a typo its not like that in my code

quote:
It depends on whether you are #include''ing cpp files. I''d guess not.

the only place i include my cpp is at the bottom of its .h file in the include guards


quote:
Nothing odd about that, it means what it says.


i know what the error means, but i incuded the code along with it for a reason, i dont see where i am returning anything, yet it still get the error, that was the question at hand.

quote:
Are you sure you don''t have a missing semicolon before the ctor?

well as far as i know my code should all be valid (im very comfortable with using oop and its structure), my only thought is the way in doint the including is what could somehow be cuasing this error.


quote:
No, no difference. What do you mean, it doesn''t have the open() function? Of course it does!


well, i made an ostream, yet open was not one of my choices plus it gave me a syntex error(had sometheing like open_mode, but no open like it should have) and i noticed that there (apon inspection of fstream, that it includes a file called oldio.h or something simular do that based off some macro (didnt really look at it for more than secounds) so i assumed that that is what it used for a console app, but still no open to be found in my win32app when i use it though...

quote:Original post by skilofreak
sure if thats what you want to call them

It''s what the C++ world calls them.

quote:
well if you mean the first one, its perfectly valid (thats used in almost every include ive ever seen).

No it''s not, it''s illegal. MS get it wrong.

quote:
the only place i include my cpp is at the bottom of its .h file in the include guards

That''s unusual. Any reason? Do you have templated code in there?

quote:
i know what the error means, but i incuded the code along with it for a reason

There is nothing wrong with the code you posted. The problem is elsewhere.

quote:
well, i made an ostream, yet open was not one of my choices plus it gave me a syntex error

You mentioned fstream earlier. fstreams are in fstream, ostreams are in ostream. ostream does not have an open() method because it isn''t connected to a file. That''s what filestreams are for. I suggest you use ofstream, declared in fstream (NOT fstream.h).
quote:
You mentioned fstream earlier. fstreams are in fstream, ostreams are in ostream. ostream does not have an open() method because it isn''t connected to a file. That''s what filestreams are for. I suggest you use ofstream, declared in fstream (NOT fstream.h).


oh thanks!, i ment to to do ofstream from the start. I dont know how i made that mistake :|


oh and the reason i include the c++ at the bottom of the header in the include guard is that i dont have my cpp files other than the main on in the build (so in therory it is like the cpp file isnt in the project, as if it was an external dependicy rather). The design seemed questionable from the start, so thats the main reason i posted this thread to begin with.
There''s almost never any reason to #include a .cpp file. What''s the point? Just build them all separately. If you claim to be comfortable with object orientation, you should be ok with the idea of modularity - and if you #include everything in one big lump, then you are effectively mashing all your modules into one.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]
quote:Original post by SabreMan

#ifndef _DEBUG_H_

Drop the leading underscore - it''s illegal.


I''m curious, why and where does it state that it is illegal?

Leading underscores are supposed to be used by compiler so _DEBUG would be illegal, but _DEBUG_ wouldn''t and shouldn''t.
quote:Original post by Void

I''m curious, why and where does it state that it is illegal?

Leading underscores are supposed to be used by compiler so _DEBUG would be illegal, but _DEBUG_ wouldn''t and shouldn''t.


That''s exactly it, identifiers with leading underscores are reserved for the compiler.
I use
#ifndef _HEADER_H_
#define _HEADER_H_

on all my projects, on multiple platforms, with different compilers, and have never had a problem. So it''s not "illegal", or the compiler would reject. Unrecommended might be a better way to say it.

Take care,
Bill



quote:Original post by Siebharinn
#ifndef _HEADER_H_
#define _HEADER_H_

on all my projects, on multiple platforms, with different compilers, and have never had a problem. So it''s not "illegal", or the compiler would reject. Unrecommended might be a better way to say it.

The compilers you use do not define the C++ Standard, which states this as being illegal (the convention is reserved for the implementor). You have a misunderstanding of what "illegal" means in terms of the Standard. It doesn''t necessarily mean the problem has to be diagnosed by the compiler.

This topic is closed to new replies.

Advertisement