3 ms·
Thank you for the feedback. The framework was originally built with exceptions always disabled, and it is currently being reworked to support both modes: except
by danlcaza 2y ago
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/ https://www.kfr.dev/blog/three-cpp-tricks/
- khold_stare 2y agoWhy is heap allocation and shared_ptr required? Can't you have the user store the widgets in whatever manner they want, as values?
- CyberDildonics 2y agoYou 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 2y agoHeap 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.
- int_19h 2y agoWhy not std::make_shared, given that you require C++20 anyway?
- vinkelhake 2y agoJust 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.