www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: How does D improve design practices over C++?

reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
Walter Bright Wrote:


 Bill Baxter wrote:

 On Wed, Oct 29, 2008 at 4:13 PM, Walter Bright
 <newshound1 digitalmars.com> wrote:

 Janderson wrote:



 - The override keyword helps you make sure really overriding something.
 
 Been fighting with some bugs in C++ that would have been prevented by that one.



 Add the corresponding final keyword in then, too, which *prevents* 
 overriding.



This is great.

I've submitted an abstract for an oral presentation on "Compiler-Assisted
Quality" at an upcoming Boeing software conference. (I haven't heard yet
whether it's been accepted.) I was going to ask for a list like this to help
prepare the presentation.

The theme of the conference is software quality, which is why I had to give the
presentation that dorky name. The presentations are not supposed to be
vendor-specific so I hesitated to use "D Programming Language" in the title
(even though D is free as in free beer) but I will be using D for all the
examples. Thanks again.

Paul
Oct 29 2008
parent reply bearophile <bearophileHUGS lycos.com> writes:
Paul D. Anderson:

I've submitted an abstract for an oral presentation on "Compiler-Assisted
Quality" at an upcoming Boeing software conference. (I haven't heard yet
whether it's been accepted.) I was going to ask for a list like this to help
prepare the presentation.<



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

Bye,
bearophile
Oct 29 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Oct 29 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:

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



Yes, you are right, I have mixed two different things. They are almost
orthogonal.
The final purpose of a good language is to allow to write in a short enough
time programs that give the correct output.
But the things I was referring to are helpers to avoid putting bugs into the
code, while SafeD is a way to not have really bad memory consequences if a
certain class of errors are present anyway in the code :-)

Bye,
bearophile
Oct 29 2008
parent reply Paul D. Anderson <paul.d.removethis.anderson comcast.andthis.net> writes:
bearophile Wrote:


 Walter Bright:

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



 Yes, you are right, I have mixed two different things. They are almost
orthogonal.
 The final purpose of a good language is to allow to write in a short enough
time programs that give the correct output.
 But the things I was referring to are helpers to avoid putting bugs into the
code, while SafeD is a way to not have really bad memory consequences if a
certain class of errors are present anyway in the code :-)
 
 Bye,
 bearophile



Since Boeing is a defense contractor many projects require safety in the "safe
from accidentally doing something that could hurt somebody" sense. Some
projects require a safety review (in the above sense) and an airworthiness
review (in an obviously related sense). The current practice is an elaborate
line-by-line, change-by-change review process, as well as an extensive test
program.

I doubt that the DoD will ever do away with these reviews (nor do I think they
should) but any help the programmers can get from the compiler to avoid unsafe
programming "gotchas" has a potential for real cost savings -- finding the
problem when it is cheap to fix, rather than in a costly review, revise,
recheck loop at the end of the design effort. And Boeing likes cost savings.

This is why I'm trying to get D noticed here at Boeing. It's a very good fit
for the things we do -- safe (memory safe and physically safe), efficient,
powerful without being too complex, and a capable systems language. We still do
a lot of bit-twiddling programming and need to be able to get to the hardware.

Paul

p.s. I'd forgotten about SafeD. Thanks for the reminder.
Oct 29 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Paul D. Anderson wrote:

 This is why I'm trying to get D noticed here at Boeing. It's a very
 good fit for the things we do -- safe (memory safe and physically
 safe), efficient, powerful without being too complex, and a capable
 systems language. We still do a lot of bit-twiddling programming and
 need to be able to get to the hardware.



I used to work at Boeing (757 stab trim design), so I have a particular 
interest in how this works out. Please keep us up to date! If I can 
help, let me know.

I'm also available to give a presentation at Boeing if invited <g>.
Oct 29 2008
prev sibling next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jarrett Billingsley wrote:

 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.



Assuming it still allows heap-allocated objects, something like this 
will still work:
----
class C {
     ubyte[16 * 1024 * 1024 - 1] memory;
}

void poke(size_t intptr, ubyte b) {
     C c; // kept at null deliberately
     c.memory[intptr - c.memory.offsetof] = b;
}

ubyte peek(size_t intptr) {
     C c; // kept at null deliberately
     return c.memory[intptr - c.memory.offsetof];
}
-----

(That is, unless it emits 'this' null-checks for object field accesses 
as well)
Oct 29 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Frits van Bommel wrote:

 Assuming it still allows heap-allocated objects, something like this 
 will still work:
 ----
 class C {
     ubyte[16 * 1024 * 1024 - 1] memory;
 }



The fix for that is to disallow objects with a large static size.
Oct 29 2008
parent Sean Kelly <sean invisibleduck.org> writes:
Walter Bright wrote:

 Frits van Bommel wrote:

 Assuming it still allows heap-allocated objects, something like this 
 will still work:
 ----
 class C {
     ubyte[16 * 1024 * 1024 - 1] memory;
 }



 The fix for that is to disallow objects with a large static size.



DMD assumes this anyway for its invariant -> object conversion routine, 
if I remember correctly, but the max size there is still pretty 
considerable.


Sean
Oct 29 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 I kind of imagined it would.  I thought the entire point of SafeD
 would be that the language would completely disallow you from touching
 memory that you don't own.  Which would include Java-like null
 reference checks.



Fortunately, the hardware does the checking for null pointers for you.
Oct 29 2008
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:

 On Wed, 29 Oct 2008, Walter Bright wrote:

 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.



True, but technically that is not a null pointer dereference. There are 
also ways to deal with it. One is to disallow fixed offsets exceeding 
the protected null space (Java prohibits objects > 64Kb in size for this 
reason). Next is to disallow pointer arithmetic (which is what SafeD 
proposes).


 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.



You're right, and SafeD should make such exploits impossible.
Oct 29 2008
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
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
Oct 29 2008
prev sibling next sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 5:43 PM, Brad Roberts <braddr 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.
Oct 29 2008
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Wed, 29 Oct 2008, Jarrett Billingsley wrote:


 On Wed, Oct 29, 2008 at 5:43 PM, Brad Roberts <braddr 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
Oct 29 2008
prev sibling parent "Jarrett Billingsley" <jarrett.billingsley gmail.com> writes:
On Wed, Oct 29, 2008 at 7:15 PM, Frits van Bommel
<fvbommel remwovexcapss.nl> wrote:

 Jarrett Billingsley wrote:

 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.



 Assuming it still allows heap-allocated objects, something like this will
 still work:
 ----
 class C {
    ubyte[16 * 1024 * 1024 - 1] memory;
 }

 void poke(size_t intptr, ubyte b) {
    C c; // kept at null deliberately
    c.memory[intptr - c.memory.offsetof] = b;
 }

 ubyte peek(size_t intptr) {
    C c; // kept at null deliberately
    return c.memory[intptr - c.memory.offsetof];
 }
 -----

 (That is, unless it emits 'this' null-checks for object field accesses as
 well)



I kind of imagined it would.  I thought the entire point of SafeD
would be that the language would completely disallow you from touching
memory that you don't own.  Which would include Java-like null
reference checks.
Oct 29 2008