Sign in to follow this  
CadetUmfer

"Pointer to Constructor"

Recommended Posts

CadetUmfer    234
Fred has no default constructor. With vector I can:
std::vector<Fred> a(10, Fred(5,7));


What is the type of the 2nd parameter? I would like to use it like this:
void Init(Fred (*construct)()) {
    Fred f = construct();
}


Please do not mark threads 'solved' in this forum. -- jpetrie [Edited by - jpetrie on June 22, 2009 10:33:57 AM]

Share this post


Link to post
Share on other sites
Waterwalker    431
The type of the second parameter is simply Fred ... an instance of the Fred class used as template to copy to all entries of the vector. Your init Function would look something like that:


void Init(Fred **f)
{
*f = new Fred();
}


Obviously that is not what you want because it is very Fred-specific. Maybe you should try to ask for a solution of a concrete problem. I guess there is some reasoning why you think you need to get a pointer to a constructor. [smile]

Edit: I should learn typing faster ... [grin]

Share this post


Link to post
Share on other sites
bobofjoe    322
std::vector allows you to specify an instance of the class that you want copied. They don't care how you give it to them.

I'd imagine that the function signiature looks something like...
vector::vector(size_t size, const T& value);

Share this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by CadetUmfer
Just thought vector was using some dark corner of the language to do the impossible.
Not really, but there's still plenty to be learned from this technique. What the STL was designed to use, here and elsewhere, is what was later recognized as the prototype pattern, whereby the nature of construction is not building a new instance from a collection of parameters (the paradigm you initially assumed was being used) but from a prototypical instance which exists not so much to be as to instruct new copies of itself. The first lesson, one that's definitely controversial, is that it should be possible for an object to exist without that existence having any side effects. That is, just because I construct a GameObject, doesn't mean it shows up on the screen. The second lesson is similar but distinct: Convenient copying, which goes beyond "remember the Rule of Three" to scary stuff like copy-on-write and shared pointers. The third, and most interesting lesson, comes when you generalize from the prototype pattern to prototype-based programming, and the central observation is that subclassing, constructor-based parameterization, and cloning-then-modifying-the-clone are all aspects of the same thing despite C++'s efforts to treat them separately.

Required reading. Really.

Share this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by swiftcoder
isn't object-oriented inheritance just a static (i.e. compile time) form of his property pattern?

Yes, it's possible to consider C++-type OOP as a special case where properties occur only in certain predefined combinations (which must exist hierarchically) and cannot change their set of properties during their lifetime. The full scope of the pattern, of course, is considerably wider.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this