Reading about D: few questions

Ali Çehreli acehreli at
Fri Dec 23 09:47:35 PST 2011

On 12/23/2011 07:25 AM, Mr. Anonymous wrote:

 > I have a couple of questions:

I prefer separate threads for each. :)

 > 1. Uninitialized Arrays and GC.
 > It's said here ^ that:
 > "The uninitialized data that is on the stack will get scanned by the
 > garbage collector looking for any references to allocated memory."
 > With the given example of: byte[1024] buffer = void;
 > So does the GC really scan this byte array? Or (sounds more logical to
 > me) does it scan only reference types?

I am not an expert on garbage collectors but I've never heard about 
differentiating the bits of data. The GC would have to need to keep meta 
data about every part of the allocated space as such and it would not be 

 > If the latter is true, I think the example should use some kind of a
 > pointer array. Also, in this case, I can't see why "Uninitialized data
 > can be a source of bugs and trouble, even when used correctly."?

I don't think that the last part is any different than the "initialize 
all of your variables" advice. The uninitialized data has come from 
memory that has been used earlier in the program and may have valid data 
(and references) to existing or already-destroyed data. Hard to debug.

 > 2. Setting Dynamic Array Length.
 > "A more practical approach would be to minimize the number of resizes"
 > The solution works but is not as clean as just using array ~= c;
 > Is there any way (language, runtime, or phobos) to declare an array that
 > would reallocate memory by chunks, which are multiple of x?

Array expansion is already more efficient than they look at first. This 
article is a good read:

 > 3. const and immutable.
 > Is there any use for const when defining variables?
 > As I see it, there is no use for using e.g. const int x;, as it can't be
 > modified anyway;
 > So with immutable, const is only good for reference variables that are
 > initialized to refer to another variable (like a function const ref
 > parameter).
 > Am I right?

Right. I have two observations myself:

- To be more useful, function parameters should not insist on immutable 
data, yet we type string all over the place.

- To be more useful, functions should not insist on the mutability of 
the data that they return.

The following function makes a new string:

char[] endWithDot(const(char)[] s)
     return s ~ '.';

     char[] s;
     s ~= "hello";
     auto a = endWithDot(s);

It is good that the parameter is const(char) so that I could pass the 
mutable s to it.

But the orthogonal problem of the type of the return is troubling. The 
result is clearly mutable yet it can't be returned as such:

Error: cannot implicitly convert expression (s ~ '.') of type 
const(char)[] to char[]

We've talked about this before. There is nothing in the language that 
makes me say "the returned object is unique; you can cast it to mutable 
or immutable freely."

 > 5. Align attribute.
 > struct S {
 > align(4) byte a; // placed at offset 0
 > align(4) byte b; // placed at offset 1
 > }
 > Explain this please.

I don't know more than what the documentation says but I remember 
reading bugs about align().

 > 6. Array slices manipulation.
 > a[] += 1; works but a[]++ doesn't.
 > Not so important but just wondering: why, and is it intended?

Again, I remember discussion and limitations about this feature. 
Fixed-length arrays have better support and the regular increment works:

     double[3] a = [ 10, 20, 30 ];

 > 7. Anonymous structs.
 > In C you can write:
 > struct { int a; } s = {10};
 > printf("%d\n", s.a);
 > In D you must declare the struct first:
 > struct S { int a; };
 > S s = {10};
 > writeln(s.a);
 > Why doesn't D allow anonymous structs?

It may be related to palsing. D does not require the semicolon at the 
end of the struct definition, so it wouldn't know what 's' is:

struct { int a; }   // definition (of unmentionable type :) )
s = {10};           // unknown s

There could be special casing but I don't think that it would be worth it.


More information about the Digitalmars-d-learn mailing list