www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - distinguish between classes and structures

reply Weed <resume755 mail.ru> writes:
Who can provide a link to an explanation about why in D has taken to 
distinguish between classes and structures?

(Sorry for my bad English)
Dec 14 2008
next sibling parent reply "Bill Baxter" <wbaxter gmail.com> writes:
On Mon, Dec 15, 2008 at 3:35 PM, Weed <resume755 mail.ru> wrote:
 Who can provide a link to an explanation about why in D has taken to
 distinguish between classes and structures?

 (Sorry for my bad English)

The main justification is eliminating the slicing problem. http://cplusplusgems.blogspot.com/2005/10/what-is-slicing-problem-class-base.html D solves it by making it impossible to have a class instance as a value type. --bb
Dec 14 2008
parent reply Weed <resume755 mail.ru> writes:
Bill Baxter пишет:
 On Mon, Dec 15, 2008 at 3:35 PM, Weed <resume755 mail.ru> wrote:
 Who can provide a link to an explanation about why in D has taken to
 distinguish between classes and structures?

 (Sorry for my bad English)

The main justification is eliminating the slicing problem. http://cplusplusgems.blogspot.com/2005/10/what-is-slicing-problem-class-base.html D solves it by making it impossible to have a class instance as a value type.

Why not disallow the casting for structs, leaving the possibility of up casting for the links and pointers to the structure?
Dec 14 2008
next sibling parent Weed <resume755 mail.ru> writes:
Weed пишет:
 Bill Baxter пишет:
 On Mon, Dec 15, 2008 at 3:35 PM, Weed <resume755 mail.ru> wrote:
 Who can provide a link to an explanation about why in D has taken to
 distinguish between classes and structures?

 (Sorry for my bad English)

The main justification is eliminating the slicing problem. http://cplusplusgems.blogspot.com/2005/10/what-is-slicing-pro lem-class-base.html D solves it by making it impossible to have a class instance as a value type.

Why not disallow the casting for structs, leaving the possibility of up casting for the links and pointers to the structure?

What is the best place for such questions?
Dec 15 2008
prev sibling parent reply Weed <resume755 mail.ru> writes:
Bill Baxter пишет:
 2008/12/15 Weed <resume755 mail.ru>:
 Bill Baxter пишет:
 On Mon, Dec 15, 2008 at 3:35 PM, Weed <resume755 mail.ru> wrote:
 Who can provide a link to an explanation about why in D has taken to
 distinguish between classes and structures?

 (Sorry for my bad English)

http://cplusplusgems.blogspot.com/2005/10/what-is-slicing-problem-class-base.html D solves it by making it impossible to have a class instance as a value type.

Why not disallow the casting for structs, leaving the possibility of up casting for the links and pointers to the structure?

I have to confess I don't really understand this question. Can you rephrase or give an example?

Sorry, English is not my native language In C++, we had the problem - "slicing" objects. In D this problem is solved inability to inherit from structs. Without inheritance of structs many things are not possible, compared with C++. Why, instead of the complete inability to inherit, just do not make impossible to up casting struct type by value. like this: struct s1 {} struct s2 : s1 {} s1 base; s2 derr; s1* base_ptr = &derr; // ok s1 val = derr; // error
Dec 15 2008
next sibling parent Weed <resume755 mail.ru> writes:
Weed пишет:
 Why, instead of the complete inability to inherit, just do not make 
 impossible to up casting struct type by value.

It's a question: Why, instead of the complete inability to inherit, just do not make impossible to up casting struct type by value?
Dec 15 2008
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Weed Wrote:

 Without inheritance of structs many things are not possible, compared 
 with C++.

for example?
Dec 15 2008
parent reply Weed <resume755 mail.ru> writes:
Kagamin пишет:
 Weed Wrote:
 
 Without inheritance of structs many things are not possible, compared 
 with C++.

for example?

it is impossible to create the struct of the object which will be arbitrary size (raised by a user) + to be able to set compile-time + should work with the structures of its type. this is mathematical matrix, for example
Dec 15 2008
parent reply Kagamin <spam here.lot> writes:
Weed Wrote:

 it is impossible to create the struct of the object which will be 
 arbitrary size (raised by a user) + to be able to set compile-time + 
 should work with the structures of its type.
 
 this is mathematical matrix, for example

Matix? Easy. class Matrix //can inherit from some generic base class { int[2] dims; int[][] data; //methods }
Dec 16 2008
parent Weed <resume755 mail.ru> writes:
Kagamin пишет:
 Weed Wrote:
 
 it is impossible to create the struct of the object which will be 
 arbitrary size (raised by a user) + to be able to set compile-time + 
 should work with the structures of its type.

 this is mathematical matrix, for example

Matix? Easy. class Matrix //can inherit from some generic base class { int[2] dims; int[][] data; //methods }

not just a matrix, see thread "struct inheritance need?" in this NG
Dec 16 2008
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Weed wrote:
 In C++, we had the problem - "slicing" objects.
 In D this problem is solved inability to inherit from structs.
 Without inheritance of structs many things are not possible, compared 
 with C++.
 Why, instead of the complete inability to inherit, just do not make 
 impossible to up casting struct type by value.
 
 like this:
 
 struct s1 {}
 struct s2 : s1 {}
 
 s1 base;
 s2 derr;
 
 s1* base_ptr = &derr; // ok
 s1 val = derr; // error

This is why: s1 val2 = *base_ptr; // error (And disallowing '*ptr' on struct pointers is not likely to find much support)
Dec 15 2008
next sibling parent Weed <resume755 mail.ru> writes:
Frits van Bommel пишет:
 Weed wrote:
 In C++, we had the problem - "slicing" objects.
 In D this problem is solved inability to inherit from structs.
 Without inheritance of structs many things are not possible, compared 
 with C++.
 Why, instead of the complete inability to inherit, just do not make 
 impossible to up casting struct type by value.

 like this:

 struct s1 {}
 struct s2 : s1 {}

 s1 base;
 s2 derr;

 s1* base_ptr = &derr; // ok
 s1 val = derr; // error

This is why: s1 val2 = *base_ptr; // error

Yes, right. I do not understand that it is wrong?
 (And disallowing '*ptr' on struct pointers is not likely to find much
 support)

I am not saying do not let '* ptr'. Besides, now you can not do this just because there is no inheritance at all.
Dec 15 2008
prev sibling next sibling parent Weed <resume755 mail.ru> writes:
Bill Baxter пишет:
 2008/12/16 Weed <resume755 mail.ru>:
 Frits van Bommel пишет:
 Weed wrote:
 In C++, we had the problem - "slicing" objects.
 In D this problem is solved inability to inherit from structs.
 Without inheritance of structs many things are not possible, compared
 with C++.
 Why, instead of the complete inability to inherit, just do not make
 impossible to up casting struct type by value.

 like this:

 struct s1 {}
 struct s2 : s1 {}

 s1 base;
 s2 derr;

 s1* base_ptr = &derr; // ok
 s1 val = derr; // error

s1 val2 = *base_ptr; // error


The problem is that base_ptr isn't actually pointing to an s1. So by dereferencing it and assigning to an s1 you just sliced it.

This break garbage collection? Or what?
  Any extra
 data derr had is lost.  Any method overrides it had are lost.  So to
 avoid slicing you would need to disallow dereferencing struct
 pointers, or disallow pointing to a struct of a different type.
 
 Disallowing dereferencing a struct pointer seems like it might be
 possible.  But then again that's also kinda what class gives you
 already.  And then you'd be left with no way to create a pointer that
 can be turned back into a value!  That doesn't sound so good.

Dec 15 2008
prev sibling parent Weed <resume755 mail.ru> writes:
Bill Baxter пишет:
 2008/12/16 Weed <resume755 mail.ru>:
 Frits van Bommel пишет:
 Weed wrote:
 In C++, we had the problem - "slicing" objects.
 In D this problem is solved inability to inherit from structs.
 Without inheritance of structs many things are not possible, compared
 with C++.
 Why, instead of the complete inability to inherit, just do not make
 impossible to up casting struct type by value.

 like this:

 struct s1 {}
 struct s2 : s1 {}

 s1 base;
 s2 derr;

 s1* base_ptr = &derr; // ok
 s1 val = derr; // error

s1 val2 = *base_ptr; // error


The problem is that base_ptr isn't actually pointing to an s1. So by dereferencing it and assigning to an s1 you just sliced it. Any extra data derr had is lost. Any method overrides it had are lost. So to avoid slicing you would need to disallow dereferencing struct pointers, or disallow pointing to a struct of a different type. Disallowing dereferencing a struct pointer seems like it might be possible. But then again that's also kinda what class gives you already. And then you'd be left with no way to create a pointer that can be turned back into a value! That doesn't sound so good. --bb

Classes can not be created at compile time. D, with its templates would do it perfectly for structs.
Dec 15 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
MjAwOC8xMi8xNSBXZWVkIDxyZXN1bWU3NTVAbWFpbC5ydT46Cj4gQmlsbCBCYXh0ZXIg0MnbxdQ6
Cj4+Cj4+IE9uIE1vbiwgRGVjIDE1LCAyMDA4IGF0IDM6MzUgUE0sIFdlZWQgPHJlc3VtZTc1NUBt
YWlsLnJ1PiB3cm90ZToKPj4+Cj4+PiBXaG8gY2FuIHByb3ZpZGUgYSBsaW5rIHRvIGFuIGV4cGxh
bmF0aW9uIGFib3V0IHdoeSBpbiBEIGhhcyB0YWtlbiB0bwo+Pj4gZGlzdGluZ3Vpc2ggYmV0d2Vl
biBjbGFzc2VzIGFuZCBzdHJ1Y3R1cmVzPwo+Pj4KPj4+IChTb3JyeSBmb3IgbXkgYmFkIEVuZ2xp
c2gpCj4+Pgo+Pgo+PiBUaGUgbWFpbiBqdXN0aWZpY2F0aW9uIGlzIGVsaW1pbmF0aW5nIHRoZSBz
bGljaW5nIHByb2JsZW0uCj4+Cj4+IGh0dHA6Ly9jcGx1c3BsdXNnZW1zLmJsb2dzcG90LmNvbS8y
MDA1LzEwL3doYXQtaXMtc2xpY2luZy1wcm9ibGVtLWNsYXNzLWJhc2UuaHRtbAo+Pgo+PiBEIHNv
bHZlcyBpdCBieSBtYWtpbmcgaXQgaW1wb3NzaWJsZSB0byBoYXZlIGEgY2xhc3MgaW5zdGFuY2Ug
YXMgYSB2YWx1ZQo+PiB0eXBlLgo+Pgo+Cj4KPiBXaHkgbm90IGRpc2FsbG93IHRoZSBjYXN0aW5n
IGZvciBzdHJ1Y3RzLCBsZWF2aW5nIHRoZSBwb3NzaWJpbGl0eSBvZiB1cAo+IGNhc3RpbmcgZm9y
IHRoZSBsaW5rcyBhbmQgcG9pbnRlcnMgdG8gdGhlIHN0cnVjdHVyZT8KCkkgaGF2ZSB0byBjb25m
ZXNzIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3RhbmQgdGhpcyBxdWVzdGlvbi4gIENhbiB5b3UKcmVw
aHJhc2Ugb3IgZ2l2ZSBhbiBleGFtcGxlPwoKLS1iYgo=
Dec 15 2008
prev sibling next sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
MjAwOC8xMi8xNSBXZWVkIDxyZXN1bWU3NTVAbWFpbC5ydT46Cj4gV2VlZCDQydvF1DoKPj4KPj4g
QmlsbCBCYXh0ZXIg0MnbxdQ6Cj4+Pgo+Pj4gT24gTW9uLCBEZWMgMTUsIDIwMDggYXQgMzozNSBQ
TSwgV2VlZCA8cmVzdW1lNzU1QG1haWwucnU+IHdyb3RlOgo+Pj4+Cj4+Pj4gV2hvIGNhbiBwcm92
aWRlIGEgbGluayB0byBhbiBleHBsYW5hdGlvbiBhYm91dCB3aHkgaW4gRCBoYXMgdGFrZW4gdG8K
Pj4+PiBkaXN0aW5ndWlzaCBiZXR3ZWVuIGNsYXNzZXMgYW5kIHN0cnVjdHVyZXM/Cj4+Pj4KPj4+
PiAoU29ycnkgZm9yIG15IGJhZCBFbmdsaXNoKQo+Pj4+Cj4+Pgo+Pj4gVGhlIG1haW4ganVzdGlm
aWNhdGlvbiBpcyBlbGltaW5hdGluZyB0aGUgc2xpY2luZyBwcm9ibGVtLgo+Pj4KPj4+IGh0dHA6
Ly9jcGx1c3BsdXNnZW1zLmJsb2dzcG90LmNvbS8yMDA1LzEwL3doYXQtaXMtc2xpY2luZy1wcm9i
bGVtLWNsYXNzLWJhc2UuaHRtbAo+Pj4KPj4+IEQgc29sdmVzIGl0IGJ5IG1ha2luZyBpdCBpbXBv
c3NpYmxlIHRvIGhhdmUgYSBjbGFzcyBpbnN0YW5jZSBhcyBhIHZhbHVlCj4+PiB0eXBlLgo+Pj4K
Pj4KPj4KPj4gV2h5IG5vdCBkaXNhbGxvdyB0aGUgY2FzdGluZyBmb3Igc3RydWN0cywgbGVhdmlu
ZyB0aGUgcG9zc2liaWxpdHkgb2YgdXAKPj4gY2FzdGluZyBmb3IgdGhlIGxpbmtzIGFuZCBwb2lu
dGVycyB0byB0aGUgc3RydWN0dXJlPwo+Cj4gV2hhdCBpcyB0aGUgYmVzdCBwbGFjZSBmb3Igc3Vj
aCBxdWVzdGlvbnM/CgpIZXJlIGlzIGZpbmUuICBkaWdpdGFsbWFycy5kIG1pZ2h0IGJlIG9rIHRv
by4KClRoaXMgc2VlbXMgbGlrZSBhIHF1ZXN0aW9uIHRoYXQgZGVzZXJ2ZXMgYSBnb29kIGFuc3dl
ciBvbiB0aGUgInJhdGlvbmFsZSIgcGFnZToKaHR0cDovL3d3dy5kaWdpdGFsbWFycy5jb20vZC8y
LjAvcmF0aW9uYWxlLmh0bWwKCkkgd2FzIGp1c3QgcXVvdGluZyB0byB5b3UgdGhlIGp1c3RpZmlj
YXRpb24gSSd2ZSBoZWFyZCBnaXZlbiBiZWZvcmUuCkJ1dCBJJ20gbm90IG5lY2Vzc2FyaWx5IGNv
bnZpbmNlZCB0aGF0IGl0J3MgYSBuZXQgd2luIGZvciB0aGUKbGFuZ3VhZ2UuICBJIGZpbmQgdGhh
dCBpdCBtYWtlcyB0aGluZ3Mgc2ltcGxlciBpbiBzb21lIHdheXMgYW5kIG1vcmUKY29tcGxpY2F0
ZWQgaW4gb3RoZXIgd2F5cy4gIEJ1dCB0aGUgInNhZmV0eSBmaXJzdCIgYXJndW1lbnQgc2F5cyB0
aGF0CmlmIGl0IGdldHMgb25lIHBvdGVudGlhbCBidWcgKGFrYSBzbGljaW5nKSwgdGhlbiBpdHMg
YSBuZXQgd2luLiAgSSdtCm5vdCBzbyBzdXJlLgoKLS1iYgo=
Dec 15 2008
prev sibling parent "Bill Baxter" <wbaxter gmail.com> writes:
MjAwOC8xMi8xNiBXZWVkIDxyZXN1bWU3NTVAbWFpbC5ydT46Cj4gRnJpdHMgdmFuIEJvbW1lbCDQ
ydvF1DoKPj4KPj4gV2VlZCB3cm90ZToKPj4+Cj4+PiBJbiBDKyssIHdlIGhhZCB0aGUgcHJvYmxl
bSAtICJzbGljaW5nIiBvYmplY3RzLgo+Pj4gSW4gRCB0aGlzIHByb2JsZW0gaXMgc29sdmVkIGlu
YWJpbGl0eSB0byBpbmhlcml0IGZyb20gc3RydWN0cy4KPj4+IFdpdGhvdXQgaW5oZXJpdGFuY2Ug
b2Ygc3RydWN0cyBtYW55IHRoaW5ncyBhcmUgbm90IHBvc3NpYmxlLCBjb21wYXJlZAo+Pj4gd2l0
aCBDKysuCj4+PiBXaHksIGluc3RlYWQgb2YgdGhlIGNvbXBsZXRlIGluYWJpbGl0eSB0byBpbmhl
cml0LCBqdXN0IGRvIG5vdCBtYWtlCj4+PiBpbXBvc3NpYmxlIHRvIHVwIGNhc3Rpbmcgc3RydWN0
IHR5cGUgYnkgdmFsdWUuCj4+Pgo+Pj4gbGlrZSB0aGlzOgo+Pj4KPj4+IHN0cnVjdCBzMSB7fQo+
Pj4gc3RydWN0IHMyIDogczEge30KPj4+Cj4+PiBzMSBiYXNlOwo+Pj4gczIgZGVycjsKPj4+Cj4+
PiBzMSogYmFzZV9wdHIgPSAmZGVycjsgLy8gb2sKPj4+IHMxIHZhbCA9IGRlcnI7IC8vIGVycm9y
Cj4+Cj4+IFRoaXMgaXMgd2h5Ogo+PiAgczEgdmFsMiA9ICpiYXNlX3B0cjsgLy8gZXJyb3IKPgo+
IEkgZG8gbm90IHVuZGVyc3RhbmQgdGhhdCBpdCBpcyB3cm9uZz8KClRoZSBwcm9ibGVtIGlzIHRo
YXQgYmFzZV9wdHIgaXNuJ3QgYWN0dWFsbHkgcG9pbnRpbmcgdG8gYW4gczEuICBTbyBieQpkZXJl
ZmVyZW5jaW5nIGl0IGFuZCBhc3NpZ25pbmcgdG8gYW4gczEgeW91IGp1c3Qgc2xpY2VkIGl0LiAg
QW55IGV4dHJhCmRhdGEgZGVyciBoYWQgaXMgbG9zdC4gIEFueSBtZXRob2Qgb3ZlcnJpZGVzIGl0
IGhhZCBhcmUgbG9zdC4gIFNvIHRvCmF2b2lkIHNsaWNpbmcgeW91IHdvdWxkIG5lZWQgdG8gZGlz
YWxsb3cgZGVyZWZlcmVuY2luZyBzdHJ1Y3QKcG9pbnRlcnMsIG9yIGRpc2FsbG93IHBvaW50aW5n
IHRvIGEgc3RydWN0IG9mIGEgZGlmZmVyZW50IHR5cGUuCgpEaXNhbGxvd2luZyBkZXJlZmVyZW5j
aW5nIGEgc3RydWN0IHBvaW50ZXIgc2VlbXMgbGlrZSBpdCBtaWdodCBiZQpwb3NzaWJsZS4gIEJ1
dCB0aGVuIGFnYWluIHRoYXQncyBhbHNvIGtpbmRhIHdoYXQgY2xhc3MgZ2l2ZXMgeW91CmFscmVh
ZHkuICBBbmQgdGhlbiB5b3UnZCBiZSBsZWZ0IHdpdGggbm8gd2F5IHRvIGNyZWF0ZSBhIHBvaW50
ZXIgdGhhdApjYW4gYmUgdHVybmVkIGJhY2sgaW50byBhIHZhbHVlISAgVGhhdCBkb2Vzbid0IHNv
dW5kIHNvIGdvb2QuCgotLWJiCg==
Dec 15 2008