Hello, As of commit 5b20f4910d8b6b48b0b6ad2df693d36edf54cf21 in the interprocess repo, the affected files seem to expect prior include of config by the the includer. Apparently this is not obvious to everyone, so it seems worth pointing out. Thanks, Steve.
El 01/02/2015 a las 10:14, Stephen Kelly escribió:
Hello,
As of commit 5b20f4910d8b6b48b0b6ad2df693d36edf54cf21 in the interprocess repo, the affected files seem to expect prior include of config by the the includer.
Apparently this is not obvious to everyone, so it seems worth pointing out.
Thanks,
Steve.
Thank you for spotting this. Best, Ion
Ion Gaztañaga wrote:
El 01/02/2015 a las 10:14, Stephen Kelly escribió:
Hello,
As of commit 5b20f4910d8b6b48b0b6ad2df693d36edf54cf21 in the interprocess repo, the affected files seem to expect prior include of config by the the includer.
Apparently this is not obvious to everyone, so it seems worth pointing out.
Thanks,
Steve.
Thank you for spotting this.
You added +#ifndef BOOST_CONFIG_HPP +# include <boost/config.hpp> +#endif instead of +#include <boost/config.hpp> Why the needless noise? Thanks, Steve.
Stephen Kelly-2 wrote
You added
+#ifndef BOOST_CONFIG_HPP +# include <boost/config.hpp> +#endif
instead of
+#include <boost/config.hpp>
Why the needless noise?
In theory the former prevents the compiler from opening the file at all whereas for the latter the compiler would have to open and reparse the header file. In reality as far as I know most modern compilers are aware of include guards and #pragma once and will not reparse headers when they are included multiple times -- View this message in context: http://boost.2283326.n4.nabble.com/BOOST-HAS-PRAGMA-ONCE-tp4671872p4672042.h... Sent from the Boost - Dev mailing list archive at Nabble.com.
El 04/02/2015 a las 18:11, alanbirtles escribió:
Stephen Kelly-2 wrote
You added
+#ifndef BOOST_CONFIG_HPP +# include <boost/config.hpp> +#endif
instead of
+#include <boost/config.hpp>
Why the needless noise?
In theory the former prevents the compiler from opening the file at all whereas for the latter the compiler would have to open and reparse the header file. In reality as far as I know most modern compilers are aware of include guards and #pragma once and will not reparse headers when they are included multiple times
Yes, it should be a very tiny help.. except if config.hpp also uses pragma once ;-) Best, Ion
Yes, it should be a very tiny help.. except if config.hpp also uses pragma once ;-)
And I've seen it uses it ;-) #ifdef BOOST_HAS_PRAGMA_ONCE #pragma once #endif so it would only help on compilers without pragma once, in any case, I just put that on one file and copy-pasted, there was no any clever intention on that. Best, Ion
On Wed, Feb 4, 2015 at 6:20 PM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Yes, it should be a very tiny help.. except if config.hpp also uses pragma once ;-)
And I've seen it uses it ;-)
#ifdef BOOST_HAS_PRAGMA_ONCE #pragma once #endif
so it would only help on compilers without pragma once, in any case, I just put that on one file and copy-pasted, there was no any clever intention on that.
Compilers without pragma once might also be smart enough not to reopen/reparse the entire file if they detect header guards.
El 04/02/2015 a las 20:28, Stephen Kelly escribió:
Ion Gaztañaga wrote:
Yes, it should be a very tiny help.. except if config.hpp also uses pragma once ;-)
You don't think it's, maybe, relying on implementation details of config, and, maybe, that's not a good thing?
Maybe ;-) It's not something new in boost: http://www.boost.org/doc/libs/1_57_0/boost/type_traits/config.hpp #ifndef BOOST_CONFIG_HPP #include <boost/config.hpp> #endif Nothing will break if boost/config.hpp does not define BOOST_CONFIG_HPP, we'll just loose the tiny help. It's ugly, I agree, but I don't think this is a problem for anyone. Ion
On Thu, Feb 5, 2015 at 8:19 AM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
Nothing will break if boost/config.hpp does not define BOOST_CONFIG_HPP, we'll just loose the tiny help. It's ugly, I agree, but I don't think this is a problem for anyone.
Unnecessarily ugly code is a problem for everyone. ;) -- Olaf
participants (4)
-
alanbirtles -
Ion Gaztañaga -
Olaf van der Spek -
Stephen Kelly