Adding detection of [u]intptr_t to Boost.Config (moving it from cstdint.hpp)
Any objection to me doing this? It would, of course, be non-breaking to anyone currently consuming it from Boost.Integer's cstdint.hpp. Glen
Glen Fernandes wrote:
Any objection to me doing this?
It would, of course, be non-breaking to anyone currently consuming it from Boost.Integer's cstdint.hpp.
How 'bout we just move cstdint.hpp to Config? It's even written by John according to the copyright notice and does not depend on anything.
On Fri, May 30, 2014 at 9:51 AM, Peter Dimov wrote:
How 'bout we just move cstdint.hpp to Config? It's even written by John according to the copyright notice and does not depend on anything.
That would be even better and, given Andrey's reply, a less-opposed notion than I initially thought it would be. Glen
On Friday 30 May 2014 09:44:28 Glen Fernandes wrote:
Any objection to me doing this?
It would, of course, be non-breaking to anyone currently consuming it from Boost.Integer's cstdint.hpp.
Is there a reason for it? The standard types are defined in cstdint, so boost/cstdint.hpp looks like the appropriate place to me. You might consider moving the whole boost/cstdint.hpp (along with its documentation) if there's a strong reason for it.
On Fri, May 30, 2014 at 10:06 AM, John Maddock wrote:
What's the rationale?
On Fri, May 30, 2014 at 9:52 AM, Andrey Semashev wrote:
Is there a reason for it?
Andrey, John: My motivation was that it fits in the category of compiler/standard library feature detection useful for Boost library authors who only want that particular feature of Boost.Integer and prefer not to pull in boost::<integer types> just for that detection. Glen
On Friday 30 May 2014 10:13:57 Glen Fernandes wrote:
On Fri, May 30, 2014 at 10:06 AM, John Maddock wrote:
What's the rationale?
On Fri, May 30, 2014 at 9:52 AM, Andrey Semashev wrote:
Is there a reason for it?
Andrey, John: My motivation was that it fits in the category of compiler/standard library feature detection useful for Boost library authors who only want that particular feature of Boost.Integer and prefer not to pull in boost::<integer types> just for that detection.
I have no problem if cstdint.hpp is moved as a whole, including its docs and tests. It seems, it only depends on Boost.Config (except for Boost.Detail in tests). What I wouldn't like is to split it into different headers across different libraries. As I mentioned, cstdint.hpp is supposed to reflect cstdint, so it should provide all the typedefs.
On Fri, May 30, 2014 at 9:52 AM, Andrey Semashev wrote:
Is there a reason for it?
Andrey, John: My motivation was that it fits in the category of compiler/standard library feature detection useful for Boost library authors who only want that particular feature of Boost.Integer and prefer not to pull in boost::<integer types> just for that detection.
I have no problem if cstdint.hpp is moved as a whole, including its docs and tests. It seems, it only depends on Boost.Config (except for Boost.Detail in tests). What I wouldn't like is to split it into different headers across different libraries. As I mentioned, cstdint.hpp is supposed to reflect cstdint, so it should provide all the typedefs.
Hmm, I guess the question is where will users expect to find the docs/tests for that file? My guess is that it's probably not in config, but I may be wrong.... John.
On Friday 30 May 2014 18:54:20 John Maddock wrote:
On Fri, May 30, 2014 at 9:52 AM, Andrey Semashev wrote:
I have no problem if cstdint.hpp is moved as a whole, including its docs and tests. It seems, it only depends on Boost.Config (except for Boost.Detail in tests). What I wouldn't like is to split it into different headers across different libraries. As I mentioned, cstdint.hpp is supposed to reflect cstdint, so it should provide all the typedefs.
Hmm, I guess the question is where will users expect to find the docs/tests for that file? My guess is that it's probably not in config, but I may be wrong....
I'm not sure either, but Boost.Integer looks no better place than Boost.Config to me. What I'm certain of is that splitting implementation, docs and tests between different submodules it not a good idea. I think we could leave a link in Boost.Integer docs to Boost.Config so that people used to the current docs don't get confused after the move.
On 30 May 2014 19:13, Andrey Semashev
I'm not sure either, but Boost.Integer looks no better place than Boost.Config to me. What I'm certain of is that splitting implementation, docs and tests between different submodules it not a good idea.
I think we could leave a link in Boost.Integer docs to Boost.Config so that people used to the current docs don't get confused after the move.
And a redirect from the current location so that links don't break.
Andrey, John: My motivation was that it fits in the category of compiler/standard library feature detection useful for Boost library authors who only want that particular feature of Boost.Integer and prefer not to pull in boost::<integer types> just for that detection.
OK. Note, however that the location of those types may vary by
compiler/platform - the only way to be sure you've pulled in the correct
header is to include
On Fri, May 30, 2014 at 10:53 AM, John Maddock
Andrey, John: My motivation was that it fits in the category of compiler/standard library feature detection useful for Boost library authors who only want that particular feature of Boost.Integer and prefer not to pull in boost::<integer types> just for that detection.
OK. Note, however that the location of those types may vary by compiler/platform - the only way to be sure you've pulled in the correct header is to include
. On the other hand, if you're relying on then BOOST_HAS_STDINT_H looks to do what you want anyway?
Except even a conforming stdint.h (or cstdint) is not required to provide uintptr_t/intptr_t (or std::uintptr_t/std::intptr_t). The standard should ideally have specified macros to allow C++ developers to detect whether the implementation has chosen to provide those types, in my opinion. However, since it does not, nothing inhibits Boost (especially Boost.Config) from solving that problem for developers (and not just fellow Boost library developers). Glen
Except even a conforming stdint.h (or cstdint) is not required to provide uintptr_t/intptr_t (or std::uintptr_t/std::intptr_t). The standard should ideally have specified macros to allow C++ developers to detect whether the implementation has chosen to provide those types, in my opinion. However, since it does not, nothing inhibits Boost (especially Boost.Config) from solving that problem for developers (and not just fellow Boost library developers).
Ah, OK go for it. John.
participants (5)
-
Andrey Semashev -
Daniel James -
Glen Fernandes -
John Maddock -
Peter Dimov