Re: Conversion from UTF32 to UTF8 for review

Discussion in 'C++' started by Maxim Yegorushkin, May 31, 2010.

  1. On 05/31/2010 04:49 PM, Leigh Johnston wrote:

    []

    > Why on earth would you have such a function emit something to stdout?
    > Consider throwing an exception instead. Also printf sucks, this is a C++
    > newsgroup not a C newsgroup.


    Does not C++ include C along with printf? What is the reason for your
    aversion?

    --
    Max
     
    Maxim Yegorushkin, May 31, 2010
    #1
    1. Advertising

  2. Leigh Johnston pulled this Usenet boner:

    > "Maxim Yegorushkin" <> wrote in message
    > news:4c03ee0d$0$3386$...
    >> On 05/31/2010 04:49 PM, Leigh Johnston wrote:
    >>
    >>> Why on earth would you have such a function emit something to stdout?
    >>> Consider throwing an exception instead. Also printf sucks, this is a C++
    >>> newsgroup not a C newsgroup.

    >>
    >> Does not C++ include C along with printf? What is the reason for your
    >> aversion?

    >
    > printf is retarded as it determines the types of its arguments at runtime
    > using a format string whilst the C++ way of doing things (e.g. with
    > std::cout) is to determine the types of its arguments at compile time which
    > is obviously superior. It is similar to the argument in favour of using
    > std::string instead of C-style strings: aging C idioms are relics of the
    > cold war.


    gcc determines the types at *compile* time also, and complains if your
    arguments don't match the printf() specs.

    I get your point, but there is one area where I *really* prefer printf():

    printf
    (
    "Parameters:\n"
    " Service Port: %d\n"
    " Host count: %d\n"
    " Heart rate (ms): %d\n"
    " Disconnect interval: %d ms\n"
    " Disconnect iteration: %d\n"
    " Number of logs: %d\n"
    " Keep-alive timeout: %d\n"
    " Keep-alive delay: %d\n"
    ,
    int(port()),
    hostCount(),
    int(heartbeat()),
    int(disconInterval()),
    int(disconIterations()),
    numLogs(),
    KeepAliveTimeout(),
    KeepAliveWarning()
    );

    You can easily see that the layout will be correct. And if you need width
    and precision specifiers, no contest in readability.

    --
    You will gain money by a speculation or lottery.
     
    Chris Ahlstrom, May 31, 2010
    #2
    1. Advertising

  3. * Leigh Johnston:
    > You cannot easily see the layout if you use a proportional font in your code
    > editor like I do


    In which case you're already a lost case ;)

    Iostream is horrible, but boost::format is a crude fix, which addresses some of
    the issues of using printf, while only adding a minor boatload of annoyance and
    cruft. Especially considering it's part of boost, which seems to maximise on
    both.

    --
    Martijn van Buul -
     
    Martijn van Buul, May 31, 2010
    #3
  4. Maxim Yegorushkin

    Öö Tiib Guest

    On 31 mai, 21:09, Christian Hackl <> wrote:
    > Chris Ahlstrom ha scritto:
    >
    >
    >
    > > I get your point, but there is one area where I *really* prefer printf():

    >
    > >       printf
    > >       (
    > >          "Parameters:\n"
    > >          "   Service Port:             %d\n"
    > >          "   Host count:               %d\n"
    > >          "   Heart rate (ms):          %d\n"
    > >          "   Disconnect interval:      %d ms\n"
    > >          "   Disconnect iteration:     %d\n"
    > >          "   Number of logs:           %d\n"
    > >          "   Keep-alive timeout:       %d\n"
    > >          "   Keep-alive delay:         %d\n"
    > >          ,
    > >          int(port()),
    > >          hostCount(),
    > >          int(heartbeat()),
    > >          int(disconInterval()),
    > >          int(disconIterations()),
    > >          numLogs(),
    > >          KeepAliveTimeout(),
    > >          KeepAliveWarning()
    > >       );

    >
    > Frankly, I don't see how this is any better than the following:
    >
    > std::cout <<
    >    "Service Port:         " << port() << "\n" <<
    >    "Host Count:           " << hostCount() << "\n" <<
    >    "Heart Rate (ms):      " << heartBeat() << "\n"
    >    // ...
    > ;
    >
    > It also has the advantage that you can change the order more easily
    > without the danger of introducing bugs.


    Yes, it is even better if to put operator at start of line like:

    cout
    << "Service Port: " << port() << endl
    << "Host Count: " << hostCount() << endl
    << "Heart Rate (ms): " << heartBeat() << endl
    ;

    > > And if you need width and precision specifiers, no contest in readability.

    >
    > But wouldn't you agree that stream manipulators names are much more
    > readable than stuff like "%+.0e"?


    Additionally there are cases when you need translations for example in
    gettext() style:

    wcout
    << _( L"Service Port: " ) << port() << wendl
    << _( L"Host Count: " ) << hostCount() << wendl
    << _( L"Heart Rate (ms): " ) << heartBeat() << wendl
    ;

    Sometimes micro-reordering may depend on translation, then use
    boost::format:

    wcout
    << boost::wformat( _( L"%1% %2% %3% %4%." ) )
    % attacker() % attack() % defender() % measure()
    << wendl
    ;

    printf() was made 1972 and was innovative back then but now ravages of
    time have done their job.
     
    Öö Tiib, Jun 1, 2010
    #4
  5. Maxim Yegorushkin

    Ian Collins Guest

    On 06/ 1/10 06:09 AM, Christian Hackl wrote:
    > Chris Ahlstrom ha scritto:
    >
    >> I get your point, but there is one area where I *really* prefer printf():
    >>
    >> printf
    >> (
    >> "Parameters:\n"
    >> " Service Port: %d\n"
    >> " Host count: %d\n"
    >> " Heart rate (ms): %d\n"
    >> " Disconnect interval: %d ms\n"
    >> " Disconnect iteration: %d\n"
    >> " Number of logs: %d\n"
    >> " Keep-alive timeout: %d\n"
    >> " Keep-alive delay: %d\n"
    >> ,
    >> int(port()),
    >> hostCount(),
    >> int(heartbeat()),
    >> int(disconInterval()),
    >> int(disconIterations()),
    >> numLogs(),
    >> KeepAliveTimeout(),
    >> KeepAliveWarning()
    >> );

    >
    > Frankly, I don't see how this is any better than the following:
    >
    > std::cout <<
    > "Service Port: " << port() << "\n" <<
    > "Host Count: " << hostCount() << "\n" <<
    > "Heart Rate (ms): " << heartBeat() << "\n"
    > // ...
    > ;
    >
    > It also has the advantage that you can change the order more easily
    > without the danger of introducing bugs.


    Not to mention changing types of the variables. Not having to know and
    specify the types to be streamed is one of the main advantages of iostreams.

    --
    Ian Collins
     
    Ian Collins, Jun 1, 2010
    #5
  6. Maxim Yegorushkin

    James Kanze Guest

    On May 31, 6:36 pm, Chris Ahlstrom <> wrote:
    > Leigh Johnston pulled this Usenet boner:


    [...]
    > gcc determines the types at *compile* time also, and complains
    > if your arguments don't match the printf() specs.


    How can it, since the format argument is typically read from a
    file (since it depends on the locale)?

    > I get your point, but there is one area where I *really* prefer printf():


    > printf
    > (
    > "Parameters:\n"
    > " Service Port: %d\n"
    > " Host count: %d\n"
    > " Heart rate (ms): %d\n"
    > " Disconnect interval: %d ms\n"
    > " Disconnect iteration: %d\n"
    > " Number of logs: %d\n"
    > " Keep-alive timeout: %d\n"
    > " Keep-alive delay: %d\n"
    > ,
    > int(port()),
    > hostCount(),
    > int(heartbeat()),
    > int(disconInterval()),
    > int(disconIterations()),
    > numLogs(),
    > KeepAliveTimeout(),
    > KeepAliveWarning()
    > );


    > You can easily see that the layout will be correct.


    In the rare case where the table contains a single variable
    field, and that field is the last, and even then... Neither
    printf nor the iostream are really practical for lining up
    tables; for that, you need something like the old Basic PRINT
    USING (or Cobols formatting patterns).

    On the other hand, most formatted output today uses variable
    width fonts, so you need a lot more (and again, neither printf
    nor ostream begin to address the issue).

    > And if you need width and precision specifiers, no contest in
    > readability.


    Just the opposite, I find. When you need the added specifiers
    with ostream, you give them a name related to the semantics
    which affects them, e.g.:
    cout << "Service Port: " << portFmt << port() << '\n';
    cout << "Host count: " << hostCountFmt << hostCount() << '\n';
    ...
    With printf, you're stuck with separate variables:
    printf( "Service Port: %*d\n"
    "Host count: %*d\n"
    ...,
    portFmt.width, int(port()),
    hostCountFmt.width, hostCount(),
    ... );
    And when someone decides that the port format must be hex, with
    leading zeros, you're stuck finding every reference to it in
    every printf, whereas with ostream, you just make the necessary
    changes in portFmt, and it automatically applies everywhere.

    It's the difference between logical markup and physical markup.
    Or between using manifest constants and named values, if you
    prefer.

    --
    James Kanze
     
    James Kanze, Jun 1, 2010
    #6
  7. Maxim Yegorushkin

    James Kanze Guest

    On Jun 1, 1:49 am, Ian Collins <> wrote:
    > On 06/ 1/10 06:09 AM, Christian Hackl wrote:


    > > Frankly, I don't see how this is any better than the following:


    > > std::cout <<
    > > "Service Port: " << port() << "\n" <<
    > > "Host Count: " << hostCount() << "\n" <<
    > > "Heart Rate (ms): " << heartBeat() << "\n"
    > > // ...
    > > ;


    > > It also has the advantage that you can change the order more easily
    > > without the danger of introducing bugs.


    > Not to mention changing types of the variables. Not having to
    > know and specify the types to be streamed is one of the main
    > advantages of iostreams.


    Or to be able to output user defined types. I could easily
    imagine user defined types for most of this.

    --
    James Kanze
     
    James Kanze, Jun 1, 2010
    #7
  8. Maxim Yegorushkin

    Ian Collins Guest

    On 06/ 1/10 09:50 PM, James Kanze wrote:
    > On May 31, 6:36 pm, Chris Ahlstrom<> wrote:
    >> Leigh Johnston pulled this Usenet boner:

    >
    > [...]
    >> gcc determines the types at *compile* time also, and complains
    >> if your arguments don't match the printf() specs.

    >
    > How can it, since the format argument is typically read from a
    > file (since it depends on the locale)?


    Except when it isn't:

    cat /tmp/x.c
    #include <stdio.h>
    int main() {
    printf( "%d\n", "hello" );
    }
    gcc -ansi -Wall -pedantic /tmp/x.c
    /tmp/x.c: In function 'main':
    /tmp/x.c:3: warning: format '%d' expects type 'int', but argument 2 has
    type 'char *'

    I still don't accept that the format argument is typically read from a
    file. A lot of code isn't translated. Try a quick search through a
    large opensource code base (say an OS kernel) and see what you get.

    --
    Ian Collins
     
    Ian Collins, Jun 1, 2010
    #8
  9. Christian Hackl pulled this Usenet boner:

    > Chris Ahlstrom ha scritto:
    >
    >> I get your point, but there is one area where I *really* prefer printf():
    >>
    >> printf
    >> (
    >> "Parameters:\n"
    >> " Service Port: %d\n"
    >> " Host count: %d\n"
    >> " Heart rate (ms): %d\n"
    >> " Disconnect interval: %d ms\n"
    >> " Disconnect iteration: %d\n"
    >> " Number of logs: %d\n"
    >> " Keep-alive timeout: %d\n"
    >> " Keep-alive delay: %d\n"
    >> ,
    >> int(port()),
    >> hostCount(),
    >> int(heartbeat()),
    >> int(disconInterval()),
    >> int(disconIterations()),
    >> numLogs(),
    >> KeepAliveTimeout(),
    >> KeepAliveWarning()
    >> );

    >
    > Frankly, I don't see how this is any better than the following:
    >
    > std::cout <<
    > "Service Port: " << port() << "\n" <<
    > "Host Count: " << hostCount() << "\n" <<
    > "Heart Rate (ms): " << heartBeat() << "\n"
    > // ...
    > ;
    >
    > It also has the advantage that you can change the order more easily
    > without the danger of introducing bugs.


    Maybe. That's why I format it in so strict a fashion.

    Also, I tend to write "classes" that deal strictly with parameters or
    configuration items in C, so I'm not restricted to C++.

    >> And if you need width and precision specifiers, no contest in readability.

    >
    > But wouldn't you agree that stream manipulators names are much more
    > readable than stuff like "%+.0e"?


    No.

    --
    Modern psychology takes completely for granted that behavior and neural function
    are perfectly correlated, that one is completely caused by the other. There is
    no separate soul or lifeforce to stick a finger into the brain now and then and
    make neural cells do what they would not otherwise. Actually, of course, this
    is a working assumption only....It is quite conceivable that someday the
    assumption will have to be rejected. But it is important also to see that we
    have not reached that day yet: the working assumption is a necessary one and
    there is no real evidence opposed to it. Our failure to solve a problem so
    far does not make it insoluble. One cannot logically be a determinist in
    physics and biology, and a mystic in psychology.
    -- D. O. Hebb, Organization of Behavior: A Neuropsychological Theory, 1949
     
    Chris Ahlstrom, Jun 1, 2010
    #9
  10. James Kanze pulled this Usenet boner:

    > On Jun 1, 1:49 am, Ian Collins <> wrote:
    >> On 06/ 1/10 06:09 AM, Christian Hackl wrote:

    >
    >> > Frankly, I don't see how this is any better than the following:

    >
    >> > std::cout <<
    >> > "Service Port: " << port() << "\n" <<
    >> > "Host Count: " << hostCount() << "\n" <<
    >> > "Heart Rate (ms): " << heartBeat() << "\n"
    >> > // ...
    >> > ;

    >
    >> > It also has the advantage that you can change the order more easily
    >> > without the danger of introducing bugs.

    >
    >> Not to mention changing types of the variables. Not having to
    >> know and specify the types to be streamed is one of the main
    >> advantages of iostreams.

    >
    > Or to be able to output user defined types. I could easily
    > imagine user defined types for most of this.


    Why would user-defined types be an issue? Just write a (C) function
    to output the user-defined type in your chosen layout.

    Anyway, I do this because I got tired of trying to get the formatting
    correct when manipulators cluttered it up, and because the style is
    just as useful in C++ as in C.

    Emitting just streams of text, yeah, then I go the iostream route.

    Or if I'm forced to construct a string piece-by-piece.

    --
    Bradyism:
    A multisibling sensibility derived from having grown up in
    large families. A rarity in those born after approximately 1965,
    symptoms of Bradyism include a facility for mind games, emotional
    withdrawal in situations of overcrowding, and a deeply felt need for a
    well-defined personal space.
    -- Douglas Coupland, "Generation X: Tales for an Accelerated
    Culture"
     
    Chris Ahlstrom, Jun 1, 2010
    #10
  11. James Kanze pulled this Usenet boner:

    > On May 31, 6:36 pm, Chris Ahlstrom <> wrote:
    >> Leigh Johnston pulled this Usenet boner:

    >
    >> gcc determines the types at *compile* time also, and complains
    >> if your arguments don't match the printf() specs.

    >
    > How can it, since the format argument is typically read from a
    > file (since it depends on the locale)?


    Even that were always true, the way I tackle it is shown in this example:

    fprintf(file, "%s %d", _("The periodicity index is"), int(pindex));

    >> printf
    >> (
    >> "Parameters:\n"
    >> " Service Port: %d\n"
    >> " Host count: %d\n"
    >> " Keep-alive delay: %d\n"
    >> ,
    >> int(port()),
    >> hostCount(),
    >> KeepAliveWarning()
    >> );

    >
    >> You can easily see that the layout will be correct.

    >
    > In the rare case where the table contains a single variable
    > field, and that field is the last, and even then... Neither
    > printf nor the iostream are really practical for lining up
    > tables; for that, you need something like the old Basic PRINT
    > USING (or Cobols formatting patterns).


    Makes sense to me.

    > On the other hand, most formatted output today uses variable
    > width fonts, so you need a lot more (and again, neither printf
    > nor ostream begin to address the issue).


    Again, very true outside my normal use-case (console output for debugging).

    >> And if you need width and precision specifiers, no contest in
    >> readability.

    >
    > Just the opposite, I find. When you need the added specifiers
    > with ostream, you give them a name related to the semantics
    > which affects them, e.g.:
    > cout << "Service Port: " << portFmt << port() << '\n';
    > cout << "Host count: " << hostCountFmt << hostCount() << '\n';
    > ...
    > With printf, you're stuck with separate variables:
    > printf( "Service Port: %*d\n"
    > "Host count: %*d\n"
    > ...,
    > portFmt.width, int(port()),
    > hostCountFmt.width, hostCount(),
    > ... );


    We'll have to just disagree on the readability issue. :)

    > And when someone decides that the port format must be hex, with
    > leading zeros, you're stuck finding every reference to it in
    > every printf, whereas with ostream, you just make the necessary
    > changes in portFmt, and it automatically applies everywhere.
    >
    > It's the difference between logical markup and physical markup.
    > Or between using manifest constants and named values, if you
    > prefer.


    I agree. Like I said, I only use the printf() in fairly restrictive
    conditions.

    Thanks for the debate.

    --
    The only people for me are the mad ones -- the ones who are mad to live,
    mad to talk, mad to be saved, desirous of everything at the same time,
    the ones who never yawn or say a commonplace thing, but burn, burn, burn
    like fabulous yellow Roman candles.
    -- Jack Kerouac, "On the Road"
     
    Chris Ahlstrom, Jun 1, 2010
    #11
  12. Maxim Yegorushkin

    Öö Tiib Guest

    On Jun 1, 3:39 pm, Chris Ahlstrom <> wrote:
    > James Kanze pulled this Usenet boner:
    > > On Jun 1, 1:49 am, Ian Collins <> wrote:
    > >> On 06/ 1/10 06:09 AM, Christian Hackl wrote:
    > >> > Frankly, I don't see how this is any better than the following:

    >
    > >> > std::cout <<
    > >> > "Service Port: " << port() << "\n" <<
    > >> > "Host Count: " << hostCount() << "\n" <<
    > >> > "Heart Rate (ms): " << heartBeat() << "\n"
    > >> > // ...
    > >> > ;

    >
    > >> > It also has the advantage that you can change the order more easily
    > >> > without the danger of introducing bugs.

    >
    > >> Not to mention changing types of the variables. Not having to
    > >> know and specify the types to be streamed is one of the main
    > >> advantages of iostreams.

    >
    > > Or to be able to output user defined types.  I could easily
    > > imagine user defined types for most of this.

    >
    > Why would user-defined types be an issue?  Just write a (C) function
    > to output the user-defined type in your chosen layout.


    Because describing itself to the world is part of interface of a
    class. You are correct of course that the part is good to be
    implemented as non-member non-friend interface because it should not
    display something that is not otherwise externally visible state.
    operator<< is natural candidate as such interface, but you may have
    some sort of toString() instead.

    > Anyway, I do this because I got tired of trying to get the formatting
    > correct when manipulators cluttered it up, and because the style is
    > just as useful in C++ as in C.


    Yes, it is sensible if you write mostly in C style. In C you have lot
    of raw floats, ints and char* around in struct's, have to externally
    manage these and apply complex format specifiers when formating.
    Massive usage of functions with ellipsis parameters also makes it
    extra hard to refactor it into something more object-oriented later,
    so it probably stays like that.
     
    Öö Tiib, Jun 1, 2010
    #12
  13. Maxim Yegorushkin

    Jorgen Grahn Guest

    printf (was Re: Conversion from UTF32 to UTF8 for review)

    On Mon, 2010-05-31, Chris Ahlstrom wrote:
    > Leigh Johnston pulled this Usenet boner:
    >
    >> "Maxim Yegorushkin" <> wrote in message
    >> news:4c03ee0d$0$3386$...
    >>> On 05/31/2010 04:49 PM, Leigh Johnston wrote:
    >>>
    >>>> Why on earth would you have such a function emit something to stdout?
    >>>> Consider throwing an exception instead. Also printf sucks, this is a C++
    >>>> newsgroup not a C newsgroup.
    >>>
    >>> Does not C++ include C along with printf? What is the reason for your
    >>> aversion?

    >>
    >> printf is retarded as it determines the types of its arguments at runtime
    >> using a format string whilst the C++ way of doing things (e.g. with
    >> std::cout) is to determine the types of its arguments at compile time which
    >> is obviously superior. It is similar to the argument in favour of using
    >> std::string instead of C-style strings: aging C idioms are relics of the
    >> cold war.

    >
    > gcc determines the types at *compile* time also, and complains if your
    > arguments don't match the printf() specs.
    >
    > I get your point, but there is one area where I *really* prefer printf():
    >
    > printf
    > (
    > "Parameters:\n"
    > " Service Port: %d\n"
    > " Host count: %d\n"
    > " Heart rate (ms): %d\n"
    > " Disconnect interval: %d ms\n"
    > " Disconnect iteration: %d\n"
    > " Number of logs: %d\n"
    > " Keep-alive timeout: %d\n"
    > " Keep-alive delay: %d\n"
    > ,
    > int(port()),
    > hostCount(),
    > int(heartbeat()),
    > int(disconInterval()),
    > int(disconIterations()),
    > numLogs(),
    > KeepAliveTimeout(),
    > KeepAliveWarning()
    > );
    >
    > You can easily see that the layout will be correct.


    I can easily see, but it will not be correct -- integers in columns
    should be right-adjusted. It doesn't change your point, but I mention
    it anyway because I really hate reading badly formatted output.

    > And if you need width
    > and precision specifiers, no contest in readability.


    Like you I trust my compiler to check the arguments of printf(), but I
    dislike it for other reasons:

    - It forces you do decide the formatting at the point of the printf
    call. I usually want different formatting for different types, not
    different formatting for the same type in different printf() calls.

    - It doesn't support user-defined types, so using printf() means you
    are more inclined to write code with weak typing.

    - And for the user-defined types, you are pretty much stuck with
    writing

    printf("foo: %s\n", to_string(foo).c_str());

    which is inefficient and ugly.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jun 2, 2010
    #13
  14. Maxim Yegorushkin

    Jorgen Grahn Guest

    On Tue, 2010-06-01, Chris Ahlstrom wrote:
    > Christian Hackl pulled this Usenet boner:

    ....
    >> But wouldn't you agree that stream manipulators names are much more
    >> readable than stuff like "%+.0e"?

    >
    > No.


    I think a lot of us, maybe the majority, find %+.0e more readable than
    whatever the stream manipulator syntax (and semantics) is.

    (Also, the printf-style thing is the same in all languages I use: C++,
    C, Perl, Python, shell scripts.)

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jun 3, 2010
    #14
  15. Maxim Yegorushkin

    Jorgen Grahn Guest

    On Thu, 2010-06-03, Peter Olcott wrote:
    > On 6/3/2010 1:59 AM, Jorgen Grahn wrote:
    >> On Tue, 2010-06-01, Chris Ahlstrom wrote:
    >>> Christian Hackl pulled this Usenet boner:

    >> ...
    >>>> But wouldn't you agree that stream manipulators names are much more
    >>>> readable than stuff like "%+.0e"?
    >>>
    >>> No.

    >>
    >> I think a lot of us, maybe the majority, find %+.0e more readable than
    >> whatever the stream manipulator syntax (and semantics) is.
    >>
    >> (Also, the printf-style thing is the same in all languages I use: C++,
    >> C, Perl, Python, shell scripts.)
    >>
    >> /Jorgen
    >>

    >
    > So because of this printf is the superior choice of output mechanisms
    > for validating developmental code.


    I might seem to contradict myself, but I really prefer ostreams for
    such things. If I need to debug-print an object, I just say

    void f(const Foo& foo)
    {
    ...
    std::cerr << foo << '\n';
    }

    and it comes out formatted exactly like I want it, anywhere, at any
    time. It's just the stream manipulators that I don't like.

    /Jorgen

    --
    // Jorgen Grahn <grahn@ Oo o. . .
    \X/ snipabacken.se> O o .
     
    Jorgen Grahn, Jun 12, 2010
    #15
    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. Spamtrap

    UTF8 to Unicode conversion

    Spamtrap, Jul 30, 2004, in forum: Perl
    Replies:
    6
    Views:
    9,936
    Joe Smith
    Jul 31, 2004
  2. www
    Replies:
    51
    Views:
    1,501
  3. Howard Hinnant
    Replies:
    0
    Views:
    724
    Howard Hinnant
    May 31, 2010
  4. Oliver Regenfelder

    Re: Conversion from UTF32 to UTF8 for review

    Oliver Regenfelder, Jun 1, 2010, in forum: C++
    Replies:
    7
    Views:
    588
    Paul Bibbings
    Jun 3, 2010
  5. gry
    Replies:
    2
    Views:
    767
    Alf P. Steinbach
    Mar 13, 2012
Loading...

Share This Page