nagle@animats.com (John Nagle) wrote in message news:<kr8Yb.13352$eF.1271@newssvr29.news.prodigy.com>...
> Helium wrote:
> > Anyway, what about boost's lexical cast:
> >
> > int n;
> > string s = "The value of n is ";
> > s += lexical_cast<string>(n);
>
>    That is so l33t.  I would never have thought of
> doing it that way.

Sarcasm aside, it fits into the language:
dynamic_cast     for RTTI-based casts
reinterpret_cast for bit-fiddling
const_cast       for const-fiddling
lexical_cast     for string stuff

So unless there's a real problem with this syntax -
and performance isn't - I don't want to add anything
to std::string.

On the other hand, many of the other posts show that
by demanding 100%, you get 0% instead of 99%.
Regards,
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

  "string" really should have some basic formatting
primitives.  Equivalents of the C "atoi" and "itoa"
primitives should be provided.

   There's something to be said for providing integer formatting
as a conversion:

 string s1, s2;
 int n;
 s = "The value of n is " + n;

  That's so convenient.

  Interpreted format processing isn't necessary here, because
concatenation is available.

  The assumption that formatting belongs with I/O is obsolete.
Today, most formatting is probably targetted at the GUI.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>
>   "string" really should have some basic formatting
> primitives.  Equivalents of the C "atoi" and "itoa"
> primitives should be provided.
>
>    There's something to be said for providing integer formatting
> as a conversion:
>
>         string s1, s2;
>         int n;
>         s = "The value of n is " + n;
>
>   That's so convenient.

What locale should it use?

>
>   Interpreted format processing isn't necessary here, because
> concatenation is available.
>
>   The assumption that formatting belongs with I/O is obsolete.
> Today, most formatting is probably targetted at the GUI.
>

Displaying text in a GUI is I/O.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:j3GXb.12885$mt7.12136@newssvr29.news.prodigy.com...

>    There's something to be said for providing integer formatting
> as a conversion:
>
> string s1, s2;
> int n;
> s = "The value of n is " + n;
>
>   That's so convenient.

Unfortunately, the expression

    "The value of n is " + n

is already defined in C, so giving it a different meaning in C++ would
create a new incompatibility.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> "string" really should have some basic formatting
> primitives.  Equivalents of the C "atoi" and "itoa"
> primitives should be provided.
>
>    There's something to be said for providing integer formatting
> as a conversion:
>
>  string s1, s2;
>  int n;
>  s = "The value of n is " + n;
>
>   That's so convenient.

What do you mean by "string"? You try to add an int to a char *.

Anyway, what about boost's lexical cast:

int n;
string s = "The value of n is ";
s += lexical_cast<string>(n);


This is convenient enough for me.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Andrew Koenig wrote:

>
> Unfortunately, the expression
>
>     "The value of n is " + n
>
> is already defined in C, so giving it a different meaning in C++ would
> create a new incompatibility.

   True.

   Is there any reason we can't have the explicit conversion?

 s = "The value of n is " + string(n);

It's trivial to write, and far more useful if standard.
The form isn't that significant, but we do need something
comparable to "atoi" and "itoa" for type "string".

    John Nagle

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Helium wrote:
> Anyway, what about boost's lexical cast:
>
> int n;
> string s = "The value of n is ";
> s += lexical_cast<string>(n);

   That is so l33t.  I would never have thought of
doing it that way.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>
>    Is there any reason we can't have the explicit conversion?
>
>         s = "The value of n is " + string(n);
>
> It's trivial to write, and far more useful if standard.
> The form isn't that significant, but we do need something
> comparable to "atoi" and "itoa" for type "string".

What data types would std::string have to support?
Integers? Floating-points? What about std::complex<>?
What about some other user-defined data types?

We already have streams for generic I/O.

    void func(std::ostream& os, int n)
    {
        os << "The value of n is " << n;
    }

If you really want a std::string, you can use std::ostringstream,
of course.

Any problem with this approach?

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Seungbeom Kim wrote:
> If you really want a std::string, you can use std::ostringstream,
> of course.
>
> Any problem with this approach?

  That works.  Thanks.  Since there's an obscure,
complicated way to do it, there's no chance of putting
in a simple way.  So I withdraw my proposal.

    John Nagle
    Animats


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Seungbeom Kim schrieb:

> John Nagle wrote:
> >
> >    Is there any reason we can't have the explicit conversion?
> >
> >         s = "The value of n is " + string(n);
> >
> > It's trivial to write, and far more useful if standard.
> > The form isn't that significant, but we do need something
> > comparable to "atoi" and "itoa" for type "string".
>
> What data types would std::string have to support?

The built-ins and complex from the library.

>
> Integers? Floating-points? What about std::complex<>?
> What about some other user-defined data types?

As always for user-defined data types, the programmers can provide them in
there class via a to_string function.

>
> We already have streams for generic I/O.
>
>     void func(std::ostream& os, int n)
>     {
>         os << "The value of n is " << n;
>     }
>
> If you really want a std::string, you can use std::ostringstream,
> of course.
>
> Any problem with this approach?

ostringstream operations can be very time expensive, so such
numeric-to-string conversions can kill you off in speed critical code. Also,
having explicit conversion functions make the code easier to read.



Personally, I think the numeric-to-string / string-to-numeric conversions are
too important to leave out for the next Standard. I have this in mind:

struct formatting
{
// set significant digits, decimal/hexadecimal/octal output, scientific or
not....
};

std::string numeric_to_string(int i, formatting f = formatting());
std::string numeric_to_string(long l, formatting f = formatting());
etc.


I haven't made this a template where the user could specify charT,
char_traitsT and allocatorT, since this would complicate things a lot,
especially when there are no default template paraemters for functions. In
case default template parameters were adopted into the next STandard, this
would read like this of course:

template <typename charT = char, char_traitsT = char_traits<charT>,
allocatorT = allocator<charT>
std::basic_string<charT, char_traitsT, allocatorT> numeric_to_string(int i,
formatting f = formatting());



and similiar for conversions from string to numeric, although IMO we don't
need formatting here (but, of course, it could be easily provided):


template <typename numeric>
numeric string_to_numeric(std::string String);

template <>
int string_to_numeric<int>(std::string String);

template <>
long string_to_numeric<long>(std::string String);
etc.


regards,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Mon, 16 Feb 2004 21:09:40 +0000 (UTC), John Nagle wrote:
>    That is so l33t.  I would never have thought of
> doing it that way.

If you are asking for adding features to C++ standard library, you
should definitely try boost first. Plenty of things are available in
boost now, and some of them will be in C++ standard at some point. Boost
library is available at www.boost.org.


B.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> Andrew Koenig wrote:
> > Unfortunately, the expression
> >
> >     "The value of n is " + n
> >
> > is already defined in C, so giving it a different meaning in C++ would
> > create a new incompatibility.
>
>    True.
>
>    Is there any reason we can't have the explicit conversion?
>
>  s = "The value of n is " + string(n);

I think this syntax is confusing.  Reading this, my natural code, my
first reaction was that it would call the

  basic_string::basic_string( size_t, CharT, Allocator )

constructor.  Only after checking in the Standard did I discover that
there is no default argument for the second parameter, despite the
equivalent constructor for most other STL containers having it.  I can
understand why std::basic_string should differ from std::vector in
this respect, but I don't think introducing a further, gratuitous
difference between the interface of std::string and the standard
sequences would help.

--
Richard Smith

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thomas Mang schrieb:

>
> std::string numeric_to_string(int i, formatting f = formatting());
> std::string numeric_to_string(long l, formatting f = formatting());
> etc.
>
> I haven't made this a template where the user could specify charT,
> char_traitsT and allocatorT, since this would complicate things a lot,
> especially when there are no default template paraemters for functions. In
> case default template parameters were adopted into the next STandard, this
> would read like this of course:

The last sentence should read:
In cae default template parameters *for functions* were adopted into the next
Standard

>
>
> template <typename numeric>
> numeric string_to_numeric(std::string String);
>
> template <>
> int string_to_numeric<int>(std::string String);
>
> template <>
> long string_to_numeric<long>(std::string String);

Ooops, three times expensive pass-by-value.

It should read
std::string const& String
in all three cases.

Seems I was a bit tired when I posted :-)


thank you,

Thomas

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thomas Mang wrote:
>
> Seungbeom Kim schrieb:
>
> > John Nagle wrote:
> > >
> > >    Is there any reason we can't have the explicit conversion?
> > >
> > >         s = "The value of n is " + string(n);
> > >
> > > It's trivial to write, and far more useful if standard.
> > > The form isn't that significant, but we do need something
> > > comparable to "atoi" and "itoa" for type "string".
> >
> > What data types would std::string have to support?
> >
> > Integers? Floating-points? What about std::complex<>?
> > What about some other user-defined data types?
>
> The built-ins and complex from the library.
>
> As always for user-defined data types, the programmers can provide them in
> there class via a to_string function.

Why only those and not others? What about a std::vector
converted to a string that enumerates all of its elements?
Making user-defined types as well supported as built-in types
has been one of the primary design goals of C++, against which
forcing user-defined types to use a less-native-looking syntax
would be.

Furthermore, there can be many ways to convert something (even
a simple bool or double) to a string: consider locales. Even
more possibilities for formatting: setting the output width
or precision or alignment, so on. Strings don't know anything about
these but streams do. So why would we have to have the same set
of functionalities duplicated in two places?

>
> ostringstream operations can be very time expensive, so such
> numeric-to-string conversions can kill you off in speed critical code.

If you would try implementing both on your own, what factor
would make ostringstream operations significantly slower than
string operations when converting something to strings?

> Also,
> having explicit conversion functions make the code easier to read.

I don't think the readability of the stream version is
significantly worse than the string version. Do you?

    s = "The value of n is " + string(n);
vs
    os << "The value of n is " << n;

Almost every C++ user should be familiar with the latter syntax.

>
> Personally, I think the numeric-to-string / string-to-numeric conversions are
> too important to leave out for the next Standard. I have this in mind:
> [code snipped]

Have you checked boost::lexical_cast?

Furthermore, restricting "something" to be converted to strings
only to "numeric" things doesn't seem to be a good idea.
We already have a fully generic mechanism(operator<<).

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

  This is becoming overdesigned.

  There's a frequent need for the simple functionality of
"atoi" and "itoa".  Beyond that, the number of things people
want to do fragments.  At that point, it's appropriate to
bring in the complexity of the stream formatting system.
I'm merely proposing that the simple case be simple.

       John Nagle

Thomas Mang wrote:
>
> Thomas Mang schrieb:
>
>
>>std::string numeric_to_string(int i, formatting f = formatting());
>>std::string numeric_to_string(long l, formatting f = formatting());
>>etc.
>>
>>I haven't made this a template where the user could specify charT,
>>char_traitsT and allocatorT, since this would complicate things a lot,
>>especially when there are no default template paraemters for functions. In
>>case default template parameters were adopted into the next STandard, this
>>would read like this of course:
>
>
> The last sentence should read:
> In cae default template parameters *for functions* were adopted into the next
> Standard
>
>
>>
>>template <typename numeric>
>>numeric string_to_numeric(std::string String);
>>
>>template <>
>>int string_to_numeric<int>(std::string String);
>>
>>template <>
>>long string_to_numeric<long>(std::string String);
>
>
> Ooops, three times expensive pass-by-value.
>
> It should read
> std::string const& String
> in all three cases.
>
> Seems I was a bit tired when I posted :-)
>
>
> thank you,
>
> Thomas
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]
>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

>   There's a frequent need for the simple functionality of
> "atoi" and "itoa".  Beyond that, the number of things people
> want to do fragments.  At that point, it's appropriate to
> bring in the complexity of the stream formatting system.
> I'm merely proposing that the simple case be simple.

I see the need but it how to meet it that is the problem.

If you are going to permit int's in your original post, then almost
certainly, all the other integral basic types should be then permitted.

At that point someone will request that floating-point types should be
supported and then after that you are onto locales with what character is
used for any decimal point.
Different countries will be demanding that they are not left out.

Stephen Howe


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nagle@animats.com (John Nagle) wrote in message news:<qgRYb.27412$%X6.17972@newssvr25.news.prodigy.com>...
>   There's a frequent need for the simple functionality of
> "atoi" and "itoa".  Beyond that, the number of things people
> want to do fragments.  At that point, it's appropriate to
> bring in the complexity of the stream formatting system.
> I'm merely proposing that the simple case be simple.

I don't see that "atoi" is that simple.  What syntax precisely
does it accept and what is your proposed error behavior?
Is there consensus on that?  Does C set the right precedent?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

albalmer@att.net ("Stephen Howe") wrote in message news:<40361a63$0$10338$ed9e5944@reading.news.pipex.net>...
> >   There's a frequent need for the simple functionality of
> > "atoi" and "itoa".  Beyond that, the number of things people
> > want to do fragments.  At that point, it's appropriate to
> > bring in the complexity of the stream formatting system.
> > I'm merely proposing that the simple case be simple.
>
> I see the need but it how to meet it that is the problem.
>
> If you are going to permit int's in your original post, then almost
> certainly, all the other integral basic types should be then permitted.
>
> At that point someone will request that floating-point types should be
> supported and then after that you are onto locales with what character is
> used for any decimal point.
> Different countries will be demanding that they are not left out.
>
How are they left out? The "C" locale _happens_ to correspond to what
many English-speaking countries use, just like the "C" language
contains keywords that are pseudo-English.  As a convention, when
storing information in data files, you store them in the "C" locale,
so they can be read by programs no matter what your preferred user
display locale is.  So conversions based on the "C" locale *are* a
special case, and are often the only conversions many programs do, if
they have no UI.  atoi()/"itoa()" is one example, others include case
conversion/case-insensitive compares etc.  I see it as a reasonable
argument that a sizeable percentage of string processing that involves
numeric representations and case conversions is specific to the "C"
locale because it is not intended for the purposes of UI, rather for
data stream processing.  Certainly in my experience, any significantly
complex piece of software ends up needing special routines to make
doing this operations easier than the standard C++ library does.  So
why shouldn't the library provide them?

Dylan

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Good morning, John Nagle,

John Nagle schrieb:

>  This is becoming overdesigned.
>  There's a frequent need for the simple functionality of "atoi" and
> "itoa".  Beyond that, the number of things people
> want to do fragments.  At that point, it's appropriate to
> bring in the complexity of the stream formatting system.
> I'm merely proposing that the simple case be simple.


What's about the locale-dependent thousands separator?

Greetings from Bremen,

Daniel


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]