On 05.07.2011 10:35, Max Klyga wrote:
On 2011-07-05 08:31:46 +0300, Dmitry Olshansky said:
On 05.07.2011 1:10, bearophile wrote:
Steven Schveighoffer:
Or, use a separate type which throws the errors if you wish.
I have recently explained why this is not good enough, or even
currently impossible:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=139950
I
don't want
runtime errors thrown in code that I didn't intend to throw. most
of the
time, overflows will not occur, so I don't want to go through all
my code
and have to throw these decorations up where I know it's safe.
The idea is to add two switches to DMD that activate the integral
overflows (one for signed and one for signed and unsigned). If you
compile your code without those, the runtime tests will not happen.
Besides, D is a systems language, and has no business doing checks
on every integer instruction.
This argument doesn't hold, Delphi and Ada too are system languages.
In case of Delphi that's a bit of stretch to say least, e.g. it
_still_ lacks normal pointer arithmetic:
<quote>
In Delphi 2009, pointer arithmetic, as usable for the PChar type
(and PAnsiChar and PWideChar), is now also possible for other
pointer types. When and where this is possible is governed by the
new $POINTERMATH compiler directive.
Pointer arithmetic is generally switched off, but it can be switched
on for a piece of code using|{$POINTERMATH ON}|, and off again
using|{$POINTERMATH OFF}|. For pointer types compiled with pointer
arithmetic (pointer math) turned on, pointer arithmetic is generally
possible.
Apparently, in/Delphi 2009/, the new pointer arithmetic doesn't work
as intended for pointers to/generic/types yet. Whatever type the
parametric type is instantiated as, indices are not scaled
by|SizeOf(T)|, as expected.
</quote>
http://rvelthuis.de/articles/articles-pointers.html
also:
http://stackoverflow.com/questions/4303880/delphi-pointer-arithmetic
Pointer arithmetic is not strictly necessary for a systems language.
Well, given this some more thought, it's not exactly necessary, much
more needed is ability to treat some memory location as either address
or integer. Having that arithmetic can be done on integers and then
casted back as pointers again, though that does gives you even _less_
safety the direct pointer arithmetic (at least it disallows /* on
pointers ... and they track size of object).
Several operating systems were written in Oberon. It has no pointer
arithmetics. Should it be considered not a systems language?
IMHO, yes, generally the features to work as close as possible to
"metal" should be first-class in a systems language, else you could fit
almost any language with meta library of "intrinsic functions" and call
it a systems language (that would make sense as long as you have a
native code compiler).
Looking on Oberon it seems to do the latter i.e. stay Pascal but use
intrinsic functions (spec of Oberon-07, page 15):
SYSTEM additional definitions that are particular to the specific,
underlying computer. In the
following, v stands for a variable, x, a, and n for expressions.
Function procedures:
Name Argument types Result type Function
ADR(v) any INTEGER address of variable v
SIZE(T) any type INTEGER size in bytes
BIT(a, n) a, n: INTEGER BOOLEAN bit n of mem[a]
Proper procedures:
Name Argument types Function
GET(a, v) a: INTEGER; v: any basic type v := mem[a]
PUT(a, x) a: INTEGER; x: any basic type mem[a] := x
Ti seems Go took the same route, but also using magic types:
http://golang.org/pkg/unsafe/
--
Dmitry Olshansky
