Initialize pointers to NULL in Managers.cpp

[280Z28]

In sdk/Managers/Managers.cpp, it is good practice to initialize the global pointers to NULL.

Code

Manager* g_Manager = NULL;
wxConfigBase* g_Config = NULL;
TemplateManager* g_TemplateManager = NULL;
PluginManager* g_PluginManager = NULL;
EditorManager* g_EditorManager = NULL;
MacrosManager* g_MacrosManager = NULL;
MessageManager* g_MessageManager = NULL;
ProjectManager* g_ProjectManager = NULL;
ToolsManager* g_ToolsManager = NULL;

[thomas]

Actually, you would use 0 rather than NULL which is defined as ((void*)0).

All Managers accessible via the Managers class are initialised via Set , but you should use Manager::Get()->GetXXX() anyway.

[Urxae]

Actually, you would use 0 rather than NULL which is defined as ((void*)0).

Actually, what exactly NULL is defined as is implementation-dependant, but on C++ compilers it's usually (if not always) 0, as ((void*)0) doesn't implicitly convert to every other pointer type anymore .

[one quick Google later]
Bjarne says NULL defined as 0 in C++, but he uses plain 0 anyway basically because macros are evil¹. I'm with him .

1) Yeah, so he didn't say it quite that strongly. Sue me.

[thomas]

If you had looked in windef.h, you would know better...

NULL is defined as ((void*) 0) which is not valid. This is one reason why I said so (and of course because I think like Stroustrup regarding macros). In fact, this is a good example of how macros can be evil, because it will break your compile in certain situations, and it is not obvious why.

Another reason is that you explicitely cast from void* to Type* when it is not necessary. Of course assigning 0 is not really any different internally, but casting from void* to anything else unless you really have to is ideologically evil. The last reason is that assigning 0 is universal (works with every type) while assigning ((void*) 0) is not.

[takeshimiya]

I do not like to use macros, but I wonder what can I use to replace them in:

-Preventing multiple header inclusion. (Why compilers doesn't prevent it?)
-Compile time options (like #ifdef UNICODE ...)
-Should I use things like
#define DEFAULT_BATCH_BUILD_ARGS _T("-na -nd -ns --batch-build-notify")
or
const wxString DEFAULT_BATCH_BUILD_ARGS(_T("-na -nd -ns --batch-build-notify"));
?
Should I use the first, because the latter would pollute the global namespace whenever the #define won't?

[tiwag]

...Should I use the first, because the latter would pollute the global namespace whenever the #define won't?

if you are born past 1977 use the latter 

[280Z28]

I only mentioned it because when I did a search in files for g_EditorManager, I did not see an immediate place where it was always initialized. If it was initialized at the declaration it would have saved me a bit of time because there would be no doubt.

[thomas]

You may want to use the latter regardless of when you were born, because macros have side effects that are not always visible, and you can always put your consts into a namespace.

The side effect in this case is noticeable if you have many calls to wxString::assign with the macro/const as argument.
If you use a const wxString, the data will be copied exactly once, and assign() will copy a pointer each time. If you use a macro, then assign() will call the CRT strlen, malloc, and memcpy functions each time!

One of the optimizations I made to the code completion tokenizer was replacing
if(blah...)
token = _T("::");
with
if(blah...)
token = constStrings::coloncolon;
in an inner loop. If you call the above a few hundred thousand times, then it is very noticeable.

EDIT: This is actually not due to using a macro, but due to the fact that you pass a const char* rather than a wxString. But the evil thing is that you don't know that. The macro does not show it.


Regarding header protection, macros are the only thing I know of (short of #pragma which is even more evil). But I guess this is a legitimate use of macros.

[thomas]

I only mentioned it because when I did a search in files for g_EditorManager, I did not see an immediate place where it was always initialized. If it was initialized at the declaration it would have saved me a bit of time because there would be no doubt.

It is a hack for MSVC++ to cope with the manager singletons.
But... you can't compile Code::Blocks with VC++ anyway, so it is pretty useless alltogether.

You can compile without that file alltogether, the compiler does not even give a warning (I just tried).

[takeshimiya]

Well, the #define DEFAULT_BATCH_BUILD_ARGS example was obtained from C::B src/associations.h, so I can deduce the autor was born before 1977

As for header protection, there isn't any compiler flag to tell the compiler "prevent multiple header inclusion please"?
Because sometimes the macro choosed clashes with another code, like #define MAIN_H or #define UTILS_H which are pretty common name of headers.
And also I sometimes forget to write the header protection.


And there is any way to not use macros in cases of compile time options (like #ifdef USE_UNICODE and such)?

[280Z28]

Macros are not the devil. I think y'all are going overboard with some of this...

[takeshimiya]

Macros is a C thing.

If C++ suffers from C heritage, so if it wants to survive from people going out to new languages like Java, Phyton, C#, etc. it should make easy to get rid of those things if the user desires so.

In fact I think that if C++ would be D, a lot of people wouldn't be migrating to those other languages.

[280Z28]

It's a neat concept, but keep in mind what language we're working with here. C++ programmers are used to seeing macros used for a wide variety of tasks and will remain so for the forseeable future. You don't want to make things difficult for new members of the project when you don't have to. One thing that would make things more difficult is changing the way that people expect to see common tasks done.

[tiwag]

I don't want to have a holy war about evil macros and so on - there are really better places (comp.lang.cpp ...) for such threads 

But i really think it is a matter of taste or maybe ignorance or it depends on what you've been used to use for much years -
so it is much more probable that you use macros instead of C++ elements when you are older and have a reasonable C background.

All the arguments for a better (saver, better portable, ...) coding style are right, no doubt,
but in the end every single programmer has to know in detail, what he is doing and i can't imagine
to use a programming language, which wouldn't me allow this  even if there exists a residual risk to make a programming error 

just my 2 cents

[thomas]

And there is any way to not use macros in cases of compile time options (like #ifdef USE_UNICODE and such)?

#pragma once
But this is even more evil than using include guards, because it is not supported by all compilers. Pragmas are compiler-specific.

if it wants to survive from people going out to new languages like Java, Phyton, C#, etc.

Not true, the language features are all there, people are only too lazy to use them.
Whether you write final int blah = 5; or const int blah = 5; is pretty much the same. Only in Java you have no other choice, while C++ will still work with a macro, too (and most people just do what they have been doing for many years). This does not make Java a better language, though (let's not even talk about C#).

so I can deduce the autor was born before 1977

I was too ... and I still use const vars except when I really have to

[Michael]

About NULL pointer, I have found the following FAQ, answer, topic and article rather interesting.

Michael

[280Z28]

About NULL pointer, I have found the following FAQ, answer, topic and article rather interesting.

Michael

I agree that 0 looks like an integer and NULL distinguishes pointer initialization from integer initialization. On that basis alone I will always have state to use NULL for pointers in my style guidelines for any project I create. I'm also a grown up, so if I know that someone else's guidelines specify something different, I will follow them with the same respect I would expect them to treat my rules with if they were helping on my projects.

[Michael]

I agree that 0 looks like an integer and NULL distinguishes pointer initialization from integer initialization. On that basis alone I will always have state to use NULL for pointers in my style guidelines for any project I create. I'm also a grown up, so if I know that someone else's guidelines specify something different, I will follow them with the same respect I would expect them to treat my rules with if they were helping on my projects.

I used NULL at the beginning as I thought it was better than 0, but switched to 0 when I discovered that it was not. In the project, I am actually working, several partners used 0 instead of  NULL. Discussing with them about that was really interesting. However, you should never accept blindly ideas, suggestions, etc. from other persons without first thinking by yourself. This is something, I have learnt.

Michael

[rickg22]

Has anyone of you noticed that wxWidgets uses NULL ?

Since C::B is a wxWidgets project, i prefer to follow the convention and use NULL. If anybody thinks of a specific situation where i MUST use 0 instead, please do so.

[thomas]

wxWidgets also does stuff like redefining global operator new. Should we do things like that too?

[Michael]

Has anyone of you noticed that wxWidgets uses NULL ?

Is NULL in wxWidgets so defined?

Code

#define NULL 0 

Michael

[tiwag]

could some admin move this thread to the Offtopics please ... 

[thomas]

Lol, before Rick does that, I have to post this request for feature:

Code

#define if(x,y) while(x){(y) break;}

:lol:

[rickg22]

Do that again, and I'll rewrite SVN plugin using wxArrays!