www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - struct intializer

reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
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
Mar 03 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 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.
Mar 03 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
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.

Mar 03 2005
parent reply Ben Hinkle <Ben_member pathlink.com> writes:
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.
Mar 03 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 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.
Mar 03 2005
parent Ben Hinkle <Ben_member pathlink.com> writes:
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.

Mar 04 2005