chore: fix deprecations by doudou · Pull Request #21 · rock-core/rtt

doudou · 2025-12-30T19:50:00Z

I fixed most warnings related to the increase in C++ version (and boost as well). However, the PR disables the built-in typekit since it relies on type deduction that I did not want to resolve (and Rock should really not depend on that built-in typekit anyways)

boost/bind.hpp imports the placeholders at toplevel, which is a deprecated behaviour. Include boost/bind/bind.hpp instead and import the relevant namespaces when needed. Note that we should move to std::bind at some point

pierrewillenbrockdfki

Looks good to me. I am going to try this locally on our CI package-set and probably also a bit of runtime-testing.

pierrewillenbrockdfki · 2026-01-05T12:04:44Z

Some small comments:

One can configure a user-global gitignore file(property core.excludesfile in .gitconfig). On the other hand, i have seen people check in their IDEs files on accident because they did not know, adding them to the repositories gitignore prevents that from happening.
I try to bunch my whitespace changes into a separate commit, so people can just skip them. Not much of an issue here, i'd like to add. Where things get bad is mixing reordering stuff and actual changes, sometimes one needs to split the commit just to review the changed bits.
Lambdas are more efficient than std::bind

pierrewillenbrockdfki · 2026-01-05T14:10:20Z

Found a compile issue, investigating. https://github.com/rock-data-processing/data_processing-orogen-type_to_vector
This is due to a leaked using namespace that no longer exists, i'd guess. I am going to provide a fix over there. No need to wait for that package. rock-data-processing/data_processing-orogen-type_to_vector#5

Looks like nothing else broke, a very small check if our various runtime orchestrations tools still work came back positive.

chhtz

Thanks a lot for cleaning this up!

My suggestions for improvement can also be done separately. I think there is also a lot of boiler-plate code which can be avoided now (assuming at least C++11 is used to compile)

chhtz · 2026-01-06T10:51:14Z

    PropertyBase* PropertyBag::find(const std::string& name) const
    {
-        const_iterator i( std::find_if(mproperties.begin(), mproperties.end(), std::bind2nd(FindProp(), name ) ) );
+        const_iterator i( std::find_if(mproperties.begin(), mproperties.end(), std::bind(FindProp(), placeholders::_1, name ) ) );


One can avoid the bind by passing name to FindProp, or just using a lambda:

std::find_if(mproperties.begin(), mproperties.end(), [](const base::PropertyBase *b1 ){return b1->getName() == name;} );

chhtz · 2026-01-06T10:52:30Z

        return 0;
    }

    base::PropertyBase* PropertyBag::getProperty(const std::string& name) const


This seems to be the same as PropertyBag::find? Maybe have one function call the other (and mark it deprecated)

chhtz · 2026-01-06T10:54:08Z

+#include <boost/bind/bind.hpp>

+using namespace boost::placeholders;


Maybe it would be a good opportunity to also replace boost::bind by std::bind?

chhtz · 2026-01-06T10:55:44Z

        Property<T>* getPropertyType(const std::string& name) const
        {
-            const_iterator i( std::find_if(mproperties.begin(), mproperties.end(), std::bind2nd(FindPropType<T>(), name ) ) );
+            const_iterator i( std::find_if(mproperties.begin(), mproperties.end(), std::bind(FindPropType<T>(), std::placeholders::_1, name ) ) );


Same as with getProperty, I would simply use a lambda here.

chhtz

I'm getting errors like the following at the moment:

In file included from /WS/tools/rtt/rtt/typekit/RealTimeTypekitOperators.cpp:44:
/WS/tools/rtt/rtt/typekit/../types/OperatorTypes.hpp: In instantiation of ‘class RTT::types::UnaryOperator<RTT::internal::identity<int> >’:
/WS/tools/rtt/rtt/typekit/RealTimeTypekitOperators.cpp:120:18:   required from here
/WS/tools/rtt/rtt/typekit/../types/OperatorTypes.hpp:58:90: error: no type named ‘argument_type’ in ‘struct RTT::internal::identity<int>’
   58 |             typedef typename internal::remove_cr<typename function::argument_type>::type arg_t;
      |                                                                                          ^~~~~
/WS/tools/rtt/rtt/typekit/../types/OperatorTypes.hpp:59:88: error: no type named ‘result_type’ in ‘struct RTT::internal::identity<int>’
   59 |             typedef typename internal::remove_cr<typename function::result_type>::type result_t;
      |                                                                                        ^~~~~~~~
/WS/tools/rtt/rtt/typekit/../types/OperatorTypes.hpp:67:45: error: no type named ‘result_type’ in ‘struct RTT::internal::identity<int>’
   67 |             internal::DataSource<result_t>* build( const std::string& op, base::DataSourceBase* a )
      |                                             ^~~~~

This is likely caused by not inheriting from (the deprecated) std::unary_function anymore.

pierrewillenbrockdfki · 2026-01-06T12:28:35Z

I'm getting errors like the following at the moment:

In file included from /WS/tools/rtt/rtt/typekit/RealTimeTypekitOperators.cpp:44:
/WS/tools/rtt/rtt/typekit/../types/OperatorTypes.hpp: In instantiation of ‘class RTT::types::UnaryOperator<RTT::internal::identity<int> >’:
/WS/tools/rtt/rtt/typekit/RealTimeTypekitOperators.cpp:120:18:   required from here
/WS/tools/rtt/rtt/typekit/../types/OperatorTypes.hpp:58:90: error: no type named ‘argument_type’ in ‘struct RTT::internal::identity<int>’
   58 |             typedef typename internal::remove_cr<typename function::argument_type>::type arg_t;
      |                                                                                          ^~~~~
/WS/tools/rtt/rtt/typekit/../types/OperatorTypes.hpp:59:88: error: no type named ‘result_type’ in ‘struct RTT::internal::identity<int>’
   59 |             typedef typename internal::remove_cr<typename function::result_type>::type result_t;
      |                                                                                        ^~~~~~~~
/WS/tools/rtt/rtt/typekit/../types/OperatorTypes.hpp:67:45: error: no type named ‘result_type’ in ‘struct RTT::internal::identity<int>’
   67 |             internal::DataSource<result_t>* build( const std::string& op, base::DataSourceBase* a )
      |                                             ^~~~~

This is likely caused by not inheriting from (the deprecated) std::unary_function anymore.

You are still building the typekit; only the default has changed to not build it, an existing build directory will keep building the typekit until you change the option.

chhtz · 2026-01-06T13:49:36Z

You are still building the typekit; only the default has changed to not build it, an existing build directory will keep building the typekit until you change the option.

You are right, rtt builds after deleting the existing build-directory and running amake. But if it is not possible to build this anymore, it should better be removed completely, right?

doudou · 2026-01-09T15:24:23Z

I changed the startegy ... Turns out that the void typeinfo is not provided by orogen (and I'd prefer adding support to this later). I now disable the problematic parts related to unary/binary functions if PLUGINS_ENABLE_SCRIPTING is OFF. This flag now disables the "operators" and "constructors" in the type info, which is what is actually depending on them. One gets essentially the same RTT if ENABLE_SCRIPTING is ON.

@chhtz and @pierrewillenbrockdfki properly migrating to C++XX (we have to choose the target XX here) is not part of this PR. IMO we should first agree on a subset of RTT we want to support and move what we do not support (e.g. scripting for me) to a rtt-extras package (or remove it altogether ... it is after all our RTT)

chhtz · 2026-01-12T16:43:33Z

@chhtz and @pierrewillenbrockdfki properly migrating to C++XX (we have to choose the target XX here) is not part of this PR. [...]

I'm fine with doing that at a later point. But if you change std::bind2nd(FindProp(), name ) to std::bind(FindProp(), placeholders::_1, name ), you require C++11 or later anyways. If you want to stay compatible with C++03, you could make name a member of FindProp with a unary operator(), and construct it with FindProp(name) (no bind necessary).

[...] IMO we should first agree on a subset of RTT we want to support and move what we do not support (e.g. scripting for me) to a rtt-extras package (or remove it altogether ... it is after all our RTT)

I honestly don't know for sure which parts of RTT are needed where. I'm fine with separating optional parts into a different library or disable compiling them by default.

pierrewillenbrockdfki · 2026-01-20T11:07:56Z

@doudou Does it make sense to enable issues in this repository for discussing this, considering that it will not be merged back anytime soon?

doudou · 2026-01-22T13:08:48Z

@doudou Does it make sense to enable issues in this repository for discussing this, considering that it will not be merged back anytime soon?

It would. From my perspective this is a hard fork.

doudou · 2026-01-22T13:10:00Z

@chhtz and @pierrewillenbrockdfki properly migrating to C++XX (we have to choose the target XX here) is not part of this PR. [...]

I'm fine with doing that at a later point. But if you change std::bind2nd(FindProp(), name ) to std::bind(FindProp(), placeholders::_1, name ), you require C++11 or later anyways. If you want to stay compatible with C++03, you could make name a member of FindProp with a unary operator(), and construct it with FindProp(name) (no bind necessary).

[...] IMO we should first agree on a subset of RTT we want to support and move what we do not support (e.g. scripting for me) to a rtt-extras package (or remove it altogether ... it is after all our RTT)

I honestly don't know for sure which parts of RTT are needed where. I'm fine with separating optional parts into a different library or disable compiling them by default.

I don't. XX >= 11. But I really wanted to be as mechanistic as possible and not get into the whole "let's get rid of boost".

Again, I'd be happy that we do it, but I have a 24.04 migration to finish first ;-)

pierrewillenbrockdfki · 2026-02-20T15:55:48Z

The compiler is allowed to assume all references are to valid objects; main difference to pointers(except this, which can also always be considred valid). The call sites that convert from a pointer need to do the checking, if any.

This actually breaks backward compatibility (technically) since I did not update the internal typekit - which is not used within Rock

We do ignore it explicitly since the place where this happens is a crash handler ... that the write does not go through properly is the least of our worries

This fixes longstanding warnings about Eigen types on data ports, and possibly remove some UBs we are not aware of.

The compiler assumes it true, so it's probably elided at any optimization level anyways

doudou · 2026-03-04T13:45:58Z

@chhtz can you check that the problem is fixed now for you ?

chhtz

LGTM
My previous comments can be addressed in a later change

fix: deprecated usage of boost/bind.hpp

f9e542a

boost/bind.hpp imports the placeholders at toplevel, which is a deprecated behaviour. Include boost/bind/bind.hpp instead and import the relevant namespaces when needed. Note that we should move to std::bind at some point

doudou requested review from jhonasiv and pierrewillenbrockdfki December 30, 2025 19:50

doudou mentioned this pull request Dec 30, 2025

chore: be compatible with a RTT built without its built-in typekit rock-core/tools-orogen#27

Closed

pierrewillenbrockdfki approved these changes Jan 5, 2026

View reviewed changes

jhonasiv approved these changes Jan 5, 2026

View reviewed changes

chhtz approved these changes Jan 6, 2026

View reviewed changes

chhtz requested changes Jan 6, 2026

View reviewed changes

doudou force-pushed the deprecations branch from 29dcd36 to 63d189c Compare January 9, 2026 15:21

pierrewillenbrockdfki mentioned this pull request Jan 29, 2026

C++XX requirement/support, which bits of RTT to keep maintaining #22

Open

doudou force-pushed the deprecations branch from 63d189c to 26df67d Compare February 5, 2026 17:40

doudou added 8 commits March 4, 2026 08:26

chore: remove usage of unary_function and binary_function

39525e5

This actually breaks backward compatibility (technically) since I did not update the internal typekit - which is not used within Rock

chore: fix warnings about requires becoming a keyword in C++20

3ec675e

chore: update gitignore

987452e

fix: remove deprecated bind2nd and bind1st

38accc5

chore: fix warning about ignoring the return value of write()

adab11b

We do ignore it explicitly since the place where this happens is a crash handler ... that the write does not go through properly is the least of our worries

chore: replace deprecated filesystem methods by their new names

4bd84d2

chore: replace T() by T{} to properly zero-initialize values

6a8264d

This fixes longstanding warnings about Eigen types on data ports, and possibly remove some UBs we are not aware of.

fix: remove comparison of &ref with NULL

6fe494a

The compiler assumes it true, so it's probably elided at any optimization level anyways

doudou force-pushed the deprecations branch from 26df67d to 6fe494a Compare March 4, 2026 11:26

doudou requested a review from chhtz March 4, 2026 13:46

chhtz approved these changes Mar 4, 2026

View reviewed changes

doudou merged commit edbda4f into master Mar 4, 2026

doudou deleted the deprecations branch March 4, 2026 19:16

		#include <boost/bind/bind.hpp>

		using namespace boost::placeholders;

Conversation

doudou commented Dec 30, 2025

Uh oh!

pierrewillenbrockdfki left a comment

Choose a reason for hiding this comment

Uh oh!

pierrewillenbrockdfki commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pierrewillenbrockdfki commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chhtz left a comment

Choose a reason for hiding this comment

Uh oh!

chhtz Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

chhtz Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

chhtz Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

chhtz Jan 6, 2026

Choose a reason for hiding this comment

Uh oh!

chhtz left a comment

Choose a reason for hiding this comment

Uh oh!

pierrewillenbrockdfki commented Jan 6, 2026

Uh oh!

chhtz commented Jan 6, 2026

Uh oh!

doudou commented Jan 9, 2026

Uh oh!

chhtz commented Jan 12, 2026

Uh oh!

pierrewillenbrockdfki commented Jan 20, 2026

Uh oh!

doudou commented Jan 22, 2026

Uh oh!

doudou commented Jan 22, 2026

Uh oh!

pierrewillenbrockdfki commented Feb 20, 2026

Uh oh!

doudou commented Mar 4, 2026

Uh oh!

chhtz left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

pierrewillenbrockdfki commented Jan 5, 2026 •

edited

Loading

pierrewillenbrockdfki commented Jan 5, 2026 •

edited

Loading