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

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

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

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

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

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

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
already
> a boolean exclusive or operator... it's called !=  !!!!!!!!

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

Agreed.


--
Stijn
OddesE_XYZ@hotmail.com
http://OddesE.cjb.net
__________________________________________
Remove _XYZ from my address when replying by mail

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