Re: Is this the correct way to do this template?
"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
news:1283mflrghr5e76@corp.supernews.com...
Jim Langston wrote:
"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
news:1283jn2thc3n315@corp.supernews.com...
Jim Langston wrote:
I have a template I call StrmConvert, which uses std::stringstream to
convert from any type to any other type that can be used by
stringstring. This is what it looks like:
template<typename T, typename F > T StrmConvert( F from )
{
std::stringstream temp;
temp << from;
T to = T();
temp >> to;
return to;
}
[snip]
int main ()
{
std::cout << StrmConvert<std::string>( 123.45 ) << std::endl;
I fail to see what that buys you compared to
std::cout << 123.45 << std::endl;
Well, usually this would be used for outputing text using a graphical
call. Something like:
draw_text( x, y, "The value is: " + jml::StrmConvert( HPs ) );
The std::cout here was just done for my test since it gained me nothing
to
bring in all my graphical code for a test.
Also note that the StrmConvert<> is broken with regard to float types:
conversion will not even remotely make a round-trip:
double x;
double y = StrmConvert<double>( x );
This will turn y into a 6-digit precission approximation (I think << has
a default precision like that). Usually that is not what you want.
Luckily for me, this is usually what I want. As I said, this is normally
used for simple output. Incidently, if I do need precision, is there
anyway I can fix it?
Yes, you would need to set the precision of the stringstream to the right
value. You could either have the template do that based upon the floating
type (partial specialization) or you pass a precision parameter as a
second
argument and have it default to something reasonable.
Also note that operator<< and operator>> are not strict inverses for
some
other types (e.g., std::string). Your cast may lead to surprising
results.
Please explain? I don't understand what you're saying here.
Well, I mistook your template for a cast. So I was concerned with code
like:
std::string s = "hello world!";
std::string t = my_fancy_cast< std::string >( s );
Now, given the naive stringstream implementation, the string t will
be "hello" and not "hello world!".
Now that I know you just want to convert to std::string so that you can
output anything via some API that takes strings or C-Strings, what about:
template< typename T >
std::string any_to_string ( T const & obj ) {
std::stringstream dummy;
if ( !( dummy << obj ) ) {
throw( std::runtime_error( "conversion to string failed" ) );
}
return dummy.str();
}
or:
template< typename T >
std::string any_to_string ( T const & obj, unsigned short prec = 6 ) {
std::stringstream dummy;
if ( !( dummy << std::setprecision(prec) << obj ) ) {
throw( std::runtime_error( "conversion to string failed" ) );
}
return dummy.str();
}
Well, sometimes I do use it to convert from strings to numbers, usually int
values.
The main use I'm using this for right now is a client/server program (game)
building and parsing strings from and to the server. Here is one real world
case of where I'm using it for this:
// Note, this is char value like "64", not a byte
CSVParser & CSVParser::operator >> (char & nOut)
{
GetField();
int tInt = jml::StrmConvert<int>( m_sField );
nOut = (char) tInt;
return *this;
}
CSVParser & CSVParser::operator >> (unsigned int & nOut)
{
GetField();
nOut = jml::StrmConvert<unsigned int>( m_sField );
return *this;
}
CSVParser & CSVParser::operator >> (unsigned long & nOut)
{
GetField();
nOut = jml::StrmConvert<unsigned long>( m_sField );
return *this;
}
CSVParser & CSVParser::operator >> (double & nOut)
{
GetField();
nOut = jml::StrmConvert<double>( m_sField );
return *this;
}
The use for double does concern me, given your comment about the precision
problems, which is why I asked how to fix it. There are some cases where
I'm transfering a float value with a number of decimal digits I need to
preserve. So far it hasn't caused any problems, but later on it will so I
will need to fix it.
Giving an optional 3rd paramter for places of precision would probably be my
best bet.