Jeremie Pelletier:
> Not always true.
I agree, I'm using D also because it offers unions. Sometimes they are useful.
But beside normal C unions that I don't want to remove from C, it can be also
useful to have safe automatic tagged unions of Cyclone. They are safer and give
just a little less performance compared to C unions. In D they may be denoted
with "record" or "tunion" or just "safe union" to save keywords. They always
contain an invisible tag (that can be read with a special built-in union
method, like Unioname.tagcheck). Such "safe unions" may even become the only
ones allowed in SafeD modules!
The following is from Cyclone docs:
<<
The C Standard says that if you read out any member of a union other than the
last one written, the result is undefined.
To avoid this problem, Cyclone provides a built-in form of tagged union and
always ensures that the tag is correlated with the last member written in the
union. In particular, whenever a tagged union member is updated, the compiler
inserts code to update the tag associated with the union. Whenever a member is
read, the tag is consulted to ensure that the member was the last one written.
If not, an exception is thrown.
Thus, the aforementioned example can be rewritten in Cyclone like this:
@tagged union U { int i; int *p; };
void pr(union U x) {
if (tagcheck(x.i))
printf("int(%d)",x.i);
else
printf("ptr(%d)",*x.p);
}
The @tagged qualifier indicates to the compiler that U should be a tagged
union. The operation tagcheck(x.i) returns true when i was the last member
written so it can be used to extract the value.
>>
> Again, that's a lazy view on programming. High level constructs are
> useful to isolate small and simple algorithms which are implemented at
> low level.
Software is inherently multi-scale. Probably in 90-95% of the code of a program
micro-optimizations aren't that necessary because those operations are done
only once in a while. But then it often happens that certain loops are done an
enormous amount of times, so even small inefficiencies inside them lead to low
performance. That's why profiling helps.
This can be seen by how HotSpot (and modern dynamic language JITters work):
usually virtual calls like you can find in a D program are quick, they don't
slow down code. Yet if a dynamic call prevents the compile to perform a
critical inlining or such dynamic call is left in the middle of a critical
code, it may lead to a slower program. That's why I have Java code go 10-30%
faster than D code compiled with LDC, not because of the GC and memory
allocations, but just because LDC isn't smart enough to inline certain virtual
methods.
------------------------------------
More quotations from the Cyclone documentation:
>In contrast, Cyclone's analysis extends to struct, union members, and pointer
>contents to ensure everything is initialized before it is used. This has two
>benefits: First, we tend to catch more bugs this way, and second, programmers
>don't pay for the overhead of automatic initialization on top of their own
>initialization code.<
This is right on-topic:
>This requires little effort from the programmer, but the NULL checks slow down
>getc. To repair this, we have extended Cyclone with a new kind of pointer,
>called a never-NULL pointer, and indicated with �...@ instead of *. For
>example, in Cyclone you can declare
int getc(FILE @);
indicating that getc expects a non-NULL FILE pointer as its argument. This
one-character change tells Cyclone that it does not need to insert NULL checks
into the body of getc. If getc is called with a possibly-NULL pointer, Cyclone
will insert a NULL check at the call :<
>Goto C's goto statements can lead to safety violations when they are used to
>jump into scopes. Here is a simple example:
int z;
{ int x = 0xBAD; goto L; }
{ int *y = &z;
L: *y = 3; // Possible segfault
}
Cyclone's static analysis detects this situation and signals an error. A goto
that does not enter a scope is safe, and is allowed in Cyclone. We apply the
same analysis to switch statements, which suffer from a similar vulnerability
in C.<
Bye,
bearophile
