An Easier Way?

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

  1. 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
    #1
    1. Advertising

  2. Mike Copeland

    Öö Tiib Guest

    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
    #2
    1. Advertising

  3. 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
    #3
  4. Mike Copeland

    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
    #4
  5. 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
    #5
  6. Mike Copeland

    Öö Tiib Guest

    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::put_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
    #6
  7. Mike Copeland

    Guest

    On Wednesday, July 24, 2013 12:50:29 PM UTC-5, Leigh Johnston wrote:
    >
    > 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
     
    , Jul 24, 2013
    #7
  8. Leigh Johnston <> wrote:
    > 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
     
    Tobias Müller, Jul 24, 2013
    #8
  9. Mike Copeland

    Jorgen Grahn Guest

    On Wed, 2013-07-24, Tobias Müller wrote:
    ....
    > 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 <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jul 24, 2013
    #9
  10. Mike Copeland

    Jorgen Grahn Guest

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

    ....
    >> Please do us all favor and stop hijacking threads.
    >> 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
    #10
  11. Mike Copeland

    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
    #11
  12. Mike Copeland

    red floyd Guest

    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
    #12
  13. Mike Copeland

    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
    #13
  14. Mike Copeland

    red floyd Guest

    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
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Norman Ackroyd
    Replies:
    1
    Views:
    567
  2. Kathy Burke
    Replies:
    0
    Views:
    359
    Kathy Burke
    Jul 31, 2003
  3. Raterus
    Replies:
    1
    Views:
    2,276
    Srinivas
    Feb 13, 2004
  4. PiotrO
    Replies:
    0
    Views:
    316
    PiotrO
    May 2, 2004
  5. David
    Replies:
    3
    Views:
    351
    Saravana [MVP]
    Jul 12, 2004
Loading...

Share This Page