Topic: Proposal: Remove operator= return type requirements for Assignable
Author: Christopher Eltschka <celtschk@physik.tu-muenchen.de>
Date: 2000/08/16 Raw View
John Potter wrote:
>
> Please note that the subject is about a requirement for elements of
> standard containers.
>
> I have no problem with the requirement as it is; however, let's object
> to the change with valid arguements.
>
> > In article <8m6gab$i5b$1@news.inet.tele.dk>,
> > "Anders J. Munch" <andersjm@post.tele.dk> wrote:
> > > "Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
> > > news:9e86LYBzydh5EwDw@robinton.demon.co.uk...
> > > > In article <8m1i4s$lqv$1@news.inet.tele.dk>, Anders J. Munch
> > > > <andersjm@post.tele.dk> writes
> > > > >This proposal will break no conforming code:
> > > >
> > > > You have absolutely no way to know this. Even if every current
> >
> > > I can't imagine how a program written in currently conforming C++
> > > would be broken. Could you provide an example, please?
>
> On Thu, 3 Aug 2000 02:41:54 CST, Anthony Williams
> <anthony_w@my-deja.com> wrote:
>
> > template<typename T>
> > T func(const T&x)
> > {
> > T a;
> > T b;
> > a=b=x;
> > return a;
> > }
>
> Func is not part of a standard container. Changing the rules for
> containers would not affect its correctness. If it were in the
> standard library, changing the requirements would not break any
> program working prior to the change.
OK, change this to:
// Container may be any standard container
template<typename Container>
void func(Container c)
{
typename Container::value_type a, b;
for (Container::iterator iter = c.begin(); iter != c.end(); ++iter)
{
a = b = *iter;
// ...
}
}
Currently, this is guaranteed to work for every standard container,
since Container::value_type is assignable, and this includes
the return type of operator=.
If the requirement is loosened, this code may break.
Of course you can repair it by explicitly adding the reqirement
to the func specification, but that's definitely a change (now
the function isn't any more guaranteed to work on every
standard container). Of course, you also can repair it with a
code change. But without a change in either code or specification,
this function is broken.
[...]
---
[ 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 ]
Author: jpotter@falcon.lhup.edu (John Potter)
Date: 2000/08/16 Raw View
On Wed, 16 Aug 2000 18:24:17 GMT, Christopher Eltschka
<celtschk@physik.tu-muenchen.de> wrote:
> John Potter wrote:
> >
> > Please note that the subject is about a requirement for elements of
> > standard containers.
> >
> > I have no problem with the requirement as it is; however, let's object
> > to the change with valid arguements.
> >
> > > In article <8m6gab$i5b$1@news.inet.tele.dk>,
> > > "Anders J. Munch" <andersjm@post.tele.dk> wrote:
> > > > "Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
> > > > news:9e86LYBzydh5EwDw@robinton.demon.co.uk...
> > > > > In article <8m1i4s$lqv$1@news.inet.tele.dk>, Anders J. Munch
> > > > > <andersjm@post.tele.dk> writes
> > > > > >This proposal will break no conforming code:
> > > > >
> > > > > You have absolutely no way to know this. Even if every current
> > >
> > > > I can't imagine how a program written in currently conforming C++
> > > > would be broken. Could you provide an example, please?
> >
> > On Thu, 3 Aug 2000 02:41:54 CST, Anthony Williams
> > <anthony_w@my-deja.com> wrote:
> >
> > > template<typename T>
> > > T func(const T&x)
> > > {
> > > T a;
> > > T b;
> > > a=b=x;
> > > return a;
> > > }
> >
> > Func is not part of a standard container. Changing the rules for
> > containers would not affect its correctness. If it were in the
> > standard library, changing the requirements would not break any
> > program working prior to the change.
>
> OK, change this to:
>
> // Container may be any standard container
> template<typename Container>
> void func(Container c)
> {
> typename Container::value_type a, b;
> for (Container::iterator iter = c.begin(); iter != c.end(); ++iter)
> {
> a = b = *iter;
> // ...
> }
> }
>
> Currently, this is guaranteed to work for every standard container,
> since Container::value_type is assignable, and this includes
> the return type of operator=.
> If the requirement is loosened, this code may break.
> Of course you can repair it by explicitly adding the reqirement
> to the func specification, but that's definitely a change (now
> the function isn't any more guaranteed to work on every
> standard container). Of course, you also can repair it with a
> code change. But without a change in either code or specification,
> this function is broken.
This is a valid half example. ;) I assume that you noticed that Mr.
Mucnh changed his tune in the above. His first statement was that
it would break no existing "code". This example shows that to be
false. His second statement was that it would break no existing
"program". No program that used the above function would break,
but new programs which used it could fail.
On one side we have Mr. Munch objecting to the standard imposing a
particular style on his code for use with the standard library. On
the other side we have reusable code writers, presumably including
Mr. Munch, objecting to a change which could break their existing
code and make it unusable in future programs. Removing the
requirement would impose a style standard on library implementers.
I see no pressing reason to leave the requirements as they are or to
reduce them. Inertia should likely win here.
Interesting that the specification of the built-in assignment operator
is currently under discussion also. There is some discussion in clc++m.
Is this up to a core issue yet? Any chance that some of the discussion
on the reflector will be made public as has been the case with at least
some core issues?
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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jpotter@falcon.lhup.edu (John Potter)
Date: 2000/08/03 Raw View
Please note that the subject is about a requirement for elements of
standard containers.
I have no problem with the requirement as it is; however, let's object
to the change with valid arguements.
> In article <8m6gab$i5b$1@news.inet.tele.dk>,
> "Anders J. Munch" <andersjm@post.tele.dk> wrote:
> > "Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
> > news:9e86LYBzydh5EwDw@robinton.demon.co.uk...
> > > In article <8m1i4s$lqv$1@news.inet.tele.dk>, Anders J. Munch
> > > <andersjm@post.tele.dk> writes
> > > >This proposal will break no conforming code:
> > >
> > > You have absolutely no way to know this. Even if every current
>
> > I can't imagine how a program written in currently conforming C++
> > would be broken. Could you provide an example, please?
On Thu, 3 Aug 2000 02:41:54 CST, Anthony Williams
<anthony_w@my-deja.com> wrote:
> template<typename T>
> T func(const T&x)
> {
> T a;
> T b;
> a=b=x;
> return a;
> }
Func is not part of a standard container. Changing the rules for
containers would not affect its correctness. If it were in the
standard library, changing the requirements would not break any
program working prior to the change.
On Thu, 3 Aug 2000 03:41:48 CST, David R Tribble <david@tribble.com>
wrote:
>
> How about:
>
> class Foo a;
> class Foo b;
> class Foo c;
>
> (a = b) = c;
Changing the requirements for containers would not affect this code.
Changing the requirements could well affect current implementations
of standard containers with future programs which would then be valid
but not compilable with current libraries.
Removing a requirement can not invalidate something which works with
the requirement.
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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Anders J. Munch" <andersjm@post.tele.dk>
Date: 2000/08/04 Raw View
"Sebastian Moleski" <sebmol@gmx.net> wrote in message news:8m57ml$l83$1@news.online.de...
> "Anders J. Munch" <andersjm@post.tele.dk>:
> > I am proposing to remove the requirement from Assignable, that given
> > u,v of type T,
> > u = v
> > must have (return) type T&.
> >
> > I see this requirement as creating problems but having no significant
> > benefits.
>
> Could you please elaborate on how this creates problems?
It places an unnecessary requirement on user types used in standard
containers or with standard algorithms. In my first post I mentioned
how one might want to use a different return type out of deliberate
choice. Another reason is that programmers (esp. those that do not
read c.l.c.m or c.s.c or Scott Meyer's books) could easily use the
wrong return type by mistake. They might get away with it for a long
time, until a port or a library upgrade suddenly makes it bomb with an
obscure compiler error or, even worse, a runtime failure. Compare
with "void main" -- everybody here knows it's illegal, but how often
do you see it anyway?
The drawback to my proposal is that standard library implementors will
loose the option to write stuff like:
f(a = b)
in standard library templates where a,b are of template parameter
type. Instead they would have to write:
f((a = b, a))
or
a = b; f(a);
I have a hunch that library implementors tend to go for the latter in
any case, as it makes fewer assumptions. But you never know. Any
std. library implementors listening?
--
Anders Munch, andersjm@post.tele.dk
Still confused but at a higher level.
---
[ 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 ]
Author: David R Tribble <david@tribble.com>
Date: 2000/08/04 Raw View
Anders J. Munch <andersjm@post.tele.dk> writes
>> This proposal will break no conforming code:
"Francis Glassborow" <francis@robinton.demon.co.uk> wrote
>> You have absolutely no way to know this. ...
"Anders J. Munch" wrote:
>> I can't imagine how a program written in currently conforming C++
>> would be broken. Could you provide an example, please?
David R Tribble wrote:
> How about:
>
> class Foo a;
> class Foo b;
> class Foo c;
>
> (a = b) = c;
>
> Horrible style, yes, but legal C++ nonetheless.
I neglected to mention that I would support a proposal to outlaw
return a non-const reference from operator=(), but allow returning
a const reference:
Type & operator =(whatever); // bad
const Type & operator =(whatever); // good
This would outlaw dubious code like what I showed above, while
still allowing perfectly reasonable code like:
a = b = c; // same as: a = (b = c);
I never understood why the C++ standard encouraged returning
non-const refs from assignment operators in the first place.
(I'm in the habit of returning const refs from operator=() in all
of my classes, and I've never had any complaints.)
--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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 ]
Author: "Anders J. Munch" <andersjm@post.tele.dk>
Date: 2000/08/01 Raw View
I am proposing to remove the requirement from Assignable, that given
u,v of type T,
u = v
must have (return) type T&.
I see this requirement as creating problems but having no significant
benefits.
The problems:
Greg Hickman wrote in comp.lang.c++.moderated,
<URL:news:8lt1nc$isj4@news1.lmtas.lmco.com>:
> Strictly speaking, I'm uncertain whether it's legal, but my implementation
> permits it. In other words,
>
> class MyType {
> public:
> ...
> const MyType& operator=(const MyType& rhs);
> };
>
> std::container<MyType> c1, c2;
As was pointed out, this code is non-conforming. I think it is
perfectly reasonable and should be allowed.
My personal preference is for operator= to return void. I see
operator= returning T& as a misguided emulation of C look-and-feel.
You may well disagree with me, many do, but the point is that the IS
should not demand that I or Greg use a certain style.
The impact of this change:
This proposal will break no conforming code: users can still return T&
from operator=, and they can still rely on std::container<T>::operator=
returning std::container<T>&.
Theoretically implemenations of standard containers could need to be
changed. But I wouldn't be surprised if most implementations don't.
--
Anders Munch, andersjm@post.tele.dk
Still confused but at a higher level.
---
[ 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 ]
Author: Francis Glassborow <francis@robinton.demon.co.uk>
Date: 2000/08/01 Raw View
In article <8m1i4s$lqv$1@news.inet.tele.dk>, Anders J. Munch
<andersjm@post.tele.dk> writes
>This proposal will break no conforming code:
You have absolutely no way to know this. Even if every current standard
library implementation was robust against your proposed change, the STL
is extensible (and that is an important feature of its design and
specification) so you have no way to know if your change might break a
fully conforming algorithm added as an extension in a third party
library.
>users can still return T&
>from operator=, and they can still rely on std::container<T>::operator=
>returning std::container<T>&.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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 ]
Author: "Anders J. Munch" <andersjm@post.tele.dk>
Date: 2000/08/02 Raw View
"Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message news:9e86LYBzydh5EwDw@robinton.demon.co.uk...
> In article <8m1i4s$lqv$1@news.inet.tele.dk>, Anders J. Munch
> <andersjm@post.tele.dk> writes
> >This proposal will break no conforming code:
>
> You have absolutely no way to know this. Even if every current standard
> library implementation was robust against your proposed change, the STL
> is extensible (and that is an important feature of its design and
> specification) so you have no way to know if your change might break a
> fully conforming algorithm added as an extension in a third party
> library.
I can't imagine how a program written in currently conforming C++
would be broken. Could you provide an example, please?
I can imagine how new code written with operator= returning T const&
or void could get in trouble with a pre-change third party template
library which uses the return value of the template parameter
operator=. However: Those that know what they're doing can keep
returning T& and no problems will come from that. Those that return T
const& or void because they do not know what they're doing are in
potential trouble today with both the standard library and third party
libraries. With my proposal they would only be in trouble with the
third party stuff.
--
Anders Munch, andersjm@post.tele.dk
Still confused but at a higher level.
---
[ 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 ]
Author: "Victor Bazarov" <vAbazarov@dAnai.com>
Date: 2000/08/02 Raw View
"David R Tribble" <david@tribble.com> wrote...
> Anders J. Munch <andersjm@post.tele.dk> writes
> >> This proposal will break no conforming code:
>
> "Francis Glassborow" <francis@robinton.demon.co.uk> wrote
> >> You have absolutely no way to know this. ...
>
> "Anders J. Munch" wrote:
> > I can't imagine how a program written in currently conforming C++
> > would be broken. Could you provide an example, please?
>
> How about:
>
> class Foo a;
> class Foo b;
> class Foo c;
>
> (a = b) = c;
>
> Horrible style, yes, but legal C++ nonetheless.
Check out the discussion about that in comp.lang.c++.moderated.
The (a = b) = c; causes undefined behaviour because it modifies 'a'
twice between sequence points...
The relevant threads are "Which operator= return value do you prefer?"
and "a = b = c; Francis, John, *now* you confused me!". I can't
claim I understand what the answer is, I only try to grasp what they
are talking about. I think that the idea is that the rvalue and lvalue
of an expression are evaluated (or can be evaluated) independently.
Victor
--
Please remove capital A's from my address when replying by mail
---
[ 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 ]
Author: Anthony Williams <anthony_w@my-deja.com>
Date: 2000/08/03 Raw View
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In article <8m6gab$i5b$1@news.inet.tele.dk>,
"Anders J. Munch" <andersjm@post.tele.dk> wrote:
> "Francis Glassborow" <francis@robinton.demon.co.uk> wrote in message
> news:9e86LYBzydh5EwDw@robinton.demon.co.uk...
> > In article <8m1i4s$lqv$1@news.inet.tele.dk>, Anders J. Munch
> > <andersjm@post.tele.dk> writes
> > >This proposal will break no conforming code:
> >
> > You have absolutely no way to know this. Even if every current
> I can't imagine how a program written in currently conforming C++
> would be broken. Could you provide an example, please?
template<typename T>
T func(const T&x)
{
T a;
T b;
a=b=x;
return a;
}
Currently the line "a=b=x" invokes
T& operator=(const T&) // b=x - return=temp
T& operator=(const T&) // a= temp
If operator=(const T&) can return anything other than T&, then the
second call
is not operator=(const T&), but operator=(return_type), or if this is
not
available, then a standard conversion operator must be applied, which
may not
even be available.
This can change the operation of the program substantially - it might
not even
compile.
Anthony
- --
alink@anthonyw.cjb.net -- Questions relating to ALINK
anthony@anthonyw.cjb.net -- Non-ALINK questions
anthonyw.cjb.net -- ALINK home page
PGP Key at: i3.yimg.com/3/c7e5ee24/g/68fc2307.asc
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com>
Comment: PGP Key at: http://i3.yimg.com/3/c7e5ee24/g/68fc2307.asc
iQA/AwUBOYfj95vw+P4cG5rVEQJafQCfXFZc8uRKn2wC/Om05Y0oTrG5Sm4An2+a
UiE8yg1VVh7k2J98Ii+u8rTZ
=eFWe
-----END PGP SIGNATURE-----
Sent via Deja.com http://www.deja.com/
Before you buy.
---
[ 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 ]
Author: David R Tribble <david@tribble.com>
Date: 2000/08/03 Raw View
Anders J. Munch <andersjm@post.tele.dk> writes
>> This proposal will break no conforming code:
"Francis Glassborow" <francis@robinton.demon.co.uk> wrote
>> You have absolutely no way to know this. ...
"Anders J. Munch" wrote:
> I can't imagine how a program written in currently conforming C++
> would be broken. Could you provide an example, please?
How about:
class Foo a;
class Foo b;
class Foo c;
(a = b) = c;
Horrible style, yes, but legal C++ nonetheless.
--
David R. Tribble, mailto:david@tribble.com, http://david.tribble.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 ]
Author: Michiel Salters <salters@lucent.com>
Date: 2000/08/03 Raw View
Victor Bazarov wrote:
> "David R Tribble" <david@tribble.com> wrote...
> > How about:
> > class Foo a;
> > class Foo b;
> > class Foo c;
> > (a = b) = c;
> > Horrible style, yes, but legal C++ nonetheless.
> Check out the discussion about that in comp.lang.c++.moderated.
> The (a = b) = c; causes undefined behaviour because it modifies 'a'
> twice between sequence points...
No, it doesn't. There is a sequence point for each function call, and
Foo::operator=() is a real function with a sequence point. That means
that there is a sequence point between the two modifications of 'a',
and no undefined behavior is possible.
You are probably refering to the behavior of builtin types, for which no
function is called.
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://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Sebastian Moleski" <sebmol@gmx.net>
Date: 2000/08/03 Raw View
"Anders J. Munch" <andersjm@post.tele.dk>:
> I am proposing to remove the requirement from Assignable, that given
> u,v of type T,
> u = v
> must have (return) type T&.
>
> I see this requirement as creating problems but having no significant
> benefits.
Could you please elaborate on how this creates problems?
TIA,
Sebastian Moleski
---
[ 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 ]