[lexical_cast] How is the degenerate case handled?
If you use lexical_cast to cast between identical types, eg. lexical_cast< int >( 4 ); does it go through all the machinery of streaming out and back, or does it short circuit? In those circumstances, does the type need to be streamable? Thanks, Rob.
Good point. I hope the answer is: - short circuited; - type need not to be streamable. B/Rgds Max From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Jones Sent: Wednesday, April 15, 2009 8:28 PM To: boost-users@lists.boost.org Subject: [Boost-users] [lexical_cast] How is the degenerate case handled? If you use lexical_cast to cast between identical types, eg. lexical_cast< int >( 4 ); does it go through all the machinery of streaming out and back, or does it short circuit? In those circumstances, does the type need to be streamable? Thanks, Rob.
Robert Jones <robertgbjones <at> gmail.com> writes:
If you use lexical_cast to cast between identical types,eg. lexical_cast< int ( 4 );does it go through all the machinery of streaming out and back, ordoes
it short circuit? In those circumstances, does the type need
to be streamable?Thanks, Rob.
This is not a common usecase and I see only one practical use of it. Trivial conversion can be used for data normalization. But ValueType is supposed to be always normalized (or to be indistinguishable from a normalized value). In fact, I can't even give you a good example because all my ideas are based on a string representation of values, e.g. "+1" -> "1" or "(0,\t1)" -> "(0,1)". For these, you need two conversions: string -> T -> string. So, you can't optimize a general case because theoretically one can use a trivial conversion for normalization. You could optimize for well known types with no-op normalization such as integers but I don't see a practical use of it. Alex
This is not a common usecase and I see only one practical use of it.
A user might want to write a template that uses lexical_cast without having to pay the performance cost when the cast isn't necessary. Specializing lexical_cast for this case would save the user from having to specialize his own template. I'm guessing template<typename Target> Target lexical_cast(const Target& arg) { return arg; } doesn't work because the compiler can't decide between lexical_cast<Foo> and lexical_cast<Foo, Foo> for lexical_cast<Foo>(some_foo). Could something like template<typename T> T lexical_cast<T, T>(const Target& arg) work? (My syntax might not be perfect; it's been a while since I've done partial specialization.) --Jeffrey Bosboom
On Tue, Apr 21, 2009 at 2:14 AM, <jbosboom@uci.edu> wrote:
Could something like
template<typename T> T lexical_cast<T, T>(const Target& arg)
work? (My syntax might not be perfect; it's been a while since I've done partial specialization.)
I recall that function templates cannot be partially specialised, so we (or the user in question) would have to do complete specialisation instead, so the given type would have to be known. Regards, Eugene Wee
I recall that function templates cannot be partially specialised, so we (or the user in question) would have to do complete specialisation instead, so the given type would have to be known.
Okay, so function templates can't be partially specialized like that, but class templates can, and classes can have static member functions. So how about template<class Target, class Source> Target lexical_cast(const Source& arg) { return lexical_cast_impl<Target, Source>::cast(arg); } template<class Target, class Source> class lexical_cast_impl { inline static cast(const Source& arg) { /* ... */ } }; //partial specialization for Target = Source template<class Target> class lexical_cast_impl<Target, Target> { inline static cast(const Source& arg) {return arg;} }; --Jeffrey Bosboom
participants (2)
-
Alexander Nasonov -
Eugene Wee -
Igor R -
jbosboom＠uci.edu -
Max -
Robert Jones