Fixed what I broke in 0.117.

http://www.digitalmars.com/d/changelog.html

Walter wrote:

> Fixed what I broke in 0.117.
> 
> http://www.digitalmars.com/d/changelog.html

Thanks! It now builds both, without problems.
(recompiles both versions of Phobos, that was)

--anders

DMDScript compiles fine, but optlink complains when linking ds.exe because of some undefined symbols. I haven't tried on linux yet, and I don't know if it also happened with 0.117 because I didn't try it.

_______________________
Carlos Santander Bernal

"Carlos Santander B." <csantander619@gmail.com> wrote in message news:d11mge$2bg9$1@digitaldaemon.com...
> DMDScript compiles fine, but optlink complains when linking ds.exe because of some undefined symbols. I haven't tried on linux yet, and I don't know if it also happened with 0.117 because I didn't try it.

It'll link in if protoerror.obj is specifically specified on the command line. I'll fix it.

Hi all.

This topic wroten by gears in Japanese D language wiki.

http://f17.aaa.livedoor.jp/~labamba/?BugTrack%2F12
--------
D cant extends a struct,
I think easily exptends a struct of D if it is possible as follows.

test.d

struct Rect : RECT {
private RECT rect;
alias rect.left   left;
alias rect.top    top;
alias rect.right  right;
alias rect.bottom bottom;

int width()  { return right-left; }
int height() { return bottom-top; }
}

PS.
sorry. this English is poor. long sentence is difficult :)

Thanks,
Hiroshi Sakurai.

Hiroshi Sakurai wrote:

> D cant extends a struct,
> I think easily exptends a struct of D if it is possible as follows.
> 
> test.d
> 
> struct Rect : RECT {
> private RECT rect;
> alias rect.left   left;
> alias rect.top    top;
> alias rect.right  right;
> alias rect.bottom bottom;
> 
> int width()  { return right-left; }
> int height() { return bottom-top; }
> }

The ancient method (in C, that is) to "extend" a struct,
is to declare the "super" structure as the first member:

struct RECT {
int left,top,right,bottom;
}

struct Rect {
private RECT rect;

int width()  { return rect.right-rect.left; }
int height() { return rect.bottom-rect.top; }
}

Then you can still cast a (RECT*) into a (Rect*), for instance.
And maybe the syntax you suggest could be introduced for this ?

--anders

In article <d1257g$2pkj$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Hiroshi Sakurai wrote:
>
>> D cant extends a struct,
>> I think easily exptends a struct of D if it is possible as follows.
>> 
>> test.d
>> 
>> struct Rect : RECT {
>> private RECT rect;
>> alias rect.left   left;
>> alias rect.top    top;
>> alias rect.right  right;
>> alias rect.bottom bottom;
>> 
>> int width()  { return right-left; }
>> int height() { return bottom-top; }
>> }
>
>The ancient method (in C, that is) to "extend" a struct,
>is to declare the "super" structure as the first member:
>
>struct RECT {
>int left,top,right,bottom;
>}
>
>struct Rect {
>private RECT rect;
>
>int width()  { return rect.right-rect.left; }
>int height() { return rect.bottom-rect.top; }
>}
>
>Then you can still cast a (RECT*) into a (Rect*), for instance.
>And maybe the syntax you suggest could be introduced for this ?
>
>--anders

Presumably the OP wants Rect to be implicitly converted to RECT, too. It might be fun to explore expanding the role of structs to have some C++-like behaviors like constructors and "inheritance" (but no vtables).

-Ben

In article <d12atd$2vo8$1@digitaldaemon.com>, Ben Hinkle says...
>
> [examples cut for brevity]
>
>Presumably the OP wants Rect to be implicitly converted to RECT, too. It might be fun to explore expanding the role of structs to have some C++-like behaviors like constructors and "inheritance" (but no vtables).
>

Makes sense to me.  Structs in D have been relegated to an "advanced" programming technique anyway, for a multitude of reasons (pass-by-value, pointers, etc).

I don't see any reason why adding static casting, and compile-time inheritance isn't doable.  It certainly couldn't make them any harder to use.

struct Rect{
uint top,left,height,width;
}

struct MyRect: Rect{
byte color_red,color_blue,color_green,color_alpha;
}

void main(){
MyRect* mr = new MyRect();
Rect *r = cast(Rect*)mr;  // compile-time type checking only (static cast)
}

I can even see interfaces thrown into the mix too, again, as a compile-time inheritance mechanism.

- EricAnderton at yahoo

>Makes sense to me.  Structs in D have been relegated to an "advanced" programming technique anyway, for a multitude of reasons (pass-by-value, pointers, etc).

Why do you say structs are advanced? They are simpler than classes. To me they are a step between basic types like ints and doubles and classes.

>I don't see any reason why adding static casting, and compile-time inheritance isn't doable.  It certainly couldn't make them any harder to use.
>
>struct Rect{
>uint top,left,height,width;
>}
>
>struct MyRect: Rect{
>byte color_red,color_blue,color_green,color_alpha;
>}
>
>void main(){
>MyRect* mr = new MyRect();
>Rect *r = cast(Rect*)mr;  // compile-time type checking only (static cast)
>}

Do you see the compile-time check as disallowing non up-casts? My first assumtion was that casting stays the same - no checks at all - but I can see how the analogy to class casting would be nice, too.

>I can even see interfaces thrown into the mix too, again, as a compile-time inheritance mechanism.
>
>- EricAnderton at yahoo

I think the only danger with adding inheritance-like features to structs is that people would confuse structs with classes. Plus we should figure out a way to avoid slicing structs. Maybe implicit upcasts would have to get the boot.

Walter wrote:
> "Carlos Santander B." <csantander619@gmail.com> wrote in message
> news:d11mge$2bg9$1@digitaldaemon.com...
> 
>>DMDScript compiles fine, but optlink complains when linking ds.exe
>>because of some undefined symbols. I haven't tried on linux yet, and I
>>don't know if it also happened with 0.117 because I didn't try it.
> 
> 
> It'll link in if protoerror.obj is specifically specified on the command
> line. I'll fix it.
> 
> 

This has been a problem with templates for a while, and I hope you address it fully because it's really complex. When having many templates in different modules, the linker complains about undefined symbols and you have to link in the oddest object files so it can go on. Obviously, the problem vanishes when you try to reduce it to send a bug.

_______________________
Carlos Santander Bernal