An Easier Way?

Discussion in 'C++' started by Mike Copeland, Jul 24, 2013.

1. Mike CopelandGuest

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();

Mike Copeland, Jul 24, 2013

2. Öö TiibGuest

On Wednesday, 24 July 2013 02:07:59 UTC+3, Mike Copeland wrote:
> 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.

Öö Tiib, Jul 24, 2013

3. Mike CopelandGuest

In article <>,
says...
> > 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.

It's really a generic problem, and time_t isn't specific to my query.
>
> > time_t nEstTime = 0; // some value...
> > ostringstream ossw;
> > string estTimeStr;
> > ossw.clear(), ossw << setw(6) << nEstTime, estTimeStr = ossw.str();

>
> 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>}}

Mike Copeland, Jul 24, 2013
4. Guest

On Tuesday, July 23, 2013 8:11:24 PM UTC-5, Öö Tiib wrote:
>
> 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

, Jul 24, 2013
5. Gerhard FiedlerGuest

Mike Copeland wrote:

> In article <>,
> says...
>> 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<{{

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

Gerhard Fiedler, Jul 24, 2013
6. Öö TiibGuest

On Wednesday, 24 July 2013 08:29:47 UTC+3, wrote:
> On Tuesday, July 23, 2013 8:11:24 PM UTC-5, Öö Tiib wrote:
> >
> > 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.

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. ;-)

> > 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?

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.

Öö Tiib, Jul 24, 2013
7. Guest

On Wednesday, July 24, 2013 12:50:29 PM UTC-5, Leigh Johnston wrote:
>
> Brian,
>

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

, Jul 24, 2013
8. Tobias MÃ¼llerGuest

Leigh Johnston <> wrote:
> Brian,
>
> 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

This is something between you and Brian, just write him an email next time.

Tobi

Tobias MÃ¼ller, Jul 24, 2013
9. Jorgen GrahnGuest

On Wed, 2013-07-24, Tobias Müller wrote:
....
> This is something between you and Brian, just write him an email next time.

Well said. Thanks!

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn, Jul 24, 2013
10. Jorgen GrahnGuest

On Wed, 2013-07-24, Leigh Johnston wrote:
> On 24/07/2013 21:34, Tobias Müller wrote:

....
>> This is something between you and Brian, just write him an email next time.

>
> 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

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn, Jul 24, 2013
11. Guest

On Wednesday, July 24, 2013 12:47:55 PM UTC-5, Öö Tiib wrote:
>
> 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

, Jul 25, 2013
12. red floydGuest

On 7/25/2013 10:58 AM, wrote:
> On Wednesday, July 24, 2013 12:47:55 PM UTC-5, Öö Tiib wrote:
>>
>> 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.
>

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.

red floyd, Jul 25, 2013
13. Guest

On Thursday, July 25, 2013 4:45:05 PM UTC-5, red floyd wrote:
>
> 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.
..

, Jul 25, 2013
14. red floydGuest

On 7/25/2013 3:16 PM, wrote:
> On Thursday, July 25, 2013 4:45:05 PM UTC-5, red floyd wrote:
>>
>> 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.
> .
>

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

For Linux, just use the "size" command.

red floyd, Jul 26, 2013