View mode: basic / threaded / horizontal-split · Log in · Help
May 19, 2003
Re: null == o?
"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.

> The inability to make free operators is really limiting.  It means you
can't
> make operator overloads unless you have full control to the source of at
> least one of the classes involved, but in many cases you may not own
either
> of the classes but may still want to provide an overloaded operator for
some
> reason. (What if someone invents a cool STL trick that works like that, in
> the future...?  C++ will be able to do it, D won't.)  There doesn't seem
to
> be any real reason why not, except that this way allows operators to be
> virtual, which I say is hogwash since you could always define your
operator
> to call a virtual method of the class itself if you choose to.

I don't like the C++ approach because:

1) its inherent asymmetry in how you do (a op b) versus (b op a).
2) its ability to produce operator overloads that have bizarrely different
semantics with the operator, such as the iostream << and >>.
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.
4) I have difficulty seeing the merit in global operator overloads. To me,
they always looked like a hack because you couldn't do (b op a) with the
operator+ syntax.

Not that I have a strong opinion about it, or anything <g>.
May 19, 2003
Re: null == o?
"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); }

> > The inability to make free operators is really limiting.  It means you
> can't
> > make operator overloads unless you have full control to the source of at
> > least one of the classes involved, but in many cases you may not own
> either
> > of the classes but may still want to provide an overloaded operator for
> some
> > reason. (What if someone invents a cool STL trick that works like that,
in
> > the future...?  C++ will be able to do it, D won't.)  There doesn't seem
> to
> > be any real reason why not, except that this way allows operators to be
> > virtual, which I say is hogwash since you could always define your
> operator
> > to call a virtual method of the class itself if you choose to.
>
> I don't like the C++ approach because:
>
> 1) its inherent asymmetry in how you do (a op b) versus (b op a).

see above.

> 2) its ability to produce operator overloads that have bizarrely different
> semantics with the operator, such as the iostream << and >>.

This is a religious issue, which makes me think this will never be solved in
D to my liking.

> 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?

> 4) I have difficulty seeing the merit in global operator overloads. To me,
> they always looked like a hack because you couldn't do (b op a) with the
> operator+ syntax.

You've used that argument 3 times now.

> Not that I have a strong opinion about it, or anything <g>.

None of us do.  ;)

At first I was all about making my operators class members in C++, but
recently, a few months ago, I had a change of heart because I was writing
some math classes and it started getting really ugly when all operators were
members.  Particularly, it became problematic to decide which class the
operator should actually belong to.  In some cases, the choice seems
completely and totally arbitrary, which indicates to me that there is no
good reason to place the operator in either class, but that it should in
fact be global (ok, module) scope.

My code got alot easier to read after that.  Well, that's good enough
argument for me.

Sean
May 21, 2003
Re: null == o?
> Think OO people. I feel like changing to Sather.
>

Why should we think OO? One of the reasons that C++ is fantastic (and widely
used) is that it supports many different programming paradigms, and
prescribes none. In my opinion OO is *vastly* overrated. D has the potential
to leave .NET & Java in the dust by following C++'s lead in supporting
multiple paradigms. Frankly, if we're just going to go OO, then I cannot
think of a reason why I wouldn't just use C# - better IDDE, bigger
libraries, more likelihood of having your work accepted by commercial
clients blah, blah, blah.

Do not think OO!

Think, and support, whatever programming paradigm (or paradigms) suitable to
your programming task.
May 21, 2003
Re: null == o?
Couldn't agree more.


"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 inability to make free operators is really limiting.  It means you
can't
> make operator overloads unless you have full control to the source of at
> least one of the classes involved, but in many cases you may not own
either
> of the classes but may still want to provide an overloaded operator for
some
> reason. (What if someone invents a cool STL trick that works like that, in
> the future...?  C++ will be able to do it, D won't.)  There doesn't seem
to
> be any real reason why not, except that this way allows operators to be
> virtual, which I say is hogwash since you could always define your
operator
> to call a virtual method of the class itself if you choose to.
>
> Sean
>
> "Giancarlo Bellido" <vicentico1@hotmail.com> wrote in message
> news:ba6l78$1gro$1@digitaldaemon.com...
> > Personally, I think that operator overloading should be something like
in
> > C++.
> > why?? because it is nicer, easy to remember, and people reading the code
> > would know that it is actually an operator.
> >
> > another thing, there is no way to create operators outside the class,
like
> > you
> > do for the istream or ostream objects in c++.
> >
> > giancarlo
> >
> > "Ilya Minkov" <midiclub@8ung.at> wrote in message
> > news:ba5kre$e25$1@digitaldaemon.com...
> > > Walter wrote:
> > > > It might be a good idea to do an "op" prefix to all the operator
> > overloads.
> > >
> > > As you mention that... maybe.
> > >
> > > How about another prefix ("oprev"?), which would allow to reverse
> > > parameter order for infix operators? Then an operator resolver would
> > > have to look both in the "left" class (for "op...") as in the "right"
> > > one (for "oprev..."), and complain if there's a collision.
> > >
> > > The motivation for this would be the ability to add new "mathematic"
> > > classes to the hierarchy without having to resort to module-wide
> > > operator definitions, which are usually done in C++.
> > >
> > > -i.
>
>
May 21, 2003
Re: null == o?
I think the python style - widely recognised and greppable names - is
superior to the C++ one  - operator /+() ... - even though it is less terse.

One of the reasons for the C++ operator style was due to Bjarne Stroustrup's
desire/need to introduce as few keywords as possible, as he had to upset the
C community to the minimum degree in the early days of C++. (Consider = 0
for pure virtuals, class for typename in template parameter declarations,
etc. etc.)

Since D does not have these same constraints, let's do what's sensible both
for compiler writers and maintenance programmers. Unambiguous symbols rule
here.
May 21, 2003
Re: null == o?
"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.
>
> > The inability to make free operators is really limiting.  It means you
> can't
> > make operator overloads unless you have full control to the source of at
> > least one of the classes involved, but in many cases you may not own
> either
> > of the classes but may still want to provide an overloaded operator for
> some
> > reason. (What if someone invents a cool STL trick that works like that,
in
> > the future...?  C++ will be able to do it, D won't.)  There doesn't seem
> to
> > be any real reason why not, except that this way allows operators to be
> > virtual, which I say is hogwash since you could always define your
> operator
> > to call a virtual method of the class itself if you choose to.
>
> I don't like the C++ approach because:
>
> 1) its inherent asymmetry in how you do (a op b) versus (b op a).

Disagree. This in convenience is well worth the fact that operators are
free, rather than members

> 2) its ability to produce operator overloads that have bizarrely different
> semantics with the operator, such as the iostream << and >>.

Agree, MASSIVELY. Those chevrons and the iostreams are a wart and a curse

> 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.

Disagree, same reason as 1)

> 4) I have difficulty seeing the merit in global operator overloads. To me,
> they always looked like a hack because you couldn't do (b op a) with the
> operator+ syntax.

Nope. Very useful. Free functions rule

>
> Not that I have a strong opinion about it, or anything <g>.
>
>
May 22, 2003
Safer and easier enums?
From the specs:

>  Arrays that parallel an enum
>
>  The C Way
>  ---------
>
>  Consider:
>  
>         enum COLORS { red, blue, green, max }; 
>         char *cstring[max] = {"red", "blue", "green" }; 
>  
>  This is fairly easy to get right because the number of entries is
>  small. But suppose it gets to be fairly large. Then it can get
>  difficult to maintain correctly when new entries are added.
>
>  The D Way
>  ---------
>  
>    enum COLORS { red, blue, green }
>  
>      char cstring[COLORS.max + 1][] = 
>      [
>          COLORS.red   : "red",
>          COLORS.blue  : "blue", 
>          COLORS.green : "green",
>      ]; 
>  
>  Not perfect, but better.


Now, having:

enum COLORS { red, blue, green }

What if we implemented:

static char cstring[][] = COLORS;

as inserting the names as strings to the string array? They are, after all,
known at compile time?

Isn't this the most common idiom to use near the definition of enums? It might
be overkill to have the enum statement implicitly define a COLORS struct with
the strings defined, but isn't this common enough to deserve a special syntax,
like:

enum COLORS {red, blue, green} : string_access;

or

static class enum COLORS {red, blue, green};

but I really believe we ought to do something about it.

If not for else, the existing syntax requires the colors to be stated two times.
This is a c(++) like "catch", isn't it? With "300 items in the list, and
counting", it is a good bet that the enums and the strings will get out of sync
sooner or later.
May 22, 2003
Re: Safer and easier enums?
Georg Wrede wrote:
> 
> From the specs:
> 
> >  Arrays that parallel an enum
> >
> >  The C Way
> >  ---------
> >
> >  Consider:
> >
> >         enum COLORS { red, blue, green, max };
> >         char *cstring[max] = {"red", "blue", "green" };
> >
> >  This is fairly easy to get right because the number of entries is
> >  small. But suppose it gets to be fairly large. Then it can get
> >  difficult to maintain correctly when new entries are added.
> >
> >  The D Way
> >  ---------
> >
> >    enum COLORS { red, blue, green }
> >
> >      char cstring[COLORS.max + 1][] =
> >      [
> >          COLORS.red   : "red",
> >          COLORS.blue  : "blue",
> >          COLORS.green : "green",
> >      ];
> >
> >  Not perfect, but better.
> 
> Now, having:
> 
> enum COLORS { red, blue, green }
> 
> What if we implemented:
> 
> static char cstring[][] = COLORS;
> 
> as inserting the names as strings to the string array? They are, after all,
> known at compile time?
> 
> Isn't this the most common idiom to use near the definition of enums? It might
> be overkill to have the enum statement implicitly define a COLORS struct with
> the strings defined, but isn't this common enough to deserve a special syntax,
> like:
> 
> enum COLORS {red, blue, green} : string_access;
> 
> or
> 
> static class enum COLORS {red, blue, green};
> 
> but I really believe we ought to do something about it.
> 
> If not for else, the existing syntax requires the colors to be stated two times.
> This is a c(++) like "catch", isn't it? With "300 items in the list, and
> counting", it is a good bet that the enums and the strings will get out of sync
> sooner or later.

Wouldn't it be nicer to have an enum property .hash returning a constant 
assoziative array allowing the efficient lookup of enum string values:

  enum COLORS {red, blue, green};
  COLORS col;

  int [char[]] enumhash;
  enumhash=col.hash;
  enumhash=COLORS.hash;

  int val;
  val=enumhash["red"];
  val=COLORS.hash["red"];
  val=col.hash["red"];

--
Helmut Leitner    leitner@hls.via.at   
Graz, Austria   www.hls-software.com
May 22, 2003
Re: Safer and easier enums?
Simply have .toString() propertys on enum members.  If they are never used,
the linker can strip their string tables out.

Sean

"Georg Wrede" <Georg_member@pathlink.com> wrote in message
news:bah62i$gpb$1@digitaldaemon.com...
> From the specs:
>
> >  Arrays that parallel an enum
> >
> >  The C Way
> >  ---------
> >
> >  Consider:
> >
> >         enum COLORS { red, blue, green, max };
> >         char *cstring[max] = {"red", "blue", "green" };
> >
> >  This is fairly easy to get right because the number of entries is
> >  small. But suppose it gets to be fairly large. Then it can get
> >  difficult to maintain correctly when new entries are added.
> >
> >  The D Way
> >  ---------
> >
> >    enum COLORS { red, blue, green }
> >
> >      char cstring[COLORS.max + 1][] =
> >      [
> >          COLORS.red   : "red",
> >          COLORS.blue  : "blue",
> >          COLORS.green : "green",
> >      ];
> >
> >  Not perfect, but better.
>
>
> Now, having:
>
> enum COLORS { red, blue, green }
>
> What if we implemented:
>
> static char cstring[][] = COLORS;
>
> as inserting the names as strings to the string array? They are, after
all,
> known at compile time?
>
> Isn't this the most common idiom to use near the definition of enums? It
might
> be overkill to have the enum statement implicitly define a COLORS struct
with
> the strings defined, but isn't this common enough to deserve a special
syntax,
> like:
>
> enum COLORS {red, blue, green} : string_access;
>
> or
>
> static class enum COLORS {red, blue, green};
>
> but I really believe we ought to do something about it.
>
> If not for else, the existing syntax requires the colors to be stated two
times.
> This is a c(++) like "catch", isn't it? With "300 items in the list, and
> counting", it is a good bet that the enums and the strings will get out of
sync
> sooner or later.
>
>
>
May 29, 2003
Re: null == o?
"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.


> > 2) its ability to produce operator overloads that have bizarrely
different
> > semantics with the operator, such as the iostream << and >>.
> This is a religious issue, which makes me think this will never be solved
in
> D to my liking.

Perhaps.

> > 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.


> > Not that I have a strong opinion about it, or anything <g>.
> None of us do.  ;)

<g>
4 5 6 7 8 9
Top | Discussion index | About this forum | D home