As a JntArray() default constructor doesn't exist, the use case scenarios for JntArray and for an equivalent std::vector
Basically, if the component is configured with the number of axes in configureHook(), then you have to "new JntArray(num_axes)" at that point, forcing all JntArray members to be pointers. A std::vector
What do people think of adding a JntArray() constructor that simply sets size(0) and data(NULL), and adding a resize() function. This would make the interface consistent with std::vector (used extensively throughout RTT and OCL code) making for more understandable code (IMHO).
I believe that all the existing JntArray functions will work as expected without modification, due to size being 0. The only exceptions are the operator() accessors and the copy constructor. They would need slight mod's to protect against the case of an default constructed JntArray object being used, or it would need to be explicitly stated that "interesting behaviour" will occur if you create an object with JntArray() and do not resize it before an operator() access, etc.
I believe there was a discussion on the forum a few weeks back about objects being created in dormant/zombie states, or something similar. I think this is an example of that ...?
S
Why is JntArray not resizable?
On Tuesday 07 October 2008 14:33:19 kiwi [dot] net [..] ... wrote:
> As a JntArray() default constructor doesn't exist, the use case scenarios
> for JntArray and for an equivalent std::vector in nAxes components are
> different. As std::vector is used through RTT and OCL examples and actual
> code, this dichotomy can be confusing and time wasting. So the question is,
> why not?
The main reason was because resizing can result in a malloc which we should
prevent in realtime use.
> Basically, if the component is configured with the number of axes in
> configureHook(), then you have to "new JntArray(num_axes)" at that point,
> forcing all JntArray members to be pointers. A std::vector can simply be
> resized in configureHook(), which is much more useful and has no impact on
> real-time operations. The dynamic allocation in both the existing and
> proposed scenarios is in the same place, in configureHook(). The difference
> is your compontents now don't have non-pointer std::vector's and pointer
> JntArray's.
You have a strong point here.
> What do people think of adding a JntArray() constructor that simply sets
> size(0) and data(NULL), and adding a resize() function. This would make the
> interface consistent with std::vector (used extensively throughout RTT and
> OCL code) making for more understandable code (IMHO).
I don't have strong objections. So i would be willing to accept a patch for
this ;). But then the KDL-1.0 release will be stalled (again :(, but this
gives me some time to finish the documentation )
> I believe that all the existing JntArray functions will work as expected
> without modification, due to size being 0. The only exceptions are the
> operator() accessors and the copy constructor. They would need slight mod's
> to protect against the case of an default constructed JntArray object being
> used, or it would need to be explicitly stated that "interesting behaviour"
> will occur if you create an object with JntArray() and do not resize it
> before an operator() access, etc.
we can always check this and do an assert in DEBUG mode. Or throw an
exception, but i do not know if this results in good realtime behaviour.
Ruben
Why is JntArray not resizable?
On Oct 8, 2008, at 03:19 , Ruben Smits wrote:
> On Tuesday 07 October 2008 14:33:19 kiwi [dot] net [..] ... wrote:
>> As a JntArray() default constructor doesn't exist, the use case
>> scenarios
>> for JntArray and for an equivalent std::vector in nAxes components
>> are
>> different. As std::vector is used through RTT and OCL examples and
>> actual
>> code, this dichotomy can be confusing and time wasting. So the
>> question is,
>> why not?
>
> The main reason was because resizing can result in a malloc which we
> should
> prevent in realtime use.
Understood, but you end up doing a new at the same point, in this
particular use case scenario. So six of one, half a dozen of another.
>> Basically, if the component is configured with the number of axes in
>> configureHook(), then you have to "new JntArray(num_axes)" at that
>> point,
>> forcing all JntArray members to be pointers. A std::vector can
>> simply be
>> resized in configureHook(), which is much more useful and has no
>> impact on
>> real-time operations. The dynamic allocation in both the existing and
>> proposed scenarios is in the same place, in configureHook(). The
>> difference
>> is your compontents now don't have non-pointer std::vector's and
>> pointer
>> JntArray's.
>
> You have a strong point here.
>
>> What do people think of adding a JntArray() constructor that simply
>> sets
>> size(0) and data(NULL), and adding a resize() function. This would
>> make the
>> interface consistent with std::vector (used extensively throughout
>> RTT and
>> OCL code) making for more understandable code (IMHO).
>
> I don't have strong objections. So i would be willing to accept a
> patch for
> this ;). But then the KDL-1.0 release will be stalled (again :(, but
> this
> gives me some time to finish the documentation )
Wilco ... patch coming soon ...
>> I believe that all the existing JntArray functions will work as
>> expected
>> without modification, due to size being 0. The only exceptions are
>> the
>> operator() accessors and the copy constructor. They would need
>> slight mod's
>> to protect against the case of an default constructed JntArray
>> object being
>> used, or it would need to be explicitly stated that "interesting
>> behaviour"
>> will occur if you create an object with JntArray() and do not
>> resize it
>> before an operator() access, etc.
>
> we can always check this and do an assert in DEBUG mode. Or throw an
> exception, but i do not know if this results in good realtime
> behaviour.
I would prefer to not exception myself, particularly as exceptions are
seldom used throughout RTT/KDL/OCL. One could argue that good
documentation of internal behaviour, coupled with an assert, would be
sufficient. That would also be consistent, as the code is currently
sprinkled with similar asserts.
Cheers
S