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)
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)
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)
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_castT*(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)
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: 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_castT*(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 typeinfo. 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)
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_castT*(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)
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)
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: 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
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: 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
[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
[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)
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 typeinfo 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
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? snip 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
