2014-05-24 17:50 GMT+02:00 Beman Dawes :

On Sat, May 24, 2014 at 10:41 AM, Andrzej Krzemienski

...

wrote:

...

2014-05-23 15:21 GMT+02:00 Andrzej Krzemienski :

...

Hi, Is there a macro in Boost.Config that would help me test if a compiler supports a C++11 feature "Rvalue references for *this" ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2439.htm)?

Here is the Trac ticket: https://svn.boost.org/trac/boost/ticket/10067

Have you considered writing it yourself and then submitting a pull request?

The process of creating a defect macro is documented at:

http://www.boost.org/doc/libs/1_55_0/libs/config/doc/html/boost_config/guide...

and of course there are lots of examples in the config library to look at.

Thanks for pointing me to these instructions. However, it may require of me more time that I am can afford. I do not understand some of the instructions. One of the bullets says: "cd into libs/config/test/all and run bjam *MACRONAME compiler-list*, where

*MACRONAME* is the name of the new macro, and *compiler-list* is a space separated list of compilers to test with."

This "compiler-list", I obviously want the macro to work for all possible compilers supported by Boost (and perhaps more), but locally, I can only test it on one. In order to define macro correctly, I would have to use Boost's testing facility, but they are only run on develop and master branches which I cannot commit to. Without having tested my macros on all compilers, I am not sure if my pull request would be a decent one. IOW, I have a chicken and egg problem here, which I do not know how to solve. any help would be much appreciated. Regards, &rzej

2014-05-26 10:32 GMT+02:00 John Maddock :

Thanks for pointing me to these instructions. However, it may require of me

...

more time that I am can afford. I do not understand some of the instructions. One of the bullets says:

"cd into libs/config/test/all and run bjam *MACRONAME compiler-list*, where

...

*MACRONAME* is the name of the new macro, and *compiler-list* is a space

separated list of compilers to test with."

This "compiler-list", I obviously want the macro to work for all possible compilers supported by Boost (and perhaps more), but locally, I can only test it on one. In order to define macro correctly, I would have to use Boost's testing facility, but they are only run on develop and master branches which I cannot commit to. Without having tested my macros on all compilers, I am not sure if my pull request would be a decent one. IOW, I have a chicken and egg problem here, which I do not know how to solve.

any help would be much appreciated.

If you can provide the test case I will test locally before committing anyway.

Thanks for the reply. What is expected of me then? Only the test case in the ipp file? Or also bjam generated test files? Or also the macro definitions in the headers, and the docs? Regards, &rzej

On Mon, May 26, 2014 at 5:04 AM, Andrzej Krzemienski wrote:

2014-05-26 10:32 GMT+02:00 John Maddock :

...

...

more time that I am can afford. I do not understand some of the instructions. One of the bullets says:

"cd into libs/config/test/all and run bjam *MACRONAME compiler-list*, where

...

*MACRONAME* is the name of the new macro, and *compiler-list* is a space

separated list of compilers to test with."

This "compiler-list", I obviously want the macro to work for all

Thanks for pointing me to these instructions. However, it may require of me possible

...

compilers supported by Boost (and perhaps more), but locally, I can only test it on one. In order to define macro correctly, I would have to use Boost's testing facility, but they are only run on develop and master branches which I cannot commit to. Without having tested my macros on all compilers, I am not sure if my pull request would be a decent one. IOW, I have a chicken and egg problem here, which I do not know how to solve.

any help would be much appreciated.

If you can provide the test case I will test locally before committing anyway.

Thanks for the reply. What is expected of me then? Only the test case in the ipp file? Or also bjam generated test files? Or also the macro definitions in the headers, and the docs?

The more you do the less the library maintainer has to do, and that speeds processing the pull request. Most of the above is pretty trivial. For example, to update the docs, edit libs/config/doc/macro_reference.qbk with your favorite text editor. Following the lines that read: [[`BOOST_NO_CXX11_RVALUE_REFERENCES`][The compiler does not support r-value references. ]] Add something like: [[`BOOST_NO_CXX11_RVALUE_REF_THIS`][The compiler does not support r-value references for *this . ]] One thing that can be a bit tricky is editing the compiler files. You might want to just do the one you are testing, and leave the others to config maintainers. --Beman

Ok, I submitted a pull request. Let's see if I got all the instructions right.

Looks like it: I've merged to *develop* not to master, also added the new macro to more (mostly obsolete) compilers. Cheers, John.

...

Ok, I submitted a pull request. Let's see if I got all the instructions

...

right.

Looks like it: I've merged to *develop* not to master, also added the new macro to more (mostly obsolete) compilers.

Thanks. Is it possible to estimate when it will make it to master? (otherwise I cannot use it in Boost.Optional)

No, but I'd like to do another merge to master before the next release - so fairly soon - remind me if it doesn't happen soonish! John.