bearophile Wrote:

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

"ore-sama" wrote
> bearophile Wrote:
>
>> 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

ore-sama:
> These are pitfalls for novice programmers. Why bother?<

I want D to be a little more novice-friendly than C++.
After 8 hours of coding, when I'm tired, I'm a novice myself, and I can appreciate any help the compiler can offer.

Bye,
bearophile

Steven Schveighoffer Wrote:

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

"ore-sama" wrote
> Steven Schveighoffer Wrote:
>
>> 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

Steven Schveighoffer wrote:
> 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.

Steven Schveighoffer wrote:
> 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.

Here's another fun one:

    printf("%d\n", 8l);

What does that print?

Reply to Walter,

> Steven Schveighoffer wrote:
> 
>> 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.
>> 
> Here's another fun one:
> 
> printf("%d\n", 8l);
> 
> What does that print?
> 

8

On Thu, 06 Nov 2008 23:34:55 +0300, Walter Bright <newshound1@digitalmars.com> wrote:

> Steven Schveighoffer wrote:
>> 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.
>
> Here's another fun one:
>
>      printf("%d\n", 8l);
>
> What does that print?

Yay, it is hardly distiguishable even at 500% zoom (Courier New)!

"BCS" wrote
> Reply to Walter,
>
>> Steven Schveighoffer wrote:
>>
>>> 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.
>>>
>> Here's another fun one:
>>
>> printf("%d\n", 8l);
>>
>> What does that print?
>>
>
> 8

On little endian systems, yes.  On big endian it would print 0.

-Steve