View mode: basic / threaded / horizontal-split · Log in · Help
May 29, 2003
Re: loose operators (was: null == o?)
"Walter" <walter@digitalmars.com> wrote in message
news:bb46ij$2nd9$1@digitaldaemon.com...
>
> "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message
> news:ba9vfv$e61$1@digitaldaemon.com...
> > "Walter" <walter@digitalmars.com> wrote in message
> > news:ba9i5m$2l4g$2@digitaldaemon.com...
> > > "Sean L. Palmer" <palmer.sean@verizon.net> wrote in message
> > > news:ba7jsb$2kdn$1@digitaldaemon.com...
> > > > I agree.  I like C++ operator overloading better.  It bugs me that
if
> I
> > > want
> > > > a '+' I have to type 'add';  I really cannot see the problem with a
> > > WYSIWYG
> > > > system.  It's not that much more work in the parser, is it?
> > > The problem comes with the reverse operators, such as divr.
> > What problem?
> > float operator-(int a, float b) { return float(a) - b; }
> > float operator-(float a, int b) { return a - float(b); }
>
> That doesn't work if you want to make them virtual.

What if I don't care if they're virtual?  Besides as has been pointed out
you can still chain to a virtual member function if you want that.

> > > 3) you need to write, in general, twice as much code in C++ to define
a
> > new
> > > class with operators than you do in D.
> > Example?
>
> In C++, you have to overload both == and !=. In D, one overload handles
> both. The same for commutative operators - in D, just do one of them, in
> C++, you must do both. Things are even more wordy in C++ if you want to do
> <, <=, >, >=. You frequently have to write 8 functions in C++, in D just
> one.

What does this have to do with the operator being a member function or not?
In fact what does it have to do with the naming scheme?  You could easily
make default operators in C++;  Boost even does it within the existing
language.

I don't understand the current stance on prohibition of nonmember operators.
I don't see any good reasoning for it.  But there are good reasons why
people want loose operators.  Often the operation doesn't really "belong" in
either class.

Look at Java.  They made it so every function has to be a class member.  Now
people have to make classes they don't need.

At least let us inherit from basic types:

struct posint : public int
{
}

Sean
May 30, 2003
Re: loose operators (was: null == o?)
>
>I don't understand the current stance on prohibition of nonmember operators.
>I don't see any good reasoning for it.  But there are good reasons why
>people want loose operators.  Often the operation doesn't really "belong" in
>either class.
>
>Look at Java.  They made it so every function has to be a class member.  Now
>people have to make classes they don't need.

I agree, fake classes to "encapsulate" all functions like Java is bad.

Read
http://www.cuj.com/documents/s=8042/cuj0002meyers/
for a related idea
May 30, 2003
Re: loose operators (was: null == o?)
> I don't understand the current stance on prohibition of nonmember
operators.
> I don't see any good reasoning for it.

Agreed.

> But there are good reasons why
> people want loose operators.  Often the operation doesn't really "belong"
in
> either class.

Agreed.

> Look at Java.  They made it so every function has to be a class member.
Now
> people have to make classes they don't need.

Agreed.

So, in summary, agreed!
June 01, 2003
Re: loose operators (was: null == o?)
It seems like it would be a good idea to unify all function and method call
syntax.

But how?  Go back to C?  Occasionally it's kind of nice to know which
parameter is the "main" parameter (called this in C++). Several languages do
this, but I'm not sure how it works out because I haven't tried it recently.
This is how everything worked in C.

Maybe access control, in general, is bad.  Perhaps data and function hiding
should be done by some other mechanism, such as modules and scopes and
namespaces, and not so much by inheritance.

This is a fundamental issue, one that would drastically alter a language
design.

Sean

"Mark T" <Mark_member@pathlink.com> wrote in message
news:bb6817$20dc$1@digitaldaemon.com...
> >
> >I don't understand the current stance on prohibition of nonmember
operators.
> >I don't see any good reasoning for it.  But there are good reasons why
> >people want loose operators.  Often the operation doesn't really "belong"
in
> >either class.
> >
> >Look at Java.  They made it so every function has to be a class member.
Now
> >people have to make classes they don't need.
>
> I agree, fake classes to "encapsulate" all functions like Java is bad.
>
> Read
> http://www.cuj.com/documents/s=8042/cuj0002meyers/
> for a related idea
June 13, 2003
Re: null == o?
"Helmut Leitner" <helmut.leitner@chello.at> wrote in message
news:3E87DEA7.A5ABC430@chello.at...
> (3) Any crash is bad. If there is a sensible way to continue operation in
>     a situation we should take the chance to tolerate it. A "close" on a
file
>     that is not open - fine, lets go on. A free on some pointer that is
NULL
>     - whats the problem? An object that doesn't exist compared to null in
D -
>     well sure it should return "true". Nothing else would make more sense.

Crashes, sure. But what is happening here is an exception is thrown, not
necessarilly a crash. A null pointer reference throws an exception, which
can be caught like any other exception.

The philosophy in D is that errors should be reported by throwing
exceptions, not by returning error codes.

If there was any error in my program logic, I'd much rather have an
exception promptly thrown. That gives me the best opportunity to debug it,
or if I want something else to happen, I can catch that exception and
soldier on.

(I view a crash as more like the program corrupted its own data or the
operating system's. In MSDOS, a crash usually meant scrambling the entire
system. Hardware generated exceptions were a huge advance.)

So, think of (o==p) with objects as "Compare the contents of object o with
object p. If either is null, there are no contents, and that is outside the
scope of the == operator's purpose. Therefore, an exception is thrown just
as if an array bounds were exceeded. If the object references are not
supposed to be null, then it's a program bug. If the object references can
be null, then explicitly code what a null reference means."
Next ›   Last »
5 6 7 8 9
Top | Discussion index | About this forum | D home