How can we ensure that sending objects (example std::string, or std::vector) throw Commands will not make memory allocations ?
If I am correct, we can do this with Ports by giving an initial value (in the port constructor). The size of the initial value will be used by RTT to allocate internal buffers. After that, if objects sent in the port or not bigger, there is no memory allocations. Is there something like this for Commands ?
I made a small test program to check this, and I can see memory allocations when sending the Command (with operator () ) during copy of std::vector, but not with std::string. I think that this can be explained because the copy constructor of stl::vector is quite different with basic_string. Before using a C++ class into Orocos, do we have to check that the copy constructor is free of memory allocations ? Which are the C++ classes safe to be used ?
Sending variable sized objects throw Commands in RTT 1.6
On Mon, Nov 30, 2009 at 17:19, <nicolas [dot] mabire [..] ...> wrote:
> How can we ensure that sending objects (example std::string, or std::vector) throw Commands will not make memory allocations ?
The only way to be sure is by
a. Making sure that the operator= is not allocating memory or,
b. passing your argument by const&
Case b. must be carefully used not to modify the arguments until the
command was executed.
RTT 2.0 will solve most of this by providing
a. A real-time memory allocator in case you know how much you need (or
have enough)
b. provide explicit synchronisation primitives, such that you can
block/poll for completion of execution.
>
> If I am correct, we can do this with Ports by giving an initial value (in the port constructor). The size of the initial value will be used by RTT to allocate internal buffers. After that, if objects sent in the port or not bigger, there is no memory allocations. Is there something like this for Commands ?
No.
>
> I made a small test program to check this, and I can see memory allocations when sending the Command (with operator () ) during copy of std::vector, but not with std::string. I think that this can be explained because the copy constructor of stl::vector is quite different with basic_string. Before using a C++ class into Orocos, do we have to check that the copy constructor is free of memory allocations ? Which are the C++ classes safe to be used ?
The copy constructor may allocate (it must !), operator=() not. All
std:: classes with dynamic sizes are not safe, unless you provide your
own allocator, which uses the stack or similar (a case where you know
how much you need, but not the size of the chunks).
Peter
Sending variable sized objects throw Commands in RTT 1.6
How can we ensure that sending objects (example std::string, or std::vector) throw Commands will not make memory allocations ?
If I am correct, we can do this with Ports by giving an initial value (in the port constructor). The size of the initial value will be used by RTT to allocate internal buffers. After that, if objects sent in the port or not bigger, there is no memory allocations. Is there something like this for Commands ?
I made a small test program to check this, and I can see memory allocations when sending the Command (with operator () ) during copy of std::vector, but not with std::string. I think that this can be explained because the copy constructor of stl::vector is quite different with basic_string. Before using a C++ class into Orocos, do we have to check that the copy constructor is free of memory allocations ? Which are the C++ classes safe to be used ?