These are my 2 cents opinions:

1) Like most programming languages, D is missing a boolean exclusive-or
operator.
I can't count the number of times I had to write something like:
if ((cond1 && !cond2) || (!cond1 && cond2)) // bad if cond1 and/or cond2
have side effect
or
if ((cond1 != 0) ^ (cond2 != 0))
the "!= 0" above are required if cond1 or cond2 can be such that (cond1 &
cond2) == 0 but (cond1 | cond2) != 0, like cond1==2 and cond2==4.
I don't use this kind of condition as often as simple || and && but often
enough to be realy anoyed.

Pppllllease, add a ^^ boolean exclusive-or operator !

2) I think that mostly, a real intrisic bool type (and requiring bool arguments to if, while, &&, ||, ^^, !...) is a good thing and protect against lots of hard to catch errors. After all, D documentation says:
>Who D is For
>Programmers who routinely use lint or similar code analysis tools to
eliminate bugs before the code is even compiled.
And declaring a variable as bool instead of int is better for code
documentation.
Perhaps a compiler option to allow/prevent automatic convertion to bool in
conditionals should be the best option to satisfy everybody.

3) I also add my support for operator overloading. I agree that it can be abused  (you can find abuses of any programming language feature) but in some cases, it can be used in a very nice and readable way. If you think it's just good for complex numbers, look at http://spirit.sourceforge.net/ for an example of a clean, usefull and nice operator overloading usage with templates: you get lex+yacc capabilities directly within C++ source, an EBNF-like notation (with overloaded C++ operators) constructing a parser during object construction, the constructed variables becoming the automaton of the parser.

Simple calculator example:
    rule<>  expr;
    rule<>  integer = lexeme[ (!(ch_p('+') | '-') >> +digit)[&doInt] ];
    rule<>  group   = '(' >> expr >> ')';
    rule<>  expr1   = integer | group;
    rule<>  expr2   = expr1 >> *(('*' >> expr1)[&doMult] | ('/' >>
expr1)[&doDiv]);
    expr            = expr2 >> *(('+' >> expr2)[&doAdd] | ('-' >>
expr2)[&doSubt]);
The >> is a sequence, !, * and + (with a single argument on the right) are
the 0-or-1, 0-or-more and 1-or-more repetitions, the actions are in the []
(functions with  pointers to the first and last elements parsed by the rule)
and | is an alternative. Execution of a rule returns the number of elements
matched. The ch_p('+') is there because '+' | '-' can't use the overloaded
|. digit is a predifined single digit parser, doInt, doAdd... are some
simple action functions not included here.
Then you just do something like:
parse(expr, "1 + ((6 * 200) - 20) / 6");

4) Perhaps also add non-vitual member functions to struct to be able to handle light/simple objects on the stack or embeded inside other struct/class (for allocation speed). This is what's done in the .NET framework and I think it's also a proposed extension for Java. It can help to prevent too much heap fragmentation with lot of tiny memory blocks.

Other than that, D seems like a great and well designed language with mostly reasonable compromises. It removes most of the things I hated in C++ like pre-processor, completely useless . -> and :: separation, forward declarations, #include (parse these headers again and again and again... or struggle with restricted precompiled headers), ambiguous syntax depending on the nature of a symbol like (type)-1 instead or (var)-1 and last but not least, added missing language supported safe garbage collection (=>full RTTI) and class properties (exist only as non-portable extensions in Borland C++ Builder and MSVC).

"Christophe Bouchon" <cbouchon@hotmail.com> wrote in message news:a2ensl$2uac$1@digitaldaemon.com...
> These are my 2 cents opinions:
>
> 1) Like most programming languages, D is missing a boolean exclusive-or
> operator.
> I can't count the number of times I had to write something like:
> if ((cond1 && !cond2) || (!cond1 && cond2)) // bad if cond1 and/or cond2
> have side effect
> or
> if ((cond1 != 0) ^ (cond2 != 0))
> the "!= 0" above are required if cond1 or cond2 can be such that (cond1 &
> cond2) == 0 but (cond1 | cond2) != 0, like cond1==2 and cond2==4.
> I don't use this kind of condition as often as simple || and && but often
> enough to be realy anoyed.
>
> Pppllllease, add a ^^ boolean exclusive-or operator !

C (and C++ and Java and D) already *have* a boolean exclusive-or operator...
it's " != "  !!!   :)

if ((cond1 != 0) != (cond2 != 0))

> 2) I think that mostly, a real intrisic bool type (and requiring bool arguments to if, while, &&, ||, ^^, !...) is a good thing and protect against lots of hard to catch errors. After all, D documentation says:
> >Who D is For
> >Programmers who routinely use lint or similar code analysis tools to
> eliminate bugs before the code is even compiled.
> And declaring a variable as bool instead of int is better for code
> documentation.
> Perhaps a compiler option to allow/prevent automatic convertion to bool in
> conditionals should be the best option to satisfy everybody.

I sit on the fence on this issue.  I don't really have a preference.

> 3) I also add my support for operator overloading. I agree that it can be abused  (you can find abuses of any programming language feature) but in some cases, it can be used in a very nice and readable way. If you think it's just good for complex numbers, look at http://spirit.sourceforge.net/ for an example of a clean, usefull and nice operator overloading usage
with
> templates: you get lex+yacc capabilities directly within C++ source, an EBNF-like notation (with overloaded C++ operators) constructing a parser during object construction, the constructed variables becoming the
automaton
> of the parser.
>
> Simple calculator example:
>     rule<>  expr;
>     rule<>  integer = lexeme[ (!(ch_p('+') | '-') >> +digit)[&doInt] ];
>     rule<>  group   = '(' >> expr >> ')';
>     rule<>  expr1   = integer | group;
>     rule<>  expr2   = expr1 >> *(('*' >> expr1)[&doMult] | ('/' >>
> expr1)[&doDiv]);
>     expr            = expr2 >> *(('+' >> expr2)[&doAdd] | ('-' >>
> expr2)[&doSubt]);
> The >> is a sequence, !, * and + (with a single argument on the right) are
> the 0-or-1, 0-or-more and 1-or-more repetitions, the actions are in the []
> (functions with  pointers to the first and last elements parsed by the
rule)
> and | is an alternative. Execution of a rule returns the number of
elements
> matched. The ch_p('+') is there because '+' | '-' can't use the overloaded
> |. digit is a predifined single digit parser, doInt, doAdd... are some
> simple action functions not included here.
> Then you just do something like:
> parse(expr, "1 + ((6 * 200) - 20) / 6");

Sounds very cool.  I love operator overloading... many many cases functional notation just makes the code uglier.  Sure operator overloading can be abused,  but as you show above it can also be a powerful tool.

> 4) Perhaps also add non-vitual member functions to struct to be able to handle light/simple objects on the stack or embeded inside other struct/class (for allocation speed). This is what's done in the .NET framework and I think it's also a proposed extension for Java. It can help to prevent too much heap fragmentation with lot of tiny memory blocks.

I'm for that.

> Other than that, D seems like a great and well designed language with
mostly
> reasonable compromises. It removes most of the things I hated in C++ like pre-processor, completely useless . -> and :: separation, forward declarations, #include (parse these headers again and again and again...
or
> struggle with restricted precompiled headers), ambiguous syntax depending
on
> the nature of a symbol like (type)-1 instead or (var)-1 and last but not
> least, added missing language supported safe garbage collection (=>full
> RTTI) and class properties (exist only as non-portable extensions in
Borland
> C++ Builder and MSVC).

Yup.  Now if it just had operator overloading and generics and DFront I'd be all set to switch over.  ;)

Actually that's not true... until I can write extremely lightweight classes (like a replacement for int, or a 3d math library) or at least get builtin 3D math stuff, I won't be able to switch for performance reasons.

Sean

Real boolean type YES.
Operator Overloading NO!
rotate operators please.

although a boolean xor does not exists; you can do if ((x<8) ^ (y>9) ) or
use !=

I like Java's approach to booleans.
&& and || are boolean, and can be short cut by the comiler in the same way C
does
& | ^ can be boolean but both sides will be evaluated (xor has to eval both
sides)
and if and while should be if (boolean-expression) {..}
true this means that if ( a = b  ) has to become if ( (a=b) != 0 )
but a 5 extra chars for a lot of time saved finding bugs.
for the same reason I also like perls aproach to blocks
instead of
  if ( expr ) stmt [else stmt]
  if ( bool-expr ) block [elseif (bool-expr) block ][else block]
but that can wait for another day...

as for operator overloading, your example is to me the prime reason for NOT
having operator overloading, on the surface it looks like one thing but is
infact something else
if I want to write a parser, I'll use Lex/Yacc/ANTLR
I do not deny that operator overloading is powerfull, but it is not realy
required and I believe leads to more problem than it solves. in my
experiance I have rarely used it ( apart from << and >> on streams) but do
not consider that reason enough for it to be included in a language.

far more important would be rotate operators
all the CPU's I've every used have shift left and right (signed and
unsigned) and rotate left and right. why do no languages have rotate
operators. instead you have to unsigned shift left but N and shift right by
integer-bitlength-N.
and it can't be that only the minimum set of bitwise operator require are
available because then you would have rotate right (or left) and nand (or
nor) !
I have required rotate operations far more than operator overloading

Mike.


"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a2gikm$131g$1@digitaldaemon.com...
> "Christophe Bouchon" <cbouchon@hotmail.com> wrote in message news:a2ensl$2uac$1@digitaldaemon.com...
> > These are my 2 cents opinions:
> >
> > 1) Like most programming languages, D is missing a boolean exclusive-or
> > operator.
> > I can't count the number of times I had to write something like:
> > if ((cond1 && !cond2) || (!cond1 && cond2)) // bad if cond1 and/or cond2
> > have side effect
> > or
> > if ((cond1 != 0) ^ (cond2 != 0))
> > the "!= 0" above are required if cond1 or cond2 can be such that (cond1
&
> > cond2) == 0 but (cond1 | cond2) != 0, like cond1==2 and cond2==4.
> > I don't use this kind of condition as often as simple || and && but
often
> > enough to be realy anoyed.
> >
> > Pppllllease, add a ^^ boolean exclusive-or operator !
>
> C (and C++ and Java and D) already *have* a boolean exclusive-or
operator...
> it's " != "  !!!   :)
>
> if ((cond1 != 0) != (cond2 != 0))
>
> > 2) I think that mostly, a real intrisic bool type (and requiring bool arguments to if, while, &&, ||, ^^, !...) is a good thing and protect against lots of hard to catch errors. After all, D documentation says:
> > >Who D is For
> > >Programmers who routinely use lint or similar code analysis tools to
> > eliminate bugs before the code is even compiled.
> > And declaring a variable as bool instead of int is better for code
> > documentation.
> > Perhaps a compiler option to allow/prevent automatic convertion to bool
in
> > conditionals should be the best option to satisfy everybody.
>
> I sit on the fence on this issue.  I don't really have a preference.
>
> > 3) I also add my support for operator overloading. I agree that it can
be
> > abused  (you can find abuses of any programming language feature) but in some cases, it can be used in a very nice and readable way. If you think it's just good for complex numbers, look at
http://spirit.sourceforge.net/
> > for an example of a clean, usefull and nice operator overloading usage
> with
> > templates: you get lex+yacc capabilities directly within C++ source, an EBNF-like notation (with overloaded C++ operators) constructing a parser during object construction, the constructed variables becoming the
> automaton
> > of the parser.
> >
> > Simple calculator example:
> >     rule<>  expr;
> >     rule<>  integer = lexeme[ (!(ch_p('+') | '-') >> +digit)[&doInt] ];
> >     rule<>  group   = '(' >> expr >> ')';
> >     rule<>  expr1   = integer | group;
> >     rule<>  expr2   = expr1 >> *(('*' >> expr1)[&doMult] | ('/' >>
> > expr1)[&doDiv]);
> >     expr            = expr2 >> *(('+' >> expr2)[&doAdd] | ('-' >>
> > expr2)[&doSubt]);
> > The >> is a sequence, !, * and + (with a single argument on the right)
are
> > the 0-or-1, 0-or-more and 1-or-more repetitions, the actions are in the
[]
> > (functions with  pointers to the first and last elements parsed by the
> rule)
> > and | is an alternative. Execution of a rule returns the number of
> elements
> > matched. The ch_p('+') is there because '+' | '-' can't use the
overloaded
> > |. digit is a predifined single digit parser, doInt, doAdd... are some
> > simple action functions not included here.
> > Then you just do something like:
> > parse(expr, "1 + ((6 * 200) - 20) / 6");
>
> Sounds very cool.  I love operator overloading... many many cases
functional
> notation just makes the code uglier.  Sure operator overloading can be abused,  but as you show above it can also be a powerful tool.
>
> > 4) Perhaps also add non-vitual member functions to struct to be able to handle light/simple objects on the stack or embeded inside other struct/class (for allocation speed). This is what's done in the .NET framework and I think it's also a proposed extension for Java. It can
help
> > to prevent too much heap fragmentation with lot of tiny memory blocks.
>
> I'm for that.
>
> > Other than that, D seems like a great and well designed language with
> mostly
> > reasonable compromises. It removes most of the things I hated in C++
like
> > pre-processor, completely useless . -> and :: separation, forward declarations, #include (parse these headers again and again and again...
> or
> > struggle with restricted precompiled headers), ambiguous syntax
depending
> on
> > the nature of a symbol like (type)-1 instead or (var)-1 and last but not
> > least, added missing language supported safe garbage collection (=>full
> > RTTI) and class properties (exist only as non-portable extensions in
> Borland
> > C++ Builder and MSVC).
>
> Yup.  Now if it just had operator overloading and generics and DFront I'd
be
> all set to switch over.  ;)
>
> Actually that's not true... until I can write extremely lightweight
classes
> (like a replacement for int, or a 3d math library) or at least get builtin 3D math stuff, I won't be able to switch for performance reasons.
>
> Sean
>
>
>
>

It's funny how all the folks who "have rarely used it" are the most voiceful critics of operator overloading.  Probably the same goes for templates.

If you guys actually used this stuff for anything you'd realize that it is *very* nice to have.

Since you don't personally use it you think that nobody else does either.

If you had operator overloading (especially the kind where you could make up new operators, not just overload existing ones) you could make your own damn rotate operator.  ;)  Think about that for a while.

You can't go asking the language designer to add every little thing you want to the language spec.  That's why operator overloading and templates are nice, you can kinda "extend" the language to suit your needs.

Sean

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:a2h3ii$1e0p$1@digitaldaemon.com...
> Real boolean type YES.
> Operator Overloading NO!
> rotate operators please.
>
> although a boolean xor does not exists; you can do if ((x<8) ^ (y>9) ) or
> use !=
>
> I like Java's approach to booleans.
> && and || are boolean, and can be short cut by the comiler in the same way
C
> does
> & | ^ can be boolean but both sides will be evaluated (xor has to eval
both
> sides)
> and if and while should be if (boolean-expression) {..}
> true this means that if ( a = b  ) has to become if ( (a=b) != 0 )
> but a 5 extra chars for a lot of time saved finding bugs.
> for the same reason I also like perls aproach to blocks
> instead of
>   if ( expr ) stmt [else stmt]
>   if ( bool-expr ) block [elseif (bool-expr) block ][else block]
> but that can wait for another day...
>
> as for operator overloading, your example is to me the prime reason for
NOT
> having operator overloading, on the surface it looks like one thing but is
> infact something else
> if I want to write a parser, I'll use Lex/Yacc/ANTLR
> I do not deny that operator overloading is powerfull, but it is not realy
> required and I believe leads to more problem than it solves. in my
> experiance I have rarely used it ( apart from << and >> on streams) but do
> not consider that reason enough for it to be included in a language.
>
> far more important would be rotate operators
> all the CPU's I've every used have shift left and right (signed and
> unsigned) and rotate left and right. why do no languages have rotate
> operators. instead you have to unsigned shift left but N and shift right
by
> integer-bitlength-N.
> and it can't be that only the minimum set of bitwise operator require are
> available because then you would have rotate right (or left) and nand (or
> nor) !
> I have required rotate operations far more than operator overloading
>
> Mike.
>
>
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a2gikm$131g$1@digitaldaemon.com...
> > "Christophe Bouchon" <cbouchon@hotmail.com> wrote in message news:a2ensl$2uac$1@digitaldaemon.com...
> > > These are my 2 cents opinions:
> > >
> > > 1) Like most programming languages, D is missing a boolean
exclusive-or
> > > operator.
> > > I can't count the number of times I had to write something like:
> > > if ((cond1 && !cond2) || (!cond1 && cond2)) // bad if cond1 and/or
cond2
> > > have side effect
> > > or
> > > if ((cond1 != 0) ^ (cond2 != 0))
> > > the "!= 0" above are required if cond1 or cond2 can be such that
(cond1
> &
> > > cond2) == 0 but (cond1 | cond2) != 0, like cond1==2 and cond2==4.
> > > I don't use this kind of condition as often as simple || and && but
> often
> > > enough to be realy anoyed.
> > >
> > > Pppllllease, add a ^^ boolean exclusive-or operator !
> >
> > C (and C++ and Java and D) already *have* a boolean exclusive-or
> operator...
> > it's " != "  !!!   :)
> >
> > if ((cond1 != 0) != (cond2 != 0))
> >
> > > 2) I think that mostly, a real intrisic bool type (and requiring bool arguments to if, while, &&, ||, ^^, !...) is a good thing and protect against lots of hard to catch errors. After all, D documentation says:
> > > >Who D is For
> > > >Programmers who routinely use lint or similar code analysis tools to
> > > eliminate bugs before the code is even compiled.
> > > And declaring a variable as bool instead of int is better for code
> > > documentation.
> > > Perhaps a compiler option to allow/prevent automatic convertion to
bool
> in
> > > conditionals should be the best option to satisfy everybody.
> >
> > I sit on the fence on this issue.  I don't really have a preference.
> >
> > > 3) I also add my support for operator overloading. I agree that it can
> be
> > > abused  (you can find abuses of any programming language feature) but
in
> > > some cases, it can be used in a very nice and readable way. If you
think
> > > it's just good for complex numbers, look at
> http://spirit.sourceforge.net/
> > > for an example of a clean, usefull and nice operator overloading usage
> > with
> > > templates: you get lex+yacc capabilities directly within C++ source,
an
> > > EBNF-like notation (with overloaded C++ operators) constructing a
parser
> > > during object construction, the constructed variables becoming the
> > automaton
> > > of the parser.
> > >
> > > Simple calculator example:
> > >     rule<>  expr;
> > >     rule<>  integer = lexeme[ (!(ch_p('+') | '-') >>
+digit)[&doInt] ];
> > >     rule<>  group   = '(' >> expr >> ')';
> > >     rule<>  expr1   = integer | group;
> > >     rule<>  expr2   = expr1 >> *(('*' >> expr1)[&doMult] | ('/' >>
> > > expr1)[&doDiv]);
> > >     expr            = expr2 >> *(('+' >> expr2)[&doAdd] | ('-' >>
> > > expr2)[&doSubt]);
> > > The >> is a sequence, !, * and + (with a single argument on the right)
> are
> > > the 0-or-1, 0-or-more and 1-or-more repetitions, the actions are in
the
> []
> > > (functions with  pointers to the first and last elements parsed by the
> > rule)
> > > and | is an alternative. Execution of a rule returns the number of
> > elements
> > > matched. The ch_p('+') is there because '+' | '-' can't use the
> overloaded
> > > |. digit is a predifined single digit parser, doInt, doAdd... are some
> > > simple action functions not included here.
> > > Then you just do something like:
> > > parse(expr, "1 + ((6 * 200) - 20) / 6");
> >
> > Sounds very cool.  I love operator overloading... many many cases
> functional
> > notation just makes the code uglier.  Sure operator overloading can be abused,  but as you show above it can also be a powerful tool.
> >
> > > 4) Perhaps also add non-vitual member functions to struct to be able
to
> > > handle light/simple objects on the stack or embeded inside other struct/class (for allocation speed). This is what's done in the .NET framework and I think it's also a proposed extension for Java. It can
> help
> > > to prevent too much heap fragmentation with lot of tiny memory blocks.
> >
> > I'm for that.
> >
> > > Other than that, D seems like a great and well designed language with
> > mostly
> > > reasonable compromises. It removes most of the things I hated in C++
> like
> > > pre-processor, completely useless . -> and :: separation, forward declarations, #include (parse these headers again and again and
again...
> > or
> > > struggle with restricted precompiled headers), ambiguous syntax
> depending
> > on
> > > the nature of a symbol like (type)-1 instead or (var)-1 and last but
not
> > > least, added missing language supported safe garbage collection
(=>full
> > > RTTI) and class properties (exist only as non-portable extensions in
> > Borland
> > > C++ Builder and MSVC).
> >
> > Yup.  Now if it just had operator overloading and generics and DFront
I'd
> be
> > all set to switch over.  ;)
> >
> > Actually that's not true... until I can write extremely lightweight
> classes
> > (like a replacement for int, or a 3d math library) or at least get
builtin
> > 3D math stuff, I won't be able to switch for performance reasons.
> >
> > Sean
> >
> >
> >
> >
>
>

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a2hn3d$1rkp$1@digitaldaemon.com...
> It's funny how all the folks who "have rarely used it" are the most
voiceful
> critics of operator overloading.  Probably the same goes for templates.

Of course, If you do not like it, you do not used it!

> If you guys actually used this stuff for anything you'd realize that it is *very* nice to have.
>
> Since you don't personally use it you think that nobody else does either.

No,  I know people who do, but I do not agree that it helps the program in
any way
it may help one programmer, but it you are working on a project with several
people and as is often the case programs that where written by people who no
longer work for the company, code has to be readable to all so I don't use
it because as you say it enhances the language, but in ways that are not
always inline with the rest of the language.
I have worked for people who would have sacked me If I produced code like
your example.
I would read Walters explanation for not including operator overloading.

> If you had operator overloading (especially the kind where you could make
up
> new operators, not just overload existing ones) you could make your own
damn
> rotate operator.  ;)  Think about that for a while.


my point against overloading is that initial observation of the code make make someone else believe that you code does things that it is not.. and I want a rotate operator not a function masked behind syntax.

if I overload operator an to do a rotate I still have to use shift left and
right to perform the operation, just as I do with a rotate function it is
just syntatic sugar.
or use assembler and then it only works on one CPU.

> You can't go asking the language designer to add every little thing you
want
> to the language spec.  That's why operator overloading and templates are nice, you can kinda "extend" the language to suit your needs.

Templates I like, but again D supports Dynamic arrays and Hashtables, they could be implemented as template classes, but apart from collections, I have not seen templates used in commersial apps.

and I still stand by my initial observation that this example is exactly why operator overloading should not be included.

for us meer mortals, that have spent 2 years working on a project that ends up with a couple of megs of source, it's damn hard to remember what you wrote. So any features that help the confusion are avoided.

Mike.

> > > >
> > > > Simple calculator example:
> > > >     rule<>  expr;
> > > >     rule<>  integer = lexeme[ (!(ch_p('+') | '-') >>
> +digit)[&doInt] ];
> > > >     rule<>  group   = '(' >> expr >> ')';
> > > >     rule<>  expr1   = integer | group;
> > > >     rule<>  expr2   = expr1 >> *(('*' >> expr1)[&doMult] | ('/' >>
> > > > expr1)[&doDiv]);
> > > >     expr            = expr2 >> *(('+' >> expr2)[&doAdd] | ('-' >>
> > > > expr2)[&doSubt]);

"Mike Wynn" <mike.wynn@l8night.co.uk> wrote in message news:a2hsk0$1v0r$1@digitaldaemon.com...
>
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a2hn3d$1rkp$1@digitaldaemon.com...
> > It's funny how all the folks who "have rarely used it" are the most
> voiceful
> > critics of operator overloading.  Probably the same goes for templates.
>
> Of course, If you do not like it, you do not used it!
>
> > If you guys actually used this stuff for anything you'd realize that it
is
> > *very* nice to have.
> >
> > Since you don't personally use it you think that nobody else does
either.
>
> No,  I know people who do, but I do not agree that it helps the program in
> any way
> it may help one programmer, but it you are working on a project with
several
> people and as is often the case programs that where written by people who
no
> longer work for the company, code has to be readable to all so I don't use it because as you say it enhances the language, but in ways that are not always inline with the rest of the language.

People who cannot understand a section of code shouldn't be working on that section of code.  If they know enough to be able to justifiably critique such code, they are perfectly capable of replacing such code with something they can read easier.  Sometimes some readability has to be sacrificed for the sake of writability.  Tools like this make code easier to write.

> I have worked for people who would have sacked me If I produced code like your example.

Wasn't my example, but personally I think the Spirit parser generator is a wonderful example of the kinds of brilliant things people will figure out how to do given a set of powerful tools (templates + operator overloading). Sure, they're "abusing" the normal syntax of C++, but they get a working user-defined parser generated for them from nice easy EBNF-like notation by their humble C++ compiler.  ;)  Try doing anything close to that without using either templates or operator overloading, I'd love to see it.  Ask Walter what a recursive-descent parser written in straight C (or D) looks like, and how easy it is to maintain that kind of monster.  I think it's a very good trade-off, one I'd be willing to make.

If you think about it, even functions are merely a tool to help the programmer hide code that they aren't concerned with at the time.  You really don't *want* to see every little thing that's going on in your program, your brain would explode.  If you want that, you should program assembly.  Even assemblers use macros.

With operator overloading, at least you can step into the operator functions in the debugger if you so desire.  Or take a few seconds to hit "browse" on one of the variables to see where it's defined... that's a good idea anyway. Never assume types of variables without seeing their declarations.

> > If you had operator overloading (especially the kind where you could
make
> up
> > new operators, not just overload existing ones) you could make your own
> damn
> > rotate operator.  ;)  Think about that for a while.
>
>
> my point against overloading is that initial observation of the code make make someone else believe that you code does things that it is not.. and I want a rotate operator not a function masked behind syntax.
>
> if I overload operator an to do a rotate I still have to use shift left
and
> right to perform the operation, just as I do with a rotate function it is
> just syntatic sugar.
> or use assembler and then it only works on one CPU.

Not all CPUs even have a rotate instruction.  After that you'll be wanting a rotate with carry operator.  ;)  It's not often in a high level language you find yourself needing a rotate operator anyway.

> > You can't go asking the language designer to add every little thing you
want
> > to the language spec.  That's why operator overloading and templates are nice, you can kinda "extend" the language to suit your needs.
>
> Templates I like, but again D supports Dynamic arrays and Hashtables, they could be implemented as template classes, but apart from collections, I
have
> not seen templates used in commersial apps.

You haven't worked much, have you?

> and I still stand by my initial observation that this example is exactly
why
> operator overloading should not be included.
>
> for us meer mortals, that have spent 2 years working on a project that
ends
> up with a couple of megs of source, it's damn hard to remember what you wrote. So any features that help the confusion are avoided.

I feel your pain.

Sean

> Mike.
>
> > > > >
> > > > > Simple calculator example:
> > > > >     rule<>  expr;
> > > > >     rule<>  integer = lexeme[ (!(ch_p('+') | '-') >>
> > +digit)[&doInt] ];
> > > > >     rule<>  group   = '(' >> expr >> ')';
> > > > >     rule<>  expr1   = integer | group;
> > > > >     rule<>  expr2   = expr1 >> *(('*' >> expr1)[&doMult] | ('/' >>
> > > > > expr1)[&doDiv]);
> > > > >     expr            = expr2 >> *(('+' >> expr2)[&doAdd] | ('-' >>
> > > > > expr2)[&doSubt]);

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a2je9c$2v8i$1@digitaldaemon.com...
>
> People who cannot understand a section of code shouldn't be working on
that
> section of code.  If they know enough to be able to justifiably critique such code, they are perfectly capable of replacing such code with
something
> they can read easier.  Sometimes some readability has to be sacrificed for the sake of writability.  Tools like this make code easier to write.
>
No one understands fully a section of code someone else wrote the first time
they see it.
and I've not worked for a company that would allow such replacement without
good justification, and have work for one company where every line of code
written always had to be reviewed by someone else before you could submit it
into the source tree.
painfull at times, but did mean that more than one person could modify any
section.

> Wasn't my example, but personally I think the Spirit parser generator is a wonderful example of the kinds of brilliant things people will figure out how to do given a set of powerful tools (templates + operator
overloading).
> Sure, they're "abusing" the normal syntax of C++, but they get a working user-defined parser generated for them from nice easy EBNF-like notation
by
> their humble C++ compiler.  ;)  Try doing anything close to that without using either templates or operator overloading, I'd love to see it.  Ask Walter what a recursive-descent parser written in straight C (or D) looks like, and how easy it is to maintain that kind of monster.  I think it's a very good trade-off, one I'd be willing to make.
>
you yourself say 'they're "abusing" the normal syntax of C++' exactly my
reason for not liking operator overloading.
as I said, if you want to write a parser use Lex/Yacc
and I've written recursive-descent parsers in C, Delphi and Java by hand the
generated abstract syntax trees for interpreters but I prefered JavaCC and
Lex/Yacc (a lot more maintainable).

> If you think about it, even functions are merely a tool to help the programmer hide code that they aren't concerned with at the time.  You really don't *want* to see every little thing that's going on in your program, your brain would explode.  If you want that, you should program assembly.  Even assemblers use macros.

I've did some DOS real mode assembler mixed with C about 8 years ago,
Segmented memory near,far and huge pointers what fun,
and little MIPS and a bit or ARM/Thumb and some x86 Protected mode.

> With operator overloading, at least you can step into the operator
functions
> in the debugger if you so desire.  Or take a few seconds to hit "browse"
on
> one of the variables to see where it's defined... that's a good idea
anyway.
> Never assume types of variables without seeing their declarations.
>
you use VC++ then, give gdb a go (without ddd).
you should not have to run the debugger to know what a program is doing.

> You haven't worked much, have you?

anout 6 major projects in the last 8 years, all involving at least 2
languages
in C++, C or Java with bits of Perl and one with some PHP. on several
platforms and architectures.

I used mysql++ on one project, along side Perl/DBI and PHP, I was tempted to use Perl/TK instead as I did not find it actually improved anything, infact it just obscured what was going on. I wanted to create SQL statements and get data back, the only reason for not using the C Api is C's lask of dynamic strings and automatic resouce management.

and I think my adversion to operator overloading stems from the set of
languages that I have used at the same time, if you have to write a Java
program and read someone else Perl source to check you doing the right
thing, or MFC programs with Perl and PHP
it's nice if they look familiar. and having written two large applications
in Java going back to C++ felt realy odd, infact I started to perfer C, if
was going to have more control over what was going on I wanted full control.

As Walter said in the D overview, Apart from SmartPointers and Strings what do you use operator overloading for ?

I prefer to see
    myStream.ouput( MyObject );
 to myStream << MyObject;
Java StringBuffer class returns ref to itself
so you can do
   myBuffer.append( 'a' ).append('b');
much like
   myBuffer << 'a' << 'b';

I know the behaviour without having to look it up
if you overload operator = do you get a right associative operator I can't
find an answer to this in my C++ book.

and I consider "operator ++(int i){}"
a bodge.

and MyBuffer >> a >> b; can easily be misread
but MyBuffer.read( a ).read(b); can not.

give me an example where operator overloading in D would improve the
language
not just save a few chars or be a "cool" way of doing something
but improve the readablility, debugability, maintainability and reduce the
learning curve for new employees. things that are important to a company.
who are, from my experiance, anyways selling products where the ink is still
wet on the designs.

Mike.

>As Walter said in the D overview, Apart from SmartPointers and Strings what do you use operator overloading for ?
>
>I prefer to see
>    myStream.ouput( MyObject );
> to myStream << MyObject;
>Java StringBuffer class returns ref to itself
>so you can do
>   myBuffer.append( 'a' ).append('b');
>much like
>   myBuffer << 'a' << 'b';
>
>I know the behaviour without having to look it up
>if you overload operator = do you get a right associative operator I can't
>find an answer to this in my C++ book.

Depends on if operator= is written correctly.  "Correctly" means that you return a reference to *this.  For a detailed explanation, check Item 15 of "Effective C++, 2nd Edition".

Because this is not widely known or clearly stated anywhere, the mechanism should only be used by experienced and well trained programmers.  But just because guns are dangerous for children doesn't mean police officers shouldn't have them either (and no, I DON'T want to get into a gun rights argument here.  It was just the first analogy that came to mind.  If you prefer axes and woodcutters (or firemen, depending on the type of axe), that's fine too.)  See comments below about automated code review tools and company policies about reviewing usage of dangerous but useful and powerful language features.

>
>and I consider "operator ++(int i){}"
>a bodge.

Agreed.  But just because the C++ standard committe had a syntax brain fart and signed it into law doesn't mean the whole idea is bad.

operator++() and ++operator() could have been used.
operator ++pre() and operator ++post() could have been used.
operator ++x() and operator x++() could have been used.

>
>and MyBuffer >> a >> b; can easily be misread
>but MyBuffer.read( a ).read(b); can not.
>
>give me an example where operator overloading in D would improve the
>language
>not just save a few chars or be a "cool" way of doing something
>but improve the readablility, debugability, maintainability and reduce the
>learning curve for new employees. things that are important to a company.
>who are, from my experiance, anyways selling products where the ink is still
>wet on the designs.
>
>Mike.
>
>

Things that work better with operator overloading:

1. Any numerical type that needs to do math and isn't built into the language.  People trying to develop symbolic mathematics engines like Mathematica are going to use types that no compiler on the planet supports natively, and they're going to want to be able to say "a=b+c", not "a.assign(b.plus(c))".

2. ANY class that needs to be sortable through a generic algorithm that is probably going to use < as the decision operator.  I refuse to believe that (given a and b as instances of a hypothetical class Fleem):

if (Fleem::less_than(a, b)) {...}

or

if (a.less_than(b)) {...}

is REALLY easier to read or understand than:

if (a < b) {...}



Operator overloading can be misused.  It frequently is.  Fire the people who repeatedly misuse it.  The ability to interface directly to C APIs is dangerous and fraught with potential errors -- do you really want to be without it in a real language?  D has pointers, and pointers are some of the most dangerous constructs you can ever give to a programmer.  They are present because they are also one of the most powerful tools you can ever give a programmer.  The danger of pointers was handled by providing other mechanisms and then basically saying "don't use pointers unless you REALLY have to".  Why not do the same with operator overloading?  ANY tool can be misused.  That does not mean that ALL tools should be outlawed.

Make code review tools that find uses of operator overloading in projects.  Require code reviews by three or more people before allowing such code.  Do not accept "abuses" of syntax.  If nothing else, the sheer hassle of this process will remove the desire to casually toss operator overloading into a project.  You will end up with operator overloading ONLY in the places that really need it, because that is the only place where programmers are willing to get grilled about their use of it.

Apply the code review tools to any incoming library.  Alternatively, occasionally apply it to entire projects.

Maybe you only need these capabilities 10% of the time.  But when you hit that 10% of the time, you're going to find out you REALLY need them.  I did a lot of Visual Basic programming at one point in my life.  If was really nice of Microsoft to store all the guns away so that I couldn't shoot myself in the foot.  Then I found out that I couldn't shoot anything else, either, and now I end up doing all of my programming in C++.  When you hit the wall of missing functionality, you can't do anything about it, and you have to switch to another language.

While operator overloading is never REQUIRED, there are cases where the alternatives are too painful to consider.  I've programmed in COBOL, and I know what hell it is to read code that essentially looks like "add transaction to total giving newtotal", which may be more readable to an accountant, but take me a lot longer to parse than "newtotal = transation + total".  (For the sake of argument, let us assume a Currency class that is not supported natively in the language.  Such variables exist in many languages designed primarily for financial calculations, because many financial calculations are rounded to the nearest penny, and roundoff errors are discarded -- as insane as that sounds, it is nevertheless true...)

Mac Reiter
Software Engineer

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a2je9c$2v8i$1@digitaldaemon.com...
>
> People who cannot understand a section of code shouldn't be working on
that
> section of code.  If they know enough to be able to justifiably critique such code, they are perfectly capable of replacing such code with
something
> they can read easier.  Sometimes some readability has to be sacrificed for the sake of writability.  Tools like this make code easier to write.

   And much easier to read, I'd say, once you learn the syntax of that
user-defined sub-language, or DSL (Domain Specific Language).

> > I have worked for people who would have sacked me If I produced code
like
> > your example.
>
> Wasn't my example, but personally I think the Spirit parser generator is a wonderful example of the kinds of brilliant things people will figure out how to do given a set of powerful tools (templates + operator
overloading).

   He has a point, though. Code like that, developed in-house, requires a
guru-head programmer in order to maintain it. That can definitely become a
problem. For example, at Ronin, where I work, I'm the only guru-head like
that, and I've done my share of template craziness. If I leave the company,
there could be a serious problem because of that.

   Things like Spirit, though, which are externally-developed libraries are
less of an issue. And they show that C++ templates, even flawed as they
might be, are tremendously powerful.

> Sure, they're "abusing" the normal syntax of C++, but they get a working user-defined parser generated for them from nice easy EBNF-like notation
by
> their humble C++ compiler.  ;)  Try doing anything close to that without using either templates or operator overloading, I'd love to see it.

   Try reading about "monadic parser combinators" for the Haskell language.
It doesn't have operator overloading (well, it has, kind of, but in a very
different way). And it sure doesn't have templates. But it can do even
better at creating powerful BNF-like parsers.

> If you think about it, even functions are merely a tool to help the programmer hide code that they aren't concerned with at the time.  You really don't *want* to see every little thing that's going on in your program, your brain would explode.  If you want that, you should program assembly.  Even assemblers use macros.

   Exactly. This is a concept that is hard to really understand for many
programmers. Just by creating a function or a typedef in a library, you're
actually modifying the language used to write your programs. Operator
overloading is no different from function overloading, really. And libraries
like Spirit just go one step further, creating a complete sub-language.

   You already have some sort of operator overloading by allowing "+" to be
used for integers, floats and complex numbers, for example.

Salutaciones,
                         JCAB

Juan Carlos Arevalo Baeza wrote:

> For example, at Ronin, where I work, I'm the only guru-head like
> that, and I've done my share of template craziness. If I leave the company,
> there could be a serious problem because of that.


Heh, I hadn't noticed your email address prior to this. Tell the
Blue Planet guys that Russell B says hi.

-RB