My original question was, why the standard string class
doesn't have a constructor that takes a character.

kanze@gabi-soft.fr (J. Kanze) writes:

> AllanW@my-dejanews.com writes:
>
>>  In article <357DC097.3F9C8BF@acm.org>,
>>    Pete Becker <petebecker@acm.org> wrote:
{SNIP}
>>>  Well, I think I got my history a bit telescoped. There was a
>>> time when having this contructor led to significant conflicts, so
>>> it got removed.  Then the interface got worked over once again,
>>> and the problem may not be there any more. That is, I think it's a
>>> historical artifact.
{SNIP}
>
> Declaring the string( char ) constructor explicit would solve this. And
> still allow
>     string s( 'a' ) ;

 Is there a reason this wasn't done? Or was it just overlooked?

>>  Do you really find writing
>>      string s2('Y');
>>  to be that much easier than writing
>>      string s3(1,'Y');
>>  instead?  Or that much more easily understood and maintained?
>
> Not significantly, but I don't see any reason not to support the first
> variant, either.

 I _do_ find it easier to read the first; if I (or someone
else) haven't looked at the standard library lately, we don't have to
dig through the website to find out what that '1' is doing there.

 The idea of C++ (well, one of them anyway ;-) is to make code
easier to read. It seems to me that the meaning of "string s1 ('Y')"
is much more intuitively obvious than the meaning of
"string s1(1,'Y')".

 Of course, I could use comments to explain it. But it's my
understanding that one signature of good C++ code is that it's self
explanatory.

 So, in a nutshell: I would find it useful to have a
string(char) constructor, I believe other people would too, and AFAIKT
there's no reason not to have one _provided_ it's declared 'explicit'.

 Yes?

 If this is the case, is there a way to add this to the current
working paper? Or, to put it another way, if I hack my copy of the
standard library, am I doing A Bad Thing? ;-)

 Thanks!

--------------------------------------------------------------------------
Dave Steffen                      Wave after wave will flow with the tide
Dept. of Physics                    And bury the world as it does
Colorado State University         Tide after tide will flow and recede
steffend@lamar.colostate.edu        Leaving life to go on as it was...
       - Peart / RUSH
"The reason that our people suffer in this way....
is that our ancestors failed to rule wisely".   -General Choi, Hong Hi




[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dave Steffen <steffend@glitch.physics.colostate.edu> wrote in article
<x6ogw6mkr2.fsf@glitch.physics.colostate.edu>...
>  Do mine eyes deceive me? It looks to me that while we have
>
> basic_string<...>& operator= (charT c);
>
>  we don't have the corresponding constructor,
>
> basic_string(charT c, ...)
> .....
>  Is there a good reason for this, i.e. was this intentional?

Well, it was intentional. Template class basic_string was reworked on
several occasions. As I recall, for a time at least the presence of the
single-argument charT constructor was causing some ambiguities.
In any event, the last major revision got rid of most such signatures --
except of course for operator=.

P.J. Plauger
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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <x6ogw6mkr2.fsf@glitch.physics.colostate.edu>,
  Dave Steffen <steffend@glitch.physics.colostate.edu> wrote:
[snip]
>  we don't have the corresponding constructor,
> basic_string(charT c, ...)
>  which strikes me as a bit odd. If it's OK to assign a
>  character to a string, surely it's OK to build a string from a
>  character.

You must always be careful about constructors that take a single argument.
These are identical (in every important way) to a global conversion operator,
in this case one that converts char (or other integer types) into a string.

If a programmer mistakenly writes this:
    string s1(80); // 80-character string
With a char constructor, s1 is a 1-character string with value "P" (on ASCII
systems -- your mileage may differ).  Without it, this is a compile-time
error.

    void func(char*);
    void func(string);
    //...
    func('Abc'); // Oops, meant func("Abc");
With a char constructor, the last line calls func(string).  Without it, the
last line is a compile error.

    void func2(char*=NULL);
    void func2(string=string(""));
    //...
    func2(NULL);
If NULL is defined as 0, then the last line correctly calls func2(char*).
But with a char constructor, this would be ambiguous.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <357BCF21.4F6CCBFA@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
>
> Dave Steffen wrote:
> >
> >
> >         we don't have the corresponding constructor,
> >
> > basic_string(charT c, ...)
> >
> >
> >         Is there a good reason for this, i.e. was this intentional?
>
> Yes, it was intentional. You get horrible ambiguity problems if that
> constructor exists. They make the class very hard to use.

Would you care to elaborate?  My own string class always had a constructo=
r
GB_String::GB_String( char ch , int length =3D 1 ) ; and I don't remember
ever having any problems with it.  (Would declaring such a constructor
explicit have helped?)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

jkanze@otelo.ibmmail.com wrote:
>
>
> Would you care to elaborate?  My own string class always had a constructor
> GB_String::GB_String( char ch , int length = 1 ) ; and I don't remember
> ever having any problems with it.  (Would declaring such a constructor
> explicit have helped?)

 Well, I think I got my history a bit telescoped. There was a time when
having this contructor led to significant conflicts, so it got removed.
Then the interface got worked over once again, and the problem may not
be there any more. That is, I think it's a historical artifact.
 Of course, there's still a rather remote possiblity of conflict if you
create a basic_string<int>, because constructing one of these with two
int arguments (charT and int) can invoke your constructor or the
templatized contructor template<class InIt>
basic_string::basic_string(InIt, InIt). But I don't suppose anyone here
finds that a convincing argument for not having basic_string(charT,int).
 -- Pete


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <x6ogw4mdmk.fsf@glitch.physics.colostate.edu>,
> > Dave Steffen wrote:
> > >         we don't have the corresponding constructor,
> > > basic_string(charT c, ...)
> > >
> > >         Is there a good reason for this, i.e. was this intentional?

> Pete Becker <petebecker@acm.org> writes:
> > Yes, it was intentional. You get horrible ambiguity problems if that
> > constructor exists. They make the class very hard to use.

  Dave Steffen <steffend@glitch.physics.colostate.edu> wrote:
>  I figured as much. Out of curiosity, why can't we use the
> 'explicit' keyword to avoid the problem?
>
>  (It just so happens that turning characters into strings, and
> vise versa, is very common in the chunk of code I'm working on right
> now. ;-)

Is it all that hard to add "1," before your single-char initializer?
Instead of
    string s1('a');
you could write
    string s1(1,'a');

If you really strongly prefer the first method for the "chunk of code"
you're working on right now, try adding this after all the #includes:
    template<class T>inline basic_string<T> String(T c)
        { return basic_string<T>(1,c); }
Then instead of string(1,'c') you could write String('c'), as in:
    string x;
    // ...
    x = String('c');
It's not quote as pretty for constructors, though;
    string y(1,'d');
changes to
    string y(String('d'));
which may be more cumbersome instead of less.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

> In article <x6ogw4mdmk.fsf@glitch.physics.colostate.edu>,
> > > Dave Steffen wrote:
> > > >         we don't have the corresponding constructor,
> > > > basic_string(charT c, ...)
>
> > Pete Becker <petebecker@acm.org> writes:
> > > Yes, it was intentional. You get horrible ambiguity problems if that
> > > constructor exists. They make the class very hard to use.
>
>   Dave Steffen <steffend@glitch.physics.colostate.edu> wrote:
> >  I figured as much. Out of curiosity, why can't we use the
> > 'explicit' keyword to avoid the problem?
>
> Is it all that hard to add "1," before your single-char initializer?
> Instead of
>     string s1('a');
> you could write
>     string s1(1,'a');

 I ended up working around the problem, so at the moment I'm
fine. I'm really asking because I've already stumbled across some
places where I think the standard library is wrong, and I want to know
if this is another one. (As opposed to the many places I thought the
standard library was wrong, until someone explained it to me.)

 So, yes, there are plenty of ways to work around this
problem. But my question still stands: doesn't the 'explicit' keyword
fix all of this, cleanly? Or am I missing something (once again)? ;-)

--------------------------------------------------------------------------
Dave Steffen                      Wave after wave will flow with the tide
Dept. of Physics                    And bury the world as it does
Colorado State University         Tide after tide will flow and recede
steffend@lamar.colostate.edu        Leaving life to go on as it was...
       - Peart / RUSH
"The reason that our people suffer in this way....
is that our ancestors failed to rule wisely".   -General Choi, Hong Hi



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <357DC097.3F9C8BF@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
>
> jkanze@otelo.ibmmail.com wrote:
> > My own string class always had a constructor
> > GB_String::GB_String( char ch , int length = 1 ) ; and I don't remember
> > ever having any problems with it.  (Would declaring such a constructor
> > explicit have helped?)
>
>  Well, I think I got my history a bit telescoped. There was a time when
> having this contructor led to significant conflicts, so it got removed.
> Then the interface got worked over once again, and the problem may not
> be there any more. That is, I think it's a historical artifact.
>  Of course, there's still a rather remote possiblity of conflict if you
> create a basic_string<int>, because constructing one of these with two
> int arguments (charT and int) can invoke your constructor or the
> templatized contructor template<class InIt>
> basic_string::basic_string(InIt, InIt). But I don't suppose anyone here
> finds that a convincing argument for not having basic_string(charT,int).

I just hate the asthetics of allowing:
    string s1 = 80;
to be legal.  It would be, if basic_string::basic_string(charT) existed
and was not explicit, but it would be surprising -- allocating a string of
length 1 whose character is charT(80).

Do you really find writing
    string s2('Y');
to be that much easier than writing
    string s3(1,'Y');
instead?  Or that much more easily understood and maintained?

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

> In article <357DC097.3F9C8BF@acm.org>,
>   Pete Becker <petebecker@acm.org> wrote:
> > finds that a convincing argument for not having basic_string(charT,int).
>
> I just hate the asthetics of allowing:
>     string s1 = 80;
> to be legal.  It would be, if basic_string::basic_string(charT) existed
> and was not explicit, but it would be surprising -- allocating a string of
         ^^^^^^^^^^^^^^
 I agree... so make it explicit. I believe (and may be wrong)
that this lets me turn single characters into strings, without getting
into horrible ambiguity or suprising type conversion problems. Yes?

> Do you really find writing
>     string s2('Y');
> to be that much easier than writing
>     string s3(1,'Y');
> instead?  Or that much more easily understood and maintained?

 Yes, I do. Dammit, there ought to be a syntactically clean way
to do this. (What? C++ is't perfect? Kill the heretic! ;-)

 Actually I've already worked around the problem. I'm asking
now because I don't understand, and would like to.

--------------------------------------------------------------------------
Dave Steffen                      Wave after wave will flow with the tide
Dept. of Physics                    And bury the world as it does
Colorado State University         Tide after tide will flow and recede
steffend@lamar.colostate.edu        Leaving life to go on as it was...
       - Peart / RUSH
"The reason that our people suffer in this way....
is that our ancestors failed to rule wisely".   -General Choi, Hong Hi



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com writes:

|>  In article <357DC097.3F9C8BF@acm.org>,
|>    Pete Becker <petebecker@acm.org> wrote:
|>  >
|>  > jkanze@otelo.ibmmail.com wrote:
|>  > > My own string class always had a constructor
|>  > > GB_String::GB_String( char ch , int length = 1 ) ; and I don't remember
|>  > > ever having any problems with it.  (Would declaring such a constructor
|>  > > explicit have helped?)
|>  >
|>  >  Well, I think I got my history a bit telescoped. There was a time when
|>  > having this contructor led to significant conflicts, so it got removed.
|>  > Then the interface got worked over once again, and the problem may not
|>  > be there any more. That is, I think it's a historical artifact.
|>  >  Of course, there's still a rather remote possiblity of conflict if you
|>  > create a basic_string<int>, because constructing one of these with two
|>  > int arguments (charT and int) can invoke your constructor or the
|>  > templatized contructor template<class InIt>
|>  > basic_string::basic_string(InIt, InIt). But I don't suppose anyone here
|>  > finds that a convincing argument for not having basic_string(charT,int).
|>
|>  I just hate the asthetics of allowing:
|>      string s1 = 80;
|>  to be legal.  It would be, if basic_string::basic_string(charT) existed
|>  and was not explicit, but it would be surprising -- allocating a string of
|>  length 1 whose character is charT(80).

Declaring the string( char ) constructor explicit would solve this. And
still allow
    string s( 'a' ) ;

|>  Do you really find writing
|>      string s2('Y');
|>  to be that much easier than writing
|>      string s3(1,'Y');
|>  instead?  Or that much more easily understood and maintained?

Not significantly, but I don't see any reason not to support the first
variant, either.

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi Folks,

 Do mine eyes deceive me? It looks to me that while we have

basic_string<...>& operator= (charT c);

 we don't have the corresponding constructor,

basic_string(charT c, ...)

 which strikes me as a bit odd. If it's OK to assign a
 character to a string, surely it's OK to build a string from a
 character.

 The closest thing is

basic_string(size_type n, charT c, ...)

 which can be used in a pinch. But that seems to me to be a
 much less commonly used thing than turning a character into a
 string for some reason.

 Is there a good reason for this, i.e. was this intentional?

THANKS!

--------------------------------------------------------------------------
Dave Steffen                      Wave after wave will flow with the tide
Dept. of Physics                    And bury the world as it does
Colorado State University         Tide after tide will flow and recede
steffend@lamar.colostate.edu        Leaving life to go on as it was...
       - Peart / RUSH
"The reason that our people suffer in this way....
is that our ancestors failed to rule wisely".   -General Choi, Hong Hi



[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Dave Steffen wrote:
>
>
>         we don't have the corresponding constructor,
>
> basic_string(charT c, ...)
>
>
>         Is there a good reason for this, i.e. was this intentional?

Yes, it was intentional. You get horrible ambiguity problems if that
constructor exists. They make the class very hard to use.
 -- Pete


[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker <petebecker@acm.org> writes:

> Dave Steffen wrote:
> >
> >
> >         we don't have the corresponding constructor,
> >
> > basic_string(charT c, ...)
> >
> >
> >         Is there a good reason for this, i.e. was this intentional?
>
> Yes, it was intentional. You get horrible ambiguity problems if that
> constructor exists. They make the class very hard to use.
>  -- Pete

 I figured as much. Out of curiosity, why can't we use the
'explicit' keyword to avoid the problem?

 (It just so happens that turning characters into strings, and
vise versa, is very common in the chunk of code I'm working on right
now. ;-)

--------------------------------------------------------------------------
Dave Steffen                      Wave after wave will flow with the tide
Dept. of Physics                    And bury the world as it does
Colorado State University         Tide after tide will flow and recede
steffend@lamar.colostate.edu        Leaving life to go on as it was...
       - Peart / RUSH
"The reason that our people suffer in this way....
is that our ancestors failed to rule wisely".   -General Choi, Hong Hi
---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]