Hi, ----- Original Message ----- From: "John Maddock" To: Sent: Wednesday, December 09, 2009 1:55 PM Subject: Re: [Boost-users] [integer]/cstdint.hpp How to use portableliterals?

...

I need to use boost::intmax_t literals in a portable way. I remember some discussion related to this subject, but I've not found the thread. Could

...

someone point me to these threads, or tell me how I can achieve this.

I'm currently using the macro INTMAX_C, but it seems that this macro is not always defined.

You need to ensure that __STDC_CONSTANT_MACROS is defined *before any headers are #included* in order to use that macro.

Doesn't boost/cstdlib.hpp provide a way to define boost::intmax_t literals in a portable way? Vicente

Hi, ----- Original Message ----- From: "John Maddock" To: Sent: Thursday, December 10, 2009 10:37 AM Subject: Re: [Boost-users] [integer]/cstdint.hpp How to use portableliterals?

...

...

You need to ensure that __STDC_CONSTANT_MACROS is defined *before any headers are #included* in order to use that macro.

Doesn't boost/cstdlib.hpp provide a way to define boost::intmax_t literals in a portable way?

It implements <cstdint> for better or worse,

How can a library ensure that __STDC_CONSTANT_MACROS is defined *before any headers are #included*? Best, Vicente

AMDG Ovanes Markarian wrote:

Compiler flag ;) gcc -D and in Project setting of VC ;)

On Thu, Dec 10, 2009 at 1:45 PM, vicente.botet wrote:

...

How can a library ensure that __STDC_CONSTANT_MACROS is defined *before any headers are #included*?

The question was how a /library/ can ensure this, not how a user can ensure it. In Christ, Steven Watanabe

Compiler flag ;) gcc -D and in Project setting of VC ;)

Sure, but that doesn't work in a library header file where you have no control over project settings... I'm thinking that maybe we should change boost/cstdint.hpp to follow C++0x and always define these macros, any objections or problems if we do that? John.

John Maddock wrote:

I'm thinking that maybe we should change boost/cstdint.hpp to follow C++0x and always define these macros, any objections or problems if we do that?

Yes, please. Otherwise the user will need to do something that will be less portable #ifdef INTMAX_C #define BOOST_XX_INTMAX_C(a) INTMAX_C(a) #else #define BOOST_XX_INTMAX_C(a) a##LL // or something based on the type size and the compiler as boost/cstdint.hpp does #endif Best, Vicente -- View this message in context: http://old.nabble.com/-integer--cstdint.hpp-How-to-use-portable-literals--tp... Sent from the Boost - Users mailing list archive at Nabble.com.

Kim Barrett-2 wrote:

On Dec 10, 2009, at 11:18 AM, John Maddock wrote:

...

...

Compiler flag ;) gcc -D and in Project setting of VC ;)

Sure, but that doesn't work in a library header file where you have no control over project settings...

I'm thinking that maybe we should change boost/cstdint.hpp to follow C++0x and always define these macros, any objections or problems if we do that?

This isn't a general solution. Consider

#include <something which includes stdint.h> #include

Documenting a required compiler flag is really the better solution, in my opinion.

That, and perhaps some utility macros to help library developers detect and report misconfiguration in a way that might direct users toward a solution.

Hi, I don't see any problem in the above code. Just boost/cstdint.hpp need to define INTMAX_C even if not defined by the preceding inclusion of #include <something which includes stdint.h>. As Howard has been signaled, C++0x <cstdint> will define INTMAX_C independently of __STDC_CONSTANT_MACROS is defined or not. Best, Vicente -- View this message in context: http://old.nabble.com/-integer--cstdint.hpp-How-to-use-portable-literals--tp... Sent from the Boost - Users mailing list archive at Nabble.com.

John Maddock wrote:

...

Compiler flag ;) gcc -D and in Project setting of VC ;)

Sure, but that doesn't work in a library header file where you have no control over project settings...

I'm thinking that maybe we should change boost/cstdint.hpp to follow C++0x and always define these macros, any objections or problems if we do that?

It's the right thing to do. Patrick

John, it might make sense to introduce the inverse macro, like BOOST_NO_STDC_CONSTANT_MACROS, so that users are able to selectively switch off boost definitions. But that is only an idea, not sure if that is really required. Best Regards, Ovanes On Fri, Dec 11, 2009 at 7:01 PM, John Maddock wrote:

Hopefully it won't break too much ;-)