1
\$\begingroup\$

I've noticed with some functions in C++ that accept objects (e.g. constructors), you can actually create the object within the function argument e.g. (this example uses an SDL_Point as the main parameter)

//Constructor for custom object
object::object(SDL_Point spawn_location);

//Declaration of new object
SDL_Point new_point {0, 0};
object new_object(new_point);

//Alternatively, this also works
object new_object(SDL_Point{0, 0});

My question is, is this also possible with derived classes? My thinking behind this is that I have a single base class with a large number of derived (and derived derived etc) classes that I'd like to instantiate using a single function (to set various variables and add to a common vector). Current this looks like this:

void create_new_object(base_class object_to_create)
{
//Do new object stuff
}

This works:

my_derived_class new_object;
create_new_object(new_object);

However, I get an error (expected primary-expression before new_object) with this:

create_new_object(object new_object);

Is this strictly a base / derived class issue, a difference between functions and constructors, or is there something more I need to do to allow the function to accept the instantiation of objects within its parameters?

Thanks

Nathan

Improve this question
\$\endgroup\$
  • 1
    \$\begingroup\$ If you have a big inheritance hierarchy of objects, you might face issues later. These architectures tend to be a nightmare to modify and understand in the long term. Generally, you should prefer composition over inheritance. \$\endgroup\$ – Vaillancourt♦ Sep 27 '16 at 14:21
  • \$\begingroup\$ Thanks Alexandre for this point. In this case nearly all of the objects in this 'game' are derived from a single base class much like a taxonomy of plants or animals, which enables things like one vector containing pointers to every object in the game. I intentionally made this design decision to effectively achieve a form of polymorphism (i.e. near interchangeable objects), and it's worked well so far without the need to create interfaces. I'd be interested to hear your thoughts on the benefits of composition rather than inheritance in this case \$\endgroup\$ – nathanburns Sep 28 '16 at 19:12
  • \$\begingroup\$ What you describe seems to be ok. Typically, the reflex of not using to much inheritance comes from experience. The idea is to stay far away from hierarchies such as this one on Wikipedia. This tend to mess up plans when you have a 'mammal' hierarchy, and parallel to that a 'lay eggs' hierarchy and you have to introduce the platypus... :P \$\endgroup\$ – Vaillancourt♦ Sep 28 '16 at 23:14
1
\$\begingroup\$

1) Not certain polymorphism works unless it is a pointer/reference parameter, it might be the case that the base-class part of your derived class is just cut and pasted into the argument , "slicing"

2) Watch out when the constructor parameter is some kind of reference, the compiler usually complains if one tries to create the object in place (i think it is just an rvalue then unless the parameter it is trying to bind to is const&) (personally I don't understand why, but I guess the c++ creators didn't think one would like to create something that is destroyed right after the fuction call is complete)

Improve this answer
\$\endgroup\$
  • \$\begingroup\$ Thanks @Emil for the thoughts and warnings - this seems to be working so far with all aspects of the 'parent' classes (not sure what the right term is here) also being constructed and stored properly \$\endgroup\$ – nathanburns Sep 28 '16 at 18:49
0
\$\begingroup\$

Bugger, solved this about two minutes after I posted the question

The answer is not to use names for the temporary objects used as arguments in functions, i.e.

create_new_object(object());

Rather than

create_new_object(object named_object());
Improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.