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.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
