In message <[EMAIL PROTECTED]>, Terje Slettebø
<[EMAIL PROTECTED]> writes
>>From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
>
>> > 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 showsto
"Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:
>> No, I am explicitly saying that if you want to avoid typeinfo maybe
>> you should also be forced to compromise and avoid exceptions too. I
>> think that would have the least negative impact on the design and I
>> like the trade-off it implies.
>
> Having a lexical_cast-specific macro will just cover that
> component, while
> the same issue could occur with another library, unless a Boost-wide
> configuration macro is used.
I am convinced. Moreover I know at least 1 more libraries that will need
such configuration - Serialization.
Gennna
>From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
> > 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.
>
> No. this has nothing to do with config
Well, as Dave A sai
>From: "David Abrahams" <[EMAIL PROTECTED]>
> "Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:
>
> >> 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 import
"Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:
>> My contribution to the discussion is that I don't think supporting C++
>> language subsets is worth complicating the interface in the way you
>> propose. Maybe lexical_cast(whatever) should return 0 on failure
>> and that should be enough for th
> 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 deem
"Rozental, Gennadiy" <[EMAIL PROTECTED]> writes:
>> 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 major
>From: "Rozental, Gennadiy" <[EMAIL PROTECTED]>
> > 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 ma
> 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
>
Kevlin Henney <[EMAIL PROTECTED]> writes:
> In article <[EMAIL PROTECTED]>, David Abrahams
> <[EMAIL PROTECTED]> writes
>>>
>>> Not quite: there is a difference between the initial construction and
>>> the copy. In an insufficient-memory condition with a compiler that
>>> creates the exception dir
> >Sorry to interfere to this fine discussion, but from my standpoint
> >introduction of std::type_info into lexical_cast is a big problem. I
usually
> >compile my program with noRTTI flag effectively making any program using
new
> >lexical cast fail to link..
>
> OK, this is a new twist. Not one t
In article <[EMAIL PROTECTED]>, Gennadiy Rozental
<[EMAIL PROTECTED]> writes
>
>Sorry to interfere to this fine discussion, but from my standpoint
>introduction of std::type_info into lexical_cast is a big problem. I usually
>compile my program with noRTTI flag effectively making any program using
In article <[EMAIL PROTECTED]>, David Abrahams
<[EMAIL PROTECTED]> writes
>Kevlin Henney <[EMAIL PROTECTED]> writes:
>
>>>Yes. Since type_info objects can't be copied, one might instead store
>>>pointers or references to them.
>>
>> Pointers would be better because, for better or for worse (mostly
On Sat, 22 Mar 2003 17:39:06 +, Kevlin Henney
<[EMAIL PROTECTED]> wrote:
>Not necessarily. It would be reasonable to fold up the inheritance
>again, and simply provide a two argument constructor and a concrete
>implementation:
>
>class bad_lexical_cast : public std::bad_cast
>
>From: "David Abrahams" <[EMAIL PROTECTED]>
> Terje Slettebø <[EMAIL PROTECTED]> writes:
>
> >>From: "Gennaro Prota" <[EMAIL PROTECTED]>
> >
> >> I'm happy that std::type_info has a private copy constructor. Hadn't
> >> it been for that, my suggestion to use just a couple of typedefs would
> >> ha
Terje Slettebø <[EMAIL PROTECTED]> writes:
>>From: "Gennaro Prota" <[EMAIL PROTECTED]>
>
>> On Sat, 22 Mar 2003 09:52:07 -0500, David Abrahams
>> <[EMAIL PROTECTED]> wrote:
>>
>> >Kevlin Henney <[EMAIL PROTECTED]> writes:
>>
>> >> However, the decision as to whether this should be in the 'what' st
>From: "Gennaro Prota" <[EMAIL PROTECTED]>
> On Sat, 22 Mar 2003 09:52:07 -0500, David Abrahams
> <[EMAIL PROTECTED]> wrote:
>
> >Kevlin Henney <[EMAIL PROTECTED]> writes:
>
> >> However, the decision as to whether this should be in the 'what' string
> >> is perhaps one that can be revisited. It w
18 matches
Mail list logo
