I should explain why it's important for me:

For example, I am making a matrix object(s)

It should be:
- any size
- with ability of making matrix instance of a given size in compile time.
- ability of creating matrix instance in runtime.

I have decided to make it struct because I need to create matrix
object in compile time. in real program I'll need matricies of
variable size and 3х1, 3х3, 6х6, 3х6 sizes (and may be other).

I want to make matrix template and insert in it with mixin operator
several structures of different sizes (and this structs are not store his dimensions in each instance, of course: variables width and height declared as invariant). By doing this I'll get several different structures  (matrix_dynamic, matrix3x3, matrix6x6 etc)

question is how those matricies can interoperate? They does not have
common parent (structures does not have inheritance) , so I can't
make common function for matricies of different sizes opAdd for
example, and have to do functions for all types of matricies.

How should I implement such a class In D properly?  	
It possible in C++, but I like some of the language D

2008/12/16 Weed <resume755@mail.ru>:
> I should explain why it's important for me:
>
> For example, I am making a matrix object(s)
>
> It should be:
> - any size
> - with ability of making matrix instance of a given size in compile time.
> - ability of creating matrix instance in runtime.
>
> I have decided to make it struct because I need to create matrix object in compile time. in real program I'll need matricies of variable size and 3х1, 3х3, 6х6, 3х6 sizes (and may be other).
>
> I want to make matrix template and insert in it with mixin operator
> several structures of different sizes (and this structs are not store his
> dimensions in each instance, of course: variables width and height declared
> as invariant). By doing this I'll get several different structures
>  (matrix_dynamic, matrix3x3, matrix6x6 etc)
>
> question is how those matricies can interoperate? They does not have common parent (structures does not have inheritance) , so I can't make common function for matricies of different sizes opAdd for example, and have to do functions for all types of matricies.
>
> How should I implement such a class In D properly?
> It possible in C++, but I like some of the language D
>

Here's one way: http://www.dsource.org/projects/openmeshd/browser/trunk/LinAlg/linalg/MatrixT.d

--bb

Bill Baxter пишет:
> 2008/12/16 Weed <resume755@mail.ru>:
>> I should explain why it's important for me:
>>
>> For example, I am making a matrix object(s)
>>
>> It should be:
>> - any size
>> - with ability of making matrix instance of a given size in compile time.
>> - ability of creating matrix instance in runtime.
>>
>> I have decided to make it struct because I need to create matrix
>> object in compile time. in real program I'll need matricies of
>> variable size and 3х1, 3х3, 6х6, 3х6 sizes (and may be other).
>>
>> I want to make matrix template and insert in it with mixin operator
>> several structures of different sizes (and this structs are not store his
>> dimensions in each instance, of course: variables width and height declared
>> as invariant). By doing this I'll get several different structures
>>  (matrix_dynamic, matrix3x3, matrix6x6 etc)
>>
>> question is how those matricies can interoperate? They does not have
>> common parent (structures does not have inheritance) , so I can't
>> make common function for matricies of different sizes opAdd for
>> example, and have to do functions for all types of matricies.
>>
>> How should I implement such a class In D properly?
>> It possible in C++, but I like some of the language D
>>
> 
> Here's one way:
> http://www.dsource.org/projects/openmeshd/browser/trunk/LinAlg/linalg/MatrixT.d
> 
> --bb

necessarily need the ability to change the size of the matrix

together with a static matrix it can be done using two types of matrices with a single parent.

Weed пишет:
> I should explain why it's important for me:
> 
> For example, I am making a matrix object(s)
> 
> It should be:
> - any size
> - with ability of making matrix instance of a given size in compile time.
> - ability of creating matrix instance in runtime.
> 
> I have decided to make it struct because I need to create matrix
> object in compile time. in real program I'll need matricies of
> variable size and 3х1, 3х3, 6х6, 3х6 sizes (and may be other).
> 
> I want to make matrix template and insert in it with mixin operator
> several structures of different sizes (and this structs are not store his dimensions in each instance, of course: variables width and height declared as invariant). By doing this I'll get several different structures  (matrix_dynamic, matrix3x3, matrix6x6 etc)
> 
> question is how those matricies can interoperate? They does not have
> common parent (structures does not have inheritance) , so I can't
> make common function for matricies of different sizes opAdd for
> example, and have to do functions for all types of matricies.
> 
> How should I implement such a class In D properly?     It possible in C++, but I like some of the language D


I think could help a static creation objects of classes (including compile-time creation), but it is also impossible now.
For example:

MatrixClass a(3,2);
static MatrixClass a(3,2);

Planned in the future to implement inheritance of structs or the static creation of classes?

Weed:
> Planned in the future to implement inheritance of structs or the static creation of classes?

Inheritance of structs: I think it's not planned. Structs in D are meant to be used for different things than classes.
Yet, as time passes structs are gaining more power: you can't believe that very recently they have gained constructors/destructors too in D2. Probably in a system language conceptual purity isn't much appreciated :-)

Static creation of classes (I think you mean creation of objects): it sounds like an interesting thing, I know of a system language that allows the creation of objects only at compile-time, and at compile-time it also performs several space optimizations among such objects (and such space optimizations often improve running speed a little).

Bye,
bearophile

bearophile пишет:
> Weed:
>> Planned in the future to implement inheritance of structs or the static creation of classes?
>
> Inheritance of structs: I think it's not planned. Structs in D are
meant to be used for different things than classes.
> Yet, as time passes structs are gaining more power: you can't believe
>
that very recently they have gained constructors/destructors too in D2.
Probably in a system language conceptual purity isn't much appreciated :-)
>

I believe that the opportunity to place an object in memory, stack or heap is more important than the struggle against "splicing".

I think not worth taking structs and classes from C#. May be bytecode interpreter C# does not show the difference in speed between the allocation of memory by a small object + its using and the use of a static object, so developers C# decided to do so as done. (but I am not a specialist in the design of compilers :))

> Static creation of classes (I think you mean creation of objects): it
> sounds like an interesting thing, I know of a system language that
> allows the creation of objects only at compile-time, and at
> compile-time it also performs several space optimizations among such
> objects (and such space optimizations often improve running speed a
> little).

And in fact we come to making structs and classes similar except that classes can not be assigned by value.

Such an option I like.

Weed wrote:
> bearophile пишет:
>  > Weed:
>  >> Planned in the future to implement inheritance of structs or the
> static creation of classes?
>  >
>  > Inheritance of structs: I think it's not planned. Structs in D are
> meant to be used for different things than classes.
>  > Yet, as time passes structs are gaining more power: you can't believe
>  >
> that very recently they have gained constructors/destructors too in D2.
> Probably in a system language conceptual purity isn't much appreciated :-)
>  >
>
> I believe that the opportunity to place an object in memory, stack or
> heap is more important than the struggle against "splicing".
>
> I think not worth taking structs and classes from C#. May be bytecode
> interpreter C# does not show the difference in speed between the
> allocation of memory by a small object + its using and the use of a
> static object, so developers C# decided to do so as done. (but I am not
> a specialist in the design of compilers :))
>
>  > Static creation of classes (I think you mean creation of objects): it
>  > sounds like an interesting thing, I know of a system language that
>  > allows the creation of objects only at compile-time, and at
>  > compile-time it also performs several space optimizations among such
>  > objects (and such space optimizations often improve running speed a
>  > little).
>
> And in fact we come to making structs and classes similar except that
> classes can not be assigned by value.
>
> Such an option I like.

If I understand you correctly - I think you confuse here two separate and orthogonal issues.
1) struct vs. class
2) memory allocation

What D tries to do is to provide types with value semantics via structs and types with reference semantics _and_polymorphism_ via classes.
IMO C++ is a prime example how to not design a language and the slicing problem is a good example of that. value types should not have polymorphism whatsoever as is done in D.

memory allocation is orthogonal to this:
class C {...}
Struct S {...}

auto c1 = new C; // classes default to heap alloc
scope c2 = new C; // c2 is on stack
S s1; // structs default to stack
auto s2 = new S; // s2 is S* (heap alloc)

I think Andrei said he wants to make changes to "scope", that is IIRC.

struct inheritance, if it gets implemented in D, should express IMO semantics similar to concepts as in C++0x, not provide polymorphism for value types which is clearly a mistake. (also this will remove the need for typedefs, isn't it?)

Yigal Chripun пишет:

> 
> If I understand you correctly - I think you confuse here two separate and orthogonal issues.
> 1) struct vs. class
> 2) memory allocation
> 
> What D tries to do is to provide types with value semantics via structs and types with reference semantics _and_polymorphism_ via classes.
> IMO C++ is a prime example how to not design a language and the slicing problem is a good example of that. value types should not have polymorphism whatsoever as is done in D.
> 
> memory allocation is orthogonal to this:
> class C {...}
> Struct S {...}
> 
> auto c1 = new C; // classes default to heap alloc
> scope c2 = new C; // c2 is on stack
> S s1; // structs default to stack
> auto s2 = new S; // s2 is S* (heap alloc)
> 
> I think Andrei said he wants to make changes to "scope", that is IIRC.
> 

What will change?

> struct inheritance, if it gets implemented in D, should express IMO semantics similar to concepts as in C++0x, not provide polymorphism for value types which is clearly a mistake. (also this will remove the need for typedefs, isn't it?)

I agree.
In my case I chose to structure rather than a class because it can be initialized at compile time.

But now I thing must be allowed to deploy class in the default data segment. And add the possibility of creating a object of class at compile time.
	
Nothing prevents this change?

Weed Wrote:

> I agree.
> In my case I chose to structure rather than a class because it can be
> initialized at compile time.
> 
> But now I thing must be allowed to deploy class in the default data segment. And add the possibility of creating a object of class at compile time.

If you want to use full blown OOP, class is your choise. There are static constructors for static initialization.

Kagamin пишет:
> Weed Wrote:
> 
>> I agree.
>> In my case I chose to structure rather than a class because it can be initialized at compile time.
>>
>> But now I thing must be allowed to deploy class in the default data segment. And add the possibility of creating a object of class at compile time.
> 
> If you want to use full blown OOP, class is your choise. There are static constructors for static initialization.

There does not need a static initialization of static members of the class. There must be able to create objects of classes at compile time.