KDL TreeElement API changes

Hi all,

More recent compilers seem to have problems with the TreeElement
definition: see
https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
information. There seems to be no easy way to fix this without an API
change.

I'm currently trying to get an estimate of the impact of this change
for our users-base. I know the Tree structure and its solvers are less
used than the Chain variants but I still would like to query the
community to see if anyone would object a merge of the pull request.

It is still open if we will use plain pointers or shared pointers.

So if anyone objects with the pending API change or has a more elegant
solution, please speak up.

Ruben

KDL TreeElement API changes

On Tue, 11 Feb 2014, Ruben Smits wrote:

> Hi all,
>
> More recent compilers seem to have problems with the TreeElement
> definition: see
> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
> information. There seems to be no easy way to fix this without an API
> change.
>
> I'm currently trying to get an estimate of the impact of this change
> for our users-base. I know the Tree structure and its solvers are less
> used than the Chain variants but I still would like to query the
> community to see if anyone would object a merge of the pull request.
>
> It is still open if we will use plain pointers or shared pointers.
>
> So if anyone objects with the pending API change or has a more elegant
> solution, please speak up.

My two cents...

I think (hope...) that the robotics community has bounced its head enough
times against the wall, hard, to have learned that "exploiting" "advanced"
C++ features is not the most maintainable way to go...

Hence, I fully support an API change, and a drastic one, namely making KDL
into a plain C library, all the way through. For the following reasons:
- maintainability: the semantic differences between C compilers is an order
of magnitude less than for C++;
- clarity of the code: much of the Eigen and Boost stuff is hiding
behaviour (especially realtime) opaquely behind interfaces with side
effects;
- platform support: the future is for mixed-hardware systems, where parts
of the functionality will have to run on "accelerated" hardware, such as
GPUs or FPGAs, embedded or not in the same System-on-a-chip; C is ready for
that ambition, C++ isn't;
- the correctness-at-build-time tests (which are a valid design motivation
in themselves!) can also be taken care of with _tooling_, that is
completely programming language agnostic, and works on a _formal model_ of
the to be constructed primitives, in casy kinematic trees;
- the step toward formal models will be _necessary_ anyway, if we ever hope
to be able to support intelligent robot systems, that can check and
create for themselves the kinematic chains they have to work with;
- the current KDL API is too limited anyway to deal with the variety of
'sensori-motor control' requirements that modern robots can/should
support, as is proven, for instance, by the API explosion for the various
forward/inverse/hybrid kinematics/dynamics solvers for kinematic chains
that people have contributed already, or are interested in having.

To put things in a somewhat broader context: robotics, computer vision and
machine learning are the only engineering domains where the mainstream of
the community has locked itself in into C++. The other domains stick to C,
and spend their useful development time in tooling.

> Ruben

Herman

KDL TreeElement API changes

On Feb 11, 2014, at 05:54 , Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:

> On Tue, 11 Feb 2014, Ruben Smits wrote:
>
>> Hi all,
>>
>> More recent compilers seem to have problems with the TreeElement
>> definition: see
>> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
>> information. There seems to be no easy way to fix this without an API
>> change.
>>
>> I'm currently trying to get an estimate of the impact of this change
>> for our users-base. I know the Tree structure and its solvers are less
>> used than the Chain variants but I still would like to query the
>> community to see if anyone would object a merge of the pull request.
>>
>> It is still open if we will use plain pointers or shared pointers.
>>
>> So if anyone objects with the pending API change or has a more elegant
>> solution, please speak up.
>
> My two cents...
>
> I think (hope...) that the robotics community has bounced its head enough
> times against the wall, hard, to have learned that "exploiting" "advanced"
> C++ features is not the most maintainable way to go...

The problem here was use of a well known and well accepted C++ approach (which actually derives from a standard C approach), which a newer C++ standard outlawed (perhaps rightly so). There is nothing advanced about the technique used, nor was it "exploited" in any sense.

> Hence, I fully support an API change, and a drastic one, namely making KDL
> into a plain C library, all the way through. For the following reasons:
> - maintainability: the semantic differences between C compilers is an order
> of magnitude less than for C++;

The difference between C++ compilers has no bearing here; that's a specious argument. This is a standards issue, and KDL has run into the problem on the first compilers to adhere to the new standard. In time, all modern compilers will adhere to the standard and then all these compilers will have the same issue. And in my experience, having multiple compilers is a good thing as they do help to find more issues.

> - clarity of the code: much of the Eigen and Boost stuff is hiding
> behaviour (especially realtime) opaquely behind interfaces with side
> effects;

Can you provide some examples of these "side effects"? I agree that Eigen and Boost can hide stuff, but I would also bet no one on this ML can write as optimized a code as Eigen has, particularly on multiple platforms; if you want performance, that's a definite example were template black magic can achieve some utterly amazing things.

> - platform support: the future is for mixed-hardware systems, where parts
> of the functionality will have to run on "accelerated" hardware, such as
> GPUs or FPGAs, embedded or not in the same System-on-a-chip; C is ready for
> that ambition, C++ isn't;

That's a very broad statement Herman. Yes, mixed-hardware systems are becoming more common, but it can take an extraordinary amount of knowledge and experience to do co-design, let alone the skills to write good FPGA code.

> - the correctness-at-build-time tests (which are a valid design motivation
> in themselves!) can also be taken care of with _tooling_, that is
> completely programming language agnostic, and works on a _formal model_ of
> the to be constructed primitives, in casy kinematic trees;

How does this not apply to C++ code?

> - the step toward formal models will be _necessary_ anyway, if we ever hope
> to be able to support intelligent robot systems, that can check and
> create for themselves the kinematic chains they have to work with;

How does C vs C++ come into this?

> - the current KDL API is too limited anyway to deal with the variety of
> 'sensori-motor control' requirements that modern robots can/should
> support, as is proven, for instance, by the API explosion for the various
> forward/inverse/hybrid kinematics/dynamics solvers for kinematic chains
> that people have contributed already, or are interested in having.

So maybe that argues for a restructuring of the design, but that is not necessarily tied to any particular language.

> To put things in a somewhat broader context: robotics, computer vision and
> machine learning are the only engineering domains where the mainstream of
> the community has locked itself in into C++. The other domains stick to C,
> and spend their useful development time in tooling.

Sorry, Herman, but that just isn't true. I have plenty of peers in non-robotics engineering fields using C++, Python, Ruby, etc., as well as peers in the robotics field using Python, Ruby, etc.

I am definitely against reverting to a purely C-based API. It will mean writing your own code for things like containers, which are well provided and well understood in C++'s STL. And in my experience C++ compilers are stricter than C compilers, which helps to find more issues at compile time.

I'm sure that Herman will disagree ...

YMMV
S

KDL TreeElement API changes

On Thu, 13 Feb 2014, S Roderick wrote:

> On Feb 11, 2014, at 05:54 , Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>
>> On Tue, 11 Feb 2014, Ruben Smits wrote:
>>
>>> Hi all,
>>>
>>> More recent compilers seem to have problems with the TreeElement
>>> definition: see
>>> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
>>> information. There seems to be no easy way to fix this without an API
>>> change.
>>>
>>> I'm currently trying to get an estimate of the impact of this change
>>> for our users-base. I know the Tree structure and its solvers are less
>>> used than the Chain variants but I still would like to query the
>>> community to see if anyone would object a merge of the pull request.
>>>
>>> It is still open if we will use plain pointers or shared pointers.
>>>
>>> So if anyone objects with the pending API change or has a more elegant
>>> solution, please speak up.
>>
>> My two cents...
>>
>> I think (hope...) that the robotics community has bounced its head enough
>> times against the wall, hard, to have learned that "exploiting" "advanced"
>> C++ features is not the most maintainable way to go...
>
> The problem here was use of a well known and well accepted C++ approach
> (which actually derives from a standard C approach), which a newer C++
> standard outlawed (perhaps rightly so). There is nothing advanced about
> the technique used, nor was it "exploited" in any sense.

My remarks go quite a bit further than this particular issue in this
particuler thread :-) Sorry if that caused confusion, or irratation.

>> Hence, I fully support an API change, and a drastic one, namely making KDL
>> into a plain C library, all the way through. For the following reasons:
>> - maintainability: the semantic differences between C compilers is an order
>> of magnitude less than for C++;
>
> The difference between C++ compilers has no bearing here; that's a
> specious argument. This is a standards issue, and KDL has run into the
> problem on the first compilers to adhere to the new standard. In time,
> all modern compilers will adhere to the standard and then all these
> compilers will have the same issue. And in my experience, having multiple
> compilers is a good thing as they do help to find more issues.

The semantics of the _runtime_ that different compilers generate is not
fully standardized, and these things cause uncertainty in the exact
realtime performance. This is not a problem for most features, but things
like exceptions will remain unpredictable between compilers. At least, if I
understand the technology correctly...

>> - clarity of the code: much of the Eigen and Boost stuff is hiding
>> behaviour (especially realtime) opaquely behind interfaces with side
>> effects;
>
> Can you provide some examples of these "side effects"? I agree that Eigen
> and Boost can hide stuff, but I would also bet no one on this ML can
> write as optimized a code as Eigen has, particularly on multiple
> platforms; if you want performance, that's a definite example were
> template black magic can achieve some utterly amazing things.

I want code whose semantics can be understood, ultimately, by robots, and
not just by compilers. I know that this sounds a bit extreme in a "hackers"
community, but the more "intelligence" one wants to bring into a system,
the less one want to rely on compiler "features" to support that.
Templates and exceptions are two examples of necessary aspects of
intelligent behaviour, and these are exactly two aspects for which
compilers hide the exact behavioural semantics inside the runtime.

>> - platform support: the future is for mixed-hardware systems, where parts
>> of the functionality will have to run on "accelerated" hardware, such as
>> GPUs or FPGAs, embedded or not in the same System-on-a-chip; C is ready for
>> that ambition, C++ isn't;
>
> That's a very broad statement Herman. Yes, mixed-hardware systems are
> becoming more common, but it can take an extraordinary amount of
> knowledge and experience to do co-design, let alone the skills to write
> good FPGA code.

The FPGA tools are extremely good, a lot better than what mainstream
hackers are used to. And their quality comes exactly from a _very_ deep
level of _modelling_ of all platform aspects ("bus", "ram" and "cpu") which
is almost completely absent in our C++ compilers.

>> - the correctness-at-build-time tests (which are a valid design motivation
>> in themselves!) can also be taken care of with _tooling_, that is
>> completely programming language agnostic, and works on a _formal model_ of
>> the to be constructed primitives, in casy kinematic trees;
>
> How does this not apply to C++ code?

Take templates as an example: they are a "poor man's version" of
Model-Driven Engineering. With the emphasis on "poor"... They are just one
of the examples where compilers (which are "abstract syntax tree"
processors) try to become "reasoners" (which requires "context-dependent
language processing"). It was fine for the first steps, but now compilers
(or rather, hackers that think they should get the last bit of juice out of
those compilers, just because they can) are holding back progress in
introducing models into our code development. And libraries like STL are
doing the same: they force the majority of developers in patterns that are
not the most optimal one for the large variety of problems in robotics. The
story of KDL solvers has been mentioned here multiple times already...

>> - the step toward formal models will be _necessary_ anyway, if we ever hope
>> to be able to support intelligent robot systems, that can check and
>> create for themselves the kinematic chains they have to work with;
>
> How does C vs C++ come into this?

C++ offers tools that basically should be done by dedicated model
transformation tools: templates, exceptions, closures, functional
programming,...

>> - the current KDL API is too limited anyway to deal with the variety of
>> 'sensori-motor control' requirements that modern robots can/should
>> support, as is proven, for instance, by the API explosion for the various
>> forward/inverse/hybrid kinematics/dynamics solvers for kinematic chains
>> that people have contributed already, or are interested in having.
>
> So maybe that argues for a restructuring of the design, but that is not
> necessarily tied to any particular language.

That is exactly what my intention is: to reduce the usage of programming
languages to the things that are not tied to any particular language; which
means more or less that one reduces them to "C"... :-)

>> To put things in a somewhat broader context: robotics, computer vision and
>> machine learning are the only engineering domains where the mainstream of
>> the community has locked itself in into C++. The other domains stick to C,
>> and spend their useful development time in tooling.
>
> Sorry, Herman, but that just isn't true. I have plenty of peers in
> non-robotics engineering fields using C++, Python, Ruby, etc., as well as
> peers in the robotics field using Python, Ruby, etc.

Are you talking about _industry-driven_ software developments, that end up
in high-reliability systems? I am thinking of cars, airplanes, litography
machines, medical instruments,...: _all_ the companies active in those
sectors and that I have some sort of access to are relying on MDE tools for
almost everything.

> I am definitely against reverting to a purely C-based API. It will mean
> writing your own code for things like containers, which are well provided
> and well understood in C++'s STL. And in my experience C++ compilers are
> stricter than C compilers, which helps to find more issues at compile
> time.

Why would you have to write your own code for containers...? All one needs
is a C library that does it well, and preferably has a formal model of what
the code is doing.

> I'm sure that Herman will disagree ...

I do not disagree with your statement that you are "definitely against
reverting to a purely C-based API": everyone is entitled to his/her own
aberrations :-)

> YMMV

Indeed. And my ambition is to (help people) travel more software miles than
what the mainstream robotics coder is thinking about... :-)

> S

Herman

KDL TreeElement API changes

On Thu, Feb 13, 2014 at 09:24:05PM +0100, Herman Bruyninckx wrote:
> On Thu, 13 Feb 2014, S Roderick wrote:
>
> > On Feb 11, 2014, at 05:54 , Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
> >
> >> On Tue, 11 Feb 2014, Ruben Smits wrote:
> >>
> >>> Hi all,
> >>>
> >>> More recent compilers seem to have problems with the TreeElement
> >>> definition: see
> >>> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
> >>> information. There seems to be no easy way to fix this without an API
> >>> change.
> >>>
> >>> I'm currently trying to get an estimate of the impact of this change
> >>> for our users-base. I know the Tree structure and its solvers are less
> >>> used than the Chain variants but I still would like to query the
> >>> community to see if anyone would object a merge of the pull request.
> >>>
> >>> It is still open if we will use plain pointers or shared pointers.
> >>>
> >>> So if anyone objects with the pending API change or has a more elegant
> >>> solution, please speak up.
> >>
> >> My two cents...
> >>
> >> I think (hope...) that the robotics community has bounced its head enough
> >> times against the wall, hard, to have learned that "exploiting" "advanced"
> >> C++ features is not the most maintainable way to go...
> >
> > The problem here was use of a well known and well accepted C++ approach
> > (which actually derives from a standard C approach), which a newer C++
> > standard outlawed (perhaps rightly so). There is nothing advanced about
> > the technique used, nor was it "exploited" in any sense.
>
> My remarks go quite a bit further than this particular issue in this
> particuler thread :-) Sorry if that caused confusion, or irratation.
>
> >> Hence, I fully support an API change, and a drastic one, namely making KDL
> >> into a plain C library, all the way through. For the following reasons:
> >> - maintainability: the semantic differences between C compilers is an order
> >> of magnitude less than for C++;
> >
> > The difference between C++ compilers has no bearing here; that's a
> > specious argument. This is a standards issue, and KDL has run into the
> > problem on the first compilers to adhere to the new standard. In time,
> > all modern compilers will adhere to the standard and then all these
> > compilers will have the same issue. And in my experience, having multiple
> > compilers is a good thing as they do help to find more issues.
>
> The semantics of the _runtime_ that different compilers generate is not
> fully standardized, and these things cause uncertainty in the exact
> realtime performance. This is not a problem for most features, but things
> like exceptions will remain unpredictable between compilers. At least, if I
> understand the technology correctly...
>
> >> - clarity of the code: much of the Eigen and Boost stuff is hiding
> >> behaviour (especially realtime) opaquely behind interfaces with side
> >> effects;
> >
> > Can you provide some examples of these "side effects"? I agree that Eigen
> > and Boost can hide stuff, but I would also bet no one on this ML can
> > write as optimized a code as Eigen has, particularly on multiple
> > platforms; if you want performance, that's a definite example were
> > template black magic can achieve some utterly amazing things.
>
> I want code whose semantics can be understood, ultimately, by robots, and
> not just by compilers. I know that this sounds a bit extreme in a "hackers"
> community, but the more "intelligence" one wants to bring into a system,
> the less one want to rely on compiler "features" to support that.
> Templates and exceptions are two examples of necessary aspects of
> intelligent behaviour, and these are exactly two aspects for which
> compilers hide the exact behavioural semantics inside the runtime.

Templates and exceptions are necessary aspects of any decent programming
language and are important for even unintelligent behaviour. C and C++
are so badly designed that cannot well support even these two basic
programming concepts (not to say about real-time programming).

> >> - platform support: the future is for mixed-hardware systems, where parts
> >> of the functionality will have to run on "accelerated" hardware, such as
> >> GPUs or FPGAs, embedded or not in the same System-on-a-chip; C is ready for
> >> that ambition, C++ isn't;
> >
> > That's a very broad statement Herman. Yes, mixed-hardware systems are
> > becoming more common, but it can take an extraordinary amount of
> > knowledge and experience to do co-design, let alone the skills to write
> > good FPGA code.
>
> The FPGA tools are extremely good, a lot better than what mainstream
> hackers are used to. And their quality comes exactly from a _very_ deep
> level of _modelling_ of all platform aspects ("bus", "ram" and "cpu") which
> is almost completely absent in our C++ compilers.
>
> >> - the correctness-at-build-time tests (which are a valid design motivation
> >> in themselves!) can also be taken care of with _tooling_, that is
> >> completely programming language agnostic, and works on a _formal model_ of
> >> the to be constructed primitives, in casy kinematic trees;
> >
> > How does this not apply to C++ code?
>
> Take templates as an example: they are a "poor man's version" of
> Model-Driven Engineering.

Templates were not intended to substitute MDE. They are "poor man's
implementation" of parametric polymorphism (and dependent types).

There is a lot of research in the programming language design that is
still neglected by the robotics community. MDE is an extremely "fat"
approach to several problems that could be solved at the programming
language level. A stateful API is just one of examples. However, we can
do very little if we stick to C vs C++ discussions.

I am not against MDE, but there are some interesting "lighter"
alternatives for software engineering in robotics.

KDL TreeElement API changes

On Thu, 13 Feb 2014, Piotr Trojanek wrote:

> On Thu, Feb 13, 2014 at 09:24:05PM +0100, Herman Bruyninckx wrote:
>> On Thu, 13 Feb 2014, S Roderick wrote:
>>
>>> On Feb 11, 2014, at 05:54 , Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>>>
>>>> On Tue, 11 Feb 2014, Ruben Smits wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> More recent compilers seem to have problems with the TreeElement
>>>>> definition: see
>>>>> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
>>>>> information. There seems to be no easy way to fix this without an API
>>>>> change.
>>>>>
>>>>> I'm currently trying to get an estimate of the impact of this change
>>>>> for our users-base. I know the Tree structure and its solvers are less
>>>>> used than the Chain variants but I still would like to query the
>>>>> community to see if anyone would object a merge of the pull request.
>>>>>
>>>>> It is still open if we will use plain pointers or shared pointers.
>>>>>
>>>>> So if anyone objects with the pending API change or has a more elegant
>>>>> solution, please speak up.
>>>>
>>>> My two cents...
>>>>
>>>> I think (hope...) that the robotics community has bounced its head enough
>>>> times against the wall, hard, to have learned that "exploiting" "advanced"
>>>> C++ features is not the most maintainable way to go...
>>>
>>> The problem here was use of a well known and well accepted C++ approach
>>> (which actually derives from a standard C approach), which a newer C++
>>> standard outlawed (perhaps rightly so). There is nothing advanced about
>>> the technique used, nor was it "exploited" in any sense.
>>
>> My remarks go quite a bit further than this particular issue in this
>> particuler thread :-) Sorry if that caused confusion, or irratation.
>>
>>>> Hence, I fully support an API change, and a drastic one, namely making KDL
>>>> into a plain C library, all the way through. For the following reasons:
>>>> - maintainability: the semantic differences between C compilers is an order
>>>> of magnitude less than for C++;
>>>
>>> The difference between C++ compilers has no bearing here; that's a
>>> specious argument. This is a standards issue, and KDL has run into the
>>> problem on the first compilers to adhere to the new standard. In time,
>>> all modern compilers will adhere to the standard and then all these
>>> compilers will have the same issue. And in my experience, having multiple
>>> compilers is a good thing as they do help to find more issues.
>>
>> The semantics of the _runtime_ that different compilers generate is not
>> fully standardized, and these things cause uncertainty in the exact
>> realtime performance. This is not a problem for most features, but things
>> like exceptions will remain unpredictable between compilers. At least, if I
>> understand the technology correctly...
>>
>>>> - clarity of the code: much of the Eigen and Boost stuff is hiding
>>>> behaviour (especially realtime) opaquely behind interfaces with side
>>>> effects;
>>>
>>> Can you provide some examples of these "side effects"? I agree that Eigen
>>> and Boost can hide stuff, but I would also bet no one on this ML can
>>> write as optimized a code as Eigen has, particularly on multiple
>>> platforms; if you want performance, that's a definite example were
>>> template black magic can achieve some utterly amazing things.
>>
>> I want code whose semantics can be understood, ultimately, by robots, and
>> not just by compilers. I know that this sounds a bit extreme in a "hackers"
>> community, but the more "intelligence" one wants to bring into a system,
>> the less one want to rely on compiler "features" to support that.
>> Templates and exceptions are two examples of necessary aspects of
>> intelligent behaviour, and these are exactly two aspects for which
>> compilers hide the exact behavioural semantics inside the runtime.
>
> Templates and exceptions are necessary aspects of any decent programming
> language and are important for even unintelligent behaviour. C and C++
> are so badly designed that cannot well support even these two basic
> programming concepts (not to say about real-time programming).

This is a better expression of the situation than mine, thanks :-)

>>>> - platform support: the future is for mixed-hardware systems, where parts
>>>> of the functionality will have to run on "accelerated" hardware, such as
>>>> GPUs or FPGAs, embedded or not in the same System-on-a-chip; C is ready for
>>>> that ambition, C++ isn't;
>>>
>>> That's a very broad statement Herman. Yes, mixed-hardware systems are
>>> becoming more common, but it can take an extraordinary amount of
>>> knowledge and experience to do co-design, let alone the skills to write
>>> good FPGA code.
>>
>> The FPGA tools are extremely good, a lot better than what mainstream
>> hackers are used to. And their quality comes exactly from a _very_ deep
>> level of _modelling_ of all platform aspects ("bus", "ram" and "cpu") which
>> is almost completely absent in our C++ compilers.
>>
>>>> - the correctness-at-build-time tests (which are a valid design motivation
>>>> in themselves!) can also be taken care of with _tooling_, that is
>>>> completely programming language agnostic, and works on a _formal model_ of
>>>> the to be constructed primitives, in casy kinematic trees;
>>>
>>> How does this not apply to C++ code?
>>
>> Take templates as an example: they are a "poor man's version" of
>> Model-Driven Engineering.
>
> Templates were not intended to substitute MDE. They are "poor man's
> implementation" of parametric polymorphism (and dependent types).

And that is the first step towards real MDE :-) But only the first one.

> There is a lot of research in the programming language design that is
> still neglected by the robotics community. MDE is an extremely "fat"
> approach to several problems that could be solved at the programming
> language level. A stateful API is just one of examples. However, we can
> do very little if we stick to C vs C++ discussions.
>
> I am not against MDE, but there are some interesting "lighter"
> alternatives for software engineering in robotics.

Not in the form of AST-based, context-free languages... Because "knowledge"
_is_ context-dependent. And that complexity even shows up in "simple"
solvers like hybrid dynamics for robotic chains! Especially when they are
not trees, such as the human musculo-skeletal system.

KDL TreeElement API changes

On Feb 11, 2014, at 05:36 , Ruben Smits <ruben [dot] smits [..] ...> wrote:

> Hi all,
>
> More recent compilers seem to have problems with the TreeElement
> definition: see
> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
> information. There seems to be no easy way to fix this without an API
> change.
>
> I'm currently trying to get an estimate of the impact of this change
> for our users-base. I know the Tree structure and its solvers are less
> used than the Chain variants but I still would like to query the
> community to see if anyone would object a merge of the pull request.

The tree implementation is broken by the C++11 standards. No way around that. We just conditionally don't compile the entire implementation on modern compilers.

I don't see a completed, alternative implementation at that pull request though. Is this something that is in the works?

> It is still open if we will use plain pointers or shared pointers.

We don't really care, as long as you use boost if you go with shared pointers. That's a dependancy for anyone using RTT anyway.

I would advocate against any custom smart pointer wrapper implementation (as noted in the pull request) unless truly necessary. There doesn't seem to be a driving need for it, particularly when boost provides such comprehensive smart pointer-type support.

> So if anyone objects with the pending API change or has a more elegant
> solution, please speak up.

We don't use tree so w're quite happy to have the API changed. :-)
S

KDL TreeElement API changes

Personally, I would prefer to use plain pointers over shared pointers to
avoid relying on additional dependencies (boost::shared_ptr) or recent
compiler features (C++11). This would maximize the chances that if current
KDL compiles on a given set-up, also the new version of KDL will continue
to compile on the same set-up without the need of any change in the host
(i.e. upgrade compiler or install a new library).

On Tue, Feb 11, 2014 at 11:36 AM, Ruben Smits
<ruben [dot] smits [..] ...>wrote:

> Hi all,
>
> More recent compilers seem to have problems with the TreeElement
> definition: see
> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
> information. There seems to be no easy way to fix this without an API
> change.
>
> I'm currently trying to get an estimate of the impact of this change
> for our users-base. I know the Tree structure and its solvers are less
> used than the Chain variants but I still would like to query the
> community to see if anyone would object a merge of the pull request.
>
> It is still open if we will use plain pointers or shared pointers.
>
> So if anyone objects with the pending API change or has a more elegant
> solution, please speak up.
>
> Ruben
>
> --
> Ruben Smits, CTO
> +32 479 511 786
> Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
> www.intermodalics.eu
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------
> This email and any attached files are confidential and may be legally
> privileged. Any copy, print or forward of this email, without the
> agreement of sender or addressee, is strictly prohibited. Misuse is a
> violation of the law on personal data protection (D. Lgs. 196/2003)
> and on secrecy of correspondence (art. 616 cp). If you have received
> this transmission in error please notify the sender immediately and
> then delete this email and any attached files.
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>

KDL TreeElement API changes

On Di, Feb 11, 2014 at 12:41:41 +0100, Silvio Traversaro wrote:
>Personally, I would prefer to use plain pointers over shared pointers to avoid
>relying on additional dependencies (boost::shared_ptr) or recent compiler
>features (C++11). This would maximize the chances that if current KDL compiles
>on a given set-up, also the new version of KDL will continue to compile on the
>same set-up without the need of any change in the host (i.e. upgrade compiler or
>install a new library).

+1

Markus

KDL TreeElement API changes

On 02/11/2014 11:36 AM, Ruben Smits wrote:
> Hi all,
>
> More recent compilers seem to have problems with the TreeElement
> definition: see
> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
> information. There seems to be no easy way to fix this without an API
> change.
>
> I'm currently trying to get an estimate of the impact of this change
> for our users-base. I know the Tree structure and its solvers are less
> used than the Chain variants but I still would like to query the
> community to see if anyone would object a merge of the pull request.
>
> It is still open if we will use plain pointers or shared pointers.
>
> So if anyone objects with the pending API change or has a more elegant
> solution, please speak up.

since you'll be braking API anyway, maybe it's an opportunity to look at API consistency between chain and tree, as proposed earlier:
http://orocos.org/wiki/main-page/kdl-wiki/user-manual/kinematic-chains/k...
http://www.orocos.org/forum/rtt/rtt-dev/feedback-api-change-kdl-tree-and...
http://git.mech.kuleuven.be/?p=robotics/orocos_kinematics_dynamics.git;a...

nick

>
> Ruben
>

KDL TreeElement API changes

Hey Ruben,

> More recent compilers seem to have problems with the TreeElement
> definition: see
> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
> information. There seems to be no easy way to fix this without an API
> change.
>
I guess the issue is raised by the correct implementation of C++11 features
in modern compilers (finally!)

>
> I'm currently trying to get an estimate of the impact of this change
> for our users-base. I know the Tree structure and its solvers are less
> used than the Chain variants but I still would like to query the
> community to see if anyone would object a merge of the pull request.
>
It will influence my code, but It won't be painful for me.

>
> It is still open if we will use plain pointers or shared pointers.
>
I would prefer the usage of shared pointers, if possible. I would also
consider which implementation to use (boost or std in C++11?)
Between these, I would start using C++11 features, with an eye for boost
for retrocompatibility....(MS C++ Compiler does not fully implement all C++
new features, as far I know...)

- Enea