Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2003-03-27 02:31:24

In message <2cfe01c2f3c7$45f91b30$8d6c6f50_at_pc>, Terje Slettebø
<tslettebo_at_[hidden]> writes
>>From: "Rozental, Gennadiy" <gennadiy.rozental_at_[hidden]>
>
>> > Even if none of the above looks sound for you I still argue that
>> > lexical_cast *should not force* inclusion of typeinfo. It's not
>> > "inconvinience" - it's showstopper. It's much more important
>> > than providing
>> > specific type info. In majority of the cases one knows it anyway.
>> >
>> > > Kevlin
>> >
>> > Gennadiy.
>>
>> So. Are we gonna stuck  with typeinfo in lexical_cast?
>>
>> Could we have at least some discussion about this?

Apologies for the non-response. I'm travelling at the minute so I
haven't had time to check the list. A quick response on this one, and
hopefully I'll get time at the weekend to respond to other postings.

What I need to understand is why type_info is very bad for you but
exception handling is not. These two normally are typically included in
or excluded from an application together. So you need to be clear about
what environmental constraints would lead you to exclude RTTI, include
EH, and also to include the not insignificant body of code that is I/O
streams.

>I'd certainly be open to make the type_info part optional. A question is how
>to do it.
>
>Using policies may complicate the interface, and from earlier discussions,
>and also from the earlier "Future directions" part of the docs, it turned
>out that adding new parameters weren't deemed acceptable (due to it no
>longer looking like a cast in that case).
>
>Another way may be a macro. However, as has been mentioned in this thread,
>it appears that the config macros aren't geared for macros with optional
>exclusion of RTTI.
>
>Then one might have a lexical_cast specific macro for it, like
>BOOST_LEXICAL_CAST_USE_RTTI, like you suggested.
>
>Kevlin or others, any thoughts?

The feature tests are really about compiler conformance rather than
arbitrarily customisable features. I am wary of introducing an opt out
for a well-supported feature unless it really is a clear cut reason.
Optionality in interfaces is generally not a good thing.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  mailto:kevlin_at_[hidden]     mobile: [phone]
  http://www.curbralan.com        fax:    [phone]
  Curbralan: Consultancy + Training + Development + Review
____________________________________________________________