> Most of the other operators have groovy symbols. So, what about
>
> <=> instead of swap
> <- instead of move
>
> ?

    Please do not forget, that besides these operators you would also need
"swap" and "move" constructors, to be able to write things like

Foo bar <- GenerateFoo();

    But again, you can have your swap operators, but they will be probably
useless, unless "no non-const operations on temporaries" restriction
is removed.

    For me, it would be fine to "rename" T(T&) and operator=(T&) as move
constructor and move operator. In fact, we have long experience doing things
that way and there are no problems at all (sure, you have to define some
"real" copy _explicit_ operations for objects, but that it is well working
idiom).

Mirek


---
[ 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.research.att.com/~austern/csc/faq.html                ]

In <xwAK6.5652$577.972902@news2-win.server.ntlworld.com> "glancaster" <glancaster@ntlworld.com> writes:

>However I also think that once there is agreement to add move, agreement to
>add swap would also be forthcoming. I think people might consider that the
>third suggestion is too much of a micro-optimization though.
>
>Most of the other operators have groovy symbols. So, what about
>
><=> instead of swap
><- instead of move

wouldn't the last one introduce syntactical problems?

    int a,b;
    if (a<-b) { // here I mean: a < -b
       a<-b;    // here I mean: a <- 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.research.att.com/~austern/csc/faq.html                ]

Garry Lancaster:
> > Most of the other operators have groovy symbols. So, what about
> >
> > <=> instead of swap
> > <- instead of move

Having thought about this further, I'd like to withdraw the move suggestion,
because (a <- b) is too similar to (a < -b) for my (and my parser's)
comfort.

<= is already taken of course, as is <<, which is already overloaded in
meaning. What about <=< (kind of nice if swap is <=>)? Anyone got any other
suggestions?

Mirek Fidler:
>     Please do not forget, that besides these operators you would also need
> "swap" and "move" constructors, to be able to write things like
>
> Foo bar <- GenerateFoo();

Move ctor yes. Swap ctor no: what would be the value of the src after this,
and why would this be different to a move ctor?

>     But again, you can have your swap operators, but they will be probably
> useless, unless "no non-const operations on temporaries" restriction
> is removed.

Not useless, but certainly less convenient.

For move and swap relaxing this restriction has advantages. I'm unsure
whether it would be better to just lift the restriction for these special
cases, or to lift it generally (less safe, more consistent) - which is what
you've been advocating since the start of this thread, right? ;-)

Incidentally, I would expect swaps involving temporaries to be rare - for
classes that define move, a move from a temporary better expresses the
intention.

>     For me, it would be fine to "rename" T(T&) and operator=(T&) as move
> constructor and move operator. In fact, we have long experience doing
things
> that way and there are no problems at all (sure, you have to define some
> "real" copy _explicit_ operations for objects, but that it is well working
> idiom).

Just dealing with the copy ctor side of this there are two problems:

1. A copy ctor is supposed to copy. It's counter-intuitive when it does
something else. Yes, I know there are already classes that violate this
expectation. The difference between us is that I see these as indicative of
as a problem that could be fixed[^], whereas you do not.

2. As each class has a maximum of one copy ctor, you can have it copy *or*
move, but you can't have both options:

class T {...};
void foo(T);

// In main.
foo( a );    // No choice - always calls T(T&)

Some classes, std::vector instantiations for instance, would benefit from
the choice.

Kind regards

Garry Lancaster
Codemill Ltd
mail << "glancaster" << at << "codemill" << dot << "net";
Visit our web site at http://www.codemill.net

^ I mean no insult to those who developed C++ here. Read "lack of language
support for intuitive use of this particular idiom, leaving potential for
improvements in a future revision of the language" if you prefer.




---
[ 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.research.att.com/~austern/csc/faq.html                ]

On Fri, 11 May 2001 09:04:56 GMT, Geert-Jan Giezeman <geert@cs.uu.nl> wrote:
> In <xwAK6.5652$577.972902@news2-win.server.ntlworld.com> "glancaster" <glancaster@ntlworld.com> writes:
>
> >However I also think that once there is agreement to add move, agreement to
> >add swap would also be forthcoming. I think people might consider that the
> >third suggestion is too much of a micro-optimization though.
> >
> >Most of the other operators have groovy symbols. So, what about
> >
> ><=> instead of swap
> ><- instead of move
>
> wouldn't the last one introduce syntactical problems?
>
>     int a,b;
>     if (a<-b) { // here I mean: a < -b
>        a<-b;    // here I mean: a <- b
>     }

The general rule is to always parse the longest possible token, hence in
both lines it would be parsed as `<-' if `<-' becomes a token (cf. '>>'
and '> >' wrt. to nested template argument lists). Of course this will
break all previous code where it was meant to be parsed as separate
tokens, which I guess almost no one will find acceptable.

This is also one reason why letting the user define arbitrary new
operators isn't such a good idea (in C++); it is prone to silently
breaking existing code in unexpected ways. A language needs to have
different token parsing rules for this to be possible; for example
mandate that all tokens that consist of operator characters need to be
separated either by whitespace or by non-operator tokens, and otherwise
are always parsed as a single operator token.

-- Niklas Matthies

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Niklas Matthies wrote:
>
> On Fri, 11 May 2001 09:04:56 GMT, Geert-Jan Giezeman <geert@cs.uu.nl> wrote:
> > In <xwAK6.5652$577.972902@news2-win.server.ntlworld.com> "glancaster" <glancaster@ntlworld.com> writes:

[...]

> > wouldn't the last one introduce syntactical problems?
> >
> >     int a,b;
> >     if (a<-b) { // here I mean: a < -b
> >        a<-b;    // here I mean: a <- b
> >     }
>
> The general rule is to always parse the longest possible token, hence in
> both lines it would be parsed as `<-' if `<-' becomes a token (cf. '>>'
> and '> >' wrt. to nested template argument lists). Of course this will
> break all previous code where it was meant to be parsed as separate
> tokens, which I guess almost no one will find acceptable.
>
> This is also one reason why letting the user define arbitrary new
> operators isn't such a good idea (in C++); it is prone to silently
> breaking existing code in unexpected ways. A language needs to have
> different token parsing rules for this to be possible; for example
> mandate that all tokens that consist of operator characters need to be
> separated either by whitespace or by non-operator tokens, and otherwise
> are always parsed as a single operator token.

I don't think anyone wanted to allow to define arbitrary character
sequences as operators. Of course, the operator name would have to
be a token, or the sequence of a made-up operator-token (say, "@")
followed by a token. Most probably, as tokens only identifiers would
be allowed.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Mirek Fidler" <cxl@iol.cz> dared to utter in
news:9dbtr1$26vq$1@news.vol.cz:

>> appropriate than a default constructor. But if you could indicate that
>> bitwise swap is OK (void swap(T&) = default; or something, see other
>
>     You do not need any new language features to indicate this. Create
>     this
> template
>
> template <class T>
> struct BitwiseSwap {
>     friend void swap(T& a, T& b) { memswap(&a, &b, sizeof(T)); }
> }
>
> and use template specialization to indicate that it is ok to use
> bitwise swap:
>
> class Foo {
> ......
> };
>
> template BitwiseSwap<Foo>;
>

Yes, I know. If I specialise std::swap for Foo, even all the STL algorithms
can take advantage of my superswap. In fact, I tried it on a couple of
STLpost classes that where never designed for this and it worked like a
charm[0].

However, that is not the point. The point is that I /don't/ want to
specialise as a bitwise swap is mostly OK anyhow.

But someone else already pointed out that all we need is a 'move' as the
one of the most fundamental operations. Swap could be implemented as a
couple of moves. And these would, I think, most of the time boil down to
something the compiler can optimise to a bitwise swap. So that is a much
better line of thought.

Regards,
M4
[0] I know, this proves nothing.

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Martijn Lievaart:
> >> appropriate than a default constructor. But if you could indicate that
> >> bitwise swap is OK (void swap(T&) = default; or something, see other

Mirek Fidler:
> >     You do not need any new language features to indicate this. Create
> >     this
> > template
> >
> > template <class T>
> > struct BitwiseSwap {
> >     friend void swap(T& a, T& b) { memswap(&a, &b, sizeof(T)); }
> > }
> > and use template specialization to indicate that it is ok to use
> > bitwise swap:
> >
> > class Foo {
> > ......
> > };
> >
> > template BitwiseSwap<Foo>;

Presumably you mean "explicit instantiation" not specialization. 14.7.2/2
has the syntax as:

template class BitwiseSwap<Foo>;

Martijn Lievaart:
> Yes, I know. If I specialise std::swap for Foo, even all the STL
algorithms
> can take advantage of my superswap.
> In fact, I tried it on a couple of
> STLpost classes that where never designed for this and it worked like a
> charm[0].

Specialising std::swap is problematic, as is expecting the standard
algorithms to use your swap. I don't really want to repeat the discussions
about this that are in the NG archives - we're supposed to be brainstorming,
not rehashing old threads - plus others are much better at explaining it
than I. But, if you need proof, visit groups.google.com and do a search for
"swap problem" in csc++m.

It is my belief that making swap an operator, and compelling the standard
algorithms that use swap behaviour to use the swap operator, would solve all
the "swap problems" elegantly (at least for swap - sometimes the term "swap
problem" is used to define a more general malaise, although all the killer
examples seem to involve std::swap). I'd be interested to see a swap problem
that didn't yield to this solution.

> However, that is not the point. The point is that I /don't/ want to
> specialise as a bitwise swap is mostly OK anyhow.

class IDefineMyOwnNonBitwiseSwap {...};

class SomeOtherClass
{
    //...
private:
    IDefineMyOwnNonBitwiseSwap data;
};

Bitwise swap doesn't work on SomeOtherClass. We'd be better off using
memberwise swap as the compiler generated implementation. It *would* work
for SomeOtherClass. Just like the memberwise copy used for default copy
assignment and copy ctors, it has the nice property that it degrades to the
bitwise operation when possible. There are still some occasions when
memberwise swap is inappropriate (they are all also cases where bitwise swap
is inappropriate - the reverse is not true), so you still need to have the
ability to override.

Even with memberwise swap I agree you need to explicitly switch the new
compiler generated swap behaviour on somehow. Otherwise some C++98 classes
will silently break when used with a compiler-generated C++0x swap.

> But someone else already pointed out that all we need is a 'move' as the
> one of the most fundamental operations. Swap could be implemented as a
> couple of moves. And these would, I think, most of the time boil down to
> something the compiler can optimise to a bitwise swap. So that is a much
> better line of thought.

I certainly agree with that. If I could just have one of move, swap and the
"local return ctor dtor" (haven't quite thought of a good name for that one
yet), I'd take move. The compiler can generate the others using move, maybe
with some loss of efficiency in some cases. But once you have a no throw
move, you get no throw swap and no throw "local return ctor dtor", which is
vital for exception safety.

However I also think that once there is agreement to add move, agreement to
add swap would also be forthcoming. I think people might consider that the
third suggestion is too much of a micro-optimization though.

Most of the other operators have groovy symbols. So, what about

<=> instead of swap
<- instead of move

?

Kind regards

Garry Lancaster
Codemill Ltd
mail << "glancaster" << at << "codemill" << dot << "net";
Visit our web site at http://www.codemill.net

---
[ 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.research.att.com/~austern/csc/faq.html                ]

glancaster wrote:
[...]
> I certainly agree with that. If I could just have one of move, swap and the
> "local return ctor dtor" (haven't quite thought of a good name for that one
> yet), I'd take move. The compiler can generate the others using move, maybe
> with some loss of efficiency in some cases. But once you have a no throw
> move, you get no throw swap and no throw "local return ctor dtor", which is
> vital for exception safety.
>
> However I also think that once there is agreement to add move, agreement to
> add swap would also be forthcoming. I think people might consider that the
> third suggestion is too much of a micro-optimization though.
>
> Most of the other operators have groovy symbols. So, what about
>
> <=> instead of swap
> <- instead of move
>
> ?

I much prefer
  a swap b;
over anything like
  a <=> b;
or
  a :=: b;

I am not so sure about move.
Maybe destructive_move or destructive_copy.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"glancaster" <glancaster@ntlworld.com> dared to utter in
news:xwAK6.5652$577.972902@news2-win.server.ntlworld.com:

>
> Martijn Lievaart:
>> Yes, I know. If I specialise std::swap for Foo, even all the STL
>> algorithms can take advantage of my superswap.
>> In fact, I tried it on a couple of
>> STLpost classes that where never designed for this and it worked like
>> a charm[0].
>
> Specialising std::swap is problematic, as is expecting the standard
> algorithms to use your swap. I don't really want to repeat the
> discussions about this that are in the NG archives - we're supposed to
> be brainstorming, not rehashing old threads - plus others are much
> better at explaining it than I. But, if you need proof, visit
> groups.google.com and do a search for "swap problem" in csc++m.
>

I will. Most interested.

(snip)
>
> Bitwise swap doesn't work on SomeOtherClass. We'd be better off using
> memberwise swap as the compiler generated implementation. It *would*
> work for SomeOtherClass. Just like the memberwise copy used for default
> copy assignment and copy ctors, it has the nice property that it
> degrades to the bitwise operation when possible. There are still some
> occasions when memberwise swap is inappropriate (they are all also
> cases where bitwise swap is inappropriate - the reverse is not true),
> so you still need to have the ability to override.

You are absolutely right.

>
> Even with memberwise swap I agree you need to explicitly switch the new
> compiler generated swap behaviour on somehow. Otherwise some C++98
> classes will silently break when used with a compiler-generated C++0x
> swap.
>

Yes, absolutely. A nice touch might be to be able to turn it on explicitely
for some classes in legacy/library code. I know I can do that today, but it
means a lot of work. I think it would make the life of library implementors
much easier if they can use some #pragma instead of #ifdefs or other
troublesome constructs to turn it on for some classes when using a post
C++98 (C++08?) compiler.

(snip)
>
> Most of the other operators have groovy symbols. So, what about
>
><=> instead of swap
><- instead of move
>
> ?
>

I like it.

Overall, thanks for your excelent post. I think you cleared up a lot of
things for me. I'll shut up now about bitwise swap as it is shown to be a
nonissue.
:-)

Thanks,
Martijn Lievaart

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Dennis Yelle <dennis51@jps.net> dared to utter in
news:3AF81DC4.527E8957@jps.net:

(bitwise swap)

>
> Perhaps the compiler should only define swap if there is an
> accessible default copy constructor.
>
> Can we say that the default swap is safe if the default copy
> constructor is safe?
>

That would be an enhancement, but bitwise swap is much more often
appropriate than a default constructor. But if you could indicate that
bitwise swap is OK (void swap(T&) = default; or something, see other
messages in this thread on enhanced syntax) that would be a big improvement
imho. Take together this and your suggestion, I think, would be perfectly
safe.

Martijn Lievaart

---
[ 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.research.att.com/~austern/csc/faq.html                ]

> appropriate than a default constructor. But if you could indicate that
> bitwise swap is OK (void swap(T&) = default; or something, see other

    You do not need any new language features to indicate this. Create this
template

template <class T>
struct BitwiseSwap {
    friend void swap(T& a, T& b) { memswap(&a, &b, sizeof(T)); }
}

and use template specialization to indicate that it is ok to use bitwise
swap:

class Foo {
......
};

template BitwiseSwap<Foo>;

Mirek

P.S.: I hope new C++ standard will not disallow this ;-)


---
[ 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.research.att.com/~austern/csc/faq.html                ]

"Mirek Fidler" <cxl@iol.cz> dared to utter in
news:9d3rqm$2b6e$1@news.vol.cz:

>> default of a bitwise swap. I have yet to think of a realistic example
>> where a bitwise swap would be inapropriate.
>
>    Think about something like this:
>
> class Foo {
>     char data[128];
>     char *end;
> public:
>     Foo(const char *q) {
>         strcpy(data, q);
>         end = data + strlen(data);
>     }
> }
>
> In fact, bitwise swap (or move) is fine in most cases, but making it
> default seems a little bit dangerous to me.
>

I thought about this as soon as I hit send (doesn't that always happen),
but more thought convinced me that it is not as bad as it seems.

First, roughly the same happens with the default copy constructor, so there
at least is a precedent that is much more dangerous. More dangerous because
there are many more situautions that this is wrong than with my proposed
swap.

Secondly, I think this situation happens infrequently, if not seldomly. And
when it happens, just specialise. This seems in concert with other areas of
C++. The only way that it may be dangerous in my eyes is that it happens
/so/ infrequently you are likely to forget it.

Thirdly, how do you implement a bitwise swap whithout my proposal? I can
write one, but then I'm at the mercy of this working for every type not
written by me, which I cannot guarentee. And I cannot add it to namespace
std because it already is defined.

I still think it is a good idea to add this. Yes, it will break existing
programs (my original context for this idea was a C++ like language), and
it can do so in a very subtle way. But the idea of a non-throwing swap that
does the right thing in 99.9% of the cases is attractive.

M4

---
[ 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.research.att.com/~austern/csc/faq.html                ]

Martijn Lievaart wrote:
>
> "Mirek Fidler" <cxl@iol.cz> dared to utter in
> news:9d3rqm$2b6e$1@news.vol.cz:
>
> >> default of a bitwise swap. I have yet to think of a realistic example
> >> where a bitwise swap would be inapropriate.
> >
> >    Think about something like this:
> >
> > class Foo {
> >     char data[128];
> >     char *end;
> > public:
> >     Foo(const char *q) {
> >         strcpy(data, q);
> >         end = data + strlen(data);
> >     }
> > }
> >
> > In fact, bitwise swap (or move) is fine in most cases, but making it
> > default seems a little bit dangerous to me.
> >
>
> I thought about this as soon as I hit send (doesn't that always happen),
> but more thought convinced me that it is not as bad as it seems.
>
> First, roughly the same happens with the default copy constructor, so there
> at least is a precedent that is much more dangerous. More dangerous because
> there are many more situautions that this is wrong than with my proposed
> swap.

Perhaps the compiler should only define swap if there is an
accessible default copy constructor.

Can we say that the default swap is safe if the default copy
constructor is safe?

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:
http://table.jps.net/~vert/

---
[ 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.research.att.com/~austern/csc/faq.html                ]

"glancaster" <glancaster@ntlworld.com> dared to utter in
<sqbJ6.3959$7_1.559499@news6-win.server.ntlworld.com>:

>
>1. Promote swap to operator status.
>
>I want to be able to say
>
>a swap b;
>
>For any type without a using declaration or namespace qualification,
>whether it's a fundamental type, in std or in some other namespace.
>Moreover, unless a programmer writes swap for a type, the compiler
>should generates one. Ideally this would be based on memberwise swap, in
>a similar manner as the default memberwise copy for copy assignment and
>construction. Unfortunately this causes problems for many classes
>written with C++98, but I'm sure it could be added somehow.

I have been thinking about this lately coincedentaly. My conclusion that I
want to lay before the experts is that I cannot find anything wrong with a
default of a bitwise swap. I have yet to think of a realistic example where
a bitwise swap would be inapropriate.

Surely there are objects that are inapropriate to be swapped, because of
the context they are used in. In that case, it is up to the context to make
sure they are not, just as the context should make sure they are not
assigned to. That's algorithm, not language.

For copy assignment you have to worry about a lot of things, but these do
not apply to a swap. The only examples I could think up where this would
create havoc would be with low-level C++ extentions as OODBMSen and GC.

>
>Certain usages of the template algorithm std::swap have a number of
>other problems that this would solve. Plus, no-throw swap
>implementations,  which would be encouraged by this change, are pretty
>essential for a lot of exception-safe code.

And that is the kicker. Bitwise swap is no-throw!

I would like to here the experts on this, someone else surely must have
thought of this as well.

Martijn Lievaart

---
[ 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.research.att.com/~austern/csc/faq.html                ]

> default of a bitwise swap. I have yet to think of a realistic example
where
> a bitwise swap would be inapropriate.

   Think about something like this:

class Foo {
    char data[128];
    char *end;
public:
    Foo(const char *q) {
        strcpy(data, q);
        end = data + strlen(data);
    }
}

In fact, bitwise swap (or move) is fine in most cases, but making it default
seems a little bit dangerous to me.

Mirek


---
[ 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.research.att.com/~austern/csc/faq.html                ]