Kagamin пишет:
> Derek Parnell Wrote:
> 
>> I think he wants to have some objects constructed at compile-time. 
> 
> Sure he wants. From my point of view, this technique is supposed to be a means to solve some problem rather than problem itself. But this problem was not put.

please read it thread:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=80945

Sergey Gromov Wrote:

> C++ static object constructors execute at run time except for trivial cases.

Although I think it's not guaranteed to work this way and compiler decides when to execute constructor. So code should be ready for run-time evaluation. And as code evolves those constructors can switch back and forth between ct and rt evaluation.

ps I know a C++ programmer, he wanted to control manually, in what order static object constructors are called :)

Weed Wrote:

> > Sure he wants. From my point of view, this technique is supposed to be a means to solve some problem rather than problem itself. But this problem was not put.
> 
> please read it thread: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=80945

The problem of matrix of arbitrary size is solved by size-agnostic base class whose interface is very similar to that of dynamic matrix.

Kagamin пишет:
> Weed Wrote:
> 
>>> Sure he wants. From my point of view, this technique is supposed to be a means to solve some problem rather than problem itself. But this problem was not put.
>> please read it thread:
>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=80945
> 
> The problem of matrix of arbitrary size is solved by size-agnostic base class whose interface is very similar to that of dynamic matrix.

If 2 predetermined matrix certain size multiplied, the produced matrix must be a certain size rather than dynamic.

Weed пишет:
> Kagamin пишет:
>> Weed Wrote:
>>
>>>> Sure he wants. From my point of view, this technique is supposed to be a means to solve some problem rather than problem itself. But this problem was not put.
>>> please read it thread:
>>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=80945 
>>>
>>
>> The problem of matrix of arbitrary size is solved by size-agnostic base class whose interface is very similar to that of dynamic matrix.
> 
> If 2 predetermined matrix certain size multiplied, the produced matrix must be a certain size rather than dynamic.

...and a matrix of static size in the same used in other objects - matrix functional mixed into this objects by mixin.

that is, suppose that after some action should get a matrix matrix3x1

You can not assign it to "pixel" struct, you will receive matrix3x1 and make copy of "pixel".

On Sun, 21 Dec 2008 19:34:52 +0300, Kagamin <spam@here.lot> wrote:

> Derek Parnell Wrote:
>
>> I think he wants to have some objects constructed at compile-time.
>
> Sure he wants. From my point of view, this technique is supposed to be a means to solve some problem rather than problem itself. But this problem was not put.

Ok, here is a problem out of my head:

Let's say we have a GUI application with Widgets and WidgetFactories. Each widget is initialized with a *valid* pointer to some WidgetFactory (a dummy one, perhaps) to avoid "if (factory !is null) factory.doSomething();" checks (for example). Our first try:

import std.stdio;

struct WidgetFactory
{
   int someParameterValue = 42;
}

WidgetFactory defaultFactory = { 14 }; 

class Widget
{
   WidgetFactory* factory = &defaultFactory;
}

void main()
{
   Widget w = new Widget();
   writefln(w.factory.someParameterValue); // prints 14
}

It works, because memory for global structs is reserved at compile time and pointer to it is also a known compile-time expression. Let's go further and see if we can replace a struct with a class instance:

WidgetFactory defaultFactory;

class Widget
{
   WidgetFactory factory = defaultFactory;
}

This code compiles but doesn't work as we need. Another try:

WidgetFactory defaultFactory;

static this()
{
   defaultFactory = new StubFactory();
}

class Widget
{
   WidgetFactory* factory = &defaultFactory;
}

Works as we need but we now have to dereference a pointer twice.

A better solution would be to have the following:

WidgetFactory defaultFactory = new StubFactory();

class Widget
{
   WidgetFactory factory = defaultFactory;
}

A memory for 'defaultFactory' is reserved at compile-time whereas a ctor is ran at run-time (similar to "static this" construct).
In fact, allowing reference type to created at compile time would eliminate most of the needs for static this. The following construct:

Foo foo;
static this()
{
   foo = new Foo();
}

could be replaced with

Foo foo = new Foo();

which behaves just the same but is shorter, nicier, easier to write and read (undestand).

Sun, 21 Dec 2008 12:04:42 -0500, Kagamin wrote:

> Sergey Gromov Wrote:
> 
>> C++ static object constructors execute at run time except for trivial cases.
> 
> Although I think it's not guaranteed to work this way and compiler decides when to execute constructor. So code should be ready for run-time evaluation. And as code evolves those constructors can switch back and forth between ct and rt evaluation.
> 
> ps I know a C++ programmer, he wanted to control manually, in what order static object constructors are called :)

Actually, static constructors are *guaranteed* to run at run time, before main().  Compiler *may* optimize them out and convert into initialized DATA if there are no side effects, that is, if optimized program works exactly as if all static ctors were executed at run time.

C++ guarantees that static ctors are executed in order they appear in a module.  There is no guarantee about the order in which different modules are initialized though.

Denis Koroskin Wrote:

> class Widget
> {
>     WidgetFactory* factory = &defaultFactory;
> }
> 
> void main()
> {
>     Widget w = new Widget();
>     writefln(w.factory.someParameterValue); // prints 14
> }

You initialize member field here. It's usually done in instance constructor.

class Widget
{
    WidgetFactory factory;
    this(){ factory = defaultFactory; }
}

Weed Wrote:

> that is, suppose that after some action should get a matrix matrix3x1

Well... if you want to template every piece of your code, this can cause disaster, so I think, this is not very good design. For example, multiplication method will be duplicated N*N*N times for all possible matrix size combinations. I'd prefer run-time checks, though templates can be used for sure.

Kagamin пишет:
> Weed Wrote:
> 
>> that is, suppose that after some action should get a matrix matrix3x1
> 
> Well... if you want to template every piece of your code, this can
> cause disaster, so I think, this is not very good design. For
> example, multiplication method will be duplicated N*N*N times for all
> possible matrix size combinations.

Only for really used combinations (i am using "duck typing" inside templates).

In any case, unused functions in the resulting file is not included.

> I'd prefer run-time checks, though
> templates can be used for sure.

This problem would help solve the availability of inheritance for structs or compile-time creation of class instances.

But now the compiler can identify duplicate parts of the code, working with the same types