Author Topic: Initialize pointers to NULL in Managers.cpp  (Read 30752 times)

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Initialize pointers to NULL in Managers.cpp
« on: December 12, 2005, 11:24:06 pm »
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;
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Initialize pointers to NULL in Managers.cpp
« Reply #1 on: December 13, 2005, 12:16:35 am »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Initialize pointers to NULL in Managers.cpp
« Reply #2 on: December 13, 2005, 12:40:40 am »
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 :P.

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

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

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Initialize pointers to NULL in Managers.cpp
« Reply #3 on: December 13, 2005, 12:54:31 am »
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.
« Last Edit: December 13, 2005, 12:56:58 am by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

takeshimiya

  • Guest
Re: Initialize pointers to NULL in Managers.cpp
« Reply #4 on: December 13, 2005, 02:12:11 am »
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?

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Initialize pointers to NULL in Managers.cpp
« Reply #5 on: December 13, 2005, 02:18:20 am »
...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  :)

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Initialize pointers to NULL in Managers.cpp
« Reply #6 on: December 13, 2005, 02:26:55 am »
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.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Initialize pointers to NULL in Managers.cpp
« Reply #7 on: December 13, 2005, 02:31:57 am »
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.
« Last Edit: December 13, 2005, 02:36:04 am by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Initialize pointers to NULL in Managers.cpp
« Reply #8 on: December 13, 2005, 02:43:53 am »
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).
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

takeshimiya

  • Guest
Re: Initialize pointers to NULL in Managers.cpp
« Reply #9 on: December 13, 2005, 03:35:36 am »
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 :P

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)?

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Initialize pointers to NULL in Managers.cpp
« Reply #10 on: December 13, 2005, 03:43:01 am »
Macros are not the devil. I think y'all are going overboard with some of this...
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

takeshimiya

  • Guest
Re: Initialize pointers to NULL in Managers.cpp
« Reply #11 on: December 13, 2005, 03:53:19 am »
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.

Offline 280Z28

  • Regular
  • ***
  • Posts: 397
  • *insert unicode here*
Re: Initialize pointers to NULL in Managers.cpp
« Reply #12 on: December 13, 2005, 04:32:25 am »
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.
78 280Z, "a few bolt-ons" - 12.71@109.04
99 Trans Am, "Daily Driver" - 525rwhp/475rwtq
 Check out The Sam Zone :cool:

Offline tiwag

  • Developer
  • Lives here!
  • *****
  • Posts: 1196
  • sailing away ...
    • tiwag.cb
Re: Initialize pointers to NULL in Managers.cpp
« Reply #13 on: December 13, 2005, 09:04:28 am »
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  8)

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  :P

just my 2 cents

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Initialize pointers to NULL in Managers.cpp
« Reply #14 on: December 13, 2005, 09:28:01 am »
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 :P
I was too ... and I still use const vars except when I really have to :)
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."