>
> 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.
>
they don't carry guns where I live, maybe that's why I'm not a fan of 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.

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

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

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

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

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

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
a
> rotate with carry operator.  ;)  It's not often in a high level language
you
> find yourself needing a rotate operator anyway.

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

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

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.