Re: freeing uBLAS arrays
Eduardo Hernandez via ublas <[email protected]>
| Newsgroups | gmane.comp.lib.boost.ublas |
|---|---|
| Message-ID | <CALrQZ85pwUz=88kUsuwy=1qf8QoRqoEA9+gUvZ_P35NDsQTDLw@mail.gmail.com> |
Thank you Nasos, Just to be clear: suppose I have a class with a data member such as boost::numeric::ublas::vector<double> my_vec; then I create an instance of the class, and when this instance goes out of scope (its destructor is called), I can rely on the fact that my_vec will delete itself and the memory it occupies will be freed, right? Cheers Eduardo On 20 September 2017 at 16:47, Nasos Iliopoulos via ublas < [email protected]> wrote: > If you created it like: > > boost::numeric:ublas::vector<double> my_vec; > /// whatever > > it will deallocate itself. This is the preferred way. > > if you need a pointer ( generally try to avoid this unless you need some > sort of dynamic allocation): > > auto my_vec = new boost::numeric:ublas::vector<double>(); > > you better use a a shared_ptr or unique_ptr depending on what you are > trying to do, like: > > auto my_vec = std::make_unique< boost::numeric:ublas::vector<double> >(); > > or > > auto my_vec = std::make_shared< boost::numeric:ublas::vector<double> >(); > > // now my_vec will again deallocate itself when it goes out of scope. > Typical use case for the unique pointer is when you want to use it in only > in one place. The second one (shared) is useful when you want to pass the > vector around (in other objects or functions). > -N > > On 09/20/2017 10:29 AM, Eduardo Hernandez via ublas wrote: > > Please excuse this probably simple question, but I couldn't find the > answer anywhere. The question is: do uBLAS arrays (e.g. vector, matrix) > deallocate themselves when going out of scope, or should one use shared_ptr > s to them to make sure they are deallocated? > > Thanks, and sorry if this is trivial; I'm new to boost, and also to c++ ;-) > > > > > _______________________________________________ > ublas mailing list > [email protected] > https://lists.boost.org/mailman/listinfo.cgi/ublas > Sent to: [email protected] >