Topic: Initialization vs. Assignment oddities


Author: Hyman Rosen <hyrosen@mail.com>
Date: Fri, 21 Jun 2002 19:31:07 CST
Raw View
John Potter wrote:
> Everything is a result of general rules.  What would you change?

Dunno. Looks fishy though, doesn't it?

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





Author: "Lawrence Rust" <lvr@nospam.softsystem.co.uk>
Date: 22 Jun 2002 00:35:26 GMT
Raw View
"John Potter" <jpotter@falcon.lhup.edu> wrote...
> > We just came across this in our code (where it had
> > been hidden by MSVC++ compiling it successfully).
> >
> > #include <string>
> > struct a { operator const char *() { return ""; } };
> > int main()
> > {
> >      a an_a;
> >      std::string s = an_a; // #1 Illegal
>
>    s.string(string(an_a.operator const char*()));
>
> Two user defined implicit conversions.

Agreed.  By 13.3.1.4 an_a must by convered to std::string.


> >      std::string t(an_a);  // #2 Fine
>
>    t.string(an_a.operator const char*());
>
> One user defined implicit conversion
>
> >      t = an_a;             // #3 Also fine
>
>    t.operator=(an_a.operator const char*());
>
> One user defined implicit conversion.  If string did not have an
> operator= taking a char const*, it would require two conversions
> and be illegal.
>
> Everything is a result of general rules.  What would you change?

To make 't = an_a' orthogonal with 'std::string s = an_a' it would make
sense to add to 13.3.1.4 something that permits the converting assignment
operators of std::string to be added to the list of candidate functions
which are then matched with user supplied conversions of a_an.

Lawrence Rust

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





Author: kanze@gabi-soft.de (James Kanze)
Date: 22 Jun 2002 00:35:33 GMT
Raw View
jpotter@falcon.lhup.edu (John Potter) wrote in message
news:<3d125c8b.38717390@news.earthlink.net>...
> On Thu, 20 Jun 2002 17:31:31 GMT, Hyman Rosen <hyrosen@mail.com>
> wrote:

> > We just came across this in our code (where it had been hidden by
> > MSVC++ compiling it successfully).

> > #include <string>
> > struct a { operator const char *() { return ""; } };
> > int main()
> > {
> >      a an_a;
> >      std::string s = an_a; // #1 Illegal

>    s.string(string(an_a.operator const char*()));

> Two user defined implicit conversions.

> >      std::string t(an_a);  // #2 Fine

>    t.string(an_a.operator const char*());

> One user defined implicit conversion

> >      t = an_a;             // #3 Also fine

>    t.operator=(an_a.operator const char*());

> One user defined implicit conversion.  If string did not have an
> operator= taking a char const*, it would require two conversions and
> be illegal.

> Everything is a result of general rules.

General rules AND a lot of unnecessary functions in std::string.

> What would you change?

Get rid of all of the extra assignment operators in std::string.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)69 63198627

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





Author: James Kanze <kanze@alex.gabi-soft.de>
Date: Mon, 24 Jun 2002 01:06:36 GMT
Raw View
"Lawrence Rust" <lvr@nospam.softsystem.co.uk> writes:

|>  "John Potter" <jpotter@falcon.lhup.edu> wrote...
|>  > > We just came across this in our code (where it had been hidden
|>  > > by MSVC++ compiling it successfully).

|>  > > #include <string>
|>  > > struct a { operator const char *() { return ""; } };
|>  > > int main()
|>  > > {
|>  > >      a an_a;
|>  > >      std::string s =3D an_a; // #1 Illegal
|>  >
|>  >    s.string(string(an_a.operator const char*()));

|>  > Two user defined implicit conversions.

|>  Agreed.  By 13.3.1.4 an_a must by convered to std::string.

|>  > >      t =3D an_a;             // #3 Also fine

|>  >    t.operator=3D(an_a.operator const char*());

|>  > One user defined implicit conversion.  If string did not have an
|>  > operator=3D taking a char const*, it would require two conversions
|>  > and be illegal.

|>  > Everything is a result of general rules.  What would you change?

|>  To make 't =3D an_a' orthogonal with 'std::string s =3D an_a' it woul=
d
|>  make sense to add to 13.3.1.4 something that permits the
|>  converting assignment operators of std::string to be added to the
|>  list of candidate functions which are then matched with user
|>  supplied conversions of a_an.

Wouldn't a more reasonable solution be to remove the additional
assignment operators in std::string?

--=20
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
                                              Tel. +33 1 41 89 80 93

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





Author: jpotter@falcon.lhup.edu (John Potter)
Date: Mon, 24 Jun 2002 02:24:46 GMT
Raw View
On 22 Jun 2002 00:35:26 GMT, "Lawrence Rust"
<lvr@nospam.softsystem.co.uk> wrote:

> "John Potter" <jpotter@falcon.lhup.edu> wrote...
> > >      std::string s = an_a; // #1 Illegal
> >
> >    s.string(string(an_a.operator const char*()));
> >
> > Two user defined implicit conversions.

[...]

> > Everything is a result of general rules.  What would you change?

> To make 't = an_a' orthogonal with 'std::string s = an_a' it would make
> sense to add to 13.3.1.4 something that permits the converting assignment
> operators of std::string to be added to the list of candidate functions
> which are then matched with user supplied conversions of a_an.

No.  We would not want to confuse the use of the symbol '=' in an
initialization with assignment to an already constructed object.
Assignment operators do not apply to initialization.

John

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





Author: Hyman Rosen <hyrosen@mail.com>
Date: Sun, 23 Jun 2002 22:11:46 CST
Raw View
John Potter wrote:
> No.  We would not want to confuse the use of the symbol '=' in an
> initialization with assignment to an already constructed object.

Too late. And given the fact that it worked in MSVC++ and failed
in Sun CC, it's not only I who am confused, it's compilers as well.

> Assignment operators do not apply to initialization.

Then it's unfortunate that the assignment operator symbol is used.

Anyway, we need that Rationale again. Why does C++ make the distinction
between copy-initialization and direct-initialization anyway?

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





Author: jpotter@falcon.lhup.edu (John Potter)
Date: Mon, 24 Jun 2002 15:48:01 GMT
Raw View
On Sun, 23 Jun 2002 22:11:46 CST, Hyman Rosen <hyrosen@mail.com>
wrote:

> John Potter wrote:

> > No.  We would not want to confuse the use of the symbol '=' in an
> > initialization with assignment to an already constructed object.
>
> Too late. And given the fact that it worked in MSVC++ and failed
> in Sun CC, it's not only I who am confused, it's compilers as well.

Premature optimization.
   std::string s = an_a; // #1 Illegal
Translate to
   s.string(make_string_from(an_a));
Optimize out the copy
   s.make_string_from(an_a);
With one user conversion
   s.string(an_a.operator char const*());

> > Assignment operators do not apply to initialization.

> Then it's unfortunate that the assignment operator symbol is used.

Too bad that the designers of C did not have the foresight to use ().

> Anyway, we need that Rationale again. Why does C++ make the distinction
> between copy-initialization and direct-initialization anyway?

How else could we get something as confusing as 8.5/14? :)

I hope we will see a better answer.

John

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





Author: Hyman Rosen <hyrosen@mail.com>
Date: Thu, 20 Jun 2002 17:31:31 GMT
Raw View
We just came across this in our code (where it had
been hidden by MSVC++ compiling it successfully).

#include <string>
struct a { operator const char *() { return ""; } };
int main()
{
     a an_a;
     std::string s = an_a; // #1 Illegal
     std::string t(an_a);  // #2 Fine
     t = an_a;             // #3 Also fine
}

Whn placed in such close proximity, it doesn't seem
reasonable for #1 to be illegal while #2 and #3 are
both OK!

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





Author: jpotter@falcon.lhup.edu (John Potter)
Date: Thu, 20 Jun 2002 18:24:13 CST
Raw View
On Thu, 20 Jun 2002 17:31:31 GMT, Hyman Rosen <hyrosen@mail.com>
wrote:

> We just came across this in our code (where it had
> been hidden by MSVC++ compiling it successfully).
>
> #include <string>
> struct a { operator const char *() { return ""; } };
> int main()
> {
>      a an_a;
>      std::string s = an_a; // #1 Illegal

   s.string(string(an_a.operator const char*()));

Two user defined implicit conversions.

>      std::string t(an_a);  // #2 Fine

   t.string(an_a.operator const char*());

One user defined implicit conversion

>      t = an_a;             // #3 Also fine

   t.operator=(an_a.operator const char*());

One user defined implicit conversion.  If string did not have an
operator= taking a char const*, it would require two conversions
and be illegal.

Everything is a result of general rules.  What would you change?

John

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