chore: fix deprecations #21

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

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

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

rtt/PropertyBag.cpp

    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

rtt/PropertyBag.cpp

        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

rtt/ConfigurationInterface.cpp

+#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

rtt/PropertyBag.hpp

        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 added 7 commits December 30, 2025 16:47

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

chore: remove usage of unary_function and binary_function

f8e37f8

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

5c56f46

chore: update gitignore

bac03b7

fix: remove deprecated bind2nd and bind1st

e840015

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

d274cee

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

29dcd36

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

Open

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore: fix deprecations #21

chore: fix deprecations #21

Uh oh!

doudou commented Dec 30, 2025

Uh oh!

pierrewillenbrockdfki left a comment

Uh oh!

pierrewillenbrockdfki commented Jan 5, 2026 •

edited

Loading

Uh oh!

pierrewillenbrockdfki commented Jan 5, 2026 •

edited

Loading

Uh oh!

chhtz left a comment

Uh oh!

chhtz Jan 6, 2026

Uh oh!

chhtz Jan 6, 2026

Uh oh!

chhtz Jan 6, 2026

Uh oh!

chhtz Jan 6, 2026

Uh oh!

chhtz left a comment

Uh oh!

pierrewillenbrockdfki commented Jan 6, 2026

Uh oh!

chhtz commented Jan 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

		#include <boost/bind/bind.hpp>

		using namespace boost::placeholders;

chore: fix deprecations #21

Are you sure you want to change the base?

chore: fix deprecations #21

Uh oh!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

pierrewillenbrockdfki commented Jan 5, 2026 •

edited

Loading

pierrewillenbrockdfki commented Jan 5, 2026 •

edited

Loading