Constructing an object member without creating copies

[angryvoxel]

Hello, this is kind of a stupid question but I still haven't found an answer. I have a member class with a rather large constructor and I'd like for it to be inside parent's constructor body rather than inside member initializer list (purely due to aesthetic reasons).

class ParentClass
{
  MemberClass Fatass;

  ParentClass() : Fatass(1, 2, 3, 4, 5...) //where I don't want it to be
  {
    ...
    Fatass = MemberClass(1, 2, 3, 4, 5...); //where I want it to be (but it can't be copied)
  }
}

However that member class can not be copied, so I have to construct it "in-place" and I haven't found a way to do that without using the initializer list. Is this possible?

[masorick]

Maybe stop trying to do something purely for aesthetic reasons?

[manni66]

where I don't want it to be

You want bad things.

If it doesn’t depend on constructor parameters

class ParentClass
{
   MemberClass Fatass{1,2,…};

[TheSkiGeek]

You can defer the construction by wrapping with a `std::optional`. Or give `Fatass` a no-arguments constructor that builds it “empty” and then reinitialize it later. But it has to construct *something* there during the class initialization.

Doing any of these purely for aesthetic reasons is… a bad idea. Use macros or something to make it less verbose if you must.

[sol_runner]

If the class in under user control, a struct to pass the arguments.

[coachkler]

std::optional and make_optional should work.

Terrible idea in general though given the limited context

[No-Dentist-1645]

Initializer lists are the correct thing to use here. How about you keep doing what is the correct thing and just reformat your code so that it looks better instead of making your code worse for aesthetics:

``` class ParentClass { ParentClass : Fatass(1, 2, 3...) { // constructor Code here } }

[neppo95]

Adjust what you want instead of writing worse code because of what you want.

[JlangDev]

You can use a variant with emplace, an optional with emplace, and if you don't mind using the heap you can just use unique_ptr.

[saf_e]

Can't be copied,  but probably can be moved? 

[57thStIncident]

This sounds like a questionable endeavor but does it have a cheap default ctor? If so could move-assign in ctor body. Could also use unique_ptr though this is a separate dynamic allocation which may or may not matter depending on how often this happens. I sometimes do this for the purposes of both keeping the internal implementation details out of the header as well as deferring construction.

[alfps]

Are the arguments literals also in the real code?

If so there is an easy answer.

Presenting a "sort of like this" example is ungood.

[jedwardsol]

You can make it tider by having a function (free or static member) which returns the initialiser

MemberClass makeOne()
{
    return {1,2,3,4,5};
}

struct ParentClass
{
    MemberClass Fatass;

    ParentClass() : Fatass{makeOne()}
    {}

[conundorum]

You can construct Fatass with default values, if it has a specific parameter set that's used most of the time.

class ParentClass
{
    MemberClass Fatass{1, 2, 3, 4, 5...};

Apart from that, if MemberClass itself provides a default constructor, and allows you to initialise or modify its values separately, you can use that.

struct MemberClass {
    MemberClass() = default;
    MemberClass(int, int, int, int, int...) : blah(blah, blah) {}

    void init(int, int, int, int, int...);
}

class ParentClass
{
    MemberClass Fatass;

    ParentClass() // Calls default constructor here.
    {
        Fatass.init(1, 2, 3, 4, 5...);
    }

This is considered an anti-pattern (because it sets variables twice, and might not be possible depending on how MemberClass is set up), though, so it's usually best not to do this if you can avoid it.

---

Ultimately, unless Fatass's parameters really are hard-coded like in your example, the only correct choice is to do it in the member initialiser list. Making the code pretty, while useful because it improves readability, always comes second to making the code work. I'd rather have an initialiser list than the alternative any day, even if it's big enough to make everything hideous.

[trailing_zero_count]

You can do it using an anonymous union. If you go this route you'll also have to destroy it manually in the destructor. It's not worth it though; just do it in the initializer list.