[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.