how should the following be eval'd ?
`foo & 0xFFFF != 0xFFFF` ? (foo is uint)
it appears to be eval'd as foo & (0xFFFF != 0xFFFF)
as opposed to what I wanted to write `(foo & 0xFFFF) != 0xFFFF`
if the latter then there is a bug in 0.71 linux DMD
if the former, then I think D should issue expr is always false errors
if ( foo & 0xFFFF != 0xFFFF ) {
// no warnings no errors but this code will never run.
}

how should the following be eval'd ?
`foo & 0xFFFF != 0xFFFF` ? (foo is uint)
it appears to be eval'd as foo & (0xFFFF != 0xFFFF)
as opposed to what I wanted to write `(foo & 0xFFFF) != 0xFFFF`
if the latter then there is a bug in 0.71 linux DMD
if the former, then I think D should issue expr is always false errors
if ( foo & 0xFFFF != 0xFFFF ) {
// no warnings no errors but this code will never run.
}

Ew, I never knew that, but being the type who puts in more parentheses than
necessary I never experience that problem. I think now would be a good time to
fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?
In article <bjmflf$1184$1 digitaldaemon.com>, Walter says...

how should the following be eval'd ?
`foo & 0xFFFF != 0xFFFF` ? (foo is uint)
it appears to be eval'd as foo & (0xFFFF != 0xFFFF)
as opposed to what I wanted to write `(foo & 0xFFFF) != 0xFFFF`
if the latter then there is a bug in 0.71 linux DMD
if the former, then I think D should issue expr is always false errors
if ( foo & 0xFFFF != 0xFFFF ) {
// no warnings no errors but this code will never run.
}

Ew, I never knew that, but being the type who puts in more parentheses than
necessary I never experience that problem. I think now would be a good time to
fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?

how should the following be eval'd ?
`foo & 0xFFFF != 0xFFFF` ? (foo is uint)
it appears to be eval'd as foo & (0xFFFF != 0xFFFF)
as opposed to what I wanted to write `(foo & 0xFFFF) != 0xFFFF`
if the latter then there is a bug in 0.71 linux DMD
if the former, then I think D should issue expr is always false errors
if ( foo & 0xFFFF != 0xFFFF ) {
// no warnings no errors but this code will never run.
}

// so cast(T)a.foo() is cast(T)(a.foo()) like java
// not (cast(T)a).foo();
// or have a low presidence cast `as`
// as(T)foo.s() => cast(T)(foo.s())

You are right. Transferring Java code to D would add it quite some value
- esp. considering casting in that form is far more frequent in Java
than in C. I guess even the C rule probably made sense in some early
variants of C, and was left as it was further on... Like, today's C
programs are fairly type-safe, hardly anyone can afford coding in C
without prototypes without his head being knocked off. :)
-eye

Ew, I never knew that, but being the type who puts in more parentheses

necessary I never experience that problem. I think now would be a good

fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?

D doesn't change the operator precedence rules from C/C++ because it would
subtly and silently screw up code that was transferred between the
languages. It also causes haywire in peoples' thinking. For example, in
England, they drive on the wrong (!) side of the road. I found that when I
step into the street, I look to my left for cars, and then get promptly run
over by a car coming from the right. My thinking got so screwed up I decided
to stop trying to remember which rule to apply and look both ways.
I had similar problems using the inline assembler in gcc, which reverses the
arguments. It just makes my eyeballs hurt looking at it, I am so used to the
Intel syntax.

Ew, I never knew that, but being the type who puts in more parentheses

than

necessary I never experience that problem. I think now would be a good

time to

fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?

D doesn't change the operator precedence rules from C/C++ because it would
subtly and silently screw up code that was transferred between the
languages. It also causes haywire in peoples' thinking. For example, in
England, they drive on the wrong (!) side of the road. I found that when I
step into the street, I look to my left for cars, and then get promptly run
over by a car coming from the right. My thinking got so screwed up I decided
to stop trying to remember which rule to apply and look both ways.
I had similar problems using the inline assembler in gcc, which reverses the
arguments. It just makes my eyeballs hurt looking at it, I am so used to the
Intel syntax.

In England/Japan/Oz you drive on the left, drive the car from the
righthand side.
In Europe/America drive on right, sit on left.
it's not so hard, (once you stop hitting the window ever time you want
to change gear)[at least the pedal are in the same order] and remember
which way to look when joining the freeway/autobahn/motorway in case
there is a lorry/truck/juggernaut already there! (roundabouts go about
round that was fun!) and crossroads where even more confusing in a
righthand drive car in Germany.
to make and array with is index as a[0 to 4][0 to 5]
C: int a[4][5];
Java: int[][] a = new int[4][5];
D: int[5][4] a;
or int[][] a = new int[5][4]; // I believe not checked.
Pascal : var a : array(0 to 4) of array(0 to 5) of integer;
cast: to cast the return from an assoc array to an different type;
Java:
MyObj func( Hashtable h, String tag ) {
return (MyObj)h.get( tag );
}
pseudo C++:
MyObj & func( Hashtable & h, char * tag ) {
return (MyObj&)(h.get( tag ));
}
D:
MyObj & func( Object[char[]] & h, char[] tag ) {
return (MyObj)(h[tag]);
}
we're already driving sideways down the center line!
if ( a + b < 3 ) { ... }
is
if ( (a+b) < 3 ) { ... }
why not make
if ( a & b < 3 ) { ... }
the more logical if ( (a&b) < 3 ) { ... }
instead of the useless if ( a & (b < 3 ) { ... }
if you realy meant the later a is obviously a boolean so it should be
instead of the useless if ( a && b < 3 ) { ... }
(having && as lower than comparison makes sence)
I know <bool-a> & <bool-b> can be used to replace <bool-a> && <bool-b>
then you want to force the eval of <bool-b> i.e.
if ( a & (b++ < 3) ) { ... }
NOT the same as
if ( a && (b++ < 3) ) { ... }
as `b++` is eval'ed in the former, but that's (imho) nasty code.
every algo based lang as a subtle difference from all the others
the array declare order annoyed me for a day or two ... but I'm a fan
now that I've actually used it.
I believe reordering the operator precidence would be a benifit
gas/intel is not too bad most of the time you can just about have
separate op codes (movl not mov) and gas uses %
mov eax, esp => eax:=esp
movl %eax, %esp => esp:=eax
I found doing perl and C together was not too hard, doing perl and php
at the same time got me confused.
(not that i'm sugesting that we prefix all vars with for visual
indication, [I have a separate syntax highlighting colour scheme for
each language which helps a lot])
conclusion ... do the right thing not the easy thing D already has lots
of subtle changes from C, one more it not going to make porting C to D
any harder.

necessary I never experience that problem. I think now would be a good

fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?

D doesn't change the operator precedence rules from C/C++ because it

subtly and silently screw up code that was transferred between the
languages. It also causes haywire in peoples' thinking. For example, in
England, they drive on the wrong (!) side of the road. I found that when

step into the street, I look to my left for cars, and then get promptly

over by a car coming from the right. My thinking got so screwed up I

to stop trying to remember which rule to apply and look both ways.

conclusion ... do the right thing not the easy thing D already has lots
of subtle changes from C, one more it not going to make porting C to D
any harder.

If you keep too many of C's problems, people won't have reason enough to
upgrade to D. ;)
People can adapt. I expect this change would break very very little legit C
code.
Sean

necessary I never experience that problem. I think now would be a good

fix the situation, bitwise operations should be higher precedence than
comparison. D _is_ breaking away from the bad parts of C right?

D doesn't change the operator precedence rules from C/C++ because it

subtly and silently screw up code that was transferred between the
languages. It also causes haywire in peoples' thinking. For example, in
England, they drive on the wrong (!) side of the road. I found that when

step into the street, I look to my left for cars, and then get promptly

over by a car coming from the right. My thinking got so screwed up I

to stop trying to remember which rule to apply and look both ways.

conclusion ... do the right thing not the easy thing D already has lots
of subtle changes from C, one more it not going to make porting C to D
any harder.

If you keep too many of C's problems, people won't have reason enough to
upgrade to D. ;)
People can adapt. I expect this change would break very very little legit C
code.
Sean

Indeed, how often is such an expression used? And of those times, how often
would there not already be parentheses around the part that should have
precedence? In such cases, the change would not cause trouble. I for one would
always put in the parentheses whether required or not. One of the reasons for
putting in the (otherwise unnecessary) parentheses is to make it clear to anyone
reading the code what is intended, that's just good coding practice.
<g>Of course, a language could enforce such good coding practice by not having
any precedence of operations, there's definitely some value to that.</g>
This topic would not have been brought up if there were not so many of us who
find this behaviour unexpected. I suppose if someone can track down why the
order of precedence was made the way it is in C to begin with it may shed some
light on the situation.
It seems to me that fixing the situation and documenting it well is the way to
go. After all, the specification already has a section on the differences
between the languages.
Furthermore, how many ports of C to D will blow up on a printf() that doesn't
have a ".*" added to a string format? Yeah, I know, that causes a more noticable
and more easily tracked-down problem, as opposed to "subtly and silently" as you
say. But it's likely to cost far more people far more hours of labor.
(Perhaps this is an example of what my last supervisor called my being
"argumentative" just before I got laid off.)
John Boucher
The King had Humpty pushed.

conclusion ... do the right thing not the easy thing D already has lots
of subtle changes from C, one more it not going to make porting C to D
any harder.

upgrade to D. ;)
People can adapt. I expect this change would break very very little

code.

In general I agree with you, but not on the operator precedence thing.

Indeed, how often is such an expression used? And of those times, how

would there not already be parentheses around the part that should have
precedence? In such cases, the change would not cause trouble. I for one

always put in the parentheses whether required or not. One of the reasons

putting in the (otherwise unnecessary) parentheses is to make it clear to

reading the code what is intended, that's just good coding practice.

It would be ok to change it if it was an obvious change that would result in
compilation errors if used the C way. But that isn't the case here - the
equation will subtly and silently break. This is not a good idea when moving
over a complicated expression from some C code.

<g>Of course, a language could enforce such good coding practice by not

any precedence of operations, there's definitely some value to that.</g>

Then you wind up with Lots of Infernally Stupid Parentheses (LISP) <g>.

This topic would not have been brought up if there were not so many of us

find this behaviour unexpected. I suppose if someone can track down why

order of precedence was made the way it is in C to begin with it may shed

light on the situation.

I view it like the QWERTY keyboard. Sure, the Dvorak layout makes more
sense, but who wants to retrain their fingers like that? Even if one wanted
to, in the process there'd be innumerable frustrating typos. And then when
you had to write a bit of C code maintenance, you're bollixed again.

It seems to me that fixing the situation and documenting it well is the

go. After all, the specification already has a section on the differences
between the languages.

Few will read the documentation thoroughly, and even if they did, it takes
an expert to learn all the subtleties of any language. Better to have it
work as expected.

Furthermore, how many ports of C to D will blow up on a printf() that

have a ".*" added to a string format? Yeah, I know, that causes a more

and more easily tracked-down problem, as opposed to "subtly and silently"

say. But it's likely to cost far more people far more hours of labor.

You're right on that, but the solution there is to write a D printf. It's on
the drawing board, just haven't done it yet.

(Perhaps this is an example of what my last supervisor called my being
"argumentative" just before I got laid off.)

LOL! You should see what routinely got written on my job performance
reviews.

It would be ok to change it if it was an obvious change that would result in
compilation errors if used the C way. But that isn't the case here - the
equation will subtly and silently break. This is not a good idea when moving
over a complicated expression from some C code.

Ah, but not if bools are strongly typed such that bitwise operations are illegal
as suggested by someone else last week.
The logical operators should only work for bool expressions, the bitwise
operators should only work for non-bool expressions.
And, having grown up in Boston, I _always_ look both ways before crossing a
street, one way or not. After all, I too have driven the wrong way on a one way
street.
In article <bjrf3n$1rpd$2 digitaldaemon.com>, Mike Wynn says...

John Boucher wrote:

OK, but if bool were strongly typed, it _should_ cause a compilation error,
shouldn't it? Even if unnecessary parentheses were used in the original:
( X & ( Y != Z ) )

Ah, but not if bools are strongly typed such that bitwise operations are
illegal
as suggested by someone else last week.
The logical operators should only work for bool expressions, the bitwise
operators should only work for non-bool expressions.

but the rhs of && or || does not need to be evaluated
with & and | both lhs and rhs are evaluated
so `if ( ((s = foo()) === null) & ((b = bar()) === null) )`
is not the same as
`if ( ((s = foo()) === null) && ((b = bar()) === null) )`
<bool> && <bool> is not quite <bool>& <bool>
also why should bitwise ops not work on bits and bools?

Oh, yeah. Dang! I forgot about the shortcutting inherent in the bitwise
operators. Well, rather than suggest a &&& operator, I'll take a nap and think
about it.
In article <bjsv4d$t5t$1 digitaldaemon.com>, Mike Wynn says...

John Boucher wrote:

Ah, but not if bools are strongly typed such that bitwise operations are
illegal
as suggested by someone else last week.
The logical operators should only work for bool expressions, the bitwise
operators should only work for non-bool expressions.

but the rhs of && or || does not need to be evaluated
with & and | both lhs and rhs are evaluated
so `if ( ((s = foo()) === null) & ((b = bar()) === null) )`
is not the same as
`if ( ((s = foo()) === null) && ((b = bar()) === null) )`
<bool> && <bool> is not quite <bool>& <bool>
also why should bitwise ops not work on bits and bools?

OK, I've had my nap... well actually I didn't, I simply took my son to the park.
Anyway... No need to reorder the precedence. Just strongly type bool.
The precedence order is correct for bools already. And with non-bools it's
unlikely or hopefully erroneous to use comparison operators so the precedence
won't matter.
Going back to
if ( X & Y != Z )
X must be bool or there will be a compilation error because the comparison
operator (which has precedence) will always produce a bool could only be &ed
with another bool.
If X (and Y) is not bool then the programmer more likely meant
if ( ( X & Y ) != Z )
and will need to add the parentheses to say so.
So I'll shut up now... about this anyway. :)
In article <bjt0q3$vek$1 digitaldaemon.com>, John Boucher says...

Oh, yeah. Dang! I forgot about the shortcutting inherent in the bitwise
operators. Well, rather than suggest a &&& operator, I'll take a nap and think
about it.
In article <bjsv4d$t5t$1 digitaldaemon.com>, Mike Wynn says...

John Boucher wrote:

Ah, but not if bools are strongly typed such that bitwise operations are
illegal
as suggested by someone else last week.
The logical operators should only work for bool expressions, the bitwise
operators should only work for non-bool expressions.

but the rhs of && or || does not need to be evaluated
with & and | both lhs and rhs are evaluated
so `if ( ((s = foo()) === null) & ((b = bar()) === null) )`
is not the same as
`if ( ((s = foo()) === null) && ((b = bar()) === null) )`
<bool> && <bool> is not quite <bool>& <bool>
also why should bitwise ops not work on bits and bools?

D doesn't change the operator precedence rules from C/C++ because it would
subtly and silently screw up code that was transferred between the
languages. It also causes haywire in peoples' thinking. For example, in
England, they drive on the wrong (!) side of the road. I found that when I
step into the street, I look to my left for cars, and then get promptly

over by a car coming from the right. My thinking got so screwed up I

to stop trying to remember which rule to apply and look both ways.

He he. Well, given the fact that the majority of the world's population is
right-handed, it is actually correct to have right-hand-drive cars, and
therefore to drive on the left. Think about it...
As for your problems, I can only smile. You guys in the US are too much
ensconced in the "one-way of doing things". In this particular case, I can
recall a time when I drove (right-hand drive) 200 miles from Manchester to
London, got on a plane, flew to Nice (2hrs) and then drove (left-hand drive)
a hire car from Nice to Briancon, and the brain didn't skip a beat. The one
scary moment was halfway through the French half of the journey when I
though to myself "I should be finding this weird!", and then had a,
thankfully resistible, urge to cross over the road.
As for operator precedence, I don't even know them, because I always use
braces.
:)
Cosmopolitan Clive

As for operator precedence, I don't even know them, because I always use
braces.

I.e. you can't remember it either and so look both ways before stepping

the street <g>. Q.E.D.

Before crossing a one-way street, you only have to look in one direction,
but it's not necessarily the way you use to look first... (and John Boucher
thinks *he* is argumentative :-) )
OK guys, back to serious speaking (more or less): AFAIK, code readability
and general good programming practice require to use parentheses to
disambiguate C expressions containing logical boolean operators, so existing
well-written C code shoudn't suffer too much from a good rationalization of
operator precedence. OTOH, this is just theory, and it is true that
perfectly legal C code would go toast before you can smell it. Nonetheless,
I'd go for the change: Lots of Infernally Stupid Parentheses is what I often
think when writing if's in C, more often than when I used LISP.
<div disclaimer="Just kidding..." offsense-intended="0"
take-it-seriously="no">
<img src="Walter_proudly_showing_his_OCCC_award.jpg" alt="Would you take
language specifications from this man?">
</div>
Ric

Touche!
I want to echo, and maybe amplify, John Boucher, and resurrect my request
that all conditional expressions and sub-expressions must be explicitly
boolean. i.e. the following would not compile:
int i;
long j;
if( !i || j) // Filthy stuff!
and would have to be formed as
if (i == 0 || j != 0)
I know this is less likely to get in than I am to get an award for
prosyletisation of C++'s iostreams, but what the hell! I'm someone that
writes code with the intention that it will live a long time, so I'm far
more interested in maintainability than in easy of first writing. It never
ceases to surprise me what little (overt at least) import this gets around
here. Sob sob. (Actually, to be fair, there seems to be precious little
interest in maintainability in any other newsgroups that I can see, so maybe
I need to take my little friend back indoors where its warm.)
"Walter" <walter digitalmars.com> wrote in message
news:bjrer8$1rgd$1 digitaldaemon.com...

Touche!
I want to echo, and maybe amplify, John Boucher, and resurrect my request
that all conditional expressions and sub-expressions must be explicitly
boolean. i.e. the following would not compile:
int i;
long j;
if( !i || j) // Filthy stuff!
and would have to be formed as
if (i == 0 || j != 0)
I know this is less likely to get in than I am to get an award for
prosyletisation of C++'s iostreams, but what the hell! I'm someone that
writes code with the intention that it will live a long time, so I'm far
more interested in maintainability than in easy of first writing. It never
ceases to surprise me what little (overt at least) import this gets around
here. Sob sob. (Actually, to be fair, there seems to be precious little
interest in maintainability in any other newsgroups that I can see, so

I need to take my little friend back indoors where its warm.)

I don't see it as more maintainable, just more typing <g>. It's a C idiom
I'm nearly as used to as my right thumb, and so I don't see the problem with
it. The C idiom that causes trouble is:
if (a = b)
and that *is* illegal in D because it's almost always a typo.

Touche!
I want to echo, and maybe amplify, John Boucher, and resurrect my request
that all conditional expressions and sub-expressions must be explicitly
boolean. i.e. the following would not compile:
int i;
long j;
if( !i || j) // Filthy stuff!
and would have to be formed as
if (i == 0 || j != 0)
I know this is less likely to get in than I am to get an award for
prosyletisation of C++'s iostreams, but what the hell! I'm someone that
writes code with the intention that it will live a long time, so I'm far
more interested in maintainability than in easy of first writing. It never
ceases to surprise me what little (overt at least) import this gets around
here. Sob sob. (Actually, to be fair, there seems to be precious little
interest in maintainability in any other newsgroups that I can see, so

I need to take my little friend back indoors where its warm.)

I don't see it as more maintainable, just more typing <g>. It's a C idiom
I'm nearly as used to as my right thumb, and so I don't see the problem with
it. The C idiom that causes trouble is:
if (a = b)
and that *is* illegal in D because it's almost always a typo.

"almost always" ? So then what do I do when I really _do_ want to do that (not
that I ever do)?
If bool is strongly typed, then
if (a = b)
will fail except when a and b are both bools. So what do we do then?
Is it simply that the parser (or whatever) is checking for the assignment
operator within a boolean expression? I mean this has to affect while and for
loops too right? Although I understand the reasoning, I don't think you should
make the rule affect only a very specific problem. Shouldn't it mean that _no_
form of assignment is allowed in a boolean expression?
But it's not that assignment in a boolean expression is necessarily bad anyway,
so why make it illegal? Perhaps a better idea would be to use the Pascal
assignment operator := and make a bare equal sign an illegal token? I know, I
know, it would cause a lot more work in porting C to D, but it's one of the
things that could be automated with a script, like adding a .* to a printf.
Can I hear an "amen"?
John Boucher
The King had Humpty pushed.

The Pascal := would be a workable alternative, but I like the less-typing =
<g>.

<soapbox>
My feeling about C and UNIX is that they were created by lazy-ass idiots who
felt that saving keystrokes was the be-all and end-all of programming
efficiency. Instead we get problems like this which, as far I know, never
occurred in earlier languages and _cause_ so much additional time and effort in
debugging.
</soapbox>
John Boucher
The King had Humpty pushed.

<soapbox>
My feeling about C and UNIX is that they were created by lazy-ass idiots
who
felt that saving keystrokes was the be-all and end-all of programming
efficiency. Instead we get problems like this which, as far I know, never
occurred in earlier languages and _cause_ so much additional time and
effort in
debugging.
</soapbox>

<soapbox>
My feeling about C and UNIX is that they were created by lazy-ass idiots

felt that saving keystrokes was the be-all and end-all of programming
efficiency. Instead we get problems like this which, as far I know, never
occurred in earlier languages and _cause_ so much additional time and

debugging.
</soapbox>

Our luck is that they used US keyboards and ASCII codes. Had Unicode been
invented before K&R started working on C, there would be single Kanji
characters instead of keywords... :-)
Ric

Touche!
I want to echo, and maybe amplify, John Boucher, and resurrect my request
that all conditional expressions and sub-expressions must be explicitly
boolean. i.e. the following would not compile:
int i;
long j;
if( !i || j) // Filthy stuff!
and would have to be formed as
if (i == 0 || j != 0)
I know this is less likely to get in than I am to get an award for
prosyletisation of C++'s iostreams, but what the hell! I'm someone that
writes code with the intention that it will live a long time, so I'm far
more interested in maintainability than in easy of first writing. It
never
ceases to surprise me what little (overt at least) import this gets
around
here. Sob sob. (Actually, to be fair, there seems to be precious little
interest in maintainability in any other newsgroups that I can see, so
maybe
I need to take my little friend back indoors where its warm.)

This has been my position for many years too. 100% support for this
concept.
'Maintainability' and 'Legibility' have higher priority than 'less typing'
and they are not always synonomous.
Things ought to be as simple as possible, but not too simple. Thus greater
priority should be bestowed on explicit coding rather than implicit
because it tells the reader/maintainer more.
Consider that one must 'translate' or 'interpret' the phrase " if not X
" into " if X is 0 " and " if X " into " if X is not 0 ". This involves a
slight mental flipping, and even if you can do that very quickly, it still
must be done.
--
Derek

that all conditional expressions and sub-expressions must be explicitly
boolean. i.e. the following would not compile:
int i;
long j;
if( !i || j) // Filthy stuff!
and would have to be formed as
if (i == 0 || j != 0)
I know this is less likely to get in than I am to get an award for
prosyletisation of C++'s iostreams, but what the hell! I'm someone that
writes code with the intention that it will live a long time, so I'm far
more interested in maintainability than in easy of first writing. It
never
ceases to surprise me what little (overt at least) import this gets
around
here. Sob sob. (Actually, to be fair, there seems to be precious little
interest in maintainability in any other newsgroups that I can see, so
maybe
I need to take my little friend back indoors where its warm.)

This has been my position for many years too. 100% support for this
concept.
'Maintainability' and 'Legibility' have higher priority than 'less typing'
and they are not always synonomous.

Seems so hard to make people really believe this. Kind of like the argument
that you'll live longer (and happier) if you drive slower on any journey
involving traffic lights!
To be aggressive/bold/assertive/grand, I will personally be very
disappointed if D is not *significantly* more maintainable than C and C++.
Nothing I've seen so far will make it more than *marginally* more
maintainable. :(
There seems to be a confusion (in the wide world, so perhaps it's just me)
that programming for maintainability constrains one into producing
boring/safe/nannied code. I for one am glad that D has pointers, so I can
get down and dirty when I need to. But I am not happy that I can write if(x)
where x can be any non-boolean type. Many a conversation I've had with
people confuses these two types of things. One is power, which we need, the
other sloppiness, which we neither need nor (should) want.
I'm keeping my mind open and my fingers crossed. :)

Things ought to be as simple as possible, but not too simple. Thus greater
priority should be bestowed on explicit coding rather than implicit
because it tells the reader/maintainer more.

I think a rather famous German scientist once said that. One must heartily
concur.

Consider that one must 'translate' or 'interpret' the phrase " if not X
" into " if X is 0 " and " if X " into " if X is not 0 ". This involves a
slight mental flipping, and even if you can do that very quickly, it still
must be done.

Indeed. I just thought through what you said, and it's quite true.
Interesting.

I hate to say it fellows but there are much much bigger fish to fry than
this, if you really want to improve maintainability. Anything that makes
the code easier to refactor, less tightly coupled, will pay off way more
than stripping the essence of C out of the language.
If you really hate C that much, use Java or Modula3. I for one read C++
every day. Little crap like this doesn't even begin to faze me; I think in
C++ terms, so if (i || !j) isn't going to bother me. Trust me, I've seen
FAR worse than that. And I also think that maintenance programmers, if they
can't figure out what the code is doing, they shouldn't be working on that
part of the code. Hire someone who can handle the job.
"Save us from ourselves" is something I hear far too often...
Sean
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bk34is$6j0$1 digitaldaemon.com...

I want to echo, and maybe amplify, John Boucher, and resurrect my

that all conditional expressions and sub-expressions must be

boolean. i.e. the following would not compile:
int i;
long j;
if( !i || j) // Filthy stuff!
and would have to be formed as
if (i == 0 || j != 0)
I know this is less likely to get in than I am to get an award for
prosyletisation of C++'s iostreams, but what the hell! I'm someone

writes code with the intention that it will live a long time, so I'm

more interested in maintainability than in easy of first writing. It
never
ceases to surprise me what little (overt at least) import this gets
around
here. Sob sob. (Actually, to be fair, there seems to be precious

interest in maintainability in any other newsgroups that I can see, so
maybe
I need to take my little friend back indoors where its warm.)

This has been my position for many years too. 100% support for this
concept.
'Maintainability' and 'Legibility' have higher priority than 'less

and they are not always synonomous.

Seems so hard to make people really believe this. Kind of like the

that you'll live longer (and happier) if you drive slower on any journey
involving traffic lights!
To be aggressive/bold/assertive/grand, I will personally be very
disappointed if D is not *significantly* more maintainable than C and C++.
Nothing I've seen so far will make it more than *marginally* more
maintainable. :(
There seems to be a confusion (in the wide world, so perhaps it's just me)
that programming for maintainability constrains one into producing
boring/safe/nannied code. I for one am glad that D has pointers, so I can
get down and dirty when I need to. But I am not happy that I can write

where x can be any non-boolean type. Many a conversation I've had with
people confuses these two types of things. One is power, which we need,

He he. There's something in what you say, Eagle-eye
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bk3pvm$15lg$1 digitaldaemon.com...

I hate to say it fellows but there are much much bigger fish to fry than
this, if you really want to improve maintainability. Anything that makes
the code easier to refactor, less tightly coupled, will pay off way more
than stripping the essence of C out of the language.
If you really hate C that much, use Java or Modula3. I for one read C++
every day. Little crap like this doesn't even begin to faze me; I think

C++ terms, so if (i || !j) isn't going to bother me. Trust me, I've seen
FAR worse than that. And I also think that maintenance programmers, if

can't figure out what the code is doing, they shouldn't be working on that
part of the code. Hire someone who can handle the job.
"Save us from ourselves" is something I hear far too often...
Sean
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bk34is$6j0$1 digitaldaemon.com...

I want to echo, and maybe amplify, John Boucher, and resurrect my

that all conditional expressions and sub-expressions must be

boolean. i.e. the following would not compile:
int i;
long j;
if( !i || j) // Filthy stuff!
and would have to be formed as
if (i == 0 || j != 0)
I know this is less likely to get in than I am to get an award for
prosyletisation of C++'s iostreams, but what the hell! I'm someone

writes code with the intention that it will live a long time, so I'm

more interested in maintainability than in easy of first writing. It
never
ceases to surprise me what little (overt at least) import this gets
around
here. Sob sob. (Actually, to be fair, there seems to be precious

interest in maintainability in any other newsgroups that I can see,

maybe
I need to take my little friend back indoors where its warm.)

This has been my position for many years too. 100% support for this
concept.
'Maintainability' and 'Legibility' have higher priority than 'less

and they are not always synonomous.

Seems so hard to make people really believe this. Kind of like the

that you'll live longer (and happier) if you drive slower on any journey
involving traffic lights!
To be aggressive/bold/assertive/grand, I will personally be very
disappointed if D is not *significantly* more maintainable than C and

Nothing I've seen so far will make it more than *marginally* more
maintainable. :(
There seems to be a confusion (in the wide world, so perhaps it's just

that programming for maintainability constrains one into producing
boring/safe/nannied code. I for one am glad that D has pointers, so I

get down and dirty when I need to. But I am not happy that I can write

where x can be any non-boolean type. Many a conversation I've had with
people confuses these two types of things. One is power, which we need,

As for operator precedence, I don't even know them, because I always use
braces.

I.e. you can't remember it either and so look both ways before stepping into
the street <g>. Q.E.D.

if you believe that brackets should be used to define the eval order
why not use prefix notation for expression its unabigious, and you can "sum"
(+ a b c)
if (== a null ) {
}
if (&& (== b 0) (|| (!= c 1) (!= d 0) (== e 4))) {
(= c (+ a b (* d c)))
}

As for operator precedence, I don't even know them, because I always
use
braces.

I.e. you can't remember it either and so look both ways before stepping
into
the street <g>. Q.E.D.

if you believe that brackets should be used to define the eval order
why not use prefix notation for expression its unabigious, and you can
"sum"
(+ a b c)
if (== a null ) {
}
if (&& (== b 0) (|| (!= c 1) (!= d 0) (== e 4))) {
(= c (+ a b (* d c)))
}