string to double

[Steven C.]

string strS;
stringstream stmT;
double dR;

stmT << strS;
stmT >> dR;

Is this the best way?

 

[Buster Copley]

string strS;
stringstream stmT;
double dR;

stmT << strS;
stmT >> dR;

Is this the best way?

No, you should test the stream state after reads and writes.
If you're going to do a lot of conversions from strings,

struct conversion_failure { };

template <typename T>
T from_string (const std::string & s)
{
T result;
std::istringstream stream (s);
if (stream >> result) return result;
throw conversion_failure ();
}

might come in handy. The client code becomes

double dR = from_string <double> (strS);

Regards,
Buster.

 

[Ryan Winter]

Thats not bad. I think this would be better though:

#include <sstream>
#include <string>
#include <ostream>

template <typename T>
bool fromString(const std::string &s, T &result)
{
std::istringstream stream ss;
return (stream >> result)
}

int main()
{
double d(0.0);
std::string s("34.543");

if (!fromString(s, d))
{
std::cerr << "error" << std::endl;
}
}

It doesnt need exceptions, and has greater type safety as you dont need
to specify the template type.

 

[Frank Schmitt]

Please don't top post - rearranged.

Thats not bad. I think this would be better though:

#include <sstream>
#include <string>
#include <ostream>

template <typename T>
bool fromString(const std::string &s, T &result)
{
std::istringstream stream ss;
return (stream >> result)
}

int main()
{
double d(0.0);
std::string s("34.543");

if (!fromString(s, d))
{
std::cerr << "error" << std::endl;
}
}

It doesnt need exceptions, and has greater type safety as you dont
need to specify the template type.

The other solution doesn't "need" exceptions as well - BTW, writing
an error to stderr from a function designed to be put in a library
is not very sensible IMHO - what happens if you use it from a GUI
program?
Apart from that: the original solution is IMHO superior in that
you can do sth like

double d = fromString<double>(s);

whereas with your solution I'd be forced to write

double d;
fromString(s,d);

And why should you gain greater type safety if you can omit the
template type???

regards
frank

 

[Buster Copley]

#include <string>
#include <ostream>

template <typename T>
bool fromString(const std::string &s, T &result)
{
std::istringstream stream ss;
return (stream >> result)
}

int main()
{
double d(0.0);
std::string s("34.543");

if (!fromString(s, d))
{
std::cerr << "error" << std::endl;
}
}

[snip]

The other solution doesn't "need" exceptions as well

Erm. Yes it does.

- BTW, writing
an error to stderr from a function designed to be put in a library
is not very sensible IMHO - what happens if you use it from a GUI
program?

This hypothetical library would contain 'fromString', not 'main'.

Apart from that: the original solution is IMHO superior in that
you can do sth like

double d = fromString<double>(s);

Thank you very much, but I don't agree.

whereas with your solution I'd be forced to write

double d;
fromString(s,d);

Careful now. You forgot the error checking:

if (fromString (s, d))
{
// non-exceptional code here
}
else
{
// other non-exceptional code. don't use d!
}

And why should you gain greater type safety if you can omit the
template type???

char c = from_string <int> ("1000000"); // oops

Regards,
Buster.

 

[Kevin Saff]

No, you should test the stream state after reads and writes.
If you're going to do a lot of conversions from strings,
[snip]
double dR = from_string <double> (strS);

Regards,
Buster.

boost::lexical_cast can do stream conversions between any streamable types,
so one can go the other way too:

std::string strS = boost::lexical_cast<std::string>(dR);

In addition, compare

 

[Ryan Winter]

#include <sstream>
#include <string>
#include <ostream>

template <typename T>
bool fromString(const std::string &s, T &result)
{
std::istringstream stream ss;
return (stream >> result)
}

int main()
{
double d(0.0);
std::string s("34.543");

if (!fromString(s, d))
{
std::cerr << "error" << std::endl;
}
}

[snip]

The other solution doesn't "need" exceptions as well

Erm. Yes it does.

- BTW, writing
an error to stderr from a function designed to be put in a library
is not very sensible IMHO - what happens if you use it from a GUI
program?

This hypothetical library would contain 'fromString', not 'main'.

Apart from that: the original solution is IMHO superior in that you
can do sth like

double d = fromString<double>(s);

Thank you very much, but I don't agree.

whereas with your solution I'd be forced to write

double d;
fromString(s,d);

Careful now. You forgot the error checking:

if (fromString (s, d))
{
// non-exceptional code here
}
else
{
// other non-exceptional code. don't use d!
}

And why should you gain greater type safety if you can omit the
template type???

char c = from_string <int> ("1000000"); // oops

You beat me to every single point Buster. Thanks

At least you got one thing right Frank, I should have followed the group
philosophy on top posting.

Ryan

 

[Frank Schmitt]

#include <sstream>
#include <string>
#include <ostream>

template <typename T>
bool fromString(const std::string &s, T &result)
{
std::istringstream stream ss;
return (stream >> result)
}

int main()
{
double d(0.0);
std::string s("34.543");

if (!fromString(s, d))
{
std::cerr << "error" << std::endl;
}
}

[snip]

The other solution doesn't "need" exceptions as well

Erm. Yes it does.

- BTW, writing
an error to stderr from a function designed to be put in a library
is not very sensible IMHO - what happens if you use it from a GUI
program?

This hypothetical library would contain 'fromString', not 'main'.

Ok, I missed that the std::cerr statement was in main and not in
fromString - sorry about that.

Thank you very much, but I don't agree.


Careful now. You forgot the error checking:

if (fromString (s, d))
{
// non-exceptional code here
}
else
{
// other non-exceptional code. don't use d!
}

Thanks - this shows exactly why exceptions are preferable to error
codes. When using error codes, I have to clutter every function
in the call stack with error checking statements, whereas with
exceptions I can handle the error *once and for all* where I
want to.

regards
frank

 

[Buster Copley]

Thanks - this shows exactly why exceptions are preferable to error
codes. When using error codes, I have to clutter every function
in the call stack with error checking statements, whereas with
exceptions I can handle the error *once and for all* where I
want to.

Unless you want to react differently to different failures. In
that case, your code would be littered with try-catches instead.
It depends whether you see the condition you are testing for
as truly exceptional, or business as usual. It's your call.

Regards,
Buster.