Reading about D: few questions

[Mr. Anonymous]

On 23.12.2011 19:47, Ali Çehreli wrote:
> On 12/23/2011 07:25 AM, Mr. Anonymous wrote:
>
>  > I have a couple of questions:
>
> I prefer separate threads for each. :)

Should I resend the questions as separate messages?

>
>  > 1. Uninitialized Arrays and GC.
>  >
>  > http://dlang.org/memory.html#uninitializedarrays
>  > 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
> practical.

Maybe not every part, but only reference parts.

>
>  > 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.
>  >
>  > http://dlang.org/arrays.html#resize
>  > "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:
>
> http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

Thanks, I'll take a look.

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

I saw that std.string functions use assumeUnique from std.exception.
As for your example, it probably should be:

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

>
>  > 5. Align attribute.
>  >
>  > http://dlang.org/attribute.html#align
>  >
>  > 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 ];
> ++a[];

++a[] works, but a[]++ doesn't.

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

Sounds reasonable.

>
> Ali
>