Jump to content
  • Advertisement
Sign in to follow this  
Telastyn

C++ Trick

This topic is 5438 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

(M-x mode-thread-hijack-on)
Quote:
Original post by CodeNow
Singletons do seem like a "trick" to me. They seem to be a trick to avoid having explicit global variables, yet still have that global variable availability. What am I missing?


You are missing the real meaning of what a singleton is: of course, this a global instance of an class. But it is the only one global instance of a particular class, while a classical global variable do not ensure unicity. Therefore, a singleton is not used to declare a global variable but to declare a variable that is unique and global to whole program. That is a rather important semantic difference (and good programming is also about semantics)
(M-x mode-thread-hijack-off)

Quote:
Original post by C-Junkie
You could take the quake route and make the console ALWAYS there...


I don't think this is a good idea. What if the console uses a lot of memory? Do you apply the same paradigm for an in-game editor?

Quote:
Original post by _the_phantom_
then you seriously need to rethink your design

To _the_phantom_ and Washu (seem to share a similar POV): I don't think having NULL pointers which hides a non-existant object is a sign of bad design. I don't see why having to deal with a NULL pointer should always throw either an assert or an exception.

If you speak about the design (if a feature is not used, then you must not have any sign of it in the code): this is very hard. Consider the case where you are using a debug log. Do you want to do:

CGame *game;
if (myExternalConfigFileSaysIMustLog) {
game = new CGameWithoutLog();
} else {
game = new CGameWithLog();
}
game->run();
delete game;

Or do you prefer

CLogger *logger;
if (myExternalConfigFileSaysIMustLog) {
logger = new CLogger();
} else {
logger = NULL;
}
CGame *game = new CGame(logger);
game->run();
delete game;

From a design point of view, I'd do the later because I don't want to write my CGame code twice (this is nonsense).

If you speak about the code construction (testing a NULL pointer instead of a false boolean): I think that having to maintain a pointer AND a boolean which explicitely says that this pointer is NULL or non-NULL IS a bad design - because it breaks unicity and is error prone. IT may leads to code like this:

if (hasThisFeature) {
assert(objectInstance != NULL);
objectInstance->doSomeStuff();
}

Which is rather weird (and fits well in the "more code, more bug" way of life).

@Telastyn: as uavfun pointed out, this code construction will not work with virtual function and therefore is very dangerous. VC++ (both 6 and .net) will generate this code when calling a virtual function:

mov eax, ecx[n]
call [eax]

ecx contains this. If this is NULL you call a very strange function. The correct thing to do is to test wether the object exists, call the function if it exists, and throw an assert if the function is called with this == NULL.

What you suggest is what I'd call (no intended offense) lazy programming. This is not a good programming practice. Good programming produces the right amount of code, not the minimal amount of code.

Regards,

Share this post


Link to post
Share on other sites
Advertisement
Use static member functions if you want to do something like that; obj->method() says I have a valid object and am invoking some method on it. Class::method() is for the type of stuff you're doing.

Quote:

If you speak about the code construction (testing a NULL pointer instead of a false boolean): I think that having to maintain a pointer AND a boolean which explicitely says that this pointer is NULL or non-NULL IS a bad design - because it breaks unicity and is error prone. IT may leads to code like this:


Why are you calling methods on objects that don't exist? There should be a container that holds valid objects (or pointers to them) or there should be a deterministic order of operations.

The only case I think is acceptable is the use of a null-pointer check for an optional "return" parameter; if they pointer isn't null we copy some result into it, otherwise we ignore it, and that's just for simple structures.

...
Quote:
Original post by CodeNow
Singletons do seem like a "trick" to me. They seem to be a trick to avoid having explicit global variables, yet still have that global variable availability. What am I missing?

Real singletons exhibit polymorphic behavior (you decide once what object to create, then everyone uses that object from then on).

Share this post


Link to post
Share on other sites
Ah, thank you for the explination as to why that is broken for the specific case of virtual functions [which I've not used until recently].

As for why, generally I've used the !this check in lists [to signify an empty list] or with optional values [say... the current equipped weapon, which might be nothing]. I'd just rather write that check once than forget it in various places.

Share this post


Link to post
Share on other sites
For "the currently equipped weapon, which might be nothing", you may be interested in the Null Object pattern.

To MKH: I finally found an application where a polymorphic Singleton might actually be useful (because implementation actually has to be decided at runtime). But I already had code that assumed a static interface. My solution was to create an object of some subclass at runtime, and delegate the static "interface" methods to appropriate object "implementation" methods. Outside code is unaware of the subclasses - it's a Facade basically. I am pretty happy with the result - although it looks kind of unusual internally, the change is transparent to the rest of the code base.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!