www.digitalmars.com         C & C++   DMDScript  

D - Missing boolean exclusive-or operator, operator overloading and real bool type advocacy

reply "Christophe Bouchon" <cbouchon hotmail.com> writes:
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

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).
Jan 20 2002
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
"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

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

 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

 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

 and | is an alternative. Execution of a rule returns the number of

 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

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

 struggle with restricted precompiled headers), ambiguous syntax depending

 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

 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
Jan 21 2002
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
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


 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

 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

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


 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


 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


 for an example of a clean, usefull and nice operator overloading usage

 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

 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)


 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

 and | is an alternative. Execution of a rule returns the number of

 matched. The ch_p('+') is there because '+' | '-' can't use the


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

 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


 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

 reasonable compromises. It removes most of the things I hated in C++


 pre-processor, completely useless . -> and :: separation, forward
 declarations, #include (parse these headers again and again and again...

 struggle with restricted precompiled headers), ambiguous syntax


 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

 C++ Builder and MSVC).

Yup. Now if it just had operator overloading and generics and DFront I'd

 all set to switch over.  ;)

 Actually that's not true... until I can write extremely lightweight

 (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

Jan 21 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
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

 does
 & | ^ can be boolean but both sides will be evaluated (xor has to eval

 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

 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

 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



 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



 have side effect
 or
 if ((cond1 != 0) ^ (cond2 != 0))
 the "!= 0" above are required if cond1 or cond2 can be such that



 &
 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


 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

 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

And declaring a variable as bool instead of int is better for code documentation. Perhaps a compiler option to allow/prevent automatic convertion to



 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


 abused  (you can find abuses of any programming language feature) but



 some cases, it can be used in a very nice and readable way. If you



 it's just good for complex numbers, look at


 for an example of a clean, usefull and nice operator overloading usage

 templates: you get lex+yacc capabilities directly within C++ source,



 EBNF-like notation (with overloaded C++ operators) constructing a



 during object construction, the constructed variables becoming the

 of the parser.

 Simple calculator example:
     rule<>  expr;
     rule<>  integer = lexeme[ (!(ch_p('+') | '-') >>



     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)


 the 0-or-1, 0-or-more and 1-or-more repetitions, the actions are in



 []
 (functions with  pointers to the first and last elements parsed by the

 and | is an alternative. Execution of a rule returns the number of

 matched. The ch_p('+') is there because '+' | '-' can't use the


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

 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



 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


 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

 reasonable compromises. It removes most of the things I hated in C++


 pre-processor, completely useless . -> and :: separation, forward
 declarations, #include (parse these headers again and again and



 or
 struggle with restricted precompiled headers), ambiguous syntax


 on
 the nature of a symbol like (type)-1 instead or (var)-1 and last but



 least, added missing language supported safe garbage collection



 RTTI) and class properties (exist only as non-portable extensions in

 C++ Builder and MSVC).

Yup. Now if it just had operator overloading and generics and DFront


 be
 all set to switch over.  ;)

 Actually that's not true... until I can write extremely lightweight

 (like a replacement for int, or a 3d math library) or at least get


 3D math stuff, I won't be able to switch for performance reasons.

 Sean


Jan 21 2002
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"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

 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

 new operators, not just overload existing ones) you could make your own

 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

 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('+') | '-') >>



     rule<>  group   = '(' >> expr >> ')';
     rule<>  expr1   = integer | group;
     rule<>  expr2   = expr1 >> *(('*' >> expr1)[&doMult] | ('/' >>
 expr1)[&doDiv]);
     expr            = expr2 >> *(('+' >> expr2)[&doAdd] | ('-' >>
 expr2)[&doSubt]);




Jan 21 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
"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

 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


 *very* nice to have.

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


 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

 people and as is often the case programs that where written by people who

 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


 up
 new operators, not just overload existing ones) you could make your own

 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

 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


 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

 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

 operator overloading should not be included.

 for us meer mortals, that have spent 2 years working on a project that

 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('+') | '-') >>



     rule<>  group   = '(' >> expr >> ')';
     rule<>  expr1   = integer | group;
     rule<>  expr2   = expr1 >> *(('*' >> expr1)[&doMult] | ('/' >>
 expr1)[&doDiv]);
     expr            = expr2 >> *(('+' >> expr2)[&doAdd] | ('-' >>
 expr2)[&doSubt]);





Jan 22 2002
next sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"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

 section of code.  If they know enough to be able to justifiably critique
 such code, they are perfectly capable of replacing such code with

 they can read easier.  Sometimes some readability has to be sacrificed for
 the sake of writability.  Tools like this make code easier to write.

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

 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

 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.

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

 in the debugger if you so desire.  Or take a few seconds to hit "browse"

 one of the variables to see where it's defined... that's a good idea

 Never assume types of variables without seeing their declarations.

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.
Jan 22 2002
next sibling parent reply reiter nomadics.com (Mac Reiter) writes:
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
Jan 22 2002
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
 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.

operator overloading :) I totally agree, the question is, and every one has a personal postion on this Is operator overloading a big enough gun to justify the extra complexity required within the compiler. There is an interesting thread on IOperator just starting up. Mike.
Jan 22 2002
prev sibling parent "Roberto Mariottini" <rmariottini lycosmail.com> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> ha scritto nel messaggio
news:a2jsjb$6ui$1 digitaldaemon.com...
 [...]
 As Walter said in the D overview, Apart from SmartPointers and Strings

 do you use operator overloading for ?

 I prefer to see
     myStream.ouput( MyObject );
  to myStream << MyObject;

Maybe that's because you know what 'output' means. What about: myStream.dajjeggiu(myObject) ? And what about: myInteger.increment(); where: class Integer { ... void increment() { value *= 3.14; } private: int value; } You think that operator overloading is not clear because you're not used to it. Doing operator overloading the right way is not confusing more than using functions. Writing functions the wrong way is confusing too.
 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

I also know the behaviour of operator << without having to look it up, but maybe someone don't know what 'append' means.
 if you overload operator = do you get a right associative operator I can't
 find an answer to this in my C++ book.

Operator precedence and associativity is one and only one. The parser decided this at an earlier stage. So operator = is right-associative. This is written somewhere in your book. Something that is not specified is order of evaluation in function parameters: int i = 43; int j = function1(++i, i++); You'll get different results for different _compilers_. (BTW, How this is handled in D?)
 and I consider "operator ++(int i){}"
 a bodge.

A trick. I would otherwise remove the post-increment operator (it's useless).
 and MyBuffer >> a >> b; can easily be misread
 but MyBuffer.read( a ).read(b); can not.

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

 wet on the designs.

Sure, operator overloading doesn't add much to the language. But this way there is no need for identifiers: double sub 2000 (double, double) return #1 + #2 - (#1 * #2); ... double = 0.33; double = 0.44; double = call 2000(#10, #11); // this is #12 printf("%g", #12); What identifiers add to the language? They add a lot for an human reader, if he/she knows what they mean. Look: double ffff(double ab, double cd) { return ab + cd - (ab * cd); } ... double hh = 0.33; double ii = 0.44; double gg = ffff(hh, ii); printf("%g", gg); This doesn't add much. But: double compound_probability(double p1, double p2) { return p1 + p2 - (p1 * p2); } ... double p_A = 0.33; double p_B = 0.44; double p_AorB = compound_probability(p_A, p_B); printf("%g", p_AorB); Or: Probability operator | (Probability a, Probablility b) { ... } ... Probability p_A(0.33); Probability p_B(0.44); Probability p_AorB = p_A | p_B; cout << p_AorB; Ciao
Jan 23 2002
prev sibling next sibling parent reply "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"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

 section of code.  If they know enough to be able to justifiably critique
 such code, they are perfectly capable of replacing such code with

 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


 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

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

 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
Jan 22 2002
parent Russell Borogove <kaleja estarcion.com> writes:
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
Jan 22 2002
prev sibling next sibling parent "Walter" <walter digitalmars.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a2je9c$2v8i$1 digitaldaemon.com...
 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.

Actually, it isn't very hard. Then again, I'm used to writing them. C++ is hard because the grammar doesn't make any sense - then again, a yacc isn't going to help much with that, either. A colleague of mine is working on a vbscript implementation. She's using bison. She told me that it was so much trouble that, if she was doing it over, she'd use a custom recursive descent parser. With D, the lexer/parser is the easy part. Of course, that's by design <g>. I know I'm in the minority dissing parser generators, most people find them useful, but hey, you asked!
Jan 25 2002
prev sibling parent "D" <s_nudds hotmail.com> writes:
Not all.  Virtually all.  And not all CPU's support floats.  So by your
argument should floats be dropped also?

Those CPU's that do not have a ROL opcode will be obligated to preform extra
work to supply one.  Tough!

Sean L. Palmer <spalmer iname.com> wrote in message
news:a2je9c$2v8i$1 digitaldaemon.com...
 Not all CPUs even have a rotate instruction.  After that you'll be wanting

 rotate with carry operator.  ;)  It's not often in a high level language

 find yourself needing a rotate operator anyway.

Feb 04 2002
prev sibling parent reply "D" <s_nudds hotmail.com> writes:
I have never used operator overloading, but I have had the "need" for it on
several occasions.  I understand it's utility, and I understand that
programmers can't be trusted to use it properly.

Face the truth.  If programmers could be trusted modern languages that
inforce structured programming and object oriented programming wouldn't be
needed.

Structure must be imposed on programmers, because programmers are for the
most part don't have a clue.  Programmers do wonderful things like inputting
strings into buffers without checking for overflow conditions.  Programmers
do things like write languages that don't support nested comments.
Programmers do brilliant things like redefining the multiply symbol to mean
<Add a record to the database>.

Providing the ability to create new operators on the other hand is a
blessing.  And yes you would be able to create your own Roll operators.

Why?

ROL is a standard part of most every CPU's native vocabulary.  You issue a
single opcode to implement it.  Creating ROL out of a string of high level
functions and pretending that the C compiler will properly optimize it to
it's single opcode equivalent is the height of foolishness.

Build in two new shift functions...  Call them ROL and ROR.



Sean L. Palmer <spalmer iname.com> wrote in message
 It's funny how all the folks who "have rarely used it" are the most

 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

 new operators, not just overload existing ones) you could make your own

 rotate operator.  ;)  Think about that for a while.

Feb 04 2002
next sibling parent reply "Sean L. Palmer" <spalmer iname.com> writes:
You're right, I'd rather have ROL/ROR built in, and emulated on those (rare)
cpu's that don't support it in hardware.  But then what about RCR/RCL?
Those are useful too.  I'm sure we could find many asm instructions for one
machine or another that would occasionally be nice to have as operators in
our nice high level language.  Gotta draw the line somewhere though.

You've got to trust the programmers at least a little bit.  If they really
suck that bad you should fire them or send them back to programming school.
Imposed structure that limits utility is no good, it just forces the good
programmers to jump through hoops to get what they need.  Imposing structure
that doesn't keep you from doing anything (just keeps you from doing it
wrongly) is a Good Thing however.

Sean


"D" <s_nudds hotmail.com> wrote in message
news:a3lk03$s9l$1 digitaldaemon.com...
 I have never used operator overloading, but I have had the "need" for it

 several occasions.  I understand it's utility, and I understand that
 programmers can't be trusted to use it properly.

 Face the truth.  If programmers could be trusted modern languages that
 inforce structured programming and object oriented programming wouldn't be
 needed.

 Structure must be imposed on programmers, because programmers are for the
 most part don't have a clue.  Programmers do wonderful things like

 strings into buffers without checking for overflow conditions.

 do things like write languages that don't support nested comments.
 Programmers do brilliant things like redefining the multiply symbol to

 <Add a record to the database>.

 Providing the ability to create new operators on the other hand is a
 blessing.  And yes you would be able to create your own Roll operators.

 Why?

 ROL is a standard part of most every CPU's native vocabulary.  You issue a
 single opcode to implement it.  Creating ROL out of a string of high level
 functions and pretending that the C compiler will properly optimize it to
 it's single opcode equivalent is the height of foolishness.

 Build in two new shift functions...  Call them ROL and ROR.



 Sean L. Palmer <spalmer iname.com> wrote in message
 It's funny how all the folks who "have rarely used it" are the most

 critics of operator overloading.  Probably the same goes for templates.

 If you guys actually used this stuff for anything you'd realize that it


 *very* nice to have.

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


 If you had operator overloading (especially the kind where you could


 up
 new operators, not just overload existing ones) you could make your own

 rotate operator.  ;)  Think about that for a while.


Feb 04 2002
parent "D" <s_nudds hotmail.com> writes:
Rotations through the carry would be nice, but no high level language gives
you access to the condition code register.  In fact many modern RISC CPU's
don't have condition code registers at all, hence there is no carry to
rotate through.  Sad...  Rather these CPU's store the result of comparisons
in another register which is then specified in a conditional jump that
typically follows.

I don't particularly like the concept but it does offer some nice advantages
with regard to pipelining instructions and parallel processing.  I would
prefer a setup where a destination condition code register could be
specified for each operation.  This is perferable to me because the various
operating flags that can be generated in parallel with performing your
typical CPU operation can be immediately used in a conditional to follow.
Without having a at least one dedicated condition code register, you lose
the ability to do that.
.
Whatever... The fact is, you don't have access to the condition code
register, and I don't see how you could reasonably give access to it in a
HLL.

Operator overloading provides <no> additional functionality.  It simply adds
the potential of improved code clarity and simplifies code writing and
correctness.

However the way overloading is implemented in C/C++ where the existing
operators can be overloaded, code clarity is typically reduced, because most
of the situations where overloading is useful don't lend themselves to the
common meanings of the existing operators.

In some instances you can stretch the meanings, like using "+" for adding a
record or appending strings, or "-" for deleting a record.  But there simply
aren't sufficient operators so you end up doing things like record = record
* record, and nonsense like that.

Much better to allow the creation of new operators and impose a syntax where
the new operators are easily distinguished from variables.


Sean L. Palmer <spalmer iname.com> wrote in message
news:a3lom3$uj1$1 digitaldaemon.com...
 You're right, I'd rather have ROL/ROR built in, and emulated on those

 cpu's that don't support it in hardware.  But then what about RCR/RCL?
 Those are useful too.  I'm sure we could find many asm instructions for

 machine or another that would occasionally be nice to have as operators in
 our nice high level language.  Gotta draw the line somewhere though.

 You've got to trust the programmers at least a little bit.  If they really
 suck that bad you should fire them or send them back to programming

 Imposed structure that limits utility is no good, it just forces the good
 programmers to jump through hoops to get what they need.  Imposing

 that doesn't keep you from doing anything (just keeps you from doing it
 wrongly) is a Good Thing however.

 Sean


 "D" <s_nudds hotmail.com> wrote in message
 news:a3lk03$s9l$1 digitaldaemon.com...
 I have never used operator overloading, but I have had the "need" for it

 several occasions.  I understand it's utility, and I understand that
 programmers can't be trusted to use it properly.

 Face the truth.  If programmers could be trusted modern languages that
 inforce structured programming and object oriented programming wouldn't


 needed.

 Structure must be imposed on programmers, because programmers are for


 most part don't have a clue.  Programmers do wonderful things like

 strings into buffers without checking for overflow conditions.

 do things like write languages that don't support nested comments.
 Programmers do brilliant things like redefining the multiply symbol to

 <Add a record to the database>.

 Providing the ability to create new operators on the other hand is a
 blessing.  And yes you would be able to create your own Roll operators.

 Why?

 ROL is a standard part of most every CPU's native vocabulary.  You issue


 single opcode to implement it.  Creating ROL out of a string of high


 functions and pretending that the C compiler will properly optimize it


 it's single opcode equivalent is the height of foolishness.

 Build in two new shift functions...  Call them ROL and ROR.



 Sean L. Palmer <spalmer iname.com> wrote in message
 It's funny how all the folks who "have rarely used it" are the most

 critics of operator overloading.  Probably the same goes for



 If you guys actually used this stuff for anything you'd realize that



 is
 *very* nice to have.

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


 If you had operator overloading (especially the kind where you could


 up
 new operators, not just overload existing ones) you could make your



 damn
 rotate operator.  ;)  Think about that for a while.



Feb 04 2002
prev sibling parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3lk03$s9l$1 digitaldaemon.com...
 I have never used operator overloading, but I have had the "need" for it

 several occasions.  I understand it's utility, and I understand that
 programmers can't be trusted to use it properly.

 Face the truth.  If programmers could be trusted modern languages that
 inforce structured programming and object oriented programming wouldn't be
 needed.

 Structure must be imposed on programmers, because programmers are for the
 most part don't have a clue.  Programmers do wonderful things like

 strings into buffers without checking for overflow conditions.

 do things like write languages that don't support nested comments.
 Programmers do brilliant things like redefining the multiply symbol to

 <Add a record to the database>.

Give me a language that (cough) "enforces" structure and I'll show you ways to abuse it to the point that you cry when you have to maintain that code for a living. Give me a language that doesn't "allow" structured code to be written and I'll show you ways to code with it that makes you go to bed at night with a smile on your face. Bottom line, a language should offer the possibility to write structured, readable code. It should not force you to use difficult and error prone features such as pointers. There are always moments that using a pointer, or functions instead of classes are cleaner than difficult workarounds however, and a language should not shut them out just because they 'might' be abused. In C dealing with simple strings is a nightmare (strcmp, strcat, strcpy, char[], char *), maybe that is the reason "Programmers do wonderful things like inputting strings into buffers without checking for overflow conditions.", and not that they "for the most part don't have a clue". -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Feb 04 2002
parent reply "D" <s_nudds hotmail.com> writes:
Every language can be abused.  True enough.  Poor programmers do such
things, and poor languages provide insufficent structure to avoid the
abuses.

I take it then that you believe structured languages should be abandoned
because spaghetti code is the way to go?


OddesE <OddesE_XYZ hotmail.com> wrote in message
news:a3msuv$1se0$1 digitaldaemon.com...

 Give me a language that (cough) "enforces" structure and I'll
 show you ways to abuse it to the point that you cry when you
 have to maintain that code for a living.
 Give me a language that doesn't "allow" structured code to
 be written and I'll show you ways to code with it that makes
 you go to bed at night with a smile on your face.

Well, when dealing with arrays of data, you have two choices, using array references or using pointer references. Pointer references have the advantage of being significantly faster since the content of the pointer is maintained between array references while with array references the pointer must be computed from the specified index for each reference. Some optimizations are possible at times, but typically none are performed by compilers from what I have seen. Buffer processing in C/C++ programs is often done without error checking because of the programming philosophy built into the language. That philosophy is to provide half baked, half working solutions to problems that usually work, but fail if the user steps outside the box. "Who is going to enter a 5K string into my password checker? No one is going to sit there and type for 5 minutes to fill the buffer. So if I set the buffer to 5K then no one is ever going to cause a problem, and 5K isn't too much memory to waste, and it makes my programming task so much easier." That is the mindset of your typical C/C++ programmer. As a result, 80% of security exploits are the result of failure to check for buffer overflows that clobber the stack. If you don't believe this sad ideology is built into the language, I draw your attention to GETS in the standard library.
 Bottom line, a language should offer the possibility to write
 structured, readable code. It should not force you to use
 difficult and error prone features such as pointers. There are
 always moments that using a pointer, or functions instead of
 classes are cleaner than difficult workarounds however, and
 a language should not shut them out just because they 'might'
 be abused. In C dealing with simple strings is a nightmare
 (strcmp, strcat, strcpy, char[], char *), maybe that is the reason
 "Programmers do wonderful things like inputting strings into
 buffers without checking for overflow conditions.", and not
 that they "for the most part don't have a clue".

Feb 04 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3njn6$29ud$1 digitaldaemon.com...
 Every language can be abused.  True enough.  Poor programmers do such
 things, and poor languages provide insufficent structure to avoid the
 abuses.

 I take it then that you believe structured languages should be abandoned
 because spaghetti code is the way to go?

Ofcourse not. I agree with you that a lot of problems can be solved with structured programming like OO. In fact, I love OO. I don't agree with you though that programmers used to write spaghetti code because they didn't want to write better code or because they just didn't care. I think that the causes for the spaghetti code of the past (and I wrote some too :) ) are the facts that programming was new and we didn't know much about structuring code and that languages provided no easy ways of writing structured code. goto was there, so people used it. classes where not there, so people didn't use them. But to turn this around and say that languages should not provide any constructs that *could* be abused, even though they might be veru usefull, is a different story altogether.
 OddesE <OddesE_XYZ hotmail.com> wrote in message
 news:a3msuv$1se0$1 digitaldaemon.com...

 Give me a language that (cough) "enforces" structure and I'll
 show you ways to abuse it to the point that you cry when you
 have to maintain that code for a living.
 Give me a language that doesn't "allow" structured code to
 be written and I'll show you ways to code with it that makes
 you go to bed at night with a smile on your face.

Well, when dealing with arrays of data, you have two choices, using array references or using pointer references. Pointer references have the advantage of being significantly faster since the content of the pointer

 maintained between array references while with array references the

 must be computed from the specified index for each reference.  Some
 optimizations are possible at times, but typically none are performed by
 compilers from what I have seen.

 Buffer processing in C/C++ programs is often done without error checking
 because of the programming philosophy built into the language.  That
 philosophy is to provide half baked, half working solutions to problems

 usually work, but fail if the user steps outside the box.

 "Who is going to enter a 5K string into my password checker?  No one is
 going to sit there and type for 5 minutes to fill the buffer.  So if I set
 the buffer to 5K then no one is ever going to cause a problem, and 5K

 too much memory to waste, and it makes my programming task so much

 That is the mindset of your typical C/C++ programmer.  As a result, 80% of
 security exploits are the result of failure to check for buffer overflows
 that clobber the stack.

 If you don't believe this sad ideology is built into the language, I draw
 your attention to GETS in the standard library.

Agreed. -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net __________________________________________ Remove _XYZ from my address when replying by mail
Feb 05 2002
parent "D" <s_nudds hotmail.com> writes:
 "D" <s_nudds hotmail.com> wrote in message
 news:a3njn6$29ud$1 digitaldaemon.com...
 Every language can be abused.  True enough.  Poor programmers do such
 things, and poor languages provide insufficent structure to avoid the
 abuses.

 I take it then that you believe structured languages should be abandoned
 because spaghetti code is the way to go?


OddesE <OddesE_XYZ hotmail.com>
 Ofcourse not.
 I agree with you that a lot of problems can be solved with
 structured programming like OO. In fact, I love OO.
 I don't agree with you though that programmers used to write
 spaghetti code because they didn't want to write better code
 or because they just didn't care. I think that the causes for the
 spaghetti code of the past (and I wrote some too  :)  ) are the
 facts that programming was new and we didn't know much
 about structuring code and that languages provided no easy
 ways of writing structured code. goto was there, so people
 used it. classes where not there, so people didn't use them.
 But to turn this around and say that languages should not
 provide any constructs that *could* be abused, even though
 they might be veru usefull, is a different story altogether.

If mistakes can happen they will happen. This is the lesson of ergonomic system design. Systems that are designed to avoid errors are inherently less prone to error than systems that make no such effort. If a change can be made to avoid error, and which does not alter a system's ability to function then that change is beneficial and will improve reliability without cost. This is the case with things like including xor, and block typing. These things can be hand at essentially zero cost, and provide real benefits that will reduce errors thereby making the language that employs them superior to one that does not. It's as simple as that. .Why Things Bite Back Edward Tenner If it can go wrong, it will--thus Murphy's Law. Science journalist Edward Tenner looks more closely at this eternal verity, named after a U.S. Air Force captain who, during a test of rocket-sled deceleration, noticed that critical gauges had been improperly set and concluded, "If there's more than one way to do a job and one of those ways will end in disaster, then somebody will do it that way." Tenner concurs, and he gives us myriad case studies of how technological fixes often create bigger problems than the ones they were meant to solve in the first place. The indiscriminate use of antibiotics, by way of example, has yielded hardier strains of bacteria and viruses that do not respond to pharmaceutical treatment; the wide-scale use of air conditioning in cities has raised the outdoor temperature in some places by as much as 10 degrees, adding stress to already-taxed cooling systems; the modern reliance on medical intervention to deal with simple illnesses, to say nothing of the rapidly growing number of elective surgeries, means that even a low percentage of error (one patient in twenty-five, by a recent estimate) can affect increasingly large numbers of people. Tenner examines what he deems the "unintended consequences" of technological innovation, drawing examples from everyday objects and situations. Although he recounts disaster after painful disaster, his book makes for curiously entertaining, if sometimes scary, reading. --Gregory McNamee The Logic of Failure Dietrich Dorner, et al That's Not What We Meant to Do: Reform and Its Unintended Consequences in the Twentieth Century Steven M. Gillon Normal Accidents Charles Perrow Systemantics The Underground Text of Systems Lore John Gall, D.H. Gall (Illustrator)
Feb 06 2002
prev sibling next sibling parent "Rajiv Bhagwat" <dataflow vsnl.com> writes:
Thank you for pointing out 'sprit'! It is certainly impressive and properly
illustrates how features of a 'higher level' language can simplify otherwise
tedious tasks.

I understand it is not for everyone, but then hey, simple tasks are simple
in most of the languages!

-Rajiv

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

 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

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

 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

 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

 and | is an alternative. Execution of a rule returns the number of

 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

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

 struggle with restricted precompiled headers), ambiguous syntax depending

 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

 C++ Builder and MSVC).

Jan 22 2002
prev sibling parent reply "D" <s_nudds hotmail.com> writes:
An exclusive or operator is needed for both logical and boolean types.
call them xor and lxor.

If you understood the meaning of the above sentence then the superiority of
xor/lxor has been proven.

For those who did not understand, it is time to seek another profession.

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

Feb 04 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"D" <s_nudds hotmail.com> wrote in message
news:a3ljb5$s15$1 digitaldaemon.com...

 An exclusive or operator is needed for both logical and boolean types.
 call them xor and lxor.

^ and ^^, then.
Feb 04 2002
parent reply "Sean L. Palmer" <spalmer iname.com> writes:
That'd be great, but the point you guys KEEP MISSING is that there's already
a boolean exclusive or operator... it's called !=  !!!!!!!!

if ((a && b) != (c && d))
{
  // executed if either a and b are both true, or c and d are both true, but
not if all four are true, and not if both sides of != are false either.
}

If you add ^^ you'll just end up with two operators that do the same thing.

Sean

"Pavel Minayev" <evilone omen.ru> wrote in message
news:a3lliv$t1a$1 digitaldaemon.com...
 "D" <s_nudds hotmail.com> wrote in message
 news:a3ljb5$s15$1 digitaldaemon.com...

 An exclusive or operator is needed for both logical and boolean types.
 call them xor and lxor.

^ and ^^, then.

Feb 04 2002
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
I think people are missing the point of && and ||
they allow for only one side to be evaled not both
xor HAS to eval both sizes

^^ serves no purpose

the same as you can use & and | to perform && and || but force eval of both
sides
you can use != or ^ to do an xor.

Mike.

"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3lott$urf$1 digitaldaemon.com...
 That'd be great, but the point you guys KEEP MISSING is that there's

 a boolean exclusive or operator... it's called !=  !!!!!!!!

 if ((a && b) != (c && d))
 {
   // executed if either a and b are both true, or c and d are both true,

 not if all four are true, and not if both sides of != are false either.
 }

 If you add ^^ you'll just end up with two operators that do the same

 Sean

 "Pavel Minayev" <evilone omen.ru> wrote in message
 news:a3lliv$t1a$1 digitaldaemon.com...
 "D" <s_nudds hotmail.com> wrote in message
 news:a3ljb5$s15$1 digitaldaemon.com...

 An exclusive or operator is needed for both logical and boolean types.
 call them xor and lxor.

^ and ^^, then.


Feb 04 2002
prev sibling next sibling parent "Juan Carlos Arevalo Baeza" <jcab roningames.com> writes:
"Sean L. Palmer" <spalmer iname.com> wrote in message
news:a3lott$urf$1 digitaldaemon.com...
 That'd be great, but the point you guys KEEP MISSING is that there's

 a boolean exclusive or operator... it's called !=  !!!!!!!!

In C++ that's not quite true. If you use != as XOR, you won't get the standard type conversions that you do with, for example, &&. This alone makes having a ^^ operator sound like a good idea. Then again, this is maybe not something that D should do: so many standard conversions, like pointer->bool and such.
Feb 04 2002
prev sibling parent "D" <s_nudds hotmail.com> writes:
That operator is not equal, not logical xor.  Programming via side effects
is a bad programming practice.  Include a proper keyword.

Sean L. Palmer <spalmer iname.com> wrote in message
news:a3lott$urf$1 digitaldaemon.com...
 That'd be great, but the point you guys KEEP MISSING is that there's

 a boolean exclusive or operator... it's called !=  !!!!!!!!

Feb 04 2002