c++ code cons/pros

Question

below i have a code that runs in most of my simple programs .. .
i want to know if it's good/bad ... and cons/pros .

.
win32 header file: win32.h

// example of a not realated code to exaplin the question
// this header have all win32 includes like win/proces/stdarg/string ... etc
#include <windows.h>
#include <process.h>
#include <stdarg.h>

main header file: inc.h

//this file includes the following

//top : the windows header file
#include "win32.h" // include the win32.h header file 

//the extern define which is the question
//the first include cause the INCS to be defined 
//any include afterwards causes the DD to go from 'nothing' into 'extern'
#ifndef INCS
    #define INCS
    #define DD
#else
    #define DD extern
#endif

// unrealted code to be more informative
//middle area of the file have the variables /defines or w/e
#ifndef VARS
    #define titlen L"my program"
#endif

DD wchar_t gtitle[512];
DD wchar_t gclass[512];
DD wchar_t gdir[32767];

//last area of the file
// this bottom area have the project's files' all included all headers and code
#include "resources.h"
#include "commonfunctions.cpp"

then all files have something like this commonfunctions.cpp

//a code just to be more informative and it's not realted to the question
#include "inc.h" // no need for includings ?

DD inline bool icmp( const char *String1, const char *String2 )
{
    if ( _stricmp( String1, String2 ) == 0 ) { return true; }
    return false;
}

DD inline bool scmp( const char *String1, const char *String2 )
{
    if ( strcmp( String1, String2 ) == 0 ) { return true; }
    return false;
}

---

DD refers to the #define DD extern

all global variables have DD infront of them and all functions/subs have DD too, that will cause the functions to be defined as extern in all file when included for the second time

is there a bad side of this ? . i came up with this idea and it wasn't problematic at all in small programs . but before i apply it in a large project will it be problematic ?. .

.

Now to the Question

DD here means the #define DD extern
DD will remove the need to do a psudo outside the code or in headers
DD will remove the need to define extern variables in each page
DD will remove the need to do the #includes of each header in each file

Now will this DD that is demostrated in the code upthere be a problem in a bigger code ?

edit:
i edited the question to be more clear

thanks in advance.

Answer 1

Why are using char * instead of C++ strings? And why are you writing your own wrappers for standard functions? None of this is a good idea.

Furthermore, if you want to return value of some condition you should do it like this:

return _stricmp( String1, String2 ) == 0;

rather than using an if.

Inside your header files always put guards, like this:

#ifndef HEADER_NAME_H
#define HEADER_NAME_H

/* code */

#endif // HEADER_NAME_H

This way you will never include it twice.

In C++ there is not reason to use #define to define consts like you do:

#define titlen L"my program"

Instead use simply const keyword:

const std::string titlen = "my program";

Answer 2

I think you are trying to automate the declaration of globals with extern and the single declaration without.

a) it is much simpler to have plain 'extern' in the header files and just have a cpp file called gtobals with the declarations in it

b) you dont need to do this for functions

Answer 3

Get out of the habit of using global variables. For toy projects they are fine, but once you start working on something a little larger & more complex, you invariably run in to design problems:

1) Your buffers are an arbitrary size and are wasteful of memory. In some cases they may not even be large enough. 2) Objects in the global namespace will collide with other things in the global namespace. This is never a problem until you get deep into a project, and then it becomes a big problem that is very hard to fix. 3) Global variables are very difficult to make thread-safe in a way that isn't brittle.

Answer 4

You've already discovered that it's possible to write code like this, but ultimately I don't think you'll find that it helps you any when writing any but the most trivial of programs.

What does DD mean? Will it make sense to anyone else reading the code?

You can also do

wchar_t titlen = L"my program";

inside your implementation file, and there's no particular need to have that bit of information in the header file.

Generally speaking, I like to follow the guideline of giving only as much information to any given scope as is absolutely necessary. Outside users of this header file don't need to know what your program's name is, they just need to know how to access it. Ditto with the arrays, they don't need to know how big they are, just what their names are.

Plus, I wouldn't advise putting "big" headers inside your own headers. E.g. including in a header might seem easier, but it'll make compiling your program take longer for no particular reason.

header:

extern const wchar_t titlen;
extern wchar_t gtitle[];
extern wchar_t gclass[];
extern wchar_t gdir[];

implementation file:

#include "win32.h"
#include "resources.h"
#include "commonfunctions.h"

const wchar_t titlen = L"my program";
wchar_t gtitle[512];
wchar_t gclass[512];
wchar_t gdir[32767];

Put the inline functions in your header, but you don't need to make them 'extern'. Making them 'static' however can help your link times and may reduce the size of your executable.

Edit: Put another way, yes, what you are doing is bad and it will cause you problems in any real projects.

Answer 5

Hmm, this is in part a matter of personal style, but in my opinion your approach will lead to fragile projects. In particular the concept of having a common include file means that every module now has a dependency on an amorphous blob of includes, whether they need them all or not. This can lead to very hard to debug compilation or even application errors.

While it is more to type up front, in the long run it is much more maintainable to have every module include just those files it actually needs. Similar, it is more maintainable to declare the identifiers in an include explicitely marked 'extern', and write out the definitions in the implementation files.

Also I would not wrap up standard functions like 'strcmp()' just because you don't like the return type, as it leads you to get used to using a dialect of C which nobody else will understand.