[gpderetta]

All those naked 'new's in the example make me nervous. I see that the library uses exceptions, if one of the widget constructor throws while composing the overall widget hierarchy, it would leak memory.

You should be able to make it work with a value-based interface and allocating behind the scenes (this would also enable a few optimization opportunities).

[danlcaza]

Thank you for the feedback. The framework was originally built with exceptions always disabled, and it is currently being reworked to support both modes: exceptions enabled and disabled. Some approaches definitely need to be reconsidered.

An alternative approach is to use the rcnew macro, which wraps a pointer in a shared_ptr under the hood. Details on the implementation of rcnew can be found at: https://www.kfr.dev/blog/three-cpp-tricks/

[int_19h]

Why not std::make_shared, given that you require C++20 anyway?

[vinkelhake]

Just a quick note that the basic form of std::make_shared (which is the one that is relevant here) has been in the language since C++11.

[khold_stare]

Why is heap allocation and shared_ptr required? Can't you have the user store the widgets in whatever manner they want, as values?

[CyberDildonics]

You absolutely can. Heap allocation for every component is already unneccesary, but loose pointers on top of that is a huge red flag.

This seems like someone who isn't up to date with the most elegant and fastest ways to write C++. Charging money on top of that is egregious, not to mention that there are lots of great GUI libraries already. FLTK, Juce, Qt to name a few.

[danlcaza]

Heap allocation is necessary in real-world scenarios because it allows a tree of potentially derived widget types to be manipulated easily. This is precisely how any robust GUI library is implemented.