How does D improve design practices over C++?

[Brad Roberts]

On Wed, 29 Oct 2008, Jarrett Billingsley wrote:

> On Wed, Oct 29, 2008 at 5:43 PM, Brad Roberts <braddr at puremagic.com> wrote:
> > On Wed, 29 Oct 2008, Walter Bright wrote:
> >
> >> bearophile wrote:
> >> > D1 is often safer than C and C++, but regarding safety there are
> >> > several things that can improved still, often with no/little
> >> > performance penalty (unsafe casting (automatic and manual), integral
> >> > overflows, GC pointers Vs other pointers, nonnull types, named
> >> > arguments, fallthrough switch cases, multi var assigns syntax
> >> > missing, octal literals, bitwise operators as symbols instead English
> >> > words, and many other smaller things I have listed in the past). You
> >> > may want to tell them about the idea of SafeD too (javesque D).
> >>
> >> "Safety" in programming languages does not refer to program correctness, but
> >> absence of bugs that could result in memory corruption. The agenda of SafeD is
> >> to find the subset of D that can guarantee there is no memory corruption.
> >>
> >> Null pointer dereferencing, for example, is a program bug but is not a safety
> >> issue because it cannot cause memory corruption.
> >
> > Actually, that's not true.  Dereferencing null _can_ corrupt memory.  As
> > you well know, ptr[index] is just ptr + index.  Use a large and accurate
> > enough index and you're out of that first page of memory and back into
> > application memory space.  Find the address of a key stack variable and
> > you've got room for all sorts of fun and mahem.
> >
> > These are the sorts of bugs in popular enough applications are the things
> > that end up costing companies lots of money to emergency fix.  One of the
> > few recent flash exploits were exactly this type of bug.
> >
> > Later,
> > Brad
> >
> 
> Interestingly, although null dereferences are unsafe, in a safe
> language like SafeD it's not actually possible to do so.  There are no
> pointers and arrays are bounds-checked.  So with the combination of
> the typing system and the runtime checks, null can never actually be
> dereferenced, so no special consideration has to be given to it.

Unless something's changed, pointers aren't even a part of SafeD, so that 
line of reasoning is largely irrelevant.  I was also talking about the 
larger context of the thread, which includes what 'safety' means in the 
context of programming in general.  Since this thread included c and c++, 
it's a legit concern.

If we're going to include the broader d language, the bounds checking is 
only on for some builds, not all builds, so the problem still exists there 
too.

Later,
Brad