RE: [boost] Re: lexical_cast
Curiously I have just posted a description of what may be the cause of this.
Attached...
My suggested remedy relies on the correct value for numeric_limits::digits (not
digits10)
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
mailto:[EMAIL PROTECTED]
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Aleksandr Golovanov
| Sent: Saturday, August 16, 2003 2:24 AM
| To: [EMAIL PROTECTED]
| Subject: [boost] Re: lexical_cast
|
|
|
| "Ross Smith" <[EMAIL PROTECTED]> wrote in message
| news:[EMAIL PROTECTED]
| > Aleksandr Golovanov wrote:
| > > "Ross Smith" <[EMAIL PROTECTED]> wrote in message
| > > news:[EMAIL PROTECTED]
| > >
| > >>Aleksandr Golovanov wrote:
| > >>
| > >>>Yesterday, I ran into a small problem, lexical_cast accepts copy
| instead of
| > >>>(const)? reference to a source. I have a class which I would prefer to
| be
| > >>>noncopyable and castable with laxical_cast at the same time.
| > >>
| > >>Wrap the object in boost::cref().
| > >
| > > Unfortunately, cref won't work because lexical_cast propagates the
| source
| > > type as a template parameter to various helper/standard templates:
| >
| > You're wrong; it works perfectly well. I tried it before I posted the
| > suggestion.
| >
|
| Following working example shows one possible case when application of
| boost::cref leads to a wrong result.
| Compiler VC6 SP5; lexical_cast from 1.30.0 boost release.
|
| #include "boost/lexical_cast.hpp"
| #include "boost/ref.hpp"
| #include
| #include
| #include
|
| class big_decimal
| {
| public:
| big_decimal() : m_val( 1.23456789 ) {}
| public:
| double m_val;
| };
|
| namespace std {
| class numeric_limits
| : public numeric_limits
| {
| };
| }
|
| std::ostream& operator<<( std::ostream& s, big_decimal const& arg )
| {
| return s << arg.m_val;
| }
|
| int main()
| {
| big_decimal dec;
| std::cout << boost::lexical_cast( dec ) << "\n";
| std::cout << boost::lexical_cast( boost::cref( dec ) ) <<
| "\n";
| return 0;
| }
|
| Result of execution:
|
| 1.23456789
| 1.23457
|
| Conclusion: usage of boost::cref with lexical_cast may lead to wrong results
| in the current implementation.
|
| --
| Thanks.
| Aleksandr Golovanov,
| MetaCommunications Engineering.
|
|
|
| ___
| Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
|
|
--- Begin Message ---
I note that the 'precision' number of digits in lexical cast is obtained from
digits10 +1
if(std::numeric_limits::is_specialized)
{
stream.precision(std::numeric_limits::digits10 + 1);
}
If, as I believe correct, the objective is to get all digits that can be
significant, and can be read back in without loss of precision, this isn't
always quite right according to:
"Lecture notes on the status of IEEE 754 standard for binary floating point
arithmetic"
William Kahan
http://http.cs.berkley.edu/~wkahan/ieee754status/ieee754.ps
gives formula for number of decimal digits which are guaranteed to be
correct on output and required for input to achieve maximum possible precision
as a function of the number of significand bits (given by
std::number_limits::digits).
In C++ the full formula is:
int significant_digits10 = int(ceil(1 + float_significand_digits * log10Two));
and using this formula :
std::numeric_limits::digits = 24 significand bits
std::numeric_limits::digits10 = 6
floor(float_significand_digits -1) * log10(2) = 6
ceil(1 + float_significand_digits * log10(2) = 9 all significant bits
(note that the existing code gives 7 here, which is 2 too few)
std::numeric_limits::digits = 53
std::numeric_limits::digits10 = 15
floor(double_significand_digits -1) * log10(2) = 15
ceil(1 + double_significand_digits * log10(2)) = 17
(note that the existing lecial_cast.hpp code gives 16 here, which is 1 too few)
32 significand bits digits10 = 6 significant_digits10 = 9
53 significand bits digits10 = 15 significant_digits10 = 17
64 significand bits digits10 = 18 significant_digits10 = 21
106 significand bitsdigits10 = 31 significant_digits10 = 33
113 significand bitsdigits10 = 33 significant_digits10 = 36
128 significand bitsdigits10 = 38 significant_digits10 = 40
(note that the rest are a few too few)
I have proposed before that numeric limits should have another item called,
perhaps,
significant_digits10 returning these useful values,
but meanwhile I suggest that following the style of boost/limits.h
BOOST_STL_DECLARE_LIMITS_MEMBER(int, digits10, (digits * 301) / 1000);
// log 2 = 0.301029995664...
The integer fraction 301/1000 is needed to avoid suggeating to the compiler that
it should do a floating point calculation (which silently fails!)
so the following formula is used instead:
int const sig_digit
Re: [boost] Re: lexical_cast segfault
you missed the point, it runs completely correctly on my system I don't need to "work around" anything, nor does boost. IMO, the problem has been fixed At Wednesday 2003-08-06 05:12, you wrote: "Victor A. Wagner, Jr." <[EMAIL PROTECTED]> writes: >>Test case (note that WinXP doesn't complain when programs segfault, hence >>the Begin/End business): See http://www.boost.org/more/error_handling.html for a way to work around that. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law" ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: lexical_cast issue
> The problem, IIRC, is that if wchar_t is just a synonym for > unsigned short, then unless the wide character handling is > disabled in lexical_cast, it will give errors if it's used > with unsigned short (such as in the Date/Time library), and > people weren't too happy about that, understandably. The > problem is that it then thinks unsigned short is wchar_t > (i.e. a character), and therefore doesn't work correctly. I completely forgot about other boost libraries depending on lexical_cast - I was only looking at the lexical_cast's dependencies _toward_ other boost libraries. Thanks for pointing this out. > This problem surfaced after the 1.30 release, so we changed > the CVS version to disable wide character handling, unless > wchar_t is an intrinsic type. On some platforms it may not be > possible to reliable detect intrinsic wchar_t or not (such as > some versions of Intel C++ on Windows), so Boost.Config errs > on the side of safety, disabling it in that case. Well, it is properly detected and disabled :( in our case, and now I see that we can't avoid that. Actually we can, but then we will break other boost libraries, which currently (for us) is not an issue, but might soon be. > It does work; it just doesn't treat unsigned short/wchar_t as > wchar_t, in that case. Would you like lexical_cast to treat > wchar_t (when synonym for unsigned short) as wchar_t? As > mentioned, that breaks other libraries, which assume that > unsigned short is an integer, not a character. Seems like I will have to dig in again and do my best to patch our compilation to treat wchar_t as it should be, native type. Millions of lines of source code affected by this change are definitely discouraging me, though. Thanks for your time, it is very appreciated, Drazen ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast issue
> From: Rodolfo Lima
>
> I had some problems with lexical_cast and not using wchar_t as a built-in
> type. For instance...
>
> std::stringstream ss;
> ss << boost::lexical_cast("23");
>
> lexical_cast would return a wstring, and a compile failure, because
> internally there is a the template that matches unsigned short as wchar_t,
> which makes lexical_cast return a wstring.
This is similar to an earlier posting I just sent a reply to. From the error message
you quote, I'm guessing you're using MSVC. As mentioned in the posting I just sent,
the 1.30 version of lexical_cast had some problems when used on platforms without
intrinsic wchar_t. Could you perhaps tried the latest CVS version (if you haven't),
and if it still doesn't work, could you have given the name and version of the
compiler you tried it on?
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast problem
Kevlin Henney wrote:
> In article <[EMAIL PROTECTED]>, Vladimir Prus
> <[EMAIL PROTECTED]> writes
>
> >The principle of least astonishment can be applied in a different way. We
> >all know that lexical cast uses streams, and
> >
> >stringstream ss(" 1 ");
> >int i;
> >ss >> i;
> >cout << i << "\n";
> >
> >certainly works. It's surprising that lexical_cast(" 1 ") does not
> >work.
>
> This is argument by false analogy. If the above were to fail, eg "a" was
> the initialiser, it won't throw an exception.
Unfortunately, I don't understand what you mean. What's the "above" and what's
"it"?
> Yes, there is an
> underlying stringstream, but lexical_cast uses stringstream; it is not
> stringstream. The current model ensures that, unlike I/O streams, input
> and output are treated more symmetrically and various constraints, such
> as the full conversion of a buffered representation, are strongly
> enforced.
Hm, where the "current model" comes from? The version in CVS was added during
1.30 preparation and it was expected to fix some known problems with the
previous version. You now say about "current model" which emerged, and
I don't see *anything* in docs about it. The docs, actually, don't say how
spaces are handled, or that any changes were made to this part and that all
input should be consumed.
> A quick inspection of its history reveals a move away from the looser
> I/O stream model of conversion. The original design was softer and more
> script-like in its tolerances, but the general needs that most users had
> were stricter.
I've some problems with this reasoning:
1. I never seen posts which asked for this change of semantic and
I'm not sure it's good in practice.
2. As I say in other post
(http://article.gmane.org/gmane.comp.lib.boost.devel/19133), the
change breaks conversions to user-defined classes.
> If you want the kind of behaviour described above, I suggest using --
> wait for it -- std::stringstream,
Using std::stringstream is not that convenient, for the reasons described
in lexical_cast docs.
> or writing a trim function that cuts
> leading and trailing space characters.
This would help in string->something conversion case, though I don't like
extra efforts.
> >BTW, I cannot find the test case for trailing space in
> >lexical_case_test.cpp, and... the following works with gcc 3.2:
...
> Thanks for spotting this. That is missing, and the accommodation of that
> behaviour is legacy -- it is incompatible with the idea that full
> conversion only is supported, and the way that textual types are
> handled.
I can say only that I'd be -1 on the change, because I don't see the practical
need to it.
> >Alas, it's not very helpfull as a debugging tool as it is.
>
> No, and that's because it is not primarily intended to be a debugging
> tool. The only resolution I can see that accommodates this in part,
> without running foul of reasonable constraints on exception types, is to
> use a fixed-size char array that truncates the residual buffer content
> if necessary.
Hmm... why is this complexity is needed? Can't you just have an
shared_ptr member in exception class, which the entire
'what' message. Yes, the required memory is unbounded, but copy
ctor will never throw an exception.
- Volodya
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast fixes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kevlin, Kevlin Henney wrote: | In article <[EMAIL PROTECTED]>, Thomas Witt | <[EMAIL PROTECTED]> writes | | (1) I would not consider that to be something to document as the | implementation should be free to choose a suitable approach, Agreed, when I was talking about getline() and str() I was using them more like a placeholder for the implied semantics. The semantic is documented now. | so long as | it satisfies the principle of least astonishment (the whitespace bug | clearly failed this test :->). Yes, it did not satisfy the principle of least surprise. No, it wasn't a bug. Thanks for the fix and the documentation update. Looks much better now. Nitpickingly yours Thomas - -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+dLaC0ds/gS3XsBoRAtIHAJwMx8x+MfIloy9nPdkzLeDOUiJzVgCeIaA9 NviKY9OWXNPGb5QSUYFisS0= =mRhl -END PGP SIGNATURE- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast fixes
Kevlin,
Kevlin Henney wrote:
In article <[EMAIL PROTECTED]>, David Abrahams
Without a documentation update?!?
The documentation is the same as it was yesterday. The change was in the
implementation and not the interface, which is what is documented.
As said before I am not trying to block the lexical_cast update for
1_30_0. That's beyond my power anyway. I'll try to rephrase my criticism
to be a bit more constructive.
That said I do have serious concerns with regard to the documentation. I
would really appreciate it if you could comment on the following issues.
All quotations from the current documentation.
In general I do think a paragraph describing the changes in semantics
with respect to the prior version is missing. To me this is a must. IIUC
there are wchar_t support aside two significant changes in semantics.
First conversions to std::basic_string and second precision of floating
point output. The change in floating point precision handling might be
surprising to some users. Especially to those who use lexical_cast for
output formatting.
In detail:
"Returns the result of streaming arg into a std::stringstream and then
out as a Target object".
IIUC this is false for conversions to std::basic_string. If I read the
code correctly std::getline is used to extract the string from the
stream. There is a big semantic difference to using operator>> as
implied by the above sentence. BTW why isn't streamobject.str() used to
extract the string? I do think this needs to be documented and a
rationale describing why the current semantics were choosen would be
really helpfull in understanding lexical_cast and the involved problems.
"Note that spaces are significant in any conversion and are not skipped."
I think this sentence was the main reason why I got the impression that
you didn't change the documentation at all. To me it is easily
misunderstood for someone who is aware of the problems with string
streaming. To me this sentence implies that
lexical_cast("U U");
does not work. I.e. whitespace is significant.
Thanks in advance
Thomas
--
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet
Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
http://www.ive.uni-hannover.de
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast
>From: "Kevlin Henney" <[EMAIL PROTECTED]> > In article <[EMAIL PROTECTED]>, David Abrahams > <[EMAIL PROTECTED]> writes > >Kevlin Henney <[EMAIL PROTECTED]> writes: > > > >>>on deficient compilers. > >> > >> Agreed. However, VC7 is not such a compiler > > > >Huh? VC7 not deficient? > > Perhaps that claim was too broad ;-) > > >It certainly doesn't support partial > >ordering. > > True. But the ordering of definitions is such that it does work on VC7 > (swap them round and it doesn't work). The error message indicated did > not seem to indicate that this was the problem. > > >most-confused-ly y'rs, > > In which case, it is clear that I must be imagining all the successful > compilations and test executions I have been having. No, you didn't; I got problem-free compilation of that version on VC7, too. Let's just say that VC7's support for partial ordering is, uhm, partial. ;) >From an earlier posting: > From the compiler messages I am > seeing, it is uncertain whether Terje's trial implementation would have > faired uniformly better. Since MSVC 6/7, and Borland C++, doesn't handle partial ordering of function templates well, or not at all, I also had to avoid that for those platforms, by having workaround code for them in my proposition. Just like you've had to avoid partial ordering in your latest version, to make it work properly on MSVC, especially version 6. My proposition would likely have fared better than the first update that was committed, due to the mentioned workaround code it had. However, since then, you've got the new version to work with tests passing on all the compilers on the Win32 tests, so it's at least as portable. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast
Kevlin Henney <[EMAIL PROTECTED]> writes: >>on deficient compilers. > > Agreed. However, VC7 is not such a compiler Huh? VC7 not deficient? It certainly doesn't support partial ordering. most-confused-ly y'rs, dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast now broken for MacOS X / darwin toolset
Kevlin Henney wrote: > In article <[EMAIL PROTECTED]>, Markus Schöpflin > <[EMAIL PROTECTED]> writes >> The new lexical_cast (with the latest fixes from beman) now fails >> with >> the darwin toolset. The error messages are at >> http://boost.sourceforge.net/regression-logs/cs-Darwin-RC_1_30_0-links.html# lexi >> cal_cast_test%20darwin > > Looks like the compiler has incorrectly deduced that the stream should > use char for a std::wstring I/O. That's because BOOST_NO_STD_WSTRING is set according to the config_info output. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast(Was: FYI)
Kevlin Henney wrote: > In article <[EMAIL PROTECTED]>, > Beman > Dawes <[EMAIL PROTECTED]> writes >> >> VC++7 is not giving trouble with any tests other than >> lexical_cast_test. On it, the message begins: >> >> D:\boost\site-RC_1_30_0\boost\lexical_cast.hpp(142) : error C2065: >> 'InputStreamable' : undeclared identifier > > Which of course, is not the case :-> The problem does not appear to be > with the code. The code has template bool operator>>(InputStreamable &output); template bool operator>>(std::basic_string &output); This seems to require partial ordering. The second overload should probably be replaced with bool operator>>(std::string &output); bool operator>>(std::wstring &output); on deficient compilers. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast(Was: FYI)
At 04:19 AM 3/13/2003, Kevlin Henney wrote: >Just to let you know that a new version is now in CVS. > >However, it appears to break under the regression test. I expected it to >break for VC6, but it is apparently failing to compile under VC7 and >Intel 7.0... which is more than a little bizarre because I have been >using VC7 as the main test compiler and Terje checked it against Intel >7.0. Both compile and run cleanly. VC++7 is not giving trouble with any tests other than lexical_cast_test. On it, the message begins: D:\boost\site-RC_1_30_0\boost\lexical_cast.hpp(142) : error C2065: 'InputStreamable' : undeclared identifier >If anyone has any inspired guesses as to why the sourceforge build is >failing for what appears to be clean and correct code, please let me >know! The error messages from various date_time library fails for both Intel and VC++ 6.0 are similar. Here is the Intel message: D:\boost\site-RC_1_30_0\boost/lexical_cast.hpp(137): error: no operator "<<" matches these operands operand types are: std::basic_stringstream, std::allocator> << const std::basic_string, std::allocator> return stream << input; Plus Robin Hu's posting: >A word on the lexical_cast_test.cpp: everything will be ok if you >commented all tests about std::wstring and wchar_t with > >#ifndef BOOST_NO_STD_WSTRING >#endif Both seem to indicate a wstring/wchar_t problem. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast "Future directions"
>From: "Thomas Witt" <[EMAIL PROTECTED]> > Kevlin Henney wrote: > >> > >>This is the philosophy that Kevlin and I agreed on when lexical_cast > >>was first introduced. However, I don't think it has stood the test of > >>time with real users, and it would be stupid to ignore that. I > > Agreed. I see the problem, I am just unsure with regard to the solution. > > >>suspect Kevlin feels the same way about it, which is why he has agreed > >>to review the changes in the Files area. > > > > Apologies for delays. Yes, I have to review Terje's changes and am > > guilty of not having applied myself to that task yet. In terms of the > > philosophy of the design, I think it would be reasonable to say that > > intuitive stream-based conversion is the aim, which is compatible with > > fixing whitespace issues. > > One more argument. lexical_cast may be able to provide intuitive > conversion for all std string types, but it will likely brake again for > custom string types. Even if the custom type has exactly the same > interface and semantics as std::string lexical_cast will break. Yes. That's why the proposal is designed to be _extensible_, to allow conversions between arbitrary types. See e.g. this posting (http://aspn.activestate.com/ASPN/Mail/Message/1403188). The interface will likely change, from using "boost::detail::lexical_cast_impl" to "boost::lexical_cast_traits", which will then perform the actual conversion. This may then be specialised for new types, which will then be handled seamlessly by lexical_cast, as shown in the mentioned posting. > naggingly yours No, this is good stuff. :) Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast "Future directions"
>From: "Early Ehlinger" <[EMAIL PROTECTED]>
> This is an interesting argument. In other words, lexical_cast is, by
> definition, conversion through a stream. Therefore, one cannot expect a
> string with whitespace to exit as it went in.
Not a string that uses whitespace as termination, no. However, that also
means that you can't lexical_cast convert any type that has whitespace in
its stream output, to std::string, which could make it rather less useful.
This is the current situation.
Note that it doesn't end there:
std::string str=boost::lexical_cast(""); // Throws
Shouldn't this be allowed, either? This is also a case that has resulted in
problem-reports for the current version. This is fixed in the proposal, and
the fix for both whitespace and empty strings can work the same way:
std::stringstream interpreter;
interpreter << source;
return interpreter.str();
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast "Future directions"
Kevlin Henney wrote: This is the philosophy that Kevlin and I agreed on when lexical_cast was first introduced. However, I don't think it has stood the test of time with real users, and it would be stupid to ignore that. I Agreed. I see the problem, I am just unsure with regard to the solution. suspect Kevlin feels the same way about it, which is why he has agreed to review the changes in the Files area. Apologies for delays. Yes, I have to review Terje's changes and am guilty of not having applied myself to that task yet. In terms of the philosophy of the design, I think it would be reasonable to say that intuitive stream-based conversion is the aim, which is compatible with fixing whitespace issues. One more argument. lexical_cast may be able to provide intuitive conversion for all std string types, but it will likely brake again for custom string types. Even if the custom type has exactly the same interface and semantics as std::string lexical_cast will break. naggingly yours Thomas -- Dipl.-Ing. Thomas Witt Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001 http://www.ive.uni-hannover.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast "Future directions"
In message <[EMAIL PROTECTED]>, David Abrahams <[EMAIL PROTECTED]> writes >"Early Ehlinger" <[EMAIL PROTECTED]> writes: > >> [Sorry for the top-posted reply... OE is giving me fits...] >> >> This is an interesting argument. In other words, lexical_cast is, >> by definition, conversion through a stream. Therefore, one cannot >> expect a string with whitespace to exit as it went in. >> >> Perhaps what is really needed is a different pseudo-cast, e.g., >> symantic_cast< >, which has different goals more in synch with what >> we are trying to accomplish, which is conversion from any type to >> another with minimized loss of symantic value. > >This is the philosophy that Kevlin and I agreed on when lexical_cast >was first introduced. However, I don't think it has stood the test of >time with real users, and it would be stupid to ignore that. I >suspect Kevlin feels the same way about it, which is why he has agreed >to review the changes in the Files area. Apologies for delays. Yes, I have to review Terje's changes and am guilty of not having applied myself to that task yet. In terms of the philosophy of the design, I think it would be reasonable to say that intuitive stream-based conversion is the aim, which is compatible with fixing whitespace issues. However, other type-to-type conversions outside of that realm generally don't fit with either the strict or loose interpretation of that design. A placeholder idea, namely interpret_cast (the original name of lexical_cast), is mentioned in the docs for smarter and more varied type conversions. However, the concrete demand for this feature has been as close to zero as arithmetic underflow. >I also suspect family and >work have been keeping him busy, which is why he hasn't done it yet >;-). > >I'd love to stop speculating and hear from Kevlin himself, though ;-) ;-) Family have been a constant source of amusement and colds, and work has been unseasonally busy -- or rather, given the current economic climate, it has econometeorologically atypical :-> 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: lexical_cast "Future directions"
"Early Ehlinger" <[EMAIL PROTECTED]> writes: > [Sorry for the top-posted reply... OE is giving me fits...] > > This is an interesting argument. In other words, lexical_cast is, > by definition, conversion through a stream. Therefore, one cannot > expect a string with whitespace to exit as it went in. > > Perhaps what is really needed is a different pseudo-cast, e.g., > symantic_cast< >, which has different goals more in synch with what > we are trying to accomplish, which is conversion from any type to > another with minimized loss of symantic value. This is the philosophy that Kevlin and I agreed on when lexical_cast was first introduced. However, I don't think it has stood the test of time with real users, and it would be stupid to ignore that. I suspect Kevlin feels the same way about it, which is why he has agreed to review the changes in the Files area. I also suspect family and work have been keeping him busy, which is why he hasn't done it yet ;-). I'd love to stop speculating and hear from Kevlin himself, though ;-) ;-) -Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast "Future directions"
>From: "Terje Slettebø" <[EMAIL PROTECTED]> > >From: "Early Ehlinger" <[EMAIL PROTECTED]> > > > std::stringstream temp; > > temp << source; > > return TargetType( temp.str().c_str() ); > > > This exact solution would work as long as the other string-types implements > the c_str() member function, like std::string. Oops, I misread the code. This would work for any target type that has a constructor which accepts a (const) char *. This is a good suggestion, and it's kind of an extension to Gennadiy's proposal (http://groups.yahoo.com/group/boost/files/lexical_cast_propositions/proposi tion1.cpp), which constructs the stringstream directly from a string, if the _source_ is a string. Your proposal covers if the _target_ is a string. I was going to add Gennadiy's proposal, and I'll add yours, as well. Thanks for the suggestion. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: lexical_cast "Future directions"
>From: "Early Ehlinger" <[EMAIL PROTECTED]>
> As a devil's advocate, consider, e.g., Borland's AnsiString class (part of
> their VCL and CLX libraries, basically a class that represents the
intrinsic
> String type in Pascal/Delphi):
>
> AnsiString foo = "Hello there";
> std::string str = boost::lexical_cast< std::string >( foo ); // exception
> for same reason!
>
> This leads me to wonder if there isn't a more generic solution to the
> problem. For example, it might be useful to have a mechanism to determine
> if source is a string type and if so, use an implementation that looks
> something like this:
>
> std::stringstream temp;
> temp << source;
> return TargetType( temp.str().c_str() );
>
> When I say "string type", I mean any type that represents the concept of a
> string, not just those that are implemented via std::basic_string. Not
sure
> what exactly the best way to do this is; perhaps a lexical_cast_traits<>
> template that the user must provide to help out? So right after I include
> the definition of AnsiString, I could do something like this:
>
> template<> struct lexical_cast_traits< AnsiString > : public
> lexical_cast_string_type { };
>
> And now lexical_cast would "know" that AnsiString is a string type.
>
> Similar things could be done to support CString from MFC as well as the
> zillions of other string implementations out there.
Thanks for the feedback. I'll look into this.
This exact solution would work as long as the other string-types implements
the c_str() member function, like std::string. The user might also provide
an implementation of the conversion (or specification of which to use), if
the type to be used doesn't have this interface. Any type that may output
whitespace, could make problems when reading it into a string.
It's possible to specialise lexical_cast_impl, to achieve the above (but as
mentioned, this isn't documented, yet), and this has been suggested to be
changed to a trait, instead, like you suggest above.
I'll update the proposal with the various suggestions that have come, and
write the docs for it, and I'll post a notice here when I've done it.
That'll give us something concrete to discuss. :)
Regards,
Terje
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
