Miscelleanous questions, here is a load of them. Sorry if some may not be be truly D specific. :p

Is static initialization of fixed-length arrays only permited for static-allocation fixed-length arrays? (what a name mess :o ) Why so?
Also is it possible to declare a fixed-length array without directly specifying the size, but instead determining it by the size of the static initializer? Like the following in C:
int iar[] = { 1, 2, 8, 7, 2 };   // iar is a fixed-length array of size 5 elements


Is there an add/insert function for associative arrays (like there is remove() )? I think I rather prefer it than the "aa[key] = value;" way.


CLASSES: "3 It is illegal to refer to this implicitly or explicitly prior to making a constructor call."
Huh, how is that even possible to do?


CLASSES: "There can be only one destructor per class, the destructor does not have any parameters, and has no attributes. It is always virtual."
Why is a destructor allways virtual?


MEMORY MANAGEMENT: "The pointer returned from new() must be to memory aligned to the default alignment. This is 8 on win32 systems."
8? On win32 is the alignment not 4 for pointers?


MEMORY MANAGEMENT: "The critical features of delete() are: ...
The pointer p may be null."
What? What sense does it make, deletion with a null pointer?



-- 
Bruno Medeiros
Computer Science/Engineering student

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:ddb14r$b60$1@digitaldaemon.com...
> Is static initialization of fixed-length arrays only permited for
> static-allocation fixed-length arrays? (what a name mess :o ) Why so?
> Also is it possible to declare a fixed-length array without directly
> specifying the size, but instead determining it by the size of the static
> initializer? Like the following in C:
> int iar[] = { 1, 2, 8, 7, 2 };   // iar is a fixed-length array of size 5
> elements

Array literals for non-static arrays aren't supported yet, unfortunately. And I don't think you can make a fixed-length array like that.  You can do this:

static int[] blah=[1,2,3];

But it'll be a dynamic array.

> Is there an add/insert function for associative arrays (like there is remove() )? I think I rather prefer it than the "aa[key] = value;" way.

I agree with you there, and there has been A LOT of debate over AAs.  I think an "add" or "put" function would be very welcome.

> CLASSES: "3 It is illegal to refer to this implicitly or explicitly prior
> to making a constructor call."
> Huh, how is that even possible to do?

Maybe it's not ;)

> CLASSES: "There can be only one destructor per class, the destructor does not have any parameters, and has no attributes. It is always virtual." Why is a destructor allways virtual?

Because otherwise, you'd get problems when you destroyed classes that inherited from other classes.  Whenever you have a derived class, the dtor should be virtual.

> MEMORY MANAGEMENT: "The pointer returned from new() must be to memory
> aligned to the default alignment. This is 8 on win32 systems."
> 8? On win32 is the alignment not 4 for pointers?

I don't know about that one.

> MEMORY MANAGEMENT: "The critical features of delete() are: ...
> The pointer p may be null."
> What? What sense does it make, deletion with a null pointer?

Because it's legal.  "delete null" is a valid statement.  In D (and in C++), calling "delete null" does nothing instead of causing an access violation.

On Tue, 09 Aug 2005 19:45:29 +0000, Bruno Medeiros <daiphoenixNO@SPAMlycos.com> wrote:
> Also is it possible to declare a fixed-length array without directly specifying the size, but instead determining it by the size of the static initializer? Like the following in C:
> int iar[] = { 1, 2, 8, 7, 2 };   // iar is a fixed-length array of size 5 elements

I don't think so. But if I may suggest a syntax...

int iar[$] = [ 1, 2, 8, 7, 2 ];

Makes sense to me as $ means length in slice context.

Regan

Jarrett Billingsley wrote:
> "Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message 
>>CLASSES: "There can be only one destructor per class, the destructor does not have any parameters, and has no attributes. It is always virtual."
>>Why is a destructor allways virtual?
> 
> 
> Because otherwise, you'd get problems when you destroyed classes that inherited from other classes.  Whenever you have a derived class, the dtor should be virtual.
> 
> 
Yes, I understand in that case, but what then if you dont have a derived
 class?..


>>MEMORY MANAGEMENT: "The critical features of delete() are: ...
>>The pointer p may be null."
>>What? What sense does it make, deletion with a null pointer?
> 
> 
> Because it's legal.  "delete null" is a valid statement.  In D (and in C++), calling "delete null" does nothing instead of causing an access violation. 
> 
I was talking about runtime, not compile-time validity. I think it would be obvious that "delete null;" would be a compile-time valid statement. Turns out we were both wrong and now I really dont know what to think anymore: I tested a "delete null;" and it fails compilation with a "null is not an lvalue" error, but a "int* pt = null; delete pt;" is compilable, and runs without crashing. :S
What's the deal after all?


-- 
Bruno Medeiros
Computer Science/Engineering student

"Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:ddgv49$1ooi$1@digitaldaemon.com...
> Yes, I understand in that case, but what then if you dont have a derived
>  class?..

Does it much matter?  The performance overhead of a virtual destructor would be rather small, I'd think.  Especially since in larger projects, classes which don't have any derived classes are rare.

> I was talking about runtime, not compile-time validity. I think it would
> be obvious that "delete null;" would be a compile-time valid statement.
> Turns out we were both wrong and now I really dont know what to think
> anymore: I tested a "delete null;" and it fails compilation with a "null
> is not an lvalue" error, but a "int* pt = null; delete pt;" is compilable,
> and runs without crashing. :S
> What's the deal after all?

delete in D does something that it doesn't in C++ - it also sets the pointer that was passed in to null.  So writing "delete null" isn't valid, as it'd be like trying to pass a number literal to a function that took an inout int.

Jarrett Billingsley wrote:
> "Bruno Medeiros" <daiphoenixNO@SPAMlycos.com> wrote in message news:ddgv49$1ooi$1@digitaldaemon.com...
> 
>>Yes, I understand in that case, but what then if you dont have a derived
>> class?..
> 
> 
> Does it much matter?  The performance overhead of a virtual destructor would be rather small, I'd think.  Especially since in larger projects, classes which don't have any derived classes are rare.
> 
Well kind of, even if just as a conceptual question.

>>I was talking about runtime, not compile-time validity. I think it would be obvious that "delete null;" would be a compile-time valid statement. Turns out we were both wrong and now I really dont know what to think anymore: I tested a "delete null;" and it fails compilation with a "null is not an lvalue" error, but a "int* pt = null; delete pt;" is compilable, and runs without crashing. :S
>>What's the deal after all?
> 
> 
> delete in D does something that it doesn't in C++ - it also sets the pointer that was passed in to null.  So writing "delete null" isn't valid, as it'd be like trying to pass a number literal to a function that took an inout int. 
> 
Ahh, I see now, that never had occured to me, but it makes perfect sense since otherwise there would be GC-related problems.

-- 
Bruno Medeiros
Computer Science/Engineering student