At 05:17 PM 1/8/2003, William E. Kempf wrote:

>> From: Rene Rivera <[EMAIL PROTECTED]>
>> I rather dislike the conditional compilation solution. It makes it rather
>> harder to write portable code as it makes for doing conditional PP code
>> outside of the library. Would it not be preferable to throw some form of
>> "unimplemented"/"unsupported" exception? Another option would be a
>discovery
>> interface to find out what's supported in the platform. Such a discovery
>> interface could be used with MPL to get the equivalent of PP.
>
>Note that we do throw exceptions in many cases where things aren't
>supported. However, if a large category of functionality is not available,
>such as scheduling, there's reasons to prefer conditional compilation.
>First, you can get rid of unecessary code. Second, you know from attempts
>to compile whether or not code can actually be ported to a given platform.
>IOW, the exception approach is only useful when you can compensate for the
>lack of a feature at run time.

I'm not a fan of conditional compilation either.

I'd rather see the functions always supplied, even as stubs, unless it is absolutely sure that every use represents a serious error.

For example, setting the stack size may have no effect on some platforms, but why should it be considered an error?

There could be a compile time way to tell if the feature has any effect, so if the user wishes to tailor the code, it is possible to do so.

Particularly between major platforms like POSIX and Windows, I'd hope that programs could be moved back and forth without user code being concerned about presence or absence of features.

--Beman


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Reply via email to