3 ms·

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 overa

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 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 ago
  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 2y ago
    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 2y ago
    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.
- int_19h 2y ago
  Why not std::make_shared, given that you require C++20 anyway?
  - vinkelhake 2y ago
    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.

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 ago
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 2y ago
  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 2y ago
  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.
int_19h 2y ago
Why not std::make_shared, given that you require C++20 anyway?
- vinkelhake 2y ago
  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.