www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C/C++ style Crashes?

reply Jon Grant <jg-no-spam jguk.org> writes:
Hi
Just having a look at the D language.
Does D still let the programmer allocate memory, cast addresses and read/write
direct address space as we can from C/C++?


Cheers
Jon
--
Weblog: http://jguk.org/
Jan 07 2007
next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
Jon Grant wrote:

 Hi
 Just having a look at the D language.
 Does D still let the programmer allocate memory, cast addresses and read/write
 direct address space as we can from C/C++?


You can use malloc & friends if you feel like, of course.



access.


Sure.


 Cheers
 Jon
 --
 Weblog: http://jguk.org/
Jan 07 2007
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Mon, 08 Jan 2007 02:15:09 +0100, Alexander Panek
<a.panek brainsware.org> wrote:



access.


Sure.


No, D does not solve this problem. You can cast pointers and do
pointer arithmetic in D if you want to.

This is important. Java is a limited languages because it makes code
'more reliable' by eliminating needed features. In reality, this
doesn't make things more reliable since you then have to work around
the limitations or simply accept that there are things that you can't
do.

In a systems language, pointer arithmetic is a necessity. There are
things you simply cannot do without it - data structures that require
it, for instance. It's all very well saying that you have lists and
hashes built in, but while these are very powerful and can do a lot,
they are not sufficient for handling every requirement especially when
efficiency (both speed and memory) is a major concern.

A reasonable analogy would be that it's like trying to improve road
safety by banning cars. Cars are dangerous so surely banning them
would improve safety, after all? Well, maybe, but only by making many
journeys impossible and by wasting a great deal of time on many
others. And its worth bearing in mind that there are far more
dangerous ways to travel than in a car.

Besides, the damage done to the economy would mean that less money is
available, which means that you can't afford health care, police, fire
and rescue services, etc etc. Whoops - not so great after all.

Sometimes, the lack of the ability to do pointer arithmetic is very
much like that. You end up having to do a lot of work to work around
the limitation. You don't get the gains that doing pointer arithmetic
can provide, and the knock-on issues in terms of development time and
code efficiency make the whole project far more difficult. And the
loss of those code efficiency gains mean you have to look elsewhere
for efficiency gains to compensate, causing further development time
issues.

Funny thing. My father is a builder. He handles dangerous tools every
day. Hundreds of them. We programmers like to consider ourselves more
intelligent than builders, and yet we are like toddlers who need
safety gates on the stairs - god help the person who suggests that we
should know how and when to climb the stairs safely.

It should be pretty obvious by now that this kind of stuff really
pisses me off. Its pathetic. Before long, Eclipse is probably going to
have a 'safety feature' that refuses to let you write any code until
you strap yourself safely into your chair. And ten minutes after you
start, it'll offer to change your nappy. In the past, you used to get
fired for wanting to go home at 7PM. Give it a year or two and by 7PM
your IDE will be tucking you into bed and reading you fairy stories.

-- 
Remove 'wants' and 'nospam' from e-mail.
Jan 08 2007
next sibling parent reply Alexander Panek <a.panek brainsware.org> writes:
And what exactly is it that makes D not solving this problem?
Jan 08 2007
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Mon, 08 Jan 2007 19:30:12 +0100, Alexander Panek
<a.panek brainsware.org> wrote:


And what exactly is it that makes D not solving this problem?


My reading of Jon Grants post...

: Does D still let the programmer allocate memory, cast addresses and read/write
: direct address space as we can from C/C++?
: 

access.

Is that the 'problem' is crashes due to pointer handling in C/C++.
This 'problem' is 'solved' in Java and some other languages by
basically banning pointer arithmetic.

Since D allows any pointer manipulation as C/C++, it can suffer the
same crashes and therefore has the same 'problem'.

And my point is that the true problem is bad programmers who don't
take responsibility for their code and don't know how to program. You
can't fix that by banning language features.

So D has the same 'problem' that C and C++ have in relation to pointer
handling, I just don't believe its a real problem.

-- 
Remove 'wants' and 'nospam' from e-mail.
Jan 08 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
Steve Horne wrote:

 On Mon, 08 Jan 2007 19:30:12 +0100, Alexander Panek
 <a.panek brainsware.org> wrote:
 

 And what exactly is it that makes D not solving this problem?


 
 My reading of Jon Grants post...
 
 : Does D still let the programmer allocate memory, cast addresses and
read/write
 : direct address space as we can from C/C++?
 : 

access.
 
 Is that the 'problem' is crashes due to pointer handling in C/C++.
 This 'problem' is 'solved' in Java and some other languages by
 basically banning pointer arithmetic.


Ok, I might have misunderstood something there. I thought the 'problem' 
would be that there's no language that allows both, high and low level 
access to memory.


 
 Since D allows any pointer manipulation as C/C++, it can suffer the
 same crashes and therefore has the same 'problem'.
 
 And my point is that the true problem is bad programmers who don't
 take responsibility for their code and don't know how to program. You
 can't fix that by banning language features.


This is very true.


 
 So D has the same 'problem' that C and C++ have in relation to pointer
 handling, I just don't believe its a real problem.


Me neither, as you might have guessed already. ;)
Jan 08 2007
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Tue, 09 Jan 2007 07:41:35 +0100, Alexander Panek
<a.panek brainsware.org> wrote:


Ok, I might have misunderstood something there. I thought the 'problem' 
would be that there's no language that allows both, high and low level 
access to memory.


No worries. It was me who was getting all stressy after all, and the
original post could be read several different ways on reflection.

-- 
Remove 'wants' and 'nospam' from e-mail.
Jan 09 2007
prev sibling parent reply Sebastian Biallas <groups.5.sepp spamgourmet.com> writes:
Steve Horne wrote:

 In a systems language, pointer arithmetic is a necessity. There are
 things you simply cannot do without it - data structures that require
 it, for instance.


Can you give an example?
Jan 11 2007
next sibling parent Alexander Panek <a.panek brainsware.org> writes:
Sebastian Biallas wrote:

 Steve Horne wrote:

 In a systems language, pointer arithmetic is a necessity. There are
 things you simply cannot do without it - data structures that require
 it, for instance.


 
 Can you give an example?


http://trac.brainsware.org/ocb/browser/trunk/src/arch/x86/idt.c

This is not D, yet, but it's pointer arithmetic. You need to do this, 
because you have to split up the address and write lower and higher half 
to two different places in the structure of the descriptor. (x86 
backwards compatibility, yay!)

Best regards,
Alex
Jan 12 2007
prev sibling parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Fri, 12 Jan 2007 04:02:50 +0100, Sebastian Biallas
<groups.5.sepp spamgourmet.com> wrote:


Steve Horne wrote:

 In a systems language, pointer arithmetic is a necessity. There are
 things you simply cannot do without it - data structures that require
 it, for instance.


Can you give an example?


A particular favorite of mine allows doubly-linked list behaviour
using a single link per item - very useful if you need extremely large
lists of small items (though a custom allocator is essential). Each
link is actually the bitwise exclusive-or of the addresses of the
previous and next items. This may sound impossible to iterate, but if
the iterator contains two pointers pointing to two adjacent items, it
is actually quite easy to step in either direction. Stepping always
requires a bitwise exclusive-or of a pointer, and inserts and deletes
require multiple bitwise exclusive-ors on pointers.

In addition, pointer casting is useful for managing template bloat.
The basic approach is to write type-unsafe non-template code, and then
use a template to add a typesafe wrapper. But in many cases, more
flexibility is needed than can be handled using simple pointer
casting.

For example, consider a library to handle flexible tree data
structures. The container being implemented may or may not have a key
field. It may or may not have a data field. It may or may not have
subtree summary data stored within nodes. The non-template part needs
a way to access fields such that the position within a node struct (of
an unknown datatype) is determined at run-time.

The most efficient way to handle this depends on what kind of
operation is being implemented. A single data structure may have two
or more ways to access the same field, just to ensure that all
operations can be handled efficiently - many accesses will probably be
done as part of small functions supplied by the typesafe wrapper, to
keep the call overheads down in inner loops. But for many accesses,
the best approach is using the offset of a field relative to the start
of a node - a relative address. The non-template code gets the
relative addresses it needs from a data block provided by the typesafe
wrapper, which does a similar job to that done by virtual tables in
method calls.

-- 
Remove 'wants' and 'nospam' from e-mail.
Jan 14 2007
parent reply Sebastian Biallas <groups.5.sepp spamgourmet.com> writes:
Steve Horne wrote:

 On Fri, 12 Jan 2007 04:02:50 +0100, Sebastian Biallas
 <groups.5.sepp spamgourmet.com> wrote:
 

 Steve Horne wrote:

 In a systems language, pointer arithmetic is a necessity. There are
 things you simply cannot do without it - data structures that require
 it, for instance.


 Can you give an example?


 
 A particular favorite of mine allows doubly-linked list behaviour
 using a single link per item - very useful if you need extremely large
 lists of small items (though a custom allocator is essential). 


I know of these lists. But they don't seem to be particulary useful:

a) Where do you need extremely large lists? Lists have a search time in
O(n). Ok, you have a O(1) insertion/deletion here, but only at one
place, since your iterators get void after an insertion/deletion
(contrary to normal double linked lists)
b) They don't work in a GC-enviroment or require special handling.

Are they really used somewhere out of the IOCCC? I'd be curious to see a
real world example.


 In addition, pointer casting is useful for managing template bloat.
 The basic approach is to write type-unsafe non-template code, and then
 use a template to add a typesafe wrapper. 


This works with normal pointer casting (no need for arithmetik). Hey,
this was even the normal usage of Java-Containers before they had the
template stuff.


 But in many cases, more
 flexibility is needed than can be handled using simple pointer
 casting.
 
 For example, consider a library to handle flexible tree data
 structures. The container being implemented may or may not have a key
 field. It may or may not have a data field. It may or may not have
 subtree summary data stored within nodes. The non-template part needs
 a way to access fields such that the position within a node struct (of
 an unknown datatype) is determined at run-time.


I don't think it's a good idea to trade portability for a few cycles.
And this might be even slower, since you confuse the compiler
(alias-analysis etc).
Jan 15 2007
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Mon, 15 Jan 2007 17:54:57 +0100, Sebastian Biallas
<groups.5.sepp spamgourmet.com> wrote:


a) Where do you need extremely large lists? Lists have a search time in
O(n). Ok, you have a O(1) insertion/deletion here, but only at one
place, since your iterators get void after an insertion/deletion
(contrary to normal double linked lists)


Depends what you're storing in the list. Consider a word processor
that is expected to handle large documents, for instance. You keep a
few iterators for key current positions, but almost all accesses are
sequential. Jumping to a specific page number is not, but that can
afford a delay, or else you can keep a mapping of page numbers to
start position iterators separately. A huge array of characters would
cause problems with inserts and deletes, but a list handles this
easily.

There are other approaches, but few as simple or elegant as they tend
to require a pair of data structure approaches working together (for
example a linked list of short strings).


b) They don't work in a GC-enviroment or require special handling.


It's called opting out of garbage collection, and certainly it would
be required in this case. Kind of handy that D allows this, therefore.


Are they really used somewhere out of the IOCCC? I'd be curious to see a
real world example.


The obfuscated C contest is about obfuscated code style. These lists
can be implemented as cleanly and clearly as any other data structure
- the code is far simpler than, for instance, red-black balanced
binary trees (as used in the STL).

So consider the word processor example. One alternative approach would
be to use a huge vector of characters, but that wouldn't work well for
insertions and deletions - the larger the document, the longer it
takes to resize the array. Another approach is to use a list of short
arrays of characters, but then you're mixing two data structure
approaches. Issues like merging overly small arrays and splitting
overly long arrays would complicate the code, by your logic making it
a candidate for the obfuscated C contest itself.

It is possible to create a tree data structure that implements a
vector-style container, and which can implement efficient inserts and
deletes anywhere, and using a multiway tree keeps the overheads
relatively small and helps with cache performance, but of course you
won't find support for this data structure in any existing language or
standard library that I know of so we are back in
creating-a-new-core-data-structure territory, with the usual bloat
management issues, and this is a significantly more complex data
structure to implement than the list approach already described (trust
me, I've done exactly this in C++).

I've never needed to write a word processor myself (I've written text
layout code, but it was non-interactive, and I've written a text
editor, but that was back in the days of DOS 3) but if you ever need
to do so, I'd recommend that you give serious consideration to the
list approach I described. Of the options that can actually handle the
job efficiently, it just might be the most simple and elegant option
available.


 In addition, pointer casting is useful for managing template bloat.
 The basic approach is to write type-unsafe non-template code, and then
 use a template to add a typesafe wrapper. 


This works with normal pointer casting (no need for arithmetik). Hey,
this was even the normal usage of Java-Containers before they had the
template stuff.


Yes - that was explanation leading into the point, not the point
itself.


 But in many cases, more
 flexibility is needed than can be handled using simple pointer
 casting.
 
 For example, consider a library to handle flexible tree data
 structures. The container being implemented may or may not have a key
 field. It may or may not have a data field. It may or may not have
 subtree summary data stored within nodes. The non-template part needs
 a way to access fields such that the position within a node struct (of
 an unknown datatype) is determined at run-time.


I don't think it's a good idea to trade portability for a few cycles.
And this might be even slower, since you confuse the compiler
(alias-analysis etc).


It should be clear that we're not talking about everyday apps
programming here. To the extent that it would be used in an
application at all, the word processor example above is probably
relevant - it would implement a core data structure in a large
application, but most developers working on the app wouldn't touch the
internals of that data structure.

The portability issues are real but not hard to handle. For getting
the offset of a specific field, for instance, the C standard library
has an offsetof macro for precisely this kind of work. The template
wrapper simply defines the struct it needs and uses offsetof to
extract the needed offsets - technicalities such as alignment are
handled automatically. The biggest issue is making sure that offsets
are held in integers of the right size, and even that isn't much of a
hassle - if you can't find an integer-the-same-size-as-a-pointer type
in the language or library, you simply define your own using
conditional compilation or template specialisation or whatever.

As for the 'a few cycles' thing, remember that we are talking about
defining core data structures here - things that will be accessed a
great deal, often in inner loops. The performance of core data
structures is important enough that Walter makes a big deal of the few
cycles per access saved due to Ds handling of hash tables (using
binary trees to handle collisions, as opposed to other common
implementations that use linked lists), and rightly so. If you have an
application that does millions of accesses, those few cycles per
access can really start to accumulate.

In fact one of the reasons why scripting languages have their core
data structures built into the language is simply that if they were
implemented using the scripting languages themselves, the performance
would be far too poor to be practical. Having efficient operations on
core data structures is extremely important.

It is of course true that, in general, programmers shouldn't fuss
about code optimisation too much - choice of algorithm and data
structure, yes, but fiddling with implementation details definitely
not. Key operations on core data structures are often an exception to
this rule, however.

And yes, there is a real chance that doing this may be slower for some
operations - very much slower. That is why I said...

: The most efficient way to handle this depends on what kind of
: operation is being implemented. A single data structure may have two
: or more ways to access the same field, just to ensure that all
: operations can be handled efficiently - many accesses will probably be
: done as part of small functions supplied by the typesafe wrapper, to
: keep the call overheads down in inner loops.

... and also why I said these techniques are needed to manage bloat
(rather than completely eliminate it). The compiler can handle these
small inner-loop functions very well, but they create bloat since each
instantiation of the template wrapper creates a new set of these small
functions. Therefore, there is an issue of balance.

So it is absolutely true that these are not things to mess with every
day. They require care, and for most things you are far better off
sticking with the containers supplied by the language itself or its
standard libraries. But there are exceptions to this rule, and
depending on the kind of code that you tend to work on, these
exceptions can happen more often than you might realise. And in any
case, someone has to write the standard library containers in the
first place.

-- 
Remove 'wants' and 'nospam' from e-mail.
Jan 15 2007
prev sibling next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Jon Grant wrote:

 Hi
 Just having a look at the D language.
 Does D still let the programmer allocate memory, cast addresses and read/write
 direct address space as we can from C/C++?
 

access.
 Cheers
 Jon
 --
 Weblog: http://jguk.org/


You can play with pointers anyway you want, it's designed to be a 
systems language; if you can do it in C you can do it in D.
In fact, D even lets you write assembly.
Jan 07 2007
parent Lutger <lutger.blijdestijn gmail.com> writes:
Hasan Aljudy wrote:

 
 
 Jon Grant wrote:

 Hi
 Just having a look at the D language.
 Does D still let the programmer allocate memory, cast addresses and 
 read/write
 direct address space as we can from C/C++?


 such access.
 Cheers
 Jon
 -- 
 Weblog: http://jguk.org/


 
 You can play with pointers anyway you want, it's designed to be a 
 systems language; if you can do it in C you can do it in D.
 In fact, D even lets you write assembly.


In addition to that: you can do it, but you don't need to as in C/C++. 
You can program entirely without pointers.

So does D solves this problem? I'd say yes if the problem is that in 
C/C++ it is too easy to crash an application.

I very rarely have bugs in my little programs that make for a crash. 
More importantly, if I do have a crash it is obvious that I have messed 
up bigtime and can repair the bug quickly. (within minutes, without a 
debugger).
Jan 08 2007
prev sibling parent reply Sebastian Biallas <groups.5.sepp spamgourmet.com> writes:
Jon Grant wrote:

 Hi
 Just having a look at the D language.
 Does D still let the programmer allocate memory, cast addresses and read/write
 direct address space as we can from C/C++?
 

access.


An important point is that this doesn't solve this problem either. Ok,
you get an exception instead of some "undefined behaviour", which is
somehow better when debugging, but:

It just doen't solve the problem that you have a bug in your program in
the first place. Reread that sentence.

Getting an unexpected exception in a shipped application is a huge bug.
In fact it can be:

*) a security risc: the program is taking a path of execution the
programmer haven't thought of.
*) a security risc2: some data might be in a undefined state after the
exception
*) a data risc: the program might be in an undefined state. Saving now,
might save garbage.

[As you might have noticed, these are exactly the problem you have with
C, C++ and D]

And, even worse, not only that Java doesn't help you getting the
exception handlers right in the code, it doesn't help you avoiding
exceptions in the first place (it getting better with the template types
(don't know how they call it)).
Jan 11 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
Sebastian Biallas wrote:

 Jon Grant wrote:

 Hi
 Just having a look at the D language.
 Does D still let the programmer allocate memory, cast addresses and read/write
 direct address space as we can from C/C++?


access.


 
 An important point is that this doesn't solve this problem either. Ok,
 you get an exception instead of some "undefined behaviour", which is
 somehow better when debugging, but:
 
 It just doen't solve the problem that you have a bug in your program in
 the first place. Reread that sentence.


Exceptions can be handled at runtime, still. try (to) catch it and there 
you go. :)


 
 Getting an unexpected exception in a shipped application is a huge bug.


That's why you always /test/ everything so good, that you just don't get 
unexpected exceptions.


 In fact it can be:
 
 *) a security risc: the program is taking a path of execution the
 programmer haven't thought of.
 *) a security risc2: some data might be in a undefined state after the
 exception
 *) a data risc: the program might be in an undefined state. Saving now,
 might save garbage.
 
 [As you might have noticed, these are exactly the problem you have with
 C, C++ and D]
 
 And, even worse, not only that Java doesn't help you getting the
 exception handlers right in the code, it doesn't help you avoiding
 exceptions in the first place (it getting better with the template types
 (don't know how they call it)).


What's the huge problem with exception handlers? They worked for me 
pretty well so far to avoid a unhandled exceptions that just terminate 
the program.
Jan 12 2007
next sibling parent reply Sebastian Biallas <groups.5.sepp spamgourmet.com> writes:
Alexander Panek wrote:

 Sebastian Biallas wrote:

 Jon Grant wrote:

 Hi
 Just having a look at the D language.
 Does D still let the programmer allocate memory, cast addresses and
 read/write
 direct address space as we can from C/C++?


 such access.


 An important point is that this doesn't solve this problem either. Ok,
 you get an exception instead of some "undefined behaviour", which is
 somehow better when debugging, but:

 It just doen't solve the problem that you have a bug in your program in
 the first place. Reread that sentence.


 
 Exceptions can be handled at runtime, still. try (to) catch it and there
 you go. :)


So, how exactly do you /handle/ an exception which "should not be there"?


 Getting an unexpected exception in a shipped application is a huge bug.


 
 That's why you always /test/ everything so good, that you just don't get
 unexpected exceptions.


Well, so you shouldn't need exceptions at all for array handling, right?
(Except for debugging, where they really help)


 What's the huge problem with exception handlers? 


There is nothing wrong which exception handlers for handling exceptions
that the programmer thought of (file-not-found, io-error, etc).

But things like ArrayOutOfBounds, NullPointer and CastErrorException are
bugs in the program (usually). Often they get thrown at places where
there's no appropriate catch around or transaction logic so they get
caught by some high level "catch everything".

So what to do now? The program is now in an unstable state.
And even if you catch the Exception on the right place: The Exception
should never have been thrown. There is a bug, and the bug is not
necessarily at the place where the exception was thrown -- the program
might have been in an inconsistent state for hours.


 They worked for me
 pretty well so far to avoid a unhandled exceptions that just terminate
 the program.


It would be even better if the compiler could prove at compiler-time,
that there are no OutOfBound, NullPointer and CastExceptions possible.

While this is hard for ArrayOutOfBounds, there are quite easy ways for
avoiding NullPointer and CastExceptions at all. In the language Nice[1]
they do this as follows:

NullPointer: They have different types for pointers that can be null
(?Type) and pointer that can't (Type). You can't dereference a ?Type
variable.

So, let's say we have

void foo(?Type t)
{
	// we want to dereference t
	if (t != null) {
		// now the compiler "magically" converts t to type Type
		t.doSomething();
	}
}

TypeCasts: You don't cast with a cast-operator, but with a
instance-of-expression:

void bar(A a)
{
	if (a instanceOf B) {
		// now a is of type B, no need to cast
	}
}

I haven't used this language yet, but these are certainly, well, nice
features :)

[1] http://nice.sf.net
Jan 12 2007
parent reply Alexander Panek <a.panek brainsware.org> writes:
Sebastian Biallas wrote:

 [...]
 It just doen't solve the problem that you have a bug in your program in
 the first place. Reread that sentence.


 Exceptions can be handled at runtime, still. try (to) catch it and there
 you go. :)


 
 So, how exactly do you /handle/ an exception which "should not be there"?


One has to make sure to catch all "should not be there" exceptions, too 
(ideally). In the real world, of course, there can happen to be mistakes 
in the code, hidden bugs and what not else. But the fact is, that in 
most software, that is really fully tested, those happen very rarely and 
can be handled with special routines - maybe also automatically sending 
a bug report to the developers or the IT department of a company. This 
depends on what kind of software you write/use(libraries). Apart from 
that, D has this neat scope(fail) thing, that will cover almost all 
circumstances, except segmentation faults .. ;)


 

 Getting an unexpected exception in a shipped application is a huge bug.


 That's why you always /test/ everything so good, that you just don't get
 unexpected exceptions.


 
 Well, so you shouldn't need exceptions at all for array handling, right?
 (Except for debugging, where they really help)


As soon as the amount of /dynamic/ data you have to handle grows, I 
don't think there's a way around using at least exceptions to stay safe.


 

 What's the huge problem with exception handlers? 


 
 There is nothing wrong which exception handlers for handling exceptions
 that the programmer thought of (file-not-found, io-error, etc).
 
 But things like ArrayOutOfBounds, NullPointer and CastErrorException are
 bugs in the program (usually). Often they get thrown at places where
 there's no appropriate catch around or transaction logic so they get
 caught by some high level "catch everything".
 
 So what to do now? The program is now in an unstable state.
 And even if you catch the Exception on the right place: The Exception
 should never have been thrown. There is a bug, and the bug is not
 necessarily at the place where the exception was thrown -- the program
 might have been in an inconsistent state for hours.


This is, of course, not so good. But then again, you should design the 
software in a way that avoids such circumstances (yes, this is not 
possible in any cases, but in very much).


 

 They worked for me
 pretty well so far to avoid a unhandled exceptions that just terminate
 the program.


 
 It would be even better if the compiler could prove at compiler-time,
 that there are no OutOfBound, NullPointer and CastExceptions possible.


AFAIK, D handles this as long as it's not dynamic data. As soon as array 
indexes, pointer arithmetic or other not so exotic things kick in, 
there's no way to determine what values/states there can be. One way 
could be, to use a debugger that reflects the whole application 
execution (there is such a debugger for Java, that records literally 
everything).


 
 While this is hard for ArrayOutOfBounds, there are quite easy ways for
 avoiding NullPointer and CastExceptions at all. In the language Nice[1]
 they do this as follows:
 
 NullPointer: They have different types for pointers that can be null
 (?Type) and pointer that can't (Type). You can't dereference a ?Type
 variable.
 
 So, let's say we have
 
 void foo(?Type t)
 {
 	// we want to dereference t
 	if (t != null) {
 		// now the compiler "magically" converts t to type Type
 		t.doSomething();
 	}
 }


How about:

void foo ( Type t )
in {
     assert( t != null );
}
body {
     t.doSomething();
}

I find this rather equal.


 
 TypeCasts: You don't cast with a cast-operator, but with a
 instance-of-expression:
 
 void bar(A a)
 {
 	if (a instanceOf B) {
 		// now a is of type B, no need to cast
 	}
 }


What exactly does an instance-of-expression? Never seen this, actually.


 
 I haven't used this language yet, but these are certainly, well, nice
 features :)
 
 [1] http://nice.sf.net


Best regards,
Alex
Jan 12 2007
parent reply Sebastian Biallas <groups.5.sepp spamgourmet.com> writes:
Alexander Panek schrieb:

 Sebastian Biallas wrote:

 [...]
 It just doen't solve the problem that you have a bug in your program in
 the first place. Reread that sentence.


 Exceptions can be handled at runtime, still. try (to) catch it and there
 you go. :)


 So, how exactly do you /handle/ an exception which "should not be there"?


 
 One has to make sure to catch all "should not be there" exceptions, too 
 (ideally). In the real world, of course, there can happen to be mistakes 
 in the code, hidden bugs and what not else. But the fact is, that in 
 most software, that is really fully tested, those happen very rarely and 
 can be handled with special routines - 


By what routines?


 maybe also automatically sending 
 a bug report to the developers or the IT department of a company. 


You can do this with C code, too (see talkback from mozilla)


 This 
 depends on what kind of software you write/use(libraries). Apart from 
 that, D has this neat scope(fail) thing, that will cover almost all 
 circumstances, except segmentation faults .. ;)


scope(xx) is nice, that's right.


 Getting an unexpected exception in a shipped application is a huge bug.


 That's why you always /test/ everything so good, that you just don't get
 unexpected exceptions.


 Well, so you shouldn't need exceptions at all for array handling, right?
 (Except for debugging, where they really help)


 
 As soon as the amount of /dynamic/ data you have to handle grows, I 
 don't think there's a way around using at least exceptions to stay safe.


I'm not sure I understand that sentence.

Maybe I should clearify my point:
Exceptions are a nice way to handle unpredictable situations at runtime, 
like an IO error. Java helps you even with this, when you use the 
throw() specifier for your io-functions.

But exceptions are IMHO a wrong way to handle /programming mistakes/. 
Programming mistakes must be fixed by a programmer -- they can't be 
fixed at runtime. It's just too late if a buggy program is running.


 So what to do now? The program is now in an unstable state.
 And even if you catch the Exception on the right place: The Exception
 should never have been thrown. There is a bug, and the bug is not
 necessarily at the place where the exception was thrown -- the program
 might have been in an inconsistent state for hours.


 
 This is, of course, not so good. But then again, you should design the 
 software in a way that avoids such circumstances (yes, this is not 
 possible in any cases, but in very much).


This is pretty much the answer you get from someone advocating C or C++ 
if you ask him why a C or C++ program behaves in such an unpredictable 
way ;)


 They worked for me
 pretty well so far to avoid a unhandled exceptions that just terminate
 the program.


 It would be even better if the compiler could prove at compiler-time,
 that there are no OutOfBound, NullPointer and CastExceptions possible.


 
 AFAIK, D handles this as long as it's not dynamic data. As soon as array 
 indexes, pointer arithmetic or other not so exotic things kick in, 
 there's no way to determine what values/states there can be. 


You need a careful designed language for this. See e.g. SPARK (I haven't 
used it yet).


 While this is hard for ArrayOutOfBounds, there are quite easy ways for
 avoiding NullPointer and CastExceptions at all. In the language Nice[1]
 they do this as follows:

 NullPointer: They have different types for pointers that can be null
 (?Type) and pointer that can't (Type). You can't dereference a ?Type
 variable.

 So, let's say we have

 void foo(?Type t)
 {
     // we want to dereference t
     if (t != null) {
         // now the compiler "magically" converts t to type Type
         t.doSomething();
     }
 }


 
 How about:
 
 void foo ( Type t )
 in {
     assert( t != null );
 }
 body {
     t.doSomething();
 }
 
 I find this rather equal.


It is rather equal. The difference is not in the source code, the 
difference is how you /can/ write this.

In Nice you just have this one possibility: If you want to dereference a 
?pointer, you have to test it against null -- otherwise it won't 
compile. In other languages this test is optional (and even whether a 
pointer can be null is not part of the language but of the 
documentation. And documentation is often not available or wrong).

Of course you can write correct code in D and other languages. The point 
is: In Nice the code is guaranteed to be correct regarding null-pointer 
checks once it compiles! There is no need of a "style guide" for this 
which will be ignored once the project reaches its deadline.


 TypeCasts: You don't cast with a cast-operator, but with a
 instance-of-expression:

 void bar(A a)
 {
     if (a instanceOf B) {
         // now a is of type B, no need to cast
     }
 }


 
 What exactly does an instance-of-expression? Never seen this, actually.


	if (a instanceOf B) {

is the same as

	if (dynamic_cast<B>(a)) {  // in C++

or

	if (cast(B) a) { // in D
Jan 12 2007
parent Alexander Panek <a.panek brainsware.org> writes:
Sebastian Biallas wrote:

 Alexander Panek schrieb:

 Sebastian Biallas wrote:

 [...]
 It just doen't solve the problem that you have a bug in your 
 program in
 the first place. Reread that sentence.


 Exceptions can be handled at runtime, still. try (to) catch it and 
 there
 you go. :)


 So, how exactly do you /handle/ an exception which "should not be 
 there"?


 One has to make sure to catch all "should not be there" exceptions, 
 too (ideally). In the real world, of course, there can happen to be 
 mistakes in the code, hidden bugs and what not else. But the fact is, 
 that in most software, that is really fully tested, those happen very 
 rarely and can be handled with special routines - 


 
 By what routines?


The bug report possibility was one example.


 

 maybe also automatically sending a bug report to the developers or the 
 IT department of a company. 


 [...]

 Getting an unexpected exception in a shipped application is a huge 
 bug.


 That's why you always /test/ everything so good, that you just don't 
 get
 unexpected exceptions.


 Well, so you shouldn't need exceptions at all for array handling, right?
 (Except for debugging, where they really help)


 As soon as the amount of /dynamic/ data you have to handle grows, I 
 don't think there's a way around using at least exceptions to stay safe.


 
 I'm not sure I understand that sentence.


I'm just saying that you have to use proper exception handling, to stay 
error safe (not bug safe), as soon as (dynamic) data of variable length 
and kind is to be handled.


 
 Maybe I should clearify my point:
 Exceptions are a nice way to handle unpredictable situations at runtime, 
 like an IO error. Java helps you even with this, when you use the 
 throw() specifier for your io-functions.


Exactly, that's what I mean.


 
 But exceptions are IMHO a wrong way to handle /programming mistakes/. 
 Programming mistakes must be fixed by a programmer -- they can't be 
 fixed at runtime. It's just too late if a buggy program is running.


Of course. But a language only may /help/ to avoid programming mistakes. 
I don't think it's feasable to really restrict pointer usage like in the 
examples you brought up. But that's just me, I love pointers and what 
you can mess up with them. :)


 So what to do now? The program is now in an unstable state.
 And even if you catch the Exception on the right place: The Exception
 should never have been thrown. There is a bug, and the bug is not
 necessarily at the place where the exception was thrown -- the program
 might have been in an inconsistent state for hours.


 This is, of course, not so good. But then again, you should design the 
 software in a way that avoids such circumstances (yes, this is not 
 possible in any cases, but in very much).


 
 This is pretty much the answer you get from someone advocating C or C++ 
 if you ask him why a C or C++ program behaves in such an unpredictable 
 way ;)


Aww, got me there. ;)


 

 They worked for me
 pretty well so far to avoid a unhandled exceptions that just terminate
 the program.


 It would be even better if the compiler could prove at compiler-time,
 that there are no OutOfBound, NullPointer and CastExceptions possible.


 AFAIK, D handles this as long as it's not dynamic data. As soon as 
 array indexes, pointer arithmetic or other not so exotic things kick 
 in, there's no way to determine what values/states there can be. 


 
 You need a careful designed language for this. See e.g. SPARK (I haven't 
 used it yet).


Where 'careful' is the thing that splits the programmers community in 
two.. (safe/unsafe and such things). I don't really know SPARK, but I 
think D does a good job /already/, regarding 'safety'.


 While this is hard for ArrayOutOfBounds, there are quite easy ways for
 avoiding NullPointer and CastExceptions at all. In the language Nice[1]
 they do this as follows:

 NullPointer: They have different types for pointers that can be null
 (?Type) and pointer that can't (Type). You can't dereference a ?Type
 variable.

 So, let's say we have

 void foo(?Type t)
 {
     // we want to dereference t
     if (t != null) {
         // now the compiler "magically" converts t to type Type
         t.doSomething();
     }
 }


 How about:

 void foo ( Type t )
 in {
     assert( t != null );
 }
 body {
     t.doSomething();
 }

 I find this rather equal.


 
 It is rather equal. The difference is not in the source code, the 
 difference is how you /can/ write this.
 
 In Nice you just have this one possibility: If you want to dereference a 
 ?pointer, you have to test it against null -- otherwise it won't 
 compile. In other languages this test is optional (and even whether a 
 pointer can be null is not part of the language but of the 
 documentation. And documentation is often not available or wrong).


Hm. Then again, why not make it automatically: every pointer that is 
dereferenced gets a comparison to null before being used (imho better 
than explicitely typing if(t==null) all the time).


 
 Of course you can write correct code in D and other languages. The point 
 is: In Nice the code is guaranteed to be correct regarding null-pointer 
 checks once it compiles! There is no need of a "style guide" for this 
 which will be ignored once the project reaches its deadline.
 

 TypeCasts: You don't cast with a cast-operator, but with a
 instance-of-expression:

 void bar(A a)
 {
     if (a instanceOf B) {
         // now a is of type B, no need to cast
     }
 }


 What exactly does an instance-of-expression? Never seen this, actually.


 
     if (a instanceOf B) {
 
 is the same as
 
     if (dynamic_cast<B>(a)) {  // in C++
 
 or
 
     if (cast(B) a) { // in D


Mh, well. That's a matter of taste, I'd say. (IIRC, it was even proposed 
somewhen?)
Jan 13 2007
prev sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Fri, 12 Jan 2007 09:48:50 +0100, Alexander Panek
<a.panek brainsware.org> wrote:


 An important point is that this doesn't solve this problem either. Ok,
 you get an exception instead of some "undefined behaviour", which is
 somehow better when debugging, but:
 
 It just doen't solve the problem that you have a bug in your program in
 the first place. Reread that sentence.


Exceptions can be handled at runtime, still. try (to) catch it and there 
you go. :)


There is a big difference between using exceptions to handle user
errors, machine limits and the like compared with handling program
bugs.

Put it this way - if your code generates exceptions due to bugs, how
exactly can you trust the exception handlers to do any better? If your
program is in an unknown illegal state because of an unknown bug, how
can your exception handler convert that back to a legal state?

Exceptions are meant to handle exceptional cases cleanly - hence the
name. We tend to think of exceptions as errors, but that isn't
necessarily the case, and besides, the meaning of error in this
context does not include bugs in the code.

Trying to hide bugs behind a catch-all exception handler tends to mean
the application stays in an illegal, unstable state that leads to more
errors. Instead of exiting at the first sign of trouble with a minimum
of data loss, the effects of that error can snowball - files get
corrupted with bad data etc etc. Things that seem minor along these
lines can actually be the worst cases - an accumulation of minor
corruptions can go unnoticed until the point where all existing
backups are corrupted, and suddenly the "clever" hiding of bugs has
led to bad publicity and paying out for damages.

Exceptions are only better than "undefined behaviour" when debugging
since you get clues to how the error arose that allow you to diagnose
and fix the bug more easily (providing it is the kind of error that
results in an exception). For instance, the debugger will stop on
unhandled exceptions, and show you where the exception throw happened,
what was on the call stack, etc.

Even then, so much can happen between the initial error and the point
where it is detected and an exception thrown that you still have a
serious detective job to do. And if you have a bug-hiding catch-all
exception handler, there just means that even more will have happened
between the initial error and its detection and the detective job will
be many times more difficult.

Catch-all exception handlers can be useful for generating diagnostic
data, but using them to hide bugs is bad programming.

-- 
Remove 'wants' and 'nospam' from e-mail.
Jan 14 2007