Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
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 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: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
"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. > > This trade-in is based on assumption that If I do not want RTTI > runtime overhead I would not want exception one also. No, it's based on the assumption that catering to a few people who are trying to use a subset of the language is less important than preserving design cleanliness and integrity. Maybe if there were one or two other people clamoring for this change I'd be more sympathetic, but so far it doesn't sound like it's worth making this change for one person. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
> 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. Gennnadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
>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 said in another mail, there is already a config macro to disable exceptions. Whether or not libraries check for it is optional, though. From the docs: "BOOST_NO_EXCEPTIONS - The compiler does not support exception handling (this setting is typically required by many C++ compilers for embedded platforms). Note that there is no requirement for boost libraries to honor this configuration setting - indeed doing so may be impossible in some cases. Those libraries that do honor this will typically abort if a critical error occurs - you have been warned!" Embedded C++ doesn't have RTTI, either. Therefore, a BOOST_NO_RTTI might be reasonable, as well. I understand that your suggestion is not for macros describing lack of compiler support, but rather user settings. Yet, couldn't these be used for either, by explicitly setting them before any Boost includes? 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. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
>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 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? > > 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 those who can't handle the exceptions we > want to throw... though I don't know how (or if) that interacts with > things like char const*. Technically, this should be possible, since it now throws an exception if you try to convert to any pointer, as it checks for that. This is to remove the possibility of trying to convert to char *, which could otherwise succeed (due to the design of basic_istream), but would give undefined behaviour. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
"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 those who can't handle the exceptions we >> want to throw... though I don't know how (or if) that interacts with >> things like char const*. > > It's not that I could not handle the exception You can't handle it if the exception includes type_info. > (exception-less interface is another topic that should be discussed > separately). See my other post on consequences of including of > . 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. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
> 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). That's is not exactly true since third parameter will have a default value. So in default case you wont see a difference. > 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 > Then one might have a lexical_cast specific macro for it, like > BOOST_LEXICAL_CAST_USE_RTTI, like you suggested. We may need this macro even policy based solution would be chosen (only for convinience). See my previos post And again if I am right and RTTI has runtime overhead whatever decision we will make I prefer not to force typeinfo inclusion. User has to have an option this way or another. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
"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 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? 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 those who can't handle the exceptions we want to throw... though I don't know how (or if) that interacts with things like char const*. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
>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 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? 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? Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
> 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? Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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 directly, rather than creating and then copying >>> it, the exception does not become active until the constructor has >>> completed. >> >>You don't think I know this? > > It is not what you said. What you know and what you say can be two > different things :^) What I said was that throwing such an exception can lead directly to terminate(). I didn't say anything about the initial construction of the exception. Your interpretation of what I said and what I actually said can be two different things. There really wasn't any need to "correct" me, was there? >>Terje throws an exception, which causes copying. > > _May_ cause copying. I am not going to dispute the fact that the code is > entitled to do so, but it is not a requirement. Simply moderating the > precision of the language, that's all. More hair-splitting. Is this really neccessary? Aren't we trying to write portable code here? >>> If the effect is the same, it does not matter where the string >>> is formatted. >> >>The effect is not the same though. > > Err, this is also what I said in my post a few sentences later. There > must be an echo ;-) I normally reply to posts point-by-point, and I sometimes don't go back and revise just because someone starts making sense later on. Sorry. This has been exceedingly frustrating. If you make it difficult for people to point out mistakes they are likely to keep silent in the future. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
> >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 that can be addressed out of the box,
> however: there is no config feature test that addresses this since, as
> the config docs state, there is no accommodation for disabling now
> commonly supported C++ features such as RTTI.
"Config feature" has nothing to do with what I was talking about. I may not
want to use RTTI even if compiler suports it (and most does). The issue I
have is that some implementations of RTTI cause significant runtime overhead
even if never used (but compiled with it), that may not be acceptable.
> >Would you want to supply type information you
> >may do it like this:
> >
> >struct bad_lexical_cast {
> >...
> >virtual char const* src() = 0;
> >virtual char const* trg() = 0;
> >};
>
> This would not be a massive improvement since the types would be, once
> again, expressed as text rather than as program entities, ie type_info
> objects.
It would be good enough for me (and may be for many others). I do not like
std::type_info based logic anyway.
> >Now, question remains how user will customize ReflectionPolicy. I see at
> >least 2 ways:
> >1. Add third template parameter to the lexical_cast with default value
> >2. Use global trait (in this case you may return customizable type from
src,
> >trg functions instead of char const*)
>
> Neither of these sounds particularly attractive, I'm afraid, and would
> still require config-level feature support.
No. Macro that could be used only for convinience puposes. If we move
default_reflection in separate header (that will include typeinfo) lexical
cast users will need to include it separately. We could include it directly
in lexical_cast.hpp and guard with macro BOOST_LEXICAL_CAST_USE_RTTI
> >I could not afford to include into my source and never do. And
I
> >do not think lexical cast should force me.
>
> If you can make a case for introducing a standard config feature test
> for RTTI this may be something we could consider using in lexical_cast.
> Otherwise, apologies for the inconvenience :-(
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.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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 new
>lexical cast fail to link..
OK, this is a new twist. Not one that can be addressed out of the box,
however: there is no config feature test that addresses this since, as
the config docs state, there is no accommodation for disabling now
commonly supported C++ features such as RTTI.
>Would you want to supply type information you
>may do it like this:
>
>struct bad_lexical_cast {
>...
>virtual char const* src() = 0;
>virtual char const* trg() = 0;
>};
This would not be a massive improvement since the types would be, once
again, expressed as text rather than as program entities, ie type_info
objects.
>Now, question remains how user will customize ReflectionPolicy. I see at
>least 2 ways:
>1. Add third template parameter to the lexical_cast with default value
>2. Use global trait (in this case you may return customizable type from src,
>trg functions instead of char const*)
Neither of these sounds particularly attractive, I'm afraid, and would
still require config-level feature support.
>I could not afford to include into my source and never do. And I
>do not think lexical cast should force me.
If you can make a case for introducing a standard config feature test
for RTTI this may be something we could consider using in lexical_cast.
Otherwise, apologies for the inconvenience :-(
Kevlin
Kevlin Henney phone: +44 117 942 2990
mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508
http://www.curbralan.comfax:+44 870 052 2289
Curbralan: Consultancy + Training + Development + Review
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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 for >> worse), standard exceptions support assignment as part of their >> interface. > >Why should boost exception classes behave like std:: exception >classes in this regard? And why should they not? It is an open question. It depends on how close in style people want the Boost experience to the standard library to be. I personally dislike the standard's design of exception classes, but I am willing to accommodate its style for an open library if that is what is expected. Kevlin Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.comfax:+44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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
>{
>public:
>...
>virtual const char *what() throw()
^
Do not forget const here! ---|
>[...]
>(in case anyone had decided to throw bad_lexical_cast in their own
>code)
Aargh! :-)
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
>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
> >> have been routinely rejected :-)
> >
> > Storing a couple of type members is not enough, by itself. How would a
> > catch-clause taking e.g. a reference to bad_lexical_cast access them? To
> > access the typedefs, you need to know the exact type thrown, which means
you
> > need to know the types to begin with...
>
> There's absolutely no reason I can see to make the exact exception
> type depend on the types concerned. Just use a straightforward
> class, something along the lines of:
>
> struct bad_lexical_cast : std::exception
> {
> bad_lexical_cast(
>std::type_info const& src, std::type_info const& dst)
> : m_src(src), m_dst(dst) {}
> char const* what() throw() { return "bad_lexical_cast"; }
>
> std::type_info const& src() const { return m_src; }
> std::type_info const& dst() const { return m_dst; }
> private:
> std::type_info const& src;
> std::type_info const& dst;
> };
Right. I see that Kevlin also suggest this approach in a later posting. The
original version of the extended exception used static initialisation, as
mentioned, which is why it was templated.
I think this is a good approach.
Regarding the other MSVC 6 warning given in the original report, Gennaro
Prota has suggested using an explicit "!=", rather than relying on the
implicit conversion from pointer to bool. This also avoids using a cast,
instead.
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
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' string
>> >> is perhaps one that can be revisited. It would be feasible to avoid any
>> >> allocation issues at all by leaving the human readable string as
> general
>> >> as it was before and adding type_info members that described the source
>> >> and target types.
>> >
>> >Yes, that was my suggestion.
>>
>> 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
>> have been routinely rejected :-)
>
> Storing a couple of type members is not enough, by itself. How would a
> catch-clause taking e.g. a reference to bad_lexical_cast access them? To
> access the typedefs, you need to know the exact type thrown, which means you
> need to know the types to begin with...
There's absolutely no reason I can see to make the exact exception
type depend on the types concerned. Just use a straightforward
class, something along the lines of:
struct bad_lexical_cast : std::exception
{
bad_lexical_cast(
std::type_info const& src, std::type_info const& dst)
: m_src(src), m_dst(dst) {}
char const* what() throw() { return "bad_lexical_cast"; }
std::type_info const& src() const { return m_src; }
std::type_info const& dst() const { return m_dst; }
private:
std::type_info const& src;
std::type_info const& dst;
};
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
>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 would be feasible to avoid any > >> allocation issues at all by leaving the human readable string as general > >> as it was before and adding type_info members that described the source > >> and target types. > > > >Yes, that was my suggestion. > > 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 > have been routinely rejected :-) Storing a couple of type members is not enough, by itself. How would a catch-clause taking e.g. a reference to bad_lexical_cast access them? To access the typedefs, you need to know the exact type thrown, which means you need to know the types to begin with... I don't understand how this relates to private copy constructor, though, could you explain? Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
