Re: [boost] Boost.Process 0.2 released

From: Boris (boriss_at_[hidden])
Date: 2008-07-05 13:55:13

On Sat, 05 Jul 2008 17:43:04 +0200, Sebastian Redl  
<sebastian.redl_at_[hidden]> wrote:

> Boris wrote:
>>
>> Thanks for the link! I'm currently comparing the code and have already  
>> a question: There was a static constant defined in one class which has  
>> been changed by Julio to a static method (it had caused problems when  
>> the header was included in more than one compilation unit). Julio  
>> couldn't use the macro BOOST_STATIC_CONSTANT (see  
>> http://www.boost.org/development/int_const_guidelines.html) as on  
>> Windows a complex type is used which must be defined outside the class.  
>> While Julio simply defined a static method I had fixed the code with:
>>
>> #if defined(BOOST_POSIX_API) || defined(BOOST_PROCESS_DOXYGEN)
>> BOOST_STATIC_CONSTANT(handle_type, INVALID_VALUE = -1);
>> #elif defined(BOOST_WINDOWS_API)
>> #  define INVALID_VALUE INVALID_HANDLE_VALUE
>> #endif
>>
>> Is there any guideline what to prefer here?
> Macros as constants are pretty much shunned. Worse, the two options here  
> have different behaviour if they're not on the global namespace. (And  
> also if they are, since the macro prevents all other uses of the name.)

I should have written the code differently:

#if defined(_MSC_VER)
#  define INVALID_VALUE INVALID_HANDLE_VALUE
#else
BOOST_STATIC_CONSTANT(handle_type, INVALID_VALUE = -1);
#endif

Now it's obvious that the macro is a workaround for VC++ only. While  
Sebastian's points are valid do they justify to change a class' interface  
because of a limitation of one compiler? I've no preference (especially as  
VC++ is not an unimportant compiler of course).

Boris