May 19, 2003
"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
"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
> 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
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
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
"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
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

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