An Easier Way?

[Mike Copeland]

The code below seems clumsy; I'm only replacing some C-based
"sprintf" logic here. Is there a simpler and slicker way to do this
sort of thing? TIA

time_t nEstTime = 0; // some value...
ostringstream ossw;
string estTimeStr;
ossw.clear(), ossw << setw(6) << nEstTime, estTimeStr = ossw.str();

 

[Öö Tiib]

The code below seems clumsy; I'm only replacing some C-based
"sprintf" logic here. Is there a simpler and slicker way to do this
sort of thing? TIA

What problem your code aims to solve? There probably is more portable
and easier to debug way to solve it. time_t is only guaranteed
to be some fundamental arithmetic type. It can be even floating point
type without violating standard and its value does usually say
nothing to human being.

time_t nEstTime = 0; // some value...
ostringstream ossw;
string estTimeStr;
ossw.clear(), ossw << setw(6) << nEstTime, estTimeStr = ossw.str();

If you need your program to do /exactly/ what sprintf or snprintf
does then better use sprintf or snprintf.

If you need to convert a numeric value to std::string then there are
std::to_string (in C++11 standard library <string>):

time_t nEstTime = 0; // some value...
string estTimeStr = std::to_string(nEstTime);

It anyway stays clumsy with time_t, because time_t is not portable and
not readable representation of a time point.

 

[Mike Copeland]

What problem your code aims to solve? There probably is more portable
and easier to debug way to solve it. time_t is only guaranteed
to be some fundamental arithmetic type. It can be even floating point
type without violating standard and its value does usually say
nothing to human being.

It's really a generic problem, and time_t isn't specific to my query.

If you need to convert a numeric value to std::string then there are
std::to_string (in C++11 standard library <string>):

time_t nEstTime = 0; // some value...
string estTimeStr = std::to_string(nEstTime);

The conversion(s) from numeric types to string seems awkward, but I
had not thought of "to_string" as a solution. 8<{{

It anyway stays clumsy with time_t, because time_t is not portable and
not readable representation of a time point.

Yes. Thank you for the "nudge" to "to_string". 8>}}

 

[woodbrian77]

If you need to convert a numeric value to std::string then there are
std::to_string (in C++11 standard library <string>):

time_t nEstTime = 0; // some value...
string estTimeStr = std::to_string(nEstTime);

I've used to_string a few times on gcc and clang, but
have turned away from it after seeing a jump in object
size compared to other alternatives. That's been over
three months ago so haven't tried it with the versions
of those compilers I'm using now. This has been one of
few disappointments for me with new stuff.

It anyway stays clumsy with time_t, because time_t is not portable and
not readable representation of a time point.

Can you suggest some portable alternatives to time_t?

Brian
Ebenezer Enterprises - In G-d we trust.
http://webEbenezer.net

 

[Gerhard Fiedler]

The conversion(s) from numeric types to string seems awkward, but I
had not thought of "to_string" as a solution. 8<{{

There's also the Boost lexical_cast. They claim that it's much faster
than stringstream-based implementations. (It may also help where
std::to_string is not available.)

Gerhard

 

[Öö Tiib]

I've used to_string a few times on gcc and clang, but
have turned away from it after seeing a jump in object
size compared to other alternatives. That's been over
three months ago so haven't tried it with the versions
of those compilers I'm using now. This has been one of
few disappointments for me with new stuff.

That "object size" generally matters only when it is embedded
software. Otherwise it is down in my wishlist somewhere among
"good to have". The authors of libstdc++ do it for free so if
you know a way how to make some thing in it more efficient then
help them. ;-)

Can you suggest some portable alternatives to time_t?

Most readable and portable at the moment are ISO 8601 compatible text
representations.

One can still use time_t and struct tm internally with those. For example
strftime seems to be available in most implementations. (Untested code):

time_t now;
time(&now);

// time_t to struct tm
struct tm now2 = gmtime(&now);

// struct tm to ISO 8601 string
std::string now3(sizeof "2013-07-24T19:59:09Z", '\0');
strftime(&t[0], t.size(), "%FT%TZ", gmtime(&now));

Parsing ISO 8601 back to struct tm is bit trickier, because POSIX
strptime is not available everywhere. OTOH one can always find an
implementation for it if it is missing.

I myself would use things in <chrono> or std::get_time/std:ut_time
if available. History has shown that standard things will be most portable
sooner or later. There is also Boost.Date_Time with lot of things done
well but it has some shortcomings too.

 

[woodbrian77]

Brian,

Please remove the link to my website (segmented_array) from your

I've removed the link to your website now.

Brian
Ebenezer Enterprises - Impeach Obama.
http://webEbenezer.net

 

[Tobias Müller]

Brian,

Please remove the link to my website (segmented_array) from your
company's website as I do not wish to be associated with homophobic
bigots, their unprofessional companies or the output of such companies.

I do not trust in any non-existent god (including "God" or "G-d") or the
people that use such a god as an excuse to hold offensive, bigoted opinions/beliefs.

/Leigh

Please do us all favor and stop hijacking threads.
This is something between you and Brian, just write him an email next time.

Tobi

 

[Jorgen Grahn]

.

Please do us all favor and stop hijacking threads.
This is something between you and Brian, just write him an email next time.

Well said. Thanks!

/Jorgen

 

[Jorgen Grahn]

On 24/07/2013 21:34, Tobias Müller wrote: ....

I bought my Internet tokens in good faith. Jog on bitch.

And now you're being rude to someone who politely asks you not to be
disruptive on comp.lang.c++. Well, despite your sometimes
constructive postings: *plonk*.

/Jorgen

 

[woodbrian77]

That "object size" generally matters only when it is embedded
software. Otherwise it is down in my wishlist somewhere among
"good to have". The authors of libstdc++ do it for free so if
you know a way how to make some thing in it more efficient then
help them. ;-)

I revisited this. I don't know if it's due to using a newer
version of clang and/or that I was more careful this time, but
I've changed my mind about to_string.

I would guess it's because I was more careful about the
testing this time and changed both of my uses of ostringstream
to to_string rather than just one of them. Anyway, now
when I change both uses, I find that the sizes of two of
my executables decrease. At any rate, I'm happy to find
that to_string is working better than stringstream. I
didn't think stringstream had set the bar that high so
was surprised in the first place with my previous results
and believe this result is more accurate.

Brian
Ebenezer Enterprises - John 3:16.
http://webEbenezer.net

 

[red floyd]

I revisited this. I don't know if it's due to using a newer
version of clang and/or that I was more careful this time, but
I've changed my mind about to_string.

The other question about "object size" is, are you meauring the
size of the executable file, or are you actually measuring the
size of the text/data/bss segments?

Because the executable is loaded with all sorts of other stuff
such as symbol tables, debugging info, etc...

If you're on a *nix system, use "size" to measure the actual
size of your executable. In Windows, I *THINK* that objdump
will do something similar.

 

[woodbrian77]

The other question about "object size" is, are you meauring the
size of the executable file, or are you actually measuring the
size of the text/data/bss segments?

Because the executable is loaded with all sorts of other stuff
such as symbol tables, debugging info, etc...

I was measuring the size of the files not the segments.
I know of objdump, but didn't know about that size command.
The executables are generally stripped of debugging info.
..

 

[red floyd]

I was measuring the size of the files not the segments.
I know of objdump, but didn't know about that size command.
The executables are generally stripped of debugging info.
.

For Windows, use "objdump -h" to get the size of the text and data
segments.

For Linux, just use the "size" command.