Usage of smart pointers #900
-
|
Hi TiGL developers 👋 Just out of interest in software architecture (low priority issue): What are your experiences on using smart pointers for libraries like TiGL? The CPACSGen classes make a lot of use of unique_ptr. Since I want to build the cpacsLibrary similarly to TiGL, I wonder to what extent smart pointers should also be used in the higher level classes. I don't find an overly large use in the TiGL classes. Also it seems that other libraries (boost, Eigen, etc.) rarely return smart pointers. From your experience - when starting from scratch - is it recommended to use raw pointers to simplify integration in third party software? Or try to use smart pointers as much as possible for the sake of good memory management? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
Obviously, TiGL's codebase comes from the pre C++11 area, with C++ libraries rarely return smart pointers as this implies a change of ownership, returning e.g. unique_ptr always implies the transfer of ownership to the caller, which often only makes sense for factories. Having just raw pointers (optional type) or references in the interface helps also keeping interfaces to other languages simpler. Generally though, I favor having smart pointers to manage the lifetime of objects. There's a good talk "Back to basics: smart pointers" at the CPPCon: https://youtu.be/xGDLkt-jBJ4 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @rainman110! Very interesting video. At the end of the talk, my question was even asked and addressed by audience: https://youtu.be/xGDLkt-jBJ4?t=3479. @joergbrech: Maybe we can move this issue to the discussions board? One open issue less then ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Done ;) |
Beta Was this translation helpful? Give feedback.
Obviously, TiGL's codebase comes from the pre C++11 area, with
std::shared_ptras the only smart pointer. This is the primary reason for the lack of smart pointers.C++ libraries rarely return smart pointers as this implies a change of ownership, returning e.g. unique_ptr always implies the transfer of ownership to the caller, which often only makes sense for factories.
Having just raw pointers (optional type) or references in the interface helps also keeping interfaces to other languages simpler. Generally though, I favor having smart pointers to manage the lifetime of objects.
There's a good talk "Back to basics: smart pointers" at the CPPCon: https://youtu.be/xGDLkt-jBJ4