Tom Plunket  <tomas@fancy.org> wrote:
+ Phil Edwards wrote:
+
+ > Optimizing the daylights out of, say, swap<int> and swap<unsigned int>
+ > could prove to be quite useful.
+
+ What could be a more optimal swap algorithm than loading the two
+ values you're swapping into registers and then writing the
+ registers back into the opposite locations?

Possibly nothing, but my poorly-worded point was that an optimizing
compiler might not come up with that on its own.  The library implementor
could specialize swap<> for some useful types, and emit the neccessary
instructions via asm("...").

If those instructions happen to be dual loads and stores, like you say,
then great, but that might still have to be done by specializations rather
than an optimizer.  (Maybe.)

Phil

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a01b5eb@andromeda.datanet.hu>,
  "Balog Pal (mh)" <pasa@lib.hu> wrote:
> The current C++ has only 2-state compare operators. However in certain
> situations you need a 3-state one, like memcmp() and its brothers.
> So you end up with code like:
>
> if (A == B)
>     return EQUAL;
> else if (A < B)
>     return LESS;
> else
>     return GREATER;
>
> The little problem of keeping the 2 ifs consistent is easily covered
by
> using a template. But we still have a penalty of two calls with the
same
> params, and the function called for < does very likely know the
answer for
> the full question anyway, just can't tell us.
> If we come to compare composite objects, implemented by comparing the
> subkeys one by one until decision is reached, that can be a serious
penalty,
> and if we need a sorting or seeking code we face this.
>
> Suppose the language had that operator, we'd have much less job, and
clearer
> code. Certainly it would be predefined for all builtin types, and
> overloadable for UDT's. I also think many people would rewrite his
existing
> compare operator overload functions, like
>
> bool operator <(const T& That)const  { return (*this <=> That) < 0; }
> bool operator <=(const T& That)const  { return (*this <=> That) <=
0; }
> and so on.
>
> (Certainly a healthy mark should be selected.)
>
> Paul
>

I personally like it - although you can emulate it quite
successfully using templates. Even for the build in types,
if the compiler is smart enough, it will generate
code as efficient as if it was a build in operator. Because
of this, it's very unprobable that the idea will have significant
support.

Radoslav Getov


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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Balog Pal (mh)" wrote:
>
> The current C++ has only 2-state compare operators. However in certain
> situations you need a 3-state one, like memcmp() and its brothers.
> So you end up with code like:
>
> if (A == B)
>     return EQUAL;
> else if (A < B)
>     return LESS;
> else
>     return GREATER;
>
> The little problem of keeping the 2 ifs consistent is easily covered by
> using a template. But we still have a penalty of two calls with the same
> params, and the function called for < does very likely know the answer for
> the full question anyway, just can't tell us.
> If we come to compare composite objects, implemented by comparing the
> subkeys one by one until decision is reached, that can be a serious penalty,
> and if we need a sorting or seeking code we face this.
>
> Suppose the language had that operator, we'd have much less job, and clearer
> code. Certainly it would be predefined for all builtin types, and
> overloadable for UDT's. I also think many people would rewrite his existing
> compare operator overload functions, like
>
> bool operator <(const T& That)const  { return (*this <=> That) < 0; }
> bool operator <=(const T& That)const  { return (*this <=> That) <= 0; }
> and so on.

I think the operator shouldn't return a number, but a three-state
type, say

enum compare_t { below = -1, equal, above };

The three way compare could be done with a simple switch:

switch(a <=> b)
{
  case below: ...
  case equal: ...
  case above: ...
}

However, there's not really a need for an operator. A function
will work well:

template<typename T>
 compare_t compare(T const& one, T const& other);

The default version would then just use operator< (so that it
is compatible with current code):

template<typename T>
 compare_t compare(T const& one, T const& other)
{
  if (one < other)
    return below;
  else if (other < one)
    return above;
  else
    return equal;
}

but specialisations could use more efficient versions, like

template<typename Char, typename Traits>
 compare_t compare(std::basic_string<Char, Traits> const& one,
                   std::basic_string<Char, Traits> const& other)
{
  typedef std::basic_string<Char, Traits> str;
  typedef str::const_iterator iter;
  for(iter begin1 = one.begin(), end1 = one.end(),
           begin2 = other.begin(), end2 = other.end();
      begin1 != end1 && begin2 != end2;
      ++begin1, ++begin2)
  {
    if (*begin1 < *begin2)
      return below;
    else if (*begin2 < *begin1)
      return above;
  }
  if (begin1 == end1)
    if (begin2 == end2)
      return equal;
    else
      return below;
  else
    return above;
}

Fortunately, both the enum and the function template can be defined
in current C++. Therefore the language can remain as it is.
However, it would be nice to have compare as part of the standard
library.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Phil Edwards wrote:

> Makes me wonder if the builtin types couldn't be specialized for swap<>
> as well.  I know you can swap two integers and not use a temporary with
> a chain of bitwise ORs, but I don't recall the exact statement.

void swap(int x, int y)
{
   x ^= y;
   y ^= x;
   x ^= y;
}

...I think.  It has been years since I thought of it in the
shower (certainly I wasn't the first, but I hadn't seen it
either).

Regardless, I would think that in hardware this would be slower
than the temporaries, because consider that to swap, you need to
load both values into registers anyway; rather than XORing the
registers three times and then writing them back to where they
came from, why not just write them back into the opposite
locations?

IOW, I have thought about this in the past, but in the end it's a
waste of cycles even though the XOR trick is "clever".

-tom!

--
Tom Plunket                                            tomas@fancy.org
PlayStation2/3D Studio geek
        "Our music is simple, it's totally fake.  It's done by
         machines 'cause they don't make mistakes."     -KMFDM

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tom Plunket wrote:
>
> Phil Edwards wrote:
>
> > Makes me wonder if the builtin types couldn't be specialized for swap<>
> > as well.  I know you can swap two integers and not use a temporary with
> > a chain of bitwise ORs, but I don't recall the exact statement.
>
> void swap(int x, int y)
> {
>    x ^= y;
>    y ^= x;
>    x ^= y;
> }

First, this is a complete no-op because it does nothing with the flopped
values.  Lets recode it as:
 void swap(int& x, int& y) {
    x ^= y;
    y ^= x;
    x ^= y;
 }

Second, the code is dangerous.  Imagine the following:
 int x = 5;
 swap(x, x);

What do you think has happened now?


> Regardless, I would think that in hardware this would be slower
> than the temporaries, because consider that to swap, you need to
> load both values into registers anyway; rather than XORing the
> registers three times and then writing them back to where they
> came from, why not just write them back into the opposite
> locations?

This is precisely the case.  Even if an additional temporary is needed
it's probably still faster (and usually a single integer sized temporary
is available).

> IOW, I have thought about this in the past, but in the end it's a
> waste of cycles even though the XOR trick is "clever".

Generally, things that look too tricky are not as fast in the long run.

A quote from Buckminster Fuller:

  When I am working on a problem, I never think about beauty...but when I have finished, if
  the solution is not beautiful, I know it is wrong.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tom Plunket  <tomas@fancy.org> wrote:
+ Phil Edwards wrote:
+
+ > Makes me wonder if the builtin types couldn't be specialized for swap<>
+ > as well.  I know you can swap two integers and not use a temporary with
+ > a chain of bitwise ORs, but I don't recall the exact statement.

That might not have been the best example I could have picked.


+ void swap(int x, int y)
+ {
+    x ^= y;
+    y ^= x;
+    x ^= y;
+ }

ORs, XORs, knew it was something like that... :-)


+ IOW, I have thought about this in the past, but in the end it's a
+ waste of cycles even though the XOR trick is "clever".

Oh, definitely.  That's why I should have picked some other example than
a series of bitwise ops.

Now I'm wondering if anybody knows of any implementations where swap<> has
been specialized for builtin types, maybe to take advantage of particular
hardware features.  That function gets called a /lot/ during sorting
routines called by the library.  Optimizing the daylights out of, say,
swap<int> and swap<unsigned int> could prove to be quite useful.

I can't think of anything off the top of my head in the standard to prohibit
such an improvement.


Luck++;
Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Phil Edwards wrote:

> Oh, definitely.  That's why I should have picked some other example than
> a series of bitwise ops.
>
> Optimizing the daylights out of, say, swap<int> and swap<unsigned int>
> could prove to be quite useful.
>
> I can't think of anything off the top of my head in the standard to
> prohibit such an improvement.

Perhaps, but that was part of my point, one that I did not make
clear.

What could be a more optimal swap algorithm than loading the two
values you're swapping into registers and then writing the
registers back into the opposite locations?  I honestly don't
think that there's any "daylight optimization" of this function,
unless you're talking about optimizing a sort of an array or
something and trying to keep your swaps in the cache, but then
we're getting outside of the realm of C++ anyway, and any
optimization of this sort would have to be hardware-specific.


-tom!

--
Tom Plunket                                            tomas@fancy.org
PlayStation2/3D Studio geek
              The best tagline is the one that you steal.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ron Natalie wrote:

> > void swap(int x, int y)
>
> First, this is a complete no-op because it does nothing with the flopped
> values.  Lets recode it as:
>  void swap(int& x, int& y) {

Yeah yeah...  :)

> Second, the code is dangerous.  Imagine the following:
>  int x = 5;
>  swap(x, x);
>
> What do you think has happened now?

Well that was code that you wrote, not me.  :)

I would probably prefer to pass in by value a two-element array/
vector/something and pass out as a return value another
two-element thing.  However, that would be even slower yet.  :)


-tom!

--
Tom Plunket                                            tomas@fancy.org
PlayStation2/3D Studio geek
        "Our music is simple, it's totally fake.  It's done by
         machines 'cause they don't make mistakes."     -KMFDM

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tom Plunket wrote in message <2htj0tstcnqjfc091g5ftnjq46brui6k7a@4ax.com>...

>What could be a more optimal swap algorithm than loading the two
>values you're swapping into registers and then writing the
>registers back into the opposite locations?

On processors that support it, you can do a load-exchange-store sequence
instead of a lo-ad-load-store-store one.

Paul


---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Balog Pal (mh)" <pasa@lib.hu> wrote in message
news:3a01b5eb@andromeda.datanet.hu...
> The current C++ has only 2-state compare operators. However in certain
> situations you need a 3-state one, like memcmp() and its brothers.
> So you end up with code like:
>
> if (A == B)
>     return EQUAL;
> else if (A < B)
>     return LESS;
> else
>     return GREATER;
>
> The little problem of keeping the 2 ifs consistent is easily covered by
> using a template. But we still have a penalty of two calls with the same
> params, and the function called for < does very likely know the answer for
> the full question anyway, just can't tell us.
> If we come to compare composite objects, implemented by comparing the
> subkeys one by one until decision is reached, that can be a serious
penalty,
> and if we need a sorting or seeking code we face this.

More generally, what you want is something like the Lisp "cond" construct.

(cond
(<condition1> <consequent1>)
(<condition2> <consequent2>)
....
(<conditionn> <consequentn>)
(else <default_consequent>)   // Optional
)

For your example (in a more C/C++-y syntax):

cond {
case (A == B): val= EQUAL; return;
case (A < B): val = LESS; return;
default: val = GREATER; return;
}


> Suppose the language had that operator, we'd have much less job, and
clearer
> code.

Yes. The Lisp cond construct is the right thing in surprisingly many cases,
and much easier to read and write correctly that the equivalent if/else
spagetti for most of those. (I presume there must have been multiple
proposals for generalizations of the switch statement for C and C++ over the
years.) However, many of those cases are recursive functions, so it is less
important in C++ than in languages that depend more heavily on recursion.

I'd say that a downward-funarg-only, reference semantics for free variables
lambda would be far more usefull for C++ than a lisp-like cond construct,
but I'd love to see both...

David J. Littleboy
Tokyo, Japan



---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Good point! I believe operator-() will also have overflows with w_char and
pointers as well since int is not guaranteed to be larger than them.

However, in practice if overflowing is not a problem, then using operator-()
on signed int's is adequate and also would most likely be faster than
computing operator<=>(). Plus, operator-() is still adequate for bools,
chars, floats, doubles, and possibly user-defined classes.

My point is just that operator-() already fulfills some of the role of the
operator<=>(), plus there is nothing to stop one from defining their own
function named e.g. Compare3 (but it won't be an infix operator). I think
operator<=>() is elegant and I would use it if it were available, but I can
also manage without it for now.

By the way, if one wants to define an infix operator by naming a function
operator<=>(), operator^^(), or operator&&=()  then perhaps C++ shouldn't
stop him -- as long as the operator can be parsed unambiguously. What do you
think?

Dennis Yelle <dennis51@jps.net> wrote in message
news:3A024CE5.B2088C98@jps.net...
> Gary Hinger wrote:
> >
> > For bools, chars, ints, floats, doubles,and pointers, C++ already has
such
> > an operator and it is called operator-().
>
> No, actually operator-() does not work that way
> in the case of integer overflow.  If both of
> the operands are random, overflow will happen
> about 25% of the time.  It is necessary to introduce
> a new operator to do what he wants to do.
> Perl, for example, has the operator <=> which returns
> -1, 0, or +1 for less, equal, or greater.
>
> > If you want to do something
> > similar for your own classes, then you could use either operator-() or
just
> > choose an ordinary function name. I personally don't need something like
> > operator<=>(), though it may be convenient for others.
> >
> > Balog Pal (mh) <pasa@lib.hu> wrote in message
> > news:3a01b5eb@andromeda.datanet.hu...
> > > The current C++ has only 2-state compare operators. However in certain
> > > situations you need a 3-state one, like memcmp() and its brothers.
> > > So you end up with code like:
> > >
> > > if (A == B)
> > >     return EQUAL;
> > > else if (A < B)
> > >     return LESS;
> > > else
> > >     return GREATER;
> > >
> > > The little problem of keeping the 2 ifs consistent is easily covered
by
> > > using a template. But we still have a penalty of two calls with the
same
> > > params, and the function called for < does very likely know the answer
for
> > > the full question anyway, just can't tell us.
> > > If we come to compare composite objects, implemented by comparing the
> > > subkeys one by one until decision is reached, that can be a serious
> > penalty,
> > > and if we need a sorting or seeking code we face this.
> > >
> > > Suppose the language had that operator, we'd have much less job, and
> > clearer
> > > code. Certainly it would be predefined for all builtin types, and
> > > overloadable for UDT's. I also think many people would rewrite his
> > existing
> > > compare operator overload functions, like
> > >
> > > bool operator <(const T& That)const  { return (*this <=> That) < 0; }
> > > bool operator <=(const T& That)const  { return (*this <=> That) <=
0; }
> > > and so on.
> > >
> > > (Certainly a healthy mark should be selected.)
> > >
> > > Paul
>
> 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                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>


---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Gary Hinger said:
>By the way, if one wants to define an infix operator by naming a function
>operator<=>(), operator^^(), or operator&&=()  then perhaps C++ shouldn't
>stop him -- as long as the operator can be parsed unambiguously. What do you
>think?

It just reminds me of some article Stroustrup wrote:
  http://www.research.att.com/~bs/whitespace98.pdf

I think a decision was made about this a long time ago: that letting
new operators be created would make C++ too mutable/unstable, even if
issues such as operator precedence had an easy resolution.

 -ivec
---------------------------------------------------------
 Ivan Vecerina, Dr. med.
 Senior Software Developer - Surgical Navigation Network
  <http://www.surgnav.com> - <http://www.cedara.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ivan Vecerina wrote:
>
> Gary Hinger said:
> >By the way, if one wants to define an infix operator by naming a function
> >operator<=>(), operator^^(), or operator&&=()  then perhaps C++ shouldn't
> >stop him -- as long as the operator can be parsed unambiguously. What do you
> >think?
>
> It just reminds me of some article Stroustrup wrote:
>   http://www.research.att.com/~bs/whitespace98.pdf

Well, that paper is an April fools joke.
That should be clear as soon as you get to this part:

    Basic Whitespace Overloading

Personally I think swap is the most important missing operator.
Perhaps it could be spelled :=: and a default operator:=:()
defined by the compiler for any class if omitted by the programmer.

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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Thu,  2 Nov 2000 18:46:06 GMT, Balog Pal (mh) <pasa@lib.hu> pisze:

> Suppose the language had that operator, we'd have much less job,
> and clearer code. Certainly it would be predefined for all builtin
> types, and overloadable for UDT's.

I agree that the three-way comparison is useful. But why operator
and not a function? Some languages call it 'compare'.

--
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST   PCZA
QRCZAK

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Dennis Yelle  <dennis51@jps.net> wrote:
+
+ Personally I think swap is the most important missing operator.
+ Perhaps it could be spelled :=: and a default operator:=:()
+ defined by the compiler for any class if omitted by the programmer.

What's wrong with std::swap<>?  It's provided and will be used for any
class unless you provide a specialization yourself.

And as far as strange operator overloading in April Fool's papers goes,
I want operator:-) to tell the compiler not to take a certain expression
too seriously.


Luck++;
Phil

--
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Phil Edwards wrote:
>
> Dennis Yelle  <dennis51@jps.net> wrote:
> +
> + Personally I think swap is the most important missing operator.
> + Perhaps it could be spelled :=: and a default operator:=:()
> + defined by the compiler for any class if omitted by the programmer.
>
> What's wrong with std::swap<>?  It's provided and will be used for any
> class unless you provide a specialization yourself.

std::swap<> creates a temp which is (almost?) never needed.
Yes, I know, it will probably be optimized away in most cases,
but it seems ugly to me to have this:

  Type t = a; a = b; b = t;

when all one really wants is this:

  a :=: b;

especially, when for many classes, swap is actually
simpler than assignment.  And, in fact, assignment
is sometimes implemented by calling swap!

An operation like swap should not be defined in terms
of an operation that is often more complex than itself.

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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Dennis Yelle" <dennis51@jps.net> schrieb im Newsbeitrag
news:3A046701.78BBC65F@jps.net...
> Ivan Vecerina wrote:
[...]
> Personally I think swap is the most important missing operator.
> Perhaps it could be spelled :=: and a default operator:=:()
> defined by the compiler for any class if omitted by the programmer.

Well,
    std::swap(a, b);
is more obvious than
    a :=: b;
isn't it? I personally would have named it operator$.
    a $ b;
The dollar sign is no longer valid in identifiers, so one could make use of
it... let's $wap it... just my $0.02...

sk



---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Dennis Yelle wrote:
...
> std::swap<> creates a temp which is (almost?) never needed.
> Yes, I know, it will probably be optimized away in most cases,
> but it seems ugly to me to have this:
>
>   Type t = a; a = b; b = t;
>
> when all one really wants is this:
>
>   a :=: b;
>
> especially, when for many classes, swap is actually
> simpler than assignment.  And, in fact, assignment

Then std::swap() should be specialized for those classes to use the more
efficient approach. That's precisely the kind of thing that is the
reason why users are allowed to specialize standard templates for
user-defined types. The standard-imposed semantics are merely the
default, which works for any Assignable type; you're not stuck with
them.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Dennis Yelle said:
>
>Ivan Vecerina wrote:
>>
>> Gary Hinger said:
>> >By the way, if one wants to define an infix operator by naming a function
>> >operator<=>(), operator^^(), or operator&&=()  then perhaps C++ shouldn't
>> >stop him -- as long as the operator can be parsed unambiguously. What do you
>> >think?
>>
>> It just reminds me of some article Stroustrup wrote:
>>   http://www.research.att.com/~bs/whitespace98.pdf
>
>Well, that paper is an April fools joke.

It definitely is.

>Personally I think swap is the most important missing operator.
>Perhaps it could be spelled :=: and a default operator:=:()
>defined by the compiler for any class if omitted by the programmer.

There are others 'most important missing operators', including
min and max that already made it as extensions in some compilers.
( I think that gcc(?) defines something like <? and >? ops ).
And personally, I would use <-> for the swap operation ;)


My understanding is that the whitespace overloading is a carricature
of the requests for new operators that Stroustrup always rejected.
His clear opinion, from what I understand, is that the 'language'
should not be encumbered with any features that could be implemented
in a library. ( He's not alone - although you could say that
the ISO C committee did introduce some new syntax extensions... )


Now if the language allowed the definition of new operators,
a library could implement all the new op requests, right ?
But then, there are serious concerns that this would make the
language too 'malleable'.
Ever landed into a project where the team has long been using
an extensive set of custom macros such as:
 #define  forever for(;;)
 #define  Case  break;case
 #define  elif else if
 etc... ?
Think how convenient it is to enter the idiosyncrasies of such
a project, and how worse it could be with custom operator
definitions...


So, well, things are probably already complicated enough in
the C++ syntax. Is avoiding a few verbose constructs worth
the risk of 'confusing the installed base' anyway ?


If an extension of the C++ syntax was considered, I would
support some more complete overhaul, attempting to resolve
numerous other issues (e.g. readability and excessive ease
of obfuscated code creation).
Proposals have been made, such as SPECS:
 http://www.cs.monash.edu.au/~damian/papers/PS/ModestProposal.ps
 http://www.cs.monash.edu.au/~damian/papers/PS/SPECS.ps


But well, this never gained much momentum ...


Best regards,
 -ivec

---------------------------------------------------------
 Ivan Vecerina, Dr. med.
 Senior Software Developer - Surgical Navigation Network
  <http://www.surgnav.com> - <http://www.cedara.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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

If you don't want std::swap to create a temporary, specialize it for your
needs.

sm

"Dennis Yelle" <dennis51@jps.net> wrote in message
news:3A04A6E8.F255C2AD@jps.net...
>
>
> Phil Edwards wrote:
> >
> > Dennis Yelle  <dennis51@jps.net> wrote:
> > +
> > + Personally I think swap is the most important missing operator.
> > + Perhaps it could be spelled :=: and a default operator:=:()
> > + defined by the compiler for any class if omitted by the programmer.
> >
> > What's wrong with std::swap<>?  It's provided and will be used for any
> > class unless you provide a specialization yourself.
>
> std::swap<> creates a temp which is (almost?) never needed.
> Yes, I know, it will probably be optimized away in most cases,
> but it seems ugly to me to have this:
>
>   Type t = a; a = b; b = t;
>
> when all one really wants is this:
>
>   a :=: b;
>
> especially, when for many classes, swap is actually
> simpler than assignment.  And, in fact, assignment
> is sometimes implemented by calling swap!
>
> An operation like swap should not be defined in terms
> of an operation that is often more complex than itself.
>
> 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                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>


---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

James Kuyper  <kuyper@wizard.net> wrote:
+ Dennis Yelle wrote:
+ ...
+ > std::swap<> creates a temp which is (almost?) never needed.
+ > Yes, I know, it will probably be optimized away in most cases,
+ > but it seems ugly to me to have this:
+ >
+ >   Type t = a; a = b; b = t;
+ >
+ > when all one really wants is this:
+ >
+ >   a :=: b;

If the latter is implemented in terms of the former -- which it would be,
recall, by default by the compiler -- then all that's been gained here is
syntactic convenience; op:=: would still be creating a temporary.


+ > especially, when for many classes, swap is actually
+ > simpler than assignment.  And, in fact, assignment
+
+ Then std::swap() should be specialized for those classes to use the more
+ efficient approach. That's precisely the kind of thing that is the
+ reason why users are allowed to specialize standard templates for
+ user-defined types. The standard-imposed semantics are merely the
+ default, which works for any Assignable type; you're not stuck with
+ them.

Exactly!  Specializations for user-defined types are one of the most useful
things about the template functions.

Makes me wonder if the builtin types couldn't be specialized for swap<>
as well.  I know you can swap two integers and not use a temporary with
a chain of bitwise ORs, but I don't recall the exact statement.


Phil

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <UJqM5.276$qu5.92948@nnrp.gol.com>,
David J. Littleboy <davidjl@gol.com> wrote:
>
>"Balog Pal (mh)" <pasa@lib.hu> wrote in message
>news:3a01b5eb@andromeda.datanet.hu...
>> The current C++ has only 2-state compare operators. However in certain
>> situations you need a 3-state one, like memcmp() and its brothers.
>> So you end up with code like:
>>
>> if (A == B)
>>     return EQUAL;
>> else if (A < B)
>>     return LESS;
>> else
>>     return GREATER;
>>
>> The little problem of keeping the 2 ifs consistent is easily covered by
>> using a template. But we still have a penalty of two calls with the same
>> params, and the function called for < does very likely know the answer for
>> the full question anyway, just can't tell us.
>> If we come to compare composite objects, implemented by comparing the
>> subkeys one by one until decision is reached, that can be a serious
>penalty,
>> and if we need a sorting or seeking code we face this.
>
>More generally, what you want is something like the Lisp "cond" construct.

I don't think he wants this.  He doesn't want to have to repeat the
parameters redundantly, or make multiple calls (first checking ==, then
checking <).  "cond" does nothing that the above if/else if/else doesn't
do.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <slrn908s9f.t1a.qrczak@qrnik.knm.org.pl>,
  qrczak@knm.org.pl (Marcin 'Qrczak' Kowalczyk) wrote:
> Thu,  2 Nov 2000 18:46:06 GMT, Balog Pal (mh) <pasa@lib.hu> pisze:

> > Suppose the language had that operator, we'd have much less job,
> > and clearer code. Certainly it would be predefined for all builtin
> > types, and overloadable for UDT's.

> I agree that the three-way comparison is useful. But why operator
> and not a function? Some languages call it 'compare'.

Not a language standard, but my classes regularly implement compare
(to return an int <, == or > 0).  I then define the operators (<,
<=...) using this function.


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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3A046701.78BBC65F@jps.net>,
  Dennis Yelle <dennis51@jps.net> wrote:

> Personally I think swap is the most important missing operator.
> Perhaps it could be spelled :=: and a default operator:=:() defined
> by the compiler for any class if omitted by the programmer.

Since we are talking about things that will never be, why not do it
right, and insist on multiple assignment, so that swap can be simply
written:
    x, y = y, x ;

This is actually simple and elegant for many things, and can be
implemented quite efficiently for the most common cases.  It also
doesn't fit in any way, shape, form or fashion into today's C++.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Ivan Vecerina" <ivec@surgnav.com> wrote in message
news:8u2pu8$ea6$1@news1.urbanet.ch...
> Dennis Yelle said:
> >
> >Personally I think swap is the most important missing operator.
> >Perhaps it could be spelled :=: and a default operator:=:()
> >defined by the compiler for any class if omitted by the programmer.
>
> There are others 'most important missing operators', including
> min and max that already made it as extensions in some compilers.

The difference is that a compiler-generated swap() would be fine in 98% of
the cases. The other compiler-generated operators have much lower "success
rate."

> ( I think that gcc(?) defines something like <? and >? ops ).
> And personally, I would use <-> for the swap operation ;)

There's nothing wrong with std::swap as a name.

--
Peter Dimov
Multi Media Ltd.


---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Peter Dimov wrote:
>
> "Ivan Vecerina" <ivec@surgnav.com> wrote in message
> news:8u2pu8$ea6$1@news1.urbanet.ch...
> > Dennis Yelle said:
> > >
> > >Personally I think swap is the most important missing operator.
> > >Perhaps it could be spelled :=: and a default operator:=:()
> > >defined by the compiler for any class if omitted by the programmer.
> >
> > There are others 'most important missing operators', including
> > min and max that already made it as extensions in some compilers.
>
> The difference is that a compiler-generated swap() would be fine in 98% of
> the cases. The other compiler-generated operators have much lower "success
> rate."

I guess I forgot to say that a compiler generated swap would normally
never throw.  But that is not true for the current std::swap.
You can only write a non-throwing swap if you have a non-throwing swap
for all member classes.  The net result of my proposal would be a compiler
generated non-throwing swap for almost every class.  While today
it is impossible to write a non-throwing swap for a class that includes
a class that fails to provide a non-throwing swap.

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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

For bools, chars, ints, floats, doubles,and pointers, C++ already has such
an operator and it is called operator-(). If you want to do something
similar for your own classes, then you could use either operator-() or just
choose an ordinary function name. I personally don't need something like
operator<=>(), though it may be convenient for others.

Balog Pal (mh) <pasa@lib.hu> wrote in message
news:3a01b5eb@andromeda.datanet.hu...
> The current C++ has only 2-state compare operators. However in certain
> situations you need a 3-state one, like memcmp() and its brothers.
> So you end up with code like:
>
> if (A == B)
>     return EQUAL;
> else if (A < B)
>     return LESS;
> else
>     return GREATER;
>
> The little problem of keeping the 2 ifs consistent is easily covered by
> using a template. But we still have a penalty of two calls with the same
> params, and the function called for < does very likely know the answer for
> the full question anyway, just can't tell us.
> If we come to compare composite objects, implemented by comparing the
> subkeys one by one until decision is reached, that can be a serious
penalty,
> and if we need a sorting or seeking code we face this.
>
> Suppose the language had that operator, we'd have much less job, and
clearer
> code. Certainly it would be predefined for all builtin types, and
> overloadable for UDT's. I also think many people would rewrite his
existing
> compare operator overload functions, like
>
> bool operator <(const T& That)const  { return (*this <=> That) < 0; }
> bool operator <=(const T& That)const  { return (*this <=> That) <= 0; }
> and so on.
>
> (Certainly a healthy mark should be selected.)
>
> Paul
>
>
>
> ---
> [ 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                ]
> [ Note that the FAQ URL has changed!  Please update your bookmarks.     ]
>


---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Gary Hinger wrote:
>
> For bools, chars, ints, floats, doubles,and pointers, C++ already has such
> an operator and it is called operator-().

No, actually operator-() does not work that way
in the case of integer overflow.  If both of
the operands are random, overflow will happen
about 25% of the time.  It is necessary to introduce
a new operator to do what he wants to do.
Perl, for example, has the operator <=> which returns
-1, 0, or +1 for less, equal, or greater.

> If you want to do something
> similar for your own classes, then you could use either operator-() or just
> choose an ordinary function name. I personally don't need something like
> operator<=>(), though it may be convenient for others.
>
> Balog Pal (mh) <pasa@lib.hu> wrote in message
> news:3a01b5eb@andromeda.datanet.hu...
> > The current C++ has only 2-state compare operators. However in certain
> > situations you need a 3-state one, like memcmp() and its brothers.
> > So you end up with code like:
> >
> > if (A == B)
> >     return EQUAL;
> > else if (A < B)
> >     return LESS;
> > else
> >     return GREATER;
> >
> > The little problem of keeping the 2 ifs consistent is easily covered by
> > using a template. But we still have a penalty of two calls with the same
> > params, and the function called for < does very likely know the answer for
> > the full question anyway, just can't tell us.
> > If we come to compare composite objects, implemented by comparing the
> > subkeys one by one until decision is reached, that can be a serious
> penalty,
> > and if we need a sorting or seeking code we face this.
> >
> > Suppose the language had that operator, we'd have much less job, and
> clearer
> > code. Certainly it would be predefined for all builtin types, and
> > overloadable for UDT's. I also think many people would rewrite his
> existing
> > compare operator overload functions, like
> >
> > bool operator <(const T& That)const  { return (*this <=> That) < 0; }
> > bool operator <=(const T& That)const  { return (*this <=> That) <= 0; }
> > and so on.
> >
> > (Certainly a healthy mark should be selected.)
> >
> > Paul

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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a01ebb9_1@news.nwlink.com>,
  "Gary Hinger" <garyh@zipperint.com> wrote:
> For bools, chars, ints, floats, doubles,and pointers, C++ already has
such
> an operator and it is called operator-().

You mean kind of like:

int x = INT_MAX;
int y = INT_MIN;

int d = x - y;

if (d < 0) printf("INT_MAX < INT_MIN!");

-------------
Mark Williams


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://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

In article <3a01ebb9_1@news.nwlink.com>, "Gary Hinger"
<garyh@zipperint.com> wrote:

> For bools, chars, ints, floats, doubles,and pointers, C++ already has such
> an operator and it is called operator-().

I hope you will never compare INT_MAX and INT_MIN. And I think you will
find that 10u - 20u > 0.

> If you want to do something
> similar for your own classes, then you could use either operator-() or just
> choose an ordinary function name. I personally don't need something like
> operator<=>(), though it may be convenient for others.

---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

The current C++ has only 2-state compare operators. However in certain
situations you need a 3-state one, like memcmp() and its brothers.
So you end up with code like:

if (A == B)
    return EQUAL;
else if (A < B)
    return LESS;
else
    return GREATER;

The little problem of keeping the 2 ifs consistent is easily covered by
using a template. But we still have a penalty of two calls with the same
params, and the function called for < does very likely know the answer for
the full question anyway, just can't tell us.
If we come to compare composite objects, implemented by comparing the
subkeys one by one until decision is reached, that can be a serious penalty,
and if we need a sorting or seeking code we face this.

Suppose the language had that operator, we'd have much less job, and clearer
code. Certainly it would be predefined for all builtin types, and
overloadable for UDT's. I also think many people would rewrite his existing
compare operator overload functions, like

bool operator <(const T& That)const  { return (*this <=> That) < 0; }
bool operator <=(const T& That)const  { return (*this <=> That) <= 0; }
and so on.

(Certainly a healthy mark should be selected.)

Paul



---
[ 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                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]