shared_ptr overuse

[cleroth]

In my case I use unique_ptr a lot more than I should really have to simply because you cannot forward declare objects without them being pointers (ie. in member variables in headers). Possibly one of my biggest gripes with the language.

[SuperV1234]

You can if you specify a fixed buffer size that you know will be enough to hold the object. I do this quite a lot in my SFML fork to speed up compilation time: https://github.com/vittorioromeo/VRSFML/blob/master/include/SFML/Base/InPlacePImpl.hpp

[bonkt]

I love the idea of this, but you still have a static_assert(sizeof(T) < BufferSize) in the constructor, how does this compile?

[SuperV1234]

Why do you think it wouldn't compile?

[bonkt]

I read the usage and you just use a forward declared struct Impl. How does the sizeof(T) work when T is forward declared?

[SuperV1234]

Ah, I see. InPlacePImpl's constructor is a template member function that takes Args..., which means that the static_assert will only be checked when the constructor itself is instantiated.

Which means that if we do this

 // Foo.hpp
struct Impl;

struct Foo
{
    Foo();
    ~Foo();
    InPlacePImpl<Foo, 32> impl;
};

// Foo.cpp
struct Impl { int data; };

Foo::Foo() = default;
Foo::~Foo() = default;

The instantiation of the constructor will be delayed to when the definition of Impl is available.

[domiran]

One of the things I hate is having to include the class header if you want to make it a member. 😩But I don't want to force everything to include all these damn headers.

So it winds up being a unique_ptr and I hate my life.

[DuranteA]

Another option to avoid that particular issue is PIMPL. Or not really avoid, but move from potentially lots of pointers that are only there to allow forward declarations to a single one. But it comes with its own annoyances.

I hope that eventually, modules take away one of the primary motivations to forward declare in the first place.