View mode: basic / threaded / horizontal-split · Log in · Help
March 03, 2005
struct intializer
struct point { int x, y; }
point p2 = { 1,2 };

I am getting this while compilation:
".\geometry.d(43): variable rect.this.p2 is not a static and cannot have 
static initializer"

Is there any logical / physical problems for "only statics" limitations?
As far as I can see from grammar point of view such initializers are not
so far from "static point p2 = { 1,2 };"

As structs have no ctors then I think having something like

point p2 = { x:1, y:2 };

would be extremely nice.

Andrew Fedoniouk.
http://terrainformatica.com
March 04, 2005
Re: struct intializer
> As structs have no ctors then I think having something like
>
> point p2 = { x:1, y:2 };
>
> would be extremely nice.

I totally agree.  That fits in nicely with the existing syntax, and 
sometimes it's just a pain to have to make a static opcall (fake ctor) for 
each struct.
March 04, 2005
Re: struct intializer
I am using  something like this for while:

point p = point.make(1,2);

ugly but works.

struct point
{
 int x,y;

 // external ctor (structs do not have ctors in D)
 // use it as:  point p = point.make(1,2);
 static point  make( int x, int y ) { point p; p.x = x; p.y = y; return 
p; }
}

Andrew.


"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message 
news:d089jo$2ndp$1@digitaldaemon.com...
>> As structs have no ctors then I think having something like
>>
>> point p2 = { x:1, y:2 };
>>
>> would be extremely nice.
>
> I totally agree.  That fits in nicely with the existing syntax, and 
> sometimes it's just a pain to have to make a static opcall (fake ctor) for 
> each struct.
>
March 04, 2005
Re: struct intializer
In article <d08fu6$2t06$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>I am using  something like this for while:
>
>point p = point.make(1,2);
>
>ugly but works.
>
>struct point
>{
>  int x,y;
>
>  // external ctor (structs do not have ctors in D)
>  // use it as:  point p = point.make(1,2);
>  static point  make( int x, int y ) { point p; p.x = x; p.y = y; return 
>p; }
>}
>
>Andrew.
>
>
>"Jarrett Billingsley" <kb3ctd2@yahoo.com> wrote in message 
>news:d089jo$2ndp$1@digitaldaemon.com...
>>> As structs have no ctors then I think having something like
>>>
>>> point p2 = { x:1, y:2 };
>>>
>>> would be extremely nice.
>>
>> I totally agree.  That fits in nicely with the existing syntax, and 
>> sometimes it's just a pain to have to make a static opcall (fake ctor) for 
>> each struct.
>> 
>

The syntax "point p2 = {x:1,y:2};" currently works if p2 is static. It also
works when you have arrays of points "point[] p3 = [{x:1,y:2},{x:3,y:4}];". I
think it came up a while ago - or comes up every now and then, to have some kind
of non-static versions of both of these.

I've personally stopped using the static opCall. Instead nowadays I use toplevel
functions called things like toPoint or depending on the struct I use some
custom name like LTRB or LTWH for constructing rectangles from
left,top,right,bottom or left,top,width,height respectively. The rectangle thing
I started in MinWin because I can never remember which system stores their
rectangles in which style so I let you do either and have the code self-document
which you are doing. These conventions will probably evolve for a while.
March 04, 2005
Re: struct intializer
> The syntax "point p2 = {x:1,y:2};" currently works if p2 is static. It 
> also
> works when you have arrays of points "point[] p3 = 
> [{x:1,y:2},{x:3,y:4}];". I
> think it came up a while ago - or comes up every now and then, to have 
> some kind
> of non-static versions of both of these.
>

Yep. Shall we ask Walter to do something?
I've digged in compiler source, seems like this is doable pretty easily.

> I've personally stopped using the static opCall. Instead nowadays I use 
> toplevel
> functions called things like toPoint or depending on the struct I use some
> custom name like LTRB or LTWH for constructing rectangles from
> left,top,right,bottom or left,top,width,height respectively. The rectangle 
> thing
> I started in MinWin because I can never remember which system stores their
> rectangles in which style so I let you do either and have the code 
> self-document
> which you are doing. These conventions will probably evolve for a while.

Ben, what is your opinion about using platform dependent Rect implementation 
on
this stage?
I've decided to use one "standard" implementation for that.
J-SMILE uses  16 "native" graphic functions from underlying OS
so I think it is not a big deal to convert Rect, Point, etc in native
function wrapers in place. Huh?

Andrew.
March 04, 2005
Re: struct intializer
In article <d08vbq$a70$1@digitaldaemon.com>, Andrew Fedoniouk says...
>
>> The syntax "point p2 = {x:1,y:2};" currently works if p2 is static. It 
>> also
>> works when you have arrays of points "point[] p3 = 
>> [{x:1,y:2},{x:3,y:4}];". I
>> think it came up a while ago - or comes up every now and then, to have 
>> some kind
>> of non-static versions of both of these.
>>
>
>Yep. Shall we ask Walter to do something?
>I've digged in compiler source, seems like this is doable pretty easily.

I think he knows but requesting again wouldn't hurt, I guess.

>> I've personally stopped using the static opCall. Instead nowadays I use 
>> toplevel
>> functions called things like toPoint or depending on the struct I use some
>> custom name like LTRB or LTWH for constructing rectangles from
>> left,top,right,bottom or left,top,width,height respectively. The rectangle 
>> thing
>> I started in MinWin because I can never remember which system stores their
>> rectangles in which style so I let you do either and have the code 
>> self-document
>> which you are doing. These conventions will probably evolve for a while.
>
>Ben, what is your opinion about using platform dependent Rect implementation 
>on this stage?
>I've decided to use one "standard" implementation for that.
>J-SMILE uses  16 "native" graphic functions from underlying OS
>so I think it is not a big deal to convert Rect, Point, etc in native
>function wrapers in place. Huh?

Either way is reasonable but for MinWin I chose to wrap all native types where
possible since a goal of MinWin is to make it easy to do platform-specific
coding. For a while I was actually just using aliases for Rect to be RECT or
XRectangle etc but a few days ago I decided that style wasn't as convenient as
defining new types that wrap the native type. For Rect and Point it might not
matter but for event structs and font structs the fancy parts differ quite a bit
between platform.

>
>Andrew.
Top | Discussion index | About this forum | D home