Modern C++

[StefanoD]

Hi,
I am wondering about many raw pointers. I.e. manual pointer destruction in destructors instead of using std::unique_ptr. This can actually cause memory leaks, because the destructor is not called when an exception within the constructor is raised.
Are you aware of that? What are the reasons of using old-school C++?

[ehopperdietzel]

Are you pointing out the use of raw pointers to the private implementation of each class? It's indeed a bad design that I haven't addressed, but luckily, it is easy to fix. I was not aware of exceptions, at least I think there is no constructor in the lib that throws or could throw exceptions. As for the second question, I primarily stick to C++11, as I haven't identified a compelling need to adopt newer standards. Is there any particular functionality from the more recent standards that you believe could be beneficial?

[ehopperdietzel]

Great! It's great for encapsulation, but I do wish there were a more elegant solution as well. 😄

[2xsaiko]

MyClass::MyClass() : m_imp(new MyClassPrivate)

Ideally unique_ptr is constructed uisng make_unique:

MyClass::MyClass() : m_imp(std::make_unique())

Does that work in this position?

[ehopperdietzel]

Yes, it works. I read that std::make_unique is safer because it performs the allocation atomically. Therefore, I'll use that. I will also need to switch to C++14.

[StefanoD]

There are, btw., more generic ways to implement the PIMPL idiom: https://herbsutter.com/gotw/_101/

[ehopperdietzel]

Uff that look a bit more complicated, I think the std::make_unique approach is simpler and works just fine, so I'll stick with that.

[StefanoD]

Yes, I was referring to private implementations and modern C++ starts for me with C++ 11 which also has smart pointers.

I was also wondering about the design choice of virtual classes instead of templates or std::function callbacks which are more efficient. But I have to say, that interfaces do have a more beautiful API design. Maybe this is the reason why you chose it.

[ehopperdietzel]

That's an excellent question. I had a tough time deciding between the two, including the observer pattern, even though it wouldn't have allowed for a default implementation.

Ultimately, I chose virtual methods because I realized that, while callback functions might be comfortable to work with, they can result in poorly structured projects with things scattered all over the place. Though reimplementing classes and overriding methods can be tedious, it forces you to maintain a well-structured project. Anyone familiar with creating a compositor with Louvre should be able to look at a project and immediately identify where each functionality is handled, or at least get an overall picture of it.

The LAnimation and LTimer classes use callbacks, though.