This page lists a lot of C++ traps and pitfalls in a short space. I assume D
has to avoid or render meaningless a quite high percentage of them.
The nice thing of that list is that I think most (maybe 80-90%) of those traps
and pitfalls (and several others that aren't listed, like allowing simple
syntactical mistakes like putting a & where a && was requires or vice versa,
etc) can be avoided by a language like D
but seeing the huge troubles C++ has gone to be as much compatible as possible
with C I'd say that keeping the original C semantics when it is known to cause
troubles is _always_ bad. In such situations I prefer a language that acts
correctly

Most of these pitfalls are actually features, not bugs and are used massively.
Like implicit casts, & instead of &&, assignment instead of comparison etc.
These are pitfalls for novice programmers. Why bother? Everything is a pitfall
for a novice programmer. You can safely say that every feature is a pitfall
because programmer can make mistake in any place. I saw a man writing a program
randomly typing something on the keyboard :) And he's not alone. What will be a
pitfall for such programmers?
ps why there was a need to reinvent identity operator, I wonder? It already was
in JavaScript.

This page lists a lot of C++ traps and pitfalls in a short space. I
assume D has to avoid or render meaningless a quite high percentage of
them.
The nice thing of that list is that I think most (maybe 80-90%) of those
traps and pitfalls (and several others that aren't listed, like allowing
simple syntactical mistakes like putting a & where a && was requires or
vice versa, etc) can be avoided by a language like D
but seeing the huge troubles C++ has gone to be as much compatible as
possible with C I'd say that keeping the original C semantics when it is
known to cause troubles is _always_ bad. In such situations I prefer a
language that acts correctly

Most of these pitfalls are actually features, not bugs and are used
massively. Like implicit casts, & instead of &&, assignment instead of
comparison etc. These are pitfalls for novice programmers. Why bother?

They can be made more difficult to do mistakenly.
Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things can be
easily prevented, and are common mistakes by all programmers.
I appreciate any effort by the compiler to not compile code that can be
definitively declared as invalid. It saves me time and bugs, and that is
worth a lot.
-Steve

I appreciate any effort by the compiler to not compile code that can be
definitively declared as invalid. It saves me time and bugs, and that is
worth a lot.

You said "definitely". Your example is meaningful, but this doesn't affect
my examples.

Yes, you are probably right. Those can be valid either way, much more than
my example.
To be honest though, I more disagree with your assertion that only novice
programmers are affected. I sometimes make these types of mistakes, and I
definitely don't consider myself a novice ;)
-Steve

To be honest though, I more disagree with your assertion that only novice
programmers are affected. I sometimes make these types of mistakes, and I
definitely don't consider myself a novice ;)

The if(e); is illegal in D because back in the 80's, the best programmer
in the company came to me asking me why his for loop executed only once:
for (i = 0; i < N; i++);
...
He had spent all afternoon chasing this problem, first isolating it to
the loop and then trying to figure it out. He was sure it was a compiler
bug. I stared at it for a while, mystified too, until I saw the ;.
There is no advantage to having the language accept such code, and even
if the programmer wrote it on purpose, it *looks* like a bug. Code that
looks right should be right, and code that looks wrong should be wrong.

A good point.
We seem to have a lot of super programmers who don't make simple
mistakes ever and know C++ back to front. That's Great!
For myself, after programming in C++ for 7 years (and other languages
before that) I still find myself making coding typo's and discovering
new things about C++. Keeping an open mind is key to getting better.
I bet even Bjarne Stroustrup himself does not know all the pitfalls he
left in the language.
A couple of quotes to put names to:
"Anyone who has never made a mistake has never tried anything new."
"...it's essential to keep an open mind, and to be willing--better yet,
eager--to try new things."
"The trouble with having an open mind, of course, is that people will
insist on coming along and trying to put things in it."
-Joel

We seem to have a lot of super programmers who don't make simple
mistakes ever and know C++ back to front. That's Great!

Who knows C++? I know C, C# and javascript.

For myself, after programming in C++ for 7 years (and other languages
before that) I still find myself making coding typo's and discovering
new things about C++. Keeping an open mind is key to getting better.

Yeah, C++ is a continuous discovery, may be because of this C++ pros can't get
used to if statement syntax? I thought, fingers know syntax, not brain... well,
it's C++ after all :3

We seem to have a lot of super programmers who don't make simple
mistakes ever and know C++ back to front. That's Great!

Who knows C++? I know C, C# and javascript.

I see then this kinda makes sense from where your coming from. C# has a
load of restrictions that help detect possible gotchas that you don't
get with C++. They could be removed to allow for more "expressive" code
but then you'd have C++. For example, trying to change the size of an
array your iterating over will flag an error in C#.

For myself, after programming in C++ for 7 years (and other languages
before that) I still find myself making coding typo's and discovering
new things about C++. Keeping an open mind is key to getting better.

Yeah, C++ is a continuous discovery, may be because of this C++ pros can't get
used to if statement syntax? I thought, fingers know syntax, not brain... well,
it's C++ after all :3

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things can be
easily prevented, and are common mistakes by all programmers.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

printf("%d\n", 8l);
What does that print?

I wouldn't've, because I use a font that actually distinguishes things
1, I, l, and | properly. <_<

0 and O is another fun one. In any case, 8l is legal C, but illegal D.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

printf("%d\n", 8l);
What does that print?

I wouldn't've, because I use a font that actually distinguishes things
1, I, l, and | properly. <_<

0 and O is another fun one. In any case, 8l is legal C, but illegal D.

In CompSci1 we had use some ridiculous Mac editor where 0 and O were
100% identical, I,l, | and 1 also. It was an incredible source of bugs.
We had to write a parser/emulator for some stupid imaginary asm language
they'd invented, where O01 was output register 1. Plus, whitespace was
significant, but it wasn't a monospaced font...
It was like the whitespace programming language.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

printf("%d\n", 8l);
What does that print?

1, I, l, and | properly. <_<

Threre are various good programmer fonts out there today that are
designed to make the 1 l | and 0 O distinctions clear.
I use the Proggy fonts. http://www.proggyfonts.com/index.php?menu=download
These days I'd say if you're not using one of these fonts for
programming you're being an extremely silly person.
--bb

I use and recommend the DejaVu Sans Mono font. With this font there is
no chance of confusing those troublesome characters, and it's very easy
on the eyes. Also, the DejaVu fonts are available in the repositories of
many (most?) Linux distributions.
http://dejavu.sourceforge.net/
-Lars

Even experienced developers fall into some of these traps. I
know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of
things
can be easily prevented, and are common mistakes by all
programmers.

printf("%d\n", 8l);
What does that print?

1, I, l, and | properly. <_<

Threre are various good programmer fonts out there today that are
designed to make the 1 l | and 0 O distinctions clear.
I use the Proggy fonts.
http://www.proggyfonts.com/index.php?menu=download
These days I'd say if you're not using one of these fonts for
programming you're being an extremely silly person.
--bb

I use and recommend the DejaVu Sans Mono font. With this font there is
no chance of confusing those troublesome characters, and it's very easy
on the eyes. Also, the DejaVu fonts are available in the repositories of
many (most?) Linux distributions.
http://dejavu.sourceforge.net/
-Lars

I was surprised to learn I already have several versions of Deja Vu
installed (on Windows). I've configured all of my text editors and even
Thunderbird to use it now. What a difference! Thanks for pointing it out.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

printf("%d\n", 8l);
What does that print?

8

If I hadn't said it was a trap, I bet you'd have said "81".

I wouldn't've, because I use a font that actually distinguishes things
1, I, l, and | properly. <_<

Same here. I thought the 'trap' was using %d with a *long* value.
--
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

printf("%d\n", 8l);
What does that print?

8

If I hadn't said it was a trap, I bet you'd have said "81".

I wouldn't've, because I use a font that actually distinguishes things
1, I, l, and | properly. <_<

Same here. I thought the 'trap' was using %d with a *long* value.

In my newsgroup client, the lower-case 'L' renders as a straight vertical
line with no serif or anything else. I can't remember ever seeing a
(non-oddball) font where the "one" digit looked like that, so I
instinctively saw it as "8L" and thought the intended gotcha was a
mismatched number of bits causing a zero on a system of the wrong
endianness. That said, I do still like D's requirement that the "L" suffix
be capitalized.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

printf("%d\n", 8l);
What does that print?

8

If I hadn't said it was a trap, I bet you'd have said "81".

I wouldn't've, because I use a font that actually distinguishes things
1, I, l, and | properly. <_<

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

printf("%d\n", 8l);
What does that print?

If I hadn't said it was a trap, I bet you'd have said "81".

I wouldn't've, because I use a font that actually distinguishes things
1, I, l, and | properly. <_<

0 and O is another fun one. In any case, 8l is legal C, but illegal D.

Threre are various good programmer fonts out there today that are
designed to make the 1 l | and 0 O distinctions clear.
I use the Proggy fonts. http://www.proggyfonts.com/index.php?menu=download
These days I'd say if you're not using one of these fonts for
programming you're being an extremely silly person.
--bb

Threre are various good programmer fonts out there today that are
designed to make the 1 l | and 0 O distinctions clear.
I use the Proggy fonts. http://www.proggyfonts.com/index.php?menu=download
These days I'd say if you're not using one of these fonts for
programming you're being an extremely silly person.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things
can be easily prevented, and are common mistakes by all programmers.

Even experienced developers fall into some of these traps. I know I
occasionally fell into this trap:
if(x);
x->doSomething();
But no more with D, because it's not allowed. Those kinds of things can be
easily prevented, and are common mistakes by all programmers.

In Delight it's also quite difficult to fall in that trap:
if x:
x->doSomething()
Many variants of that syntax are all disallowed:
if x
x->doSomething()
if x:
x->doSomething()
if x
x->doSomething()
etc.
So instead of making the language more confusing, it actually has the opposite
effect.
Bye,
bearophile