freeing uBLAS arrays

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

freeing uBLAS arrays

Boost - uBLAS mailing list
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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: freeing uBLAS arrays

Boost - uBLAS mailing list

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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: freeing uBLAS arrays

Boost - uBLAS mailing list
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 <[hidden email]> 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]


_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: freeing uBLAS arrays

Boost - uBLAS mailing list

Correct


On 09/20/2017 11:09 AM, Eduardo Hernandez via ublas wrote:
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 <[hidden email]> 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
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]



_______________________________________________

_______________________________________________
ublas mailing list
[hidden email]
https://lists.boost.org/mailman/listinfo.cgi/ublas
Sent to: [hidden email]