On 2/18/2012 8:36 AM, Klaim - Joël Lamotte wrote:

I guess it is ok to ask about details even if the library isn't in review yet, right?

Sure.. As it certainly won't prevent me from answering them ;-)

I'm not an expert in architecture so I hope I'm not asking something obvious.

My understanding is that for example if you're targeting classic PC hardware, you'll get BOOST_ARCHITECTURE_X86 for 32Bit OS BOOST_ARCHITECTURE_AMD64 for 64Bit OS (running on 64bit processor).

If you are targeting 64Bit you are more likely to get both BOOST_ARCHITECTURE_AMD64 and BOOST_ARCHITECTURE_IA64.

That assume that the hardware have a "normal" Intel or AMD processor. Then if it doesn't, it can be other kind of architecture (ARM or other listed in the defines)

Would it be possible to also provide macros that would tell what is the "bit size" (I don't know the correct word here) without the architecture name? Something like BOOST_ARCHITECTURE_BITS_32 BOOST_ARCHITECTURE_BITS_64

It is possible.. But the question of what size you are measuring comes up first. The bit size could refer to pointer size, integer size, float size, register size, or the "word" size. Which suggest that you would want a more specific set of macros for the various measured types. Ideally it would be better to base such macros on something natively defined by the compiler.. As determining these from the BOOST_ARCHITECTURE_* macros would be a bit a chore.

Again, maybe I'm being naive about this, but I'm thinking about code that should behave differently under those conditions and shouldn't have to check all the corresponding architecture macro to detect wether it's 32 or 64 bits.

Not totally naive, and certainly a good abstraction idea.

Anyway, it's a nice library that would allow me to not have to set some (certainly flawed) macro myself.

Thanks. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On 02/18/2012 10:18 PM, Lars Viklund wrote:

On Sat, Feb 18, 2012 at 03:01:49PM -0600, Rene Rivera wrote:

...

On 2/18/2012 8:36 AM, Klaim - Joël Lamotte wrote:

...

I guess it is ok to ask about details even if the library isn't in review yet, right?

Sure.. As it certainly won't prevent me from answering them ;-)

...

I'm not an expert in architecture so I hope I'm not asking something obvious.

My understanding is that for example if you're targeting classic PC hardware, you'll get BOOST_ARCHITECTURE_X86 for 32Bit OS BOOST_ARCHITECTURE_AMD64 for 64Bit OS (running on 64bit processor).

If you are targeting 64Bit you are more likely to get both BOOST_ARCHITECTURE_AMD64 and BOOST_ARCHITECTURE_IA64.

The set of 64-bit architectures is a bit error-prone to enumerate explicitly in user code, as the set will inevitably be either incomplete or stale.

Just consider SPARC, IBM's POWER, MIPS, and not to mention the most glorious DEC Alpha.

Couldn't you just use static_if(sizeof(void*) == 8) for this? ;)

On Sat, Feb 18, 2012 at 9:23 AM, Rene Rivera <grafikrobot@gmail.com> wrote:

On 2/18/2012 8:08 AM, Joel Falcou wrote:

...

=============== How to get it ? =============== Sources and documentation can be retrieved from http://tinyurl.com/73n6a3k

You can also find the sources and docs in the sandbox <http://svn.boost.org/svn/boost/sandbox/predef/>. Browsable docs at <http://svn.boost.org/svn/boost/sandbox/predef/libs/predef/doc/html/index.html>.

Rene.

BOOST_VERSION_NUMBER() should be renamed to BOOST_MAKE_VERSION_NUMBER() or similar. Tony

On 2/27/2012 1:20 PM, Dave Abrahams wrote:

on Sat Feb 18 2012, Rene Rivera<grafikrobot-AT-gmail.com> wrote:

...

On 2/18/2012 8:08 AM, Joel Falcou wrote:

...

=============== How to get it ? =============== Sources and documentation can be retrieved from http://tinyurl.com/73n6a3k

You can also find the sources and docs in the sandbox <http://svn.boost.org/svn/boost/sandbox/predef/>. Browsable docs at <http://svn.boost.org/svn/boost/sandbox/predef/libs/predef/doc/html/index.html>.

One thing I don't see is any distinction between the target being compiled for and the host on which the compilation is happening. You could make an argument that no such distinction is needed, but in the absence of such an argument I suggest changes like BOOST_ARCHITECTURE_XXX => BOOST_TARGET_ARCHITECTURE_XXX

I don't think I made such an argument :-) The argument is way simpler than that. None of the compilers I'm aware of tell you *directly* what host architecture they are running if it happens to be different from the target architecture. The best you can do is some user defined predef, or something derived from running something like uname. As for the name.. I'm open to suggestions. But as was mentioned ealier the name is rather long already. Which many people already object to. In general I'm all for detecting as much as we can from the compilers. Assuming that it's something that is generally possible. As detecting something for one or two compilers seems like a waste of development time. But then, the Predef library is also about giving users a way to define such detected version numbers on their own. Which is something that seems to have been lost. So I'm pointing it out for clarity.

Also, when BOOST_TARGET_ARCHITECTURE_XXX is 1, shouldn't we also have

#define BOOST_TARGET_ARCHITECTURE XXX

?

What would the "XXX" be in the define? ..The only option I can see is defining a string literal. Which is only useful for informational debugging uses. And not the more general decision testing. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On 02/20/2012 01:56 PM, Joshua Boyce wrote:

I think that it is useful, even if it's in the wrong category. I also think it could be improved. Specifically, I would like to be able to differentiate between MinGW and MinGW-w64.

It doesn't really make sense. Just use BOOST_CXX_GCC && BOOST_OS_WINDOWS.

...

When you include a header like<boost/predef.h>

...

you get 103 files included... 103 stats, fopen, fclose, read parse and so on.

More then that, consider build systems that should stat 103 files for each cpp file compiled.

One option I can think of is to provide a single concatenated header that is generated from the current modular headers. This, of course is a bit more work on the library side, and is considerably harder for users to humanly understand one big concatenated header file.

But easier to compiler... :-)

Hence this is something that I would seriously consider adjusting if the number of headers becomes a real measurable problem. Which also suggests that I should add some header parsing performance tests.

The problem is not header parsing performance only. Every build system checks dependencies, that means it stats() all the files it makes the process slower. So even if the process of parsing and stating takes only 0.1s it becomes critical for many files.

For just all the definitions that this library currently does I can't see how a compiled test could do any better.

The point is that 99% of the stuff is already available from Boost.Config so in current version it becomes yet another Boost.Config.

...

the "include" much faster and easier to read.

I disagree that this would make it easier to read. If one has to generate multiple "conf_predef.h" files, because one is dealing with multiple configurations,

See, when you deal with multiple configurations you still need multiple libraries and even headers that are not compatible. See almost all big libraries around using "configuration defined headers" I think Boost is the only "big" library that does not generate some "config.h" But I understand that this is out of the current scope and this is not what prevented from me to vote Yes.

...

And so on.

The "so on" would be subject to the goals ;-)

So on is for every configuration part that can't be done using header only solution... And this is huge.

...

1. Do not create 103 files but several maybe bigger files.

If I'm going to do that, I'd create just one file. After all if file system performance is the reason for doing it then it makes more sense to eliminate as much of it as possible.

Ok...

...

Or use compiler version - library binded to specific compiler.

That is not sufficient. You can have a compiler that can target multiple configurations and hence this version may not have any relevance to the library one is actually compiling to. Unless you meant something else?

Generally gcc uses his own library unless it uses some 3rd part software like STLPort. So with gcc version + test if we using libstdc++ gives us exact version we need. It has nothing to do with multiple configurations. For example libstdc++ is released with a compiler and documentation of the version relates to the compiler.

...

It is not really intuitive because I do not remember in what year

gcc-4.5 was released but I do know when for example unique_ptr was introduced.

Actually you'd have to look up more than just the year You would need the exact date to be sure you have to correct condition as any particular feature may have been added late in a year where there are multiple releases as has been the case for all gcc release <http://gcc.gnu.org/releases.html>.

More then that there can be a situation where   year(gcc-4.6.0) < year(gcc-4.5.7 - maintenance release) While actually from library point of view   version(gcc-4.6.0) > version(gcc-4.5.7 - maintenance release) So it just become inconsistent from features point of view

...

Architecture ------------

I notices several problems:

1. Arm has several architectures ARM, ARMEL should be distinguished

Sorry if I don't know.. But what is ARMEL is exactly in relation to ARM? In particular how does it relate to the various ARM chips produced <http://en.wikipedia.org/wiki/ARM_architecture>? And how would I determine an ARMEL?

I don't know how to distinguish... But in general, for example Debian distinguish between two architectures, technically from CPU point of view they are the same but they use totally different ABI so from user perspective they are different incompatible architectures.

...

2. There are MIPS and MIPSEL - Little Endian MIPS (debian has both for example)

Same question as above <http://en.wikipedia.org/wiki/MIPS_architecture>. Hm.. Or is "EL" some tag for specifying the target endian-ness? Because if it is, adding an orthogonal endian definition is something I'd like to do in the near future. Although, like the "word" size, is not something as easily done as just enumerating architectures.

Same as in case of ARM, from user point of view they are incompatible architectures.  

...

- I'd rather like to See Darwin then MACOS - MACOS not good.

Well given recent development it might make more sense to just use MACOS and OSX. But yes, I'll consider better naming for those. Although given that the current definitions only cover 9.0 vs 10.0, it might not yield much of a gain in clarity.

That is why MACOS - for classis Mac and DARWIN for Mac OS 10,11 etc. BTW for example I use some VM with Darwin 8 (== Mac OS 10.4) it is not Mac OS but it is apple operating system.

...

Testing... ---------

1. Unfortunately I see none on this.

There is testing for at least the functionality of the version macro and the decomposition utility macros. So I object to the "none" characterization.

These are very basic and cosmetic tests that do not actually test the core functionality

Testing for this library was something I asked about previously on this list. And there were not any really attainable solutions. The solutions boiled down to either simulate the target configuration or human verification. Unfortunately the former is essentially a tautological test as the test is specifying both the definition and test. Human verification has the benefits that it is distributed and in this use case doesn't need to be repeated.

Small examples: 1. You can use Boost.Build that already defines almost 80% of that parameters for    target os and check. 2. You can do particular checks when target==host and use uname - at least for native    builds it would be checked and for non-native you can assume that definitions    would not change during cross compilation. There are more ideas. I understand that they would not solve all use cases and live some cases unsolved but at least it would give some automated testing for core system.

...

I understand that is is not simple but

Indeed :-\

This library should not be simple ;-)

The current testing only involved the automated testing I mention above for the version and decomposition macros. Plus testing in the platforms that I have immediate access to: Windows, OSX, Linux (OpenSUSE), and iOS.

I would strongly recommend to take a look on OS Zoo and qemu. It gives you at least 4-5 architectures (x86, x86_86, mips(el), arm, sparc) you can also install OpenSolaris and FreeBSD in VM and of course Darwin 8 So if all your tests are manual at least make sure they work as expected.

...

1. Almost all tests do not even compile on Cygwin...

Could you elaborate? What cygwin version are you trying?

1.7 I'll give you an error when I'll get to a PC with Cygwin.

...

2. Under mingw gcc-4.5.3 I see following output of info_as_cpp

    For example:

    ** Detected **     ....     BOOST_LIBSTD_GNU = 410400028 (41,4,28) | GNU     ...

    How should I treat it?

The docs say "Version number available as year (from 1970), month, and day." I.e. the above says libstdc++ released on 2011/04/28.

Ok it was not clear to me I'd expect in such case something like: (2011,4,28) which is much more clear. But ok I understand this now.

...

...

      - Do you think the library should be accepted as a Boost library?

Unfortunately, No.

Sorry to hear that..

...

But I strongly recommend to improve the library and submit it for further review.

Problems:

1. Too many macros are not fine grained as they should be     or they generate unexpected or surprising definitions.

Do you have more examples than the ones you mentioned above?

At least when I looked at something that I'm familiar with  gcc - ok  linux - ok  libstdc++  - bad versioning  cxx_cygwin - no such thing  os_windows 1 and not version I found that at least 50% of them had given unexpected results. others I just could not check, that is why I asked on what platforms have you manually tested the library. So I can't say how more problems there are but they are too many for a small test case that I looked at.

...

2. Documentation must be improved because for now it is very unclear.

All documentation can always be improved ;-) Did my answers above address this for you?

The problem that 80% of the macros have so brief documentation that I can't really understand how to use them, what version to check, what ranges examples etc. The particular examples were only examples of general problem.

...

3. Many problems with different definitions like there is no such     thing like Cygwin compiler should be fixed. 4. 103 files in headers that would slow down the build process. 5. No real test suite exists

Is there more I can expand on to address those?

I mostly think that much more deep testing required. I mean all macro that can be tested using available tools should be tested and result validated with users. I don't expect that for example you'll be able to test OpenVMS or z/390 but there is no reason that basic things would behave unexpectedly. I understand that it would increase the amount of the work by 200-300% if not more but my current feeling that the library does not seems to be ready I'm sorry, it is a very good direction but I feel that more work is required that is why I don't think it is ready for Boost. Artyom Beilis -------------- CppCMS - C++ Web Framework:   http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

On 02/21/2012 11:48 AM, Artyom Beilis wrote:

Linux x86_64 g++/stlport (libstdc++ and IA64 detected) Linux x86_64 clang (gcc and ia64 detected)

The structure of the library should already enforce mutually exclusive values and prevent this from happening. The fact that it doesn't is a sign of poor design and means that the library essentially needs to be rewritten.

On 02/21/2012 11:09 AM, Artyom Beilis wrote:

...

...

When you include a header like<boost/predef.h>

...

...

you get 103 files included... 103 stats, fopen, fclose, read parse and so on.

More then that, consider build systems that should stat 103 files for each cpp file compiled.

One option I can think of is to provide a single concatenated header that is generated from the current modular headers. This, of course is a bit more work on the library side, and is considerably harder for users to humanly understand one big concatenated header file.

But easier to compiler... :-)

I am strongly opposed to this! First of all, it is the job of the compiler to compile. In theory, it doesn't matter how many files he needs to open to get the job done. However, it matters for us humans. Is this just over pessimistic, premature optimization?

...

Hence this is something that I would seriously consider adjusting if the number of headers becomes a real measurable problem. Which also suggests that I should add some header parsing performance tests.

The problem is not header parsing performance only. Every build system checks dependencies, that means it stats() all the files it makes the process slower.

So even if the process of parsing and stating takes only 0.1s it becomes critical for many files.

What you are suggesting effectively sounds like throwing all kinds of structure and file organization away that makes sense for us mere humans just to compile a little faster. Please, back it up with some proof. Additionally, i would like to add that a fine grained header file organization also leads to less includes. One might always need everything defined in the library in one TU. I claim that having those big headers is slowing the process down. So, how big is the impact? Did you do some real measurements?

On 2/23/2012 4:52 AM, Mathias Gaunard wrote:

On 02/22/2012 09:28 AM, Thomas Heller wrote:

...

What you are suggesting effectively sounds like throwing all kinds of structure and file organization away that makes sense for us mere humans just to compile a little faster. Please, back it up with some proof. Additionally, i would like to add that a fine grained header file organization also leads to less includes. One might always need everything defined in the library in one TU. I claim that having those big headers is slowing the process down.

Detecting the compiler is a global process, and requires knowledge about all the other compilers.

In particular, order in which compilers are detected matters so that Clang is not detected as GCC.

So it makes sense to only have one header for all compilers; all other approaches are likely to be dangerous or broken.

Having one header per compiler doesn't make sense. It should never be allowed to include just one compiler header.

The current Boost.Config has one header per compiler so obviously it does make sense. Another header attempts to figure out the compiler being used and then the particular compiler's header is included. What is so arcane about that ? The words 'always' and 'never' should always be banned from computer programming discussions. They are words which are never correct to use.

On 2/24/2012 7:49 AM, Mathias Gaunard wrote:

On 02/24/2012 03:33 AM, Edward Diener wrote:

...

The current Boost.Config has one header per compiler so obviously it does make sense. Another header attempts to figure out the compiler being used and then the particular compiler's header is included. What is so arcane about that ?

Those are not "real" headers. You're not allowed to ever include one of those directly.

Including any of those directly would open a whole can of worms. They don't even have include guards or anything of the sort.

It could be argued that the extension should be changed from .hpp to .inl.

Or rather, .ipp, as that's what other Boost libraries use for internal headers. Or inside a detail directory. I should also point out that the same also really applies to my library. The non-top level headers could be rearranged as implementation details. And I mentioned before, could be moved so that concatenated headers are used. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

I have a couple of comments about Boost.Predef: Undefined vs null ================= You define macros for the pertinent platform (OS, CPU, compiler, standard) and set their value to the appropriate version number. If no version number could be determined, 0.0.1 is used instead. But you also define macros for all non-pertinent platforms and set their value to 0.0.0. I know that you are doing this to allow the compiler (rather than the preprocessor) to use the macros. However, this design decision makes the by far most common use case (#ifdef MACRO) more difficult in order to support a rare use case (if (MACRO)). This is not how developers are used to working with platform macros, and it will be an eternal source of confusion. I encourage you to reconsider this design decision, and instead only define macros that are relevant for the platform. This is more in line with the expectations of your future users. Version layout ============== You encode the version number as decimal numbers in the range from 0 to 1000000000. If you encode them as hexadecimal numbers instead, you can utilize the full range from 0 to 2^32. Extension macros ================ Some macros, such as __GNUC__, _MSC_VER, and _WIN32 serve a dual purpose. They are partly used to identify a platform, and partly to enable certain extensions in header files. Other compilers will therefore define these macros as well when they want access to these extensions. For instance clang defines __GNUC__ (and related macros). If you wish BOOST_CXX_GNUC only to be defined for GCC, then you need to exclude all other compilers that may set the __GNUC__ macro. For example: #if defined(__GNUC__) && !defined(__clang__) As your predef/compiler/gcc.h file has to know the clang macro too, you might as well put all compiler macros into a single file (as discussed earlier in the thread.) C++ version =========== Your choice of using 0.0.YYYY as the version layout for C++ standards is quite unusual. I understand that you are doing it for technical reasons (the patch number is the only entry that can contain four digits numbers), but I still think that a more intuitive solution is needed. One solution could be to use an encoding similar to your BOOST_PREDEF_MAKE_YYYY_MM_DD macro. Another solution could be to define an explicit macro for each supported standard. E.g. #if __cplusplus - 0 >= 199711L # define BOOST_LANGUAGE_CXX98 1 #endif Indentation of preprocessor directives ====================================== Old preprocessors will only recognize directives if these is a hash (#) in the first column of the line. The most portable way of indenting directives is therefore to put the hash sign in the first column and then put whitespaces between the hash sign and the rest of the directive. E.g. "# if" instead of " #if". Else if ======= You use the #elif directive in some files. Notice that older Borland preprocessors will fail with that directive. The portable way to do else-ifs is the more tedious alternative: #if MACRO #else # if MACRO2 # endif #endif Apropos else-if, in compiler/greenhills.h you are using the incorrect "#else if defined" construct. Credit ====== As the main author of the predef.sourceforge.net pages, it is pretty clear to me that you have extracted much information from those pages, so I think that a reference to those pages may be in order.

On 2/26/2012 9:06 AM, Bjorn Reese wrote:

I have a couple of comments about Boost.Predef:

Undefined vs null ================= You define macros for the pertinent platform (OS, CPU, compiler, standard) and set their value to the appropriate version number. If no version number could be determined, 0.0.1 is used instead.

But you also define macros for all non-pertinent platforms and set their value to 0.0.0.

Right.

I know that you are doing this to allow the compiler (rather than the preprocessor) to use the macros.

Actually, that's not the core reason..

However, this design decision makes the by far most common use case (#ifdef MACRO) more difficult in order to support a rare use case (if (MACRO)). This is not how developers are used to working with platform macros, and it will be an eternal source of confusion.

I guess that depends on the developers. The reasons the macros are always defined, to zero when not detected, is to reduce the amount of checks when writing conditionals. At least in Boost, the common use case goes something like this: #if defined(_some_compiler_) && (_some_compiler_ < 123) //... #endif Or the longer equivalent: #ifdef _some_compiler_ #if (_some_compiler_ < 123) ... #endif #endif This is because many times we are interested in a particular version number not just if it's one platform vs. another.

I encourage you to reconsider this design decision, and instead only define macros that are relevant for the platform. This is more in line with the expectations of your future users.

Version layout ============== You encode the version number as decimal numbers in the range from 0 to 1000000000. If you encode them as hexadecimal numbers instead, you can utilize the full range from 0 to 2^32.

It's a good thing it's easy to change when one has a single version definition macro :-) At the time of choosing the 2/2/5 split it wasn't a problem as I wasn't including some of the predefs that could make use of say a bigger major number, i.e. the ones that are dates. If we switched to using hex and keep at least the current allowed range it would have to be at least FF/FE/1FFFF, i.e. a decimal range of [0,255]-[0,127]-[0,131071]. Which gives some slightly larger ranges in each number, but not enough to get a year into the major number. But it might be worth it just for the patch number range increase.

Extension macros ================ Some macros, such as __GNUC__, _MSC_VER, and _WIN32 serve a dual purpose. They are partly used to identify a platform, and partly to enable certain extensions in header files. Other compilers will therefore define these macros as well when they want access to these extensions. For instance clang defines __GNUC__ (and related macros).

Right.

If you wish BOOST_CXX_GNUC only to be defined for GCC,

Which is the distinction between *actual* and *emulated* I mentioned in the other post tonight.

then you need to exclude all other compilers that may set the __GNUC__ macro. For example:

#if defined(__GNUC__) && !defined(__clang__)

As your predef/compiler/gcc.h file has to know the clang macro too, you might as well put all compiler macros into a single file (as discussed earlier in the thread.)

That doesn't follow from the argument. It is possible to instead have the clang.h file both define the Clang compiler, and undef all the other *emulation* predefs. Or more useful, define separate emulation predefs also. It's even possible to arrange it so that this works regardless of inclusion order of the gcc.h and clang.h headers. This has the benefit of keeping the knowledge about the real compiler in the real compilers' header only. Making it likely to be maintained accurately.

C++ version =========== Your choice of using 0.0.YYYY as the version layout for C++ standards is quite unusual. I understand that you are doing it for technical reasons (the patch number is the only entry that can contain four digits numbers), but I still think that a more intuitive solution is needed.

One solution could be to use an encoding similar to your BOOST_PREDEF_MAKE_YYYY_MM_DD macro.

Another solution could be to define an explicit macro for each supported standard. E.g.

#if __cplusplus - 0 >= 199711L # define BOOST_LANGUAGE_CXX98 1 #endif

Yes, I'm not that happy with the choice of 0.0.YYYY either. And I'm leaning towards standardizing all the predefs with even partial dates to be the YYYY.MM.DD - 1970.0.0 format.

Indentation of preprocessor directives ====================================== Old preprocessors will only recognize directives if these is a hash (#) in the first column of the line. The most portable way of indenting directives is therefore to put the hash sign in the first column and then put whitespaces between the hash sign and the rest of the directive. E.g. "# if" instead of " #if".

Even if I've been programming for a long time.. I don't even remember having to deal with those. But if they are still sufficiently used, and worth supporting, I'm willing to adjust them.

Else if ======= You use the #elif directive in some files. Notice that older Borland preprocessors will fail with that directive. The portable way to do else-ifs is the more tedious alternative:

#if MACRO #else # if MACRO2 # endif #endif

At least I've run into that one a few times :-) And I'm also willing to adjust accordingly to increase portability.. But wouldn't this only be needed for the parts that would be considered by the boarland PP. I.e. the common parts and the borland header itself? (Assuming the others bail after the first #if)

Apropos else-if, in compiler/greenhills.h you are using the incorrect "#else if defined" construct.

Making a not of that, thanks. OK, ran out of time for tonight :-( Other replies, after the C/C++UG meeting tomorrow night. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

Rene Rivera wrote:

On 2/26/2012 9:06 AM, Bjorn Reese wrote:

...

But you also define macros for all non-pertinent platforms and set their value to 0.0.0.

Right. [snip]

...

However, this design decision makes the by far most common use case (#ifdef MACRO) more difficult in order to support a rare use case (if (MACRO)). This is not how developers are used to working with platform macros, and it will be an eternal source of confusion.

I guess that depends on the developers. The reasons the macros are always defined, to zero when not detected, is to reduce the amount of checks when writing conditionals. At least in Boost, the common use case goes something like this:

#if defined(_some_compiler_) && (_some_compiler_ < 123) //... #endif [snip] This is because many times we are interested in a particular version number not just if it's one platform vs. another.

However, if _some_compiler_ is always set, to 0.0.0 if to nothing else, then the first test is useless. Besides, I frequently write conditional code of the following form: #if defined _some_compiler_ //... #endif That is, the version is not relevant to me, either because I can assume a limited version range, or because I've rejected irrelevant versions elsewhere. If _some_compiler_ is always defined, even if to 0.0.0, then such tests are not possible. Did I miss something? _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

On 02/21/2012 08:17 AM, Rene Rivera wrote:

...

More then that, consider build systems that should stat 103 files for each cpp file compiled.

That thought did cross my mind when deciding on the header structure. But, given how many compilers support some form of precompiled inclusion I decided that it was OK to go with the modular arrangement. Especially for the much easier maintainability of the library. One option I can think of is to provide a single concatenated header that is generated from the current modular headers. This, of course is a bit more work on the library side, and is considerably harder for users to humanly understand one big concatenated header file. Hence this is something that I would seriously consider adjusting if the number of headers becomes a real measurable problem. Which also suggests that I should add some header parsing performance tests.

Bryce Lelbach did a similar library to yours: <https://github.com/brycelelbach/detect> It only contains 4 short files + 1 file to include them all and is perfectly maintainable. If you cut the line explicitly between mutually-exclusive macros and others that are not, then this structure works very well. To me it doesn't make sense if the library has more than 10 files. It is a sign there is a big design and scalability problem there.

- The above assume a NULL defined style macro rather than an undefined macro style – as has been mentioned I think perhaps undefined macros are the better choice for these very low level definitions. I’d suggest it’s likely that if you have to use these for areas of the code then the code being blocked off is likely not legal in most other cases (and so the alternative C++ compiler “if” usage would not be possible anyway and so removes the only reason I can see to have things as they are). Ahem - this point can be safely ignored :o)

I actually knew this wasn't the "only" reason to have things as they are even before it was spelled out (in another post) - honest! I blame a sleep addled brain. However, the choice between undefined and null defined is perhaps best left to the user? So, a set of BOOST_CXX_GCC and associated BOOST_CXX_GCC_VERSION might be worth doing - the first is defined only on when the compiler is GCC (or emulates GCC) the second is always defined, but null when not GCC. Best of both worlds, no? Iain