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]
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.