digitalmars.D - struct intializer
- Andrew Fedoniouk (13/13) Mar 03 2005 struct point { int x, y; }
- Jarrett Billingsley (3/6) Mar 03 2005 I totally agree. That fits in nicely with the existing syntax, and
- Andrew Fedoniouk (14/23) Mar 03 2005 I am using something like this for while:
- Ben Hinkle (12/36) Mar 03 2005 The syntax "point p2 = {x:1,y:2};" currently works if p2 is static. It a...
- Andrew Fedoniouk (10/27) Mar 03 2005 Ben, what is your opinion about using platform dependent Rect implementa...
- Ben Hinkle (9/36) Mar 04 2005 Either way is reasonable but for MinWin I chose to wrap all native types...
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
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
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
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
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
Ben Hinkle <Ben_member pathlink.com> In article <d08vbq$a70$1 digitaldaemon.com>, Andrew Fedoniouk says...I think he knows but requesting again wouldn't hurt, I guess.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.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.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 04 2005