Jump to content
  • Advertisement
Sign in to follow this  
JoHnOnIzEr

class constructor?

This topic is 5021 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

does it matter what restriction you put on th e constructor/deconstructor? like private, protected, public? what effects does it have?

Share this post


Link to post
Share on other sites
Advertisement
making it protected or private has the same meaning as it does for normal functions: only instances of the class itself, or friend classes, or child classes (in the case of protected, but not private) can call the method. i.e. if you have a private constructor you can't call new ObjectName from anywhere but inside the class itself.

in general there are very few instances in which you would want the constructor as anything other than public. A singelton pattern is the example of wanting a private/protected constructor that springs to mind first.

-me

Share this post


Link to post
Share on other sites
someone correct me if I'm wrong, but I believe it has to be public...'cause you wouldn't be able to call it from outside functions otherwise, and thus you wouldn't be able to access the class except within itself...and that wouldn't be good...

Share this post


Link to post
Share on other sites
It doesn't have to be public to be useful: consider that you may sometimes want the class itself to be the only thing that can create objects of itself. The prime example of this is singletons, where the constructor is always protected or private.

Share this post


Link to post
Share on other sites
Quote:
Original post by NewbJ
someone correct me if I'm wrong, but I believe it has to be public...'cause you wouldn't be able to call it from outside functions otherwise, and thus you wouldn't be able to access the class except within itself...and that wouldn't be good...


a basic, though crappy singleton:

class Foo
{
public:
static Foo &GetInstance()
{
static Foo theInstance;
return theInstance;
}

protected:
Foo() {}
};




-me

Share this post


Link to post
Share on other sites
Singletons are the subject of much debate in OO circles, but it's worth noting that they are really just a special case of Factory, which is to say, you are controlling the means by which objects of the class are created. This can be useful for working with other patterns e.g. Flyweight:


class Thingy {
private:
static std::map<int, Thingy> alreadyProduced;
// a bunch of other stuff magically determined by the input integer

Thingy(int x) : /* initialize stuff */ {
// more initialization possibly
}

public:
void getThingy(int x) {
// if alreadyProduced contains the Thingy mapped to x,
// return that Thingy
// Else produce it, stuff it into the map, and return it.
// I forgot std::map syntax :(
}
}



The result here is that every one who asked for a Thingy with the same x, has the same Thingy, saving on the number of objects you create. (For program correctness, this generally requires that your Thingy is a value object, i.e. all data is immutable after creation.) And if, say, some datum of Thingy is calculated by a binary-recursive function of x, you can get a speed-up by making use of getThingy() inside the constructor - dynamic programming :)

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!