digitalmars.D.learn - Best way to reference an array in a child class...
- captain_fid (4/4) Mar 06 2014 Sorry for the very basic question. Much still alludes me with
-
captain_fid
(25/29)
Mar 06 2014
Wow sorry for that. I'm a moron... don't press
... - Steven Schveighoffer (6/35) Mar 06 2014 I would highly suggest to just use S[] and not S[]*. A slice is already ...
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (5/15) Mar 06 2014 But what if there are elements added to B.items later on? I assumed the
- Steven Schveighoffer (20/36) Mar 06 2014 First, it's very cumbersome to work with a pointer to an array. All arra...
- Steven Schveighoffer (5/7) Mar 06 2014 Sorry, I meant an array *reference*, not an array. Clearly allocating an...
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (4/7) Mar 06 2014 Agreed. Alternatively, a member function in the child class could return...
- captain_fid (14/22) Mar 06 2014 Steve, thanks for the link and the nicely written article. Also
- Steven Schveighoffer (36/60) Mar 06 2014 e =
- captain_fid (10/66) Mar 06 2014 Yes Steve!
- captain_fid (6/7) Mar 06 2014 strangely enough, when modeling this the first time (using items
- captain_fid (22/22) Mar 06 2014 Well, actually... take it back.
- bearophile (8/26) Mar 06 2014 For reasons I don't know that {} syntax doesn't always work in D.
- captain_fid (3/32) Mar 06 2014 Going to have to buy the whole bar a round. Thanks bearophile for
- Steven Schveighoffer (13/19) Mar 07 2014 I missed this the first time. That is a difference between my code and
- captain_fid (12/49) Mar 07 2014 Steve, I don't think I know my use case -- So it's not you. I'm
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (69/73) Mar 06 2014 function?
- captain_fid (5/5) Mar 06 2014 Steve and Ali, Thanks for the quick helpful suggestions. In this
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (54/83) Mar 06 2014 You need to dereference the pointer by * and you would be using a slice:
Sorry for the very basic question. Much still alludes me with this language. I appreciate the forum. struct S {
Mar 06 2014
On Thursday, 6 March 2014 at 19:19:29 UTC, captain_fid wrote:Sorry for the very basic question. Much still alludes me with this language. I appreciate the forum. struct S {Wow sorry for that. I'm a moron... don't press <tab> <enter>... struct S { int a; string b; } class A { S[]* pointer_to_list; abstract... } class B: A { S[] items = [ {10, "first"}, {20, "second"}]; this() { pointer_to_list = &items; } } My problem is in de-referencing later (seg fault). Is this even the best way? I Really need to access the array in a derived class. 'S' (I believe) really is best as a Structure. Any suggestions. Thanks in advance (and sorry for the rough start).
Mar 06 2014
On Thu, 06 Mar 2014 14:31:52 -0500, captain_fid <bell.hue gmail.com> wrote:On Thursday, 6 March 2014 at 19:19:29 UTC, captain_fid wrote:I would highly suggest to just use S[] and not S[]*. A slice is already a reference (coupled with a length). You can read more about D arrays and slices here: http://dlang.org/d-array-article.html -SteveSorry for the very basic question. Much still alludes me with this language. I appreciate the forum. struct S {Wow sorry for that. I'm a moron... don't press <tab> <enter>... struct S { int a; string b; } class A { S[]* pointer_to_list; abstract... } class B: A { S[] items = [ {10, "first"}, {20, "second"}]; this() { pointer_to_list = &items; } } My problem is in de-referencing later (seg fault). Is this even the best way? I Really need to access the array in a derived class. 'S' (I believe) really is best as a Structure. Any suggestions. Thanks in advance (and sorry for the rough start).
Mar 06 2014
On 03/06/2014 11:40 AM, Steven Schveighoffer wrote:class A { S[]* pointer_to_list; abstract... }I would highly suggest to just use S[] and not S[]*. A slice is already a reference (coupled with a length).But what if there are elements added to B.items later on? I assumed the OP wanted a true reference.You can read more about D arrays and slices here: http://dlang.org/d-array-article.htmlMy I suggest you do the same. :o)-SteveAli
Mar 06 2014
On Thu, 06 Mar 2014 14:47:49 -0500, Ali =C3=87ehreli <acehreli yahoo.com=wrote:On 03/06/2014 11:40 AM, Steven Schveighoffer wrote: >> class A >> { >> S[]* pointer_to_list; >> abstract... >> } > I would highly suggest to just use S[] and not S[]*. A slice is =already > a reference (coupled with a length). But what if there are elements added to B.items later on? I assumed th=e =OP wanted a true reference.First, it's very cumbersome to work with a pointer to an array. All arra= y = syntax sugar does not peek through the reference, you have to * everythi= ng. Second, it's very difficult to get an array, just by itself, in the heap= . = And you don't want to store a reference to a stack-frame slice. I think there is a good reason you seldom see code that has pointers to = = array in D, the above code snippet seems to me like a programmer who = doesn't understand what a D slice is. Actually, given the subject of this post, I take it back. The best way t= o = reference an array in a child class, especially one of a static type, is= = to not have another copy in the child class :)> You can read more about D arrays and slices here: > > http://dlang.org/d-array-article.html My I suggest you do the same. :o)TL;DR ;) -Steve
Mar 06 2014
On Thu, 06 Mar 2014 15:02:14 -0500, Steven Schveighoffer <schveiguy yahoo.com> wrote:Second, it's very difficult to get an array, just by itself, in the heap. And you don't want to store a reference to a stack-frame slice.Sorry, I meant an array *reference*, not an array. Clearly allocating an array in the heap is easy, but allocating a pointer to an array is not :) -Steve
Mar 06 2014
On 03/06/2014 12:02 PM, Steven Schveighoffer wrote:The best way to reference an array in a child class, especially one of a static type, is to not have another copy in the child class :)Agreed. Alternatively, a member function in the child class could return a slice. Ali
Mar 06 2014
On Thursday, 6 March 2014 at 21:26:11 UTC, Ali Çehreli wrote:On 03/06/2014 12:02 PM, Steven Schveighoffer wrote:Steve, thanks for the link and the nicely written article. Also for the assessment on pointer syntax, I'd love to avoid if possible (especially w/ limitations you noted). I had been spending time over at http://dlang.org/arrays.html and had forgotten (or never understood) dynamic arrays were passed by slices. That link only talks about passing static arrays (IIRC). Keeping track of 'what being passed how' is tough for this programmer. Your suggestion Ali (of not accessing the base member in the child was great) and it works properly. Believe if I understand what you are suggesting above is never to have the array in base? simply retrieve slice through the child member function?The best way to reference an array in a child class, especially one of astatic type,is to not have another copy in the child class :)Agreed. Alternatively, a member function in the child class could return a slice. Ali
Mar 06 2014
On Thu, 06 Mar 2014 17:05:12 -0500, captain_fid <bell.hue gmail.com> wro= te:On Thursday, 6 March 2014 at 21:26:11 UTC, Ali =C3=87ehreli wrote:On 03/06/2014 12:02 PM, Steven Schveighoffer wrote:The best way to reference an array in a child class, especially one of astatic type,is to not have another copy in the child class :)Agreed. Alternatively, a member function in the child class could =e =return a slice. AliSteve, thanks for the link and the nicely written article. Also for th=assessment on pointer syntax, I'd love to avoid if possible (especiall=y =w/ limitations you noted). I had been spending time over at http://dlang.org/arrays.html and had ==forgotten (or never understood) dynamic arrays were passed by slices. ==That link only talks about passing static arrays (IIRC). Keeping track==of 'what being passed how' is tough for this programmer. Your suggestion Ali (of not accessing the base member in the child was==great) and it works properly. Believe if I understand what you are suggesting above is never to have==the array in base? simply retrieve slice through the child member =function?I think what Ali means is: class A { abstract S[] items(); } class B : A { S[] _items =3D [ {10, "first"}, {20, "second"}]; override S[] items() { return _items;} } What I was saying is, if you know the items are going to be stored in th= e = object, just store them in the base: class A { S[] items; } class B : A { this() {items =3D [ {10, "first"}, {20, "second"}];} } This way, both the derived and the base will always see the same items, = = and you only store it in the object once. Obviously if you store the ite= ms = elsewhere in some derivatives, Ali's idea is preferable. -Steve
Mar 06 2014
On Thursday, 6 March 2014 at 22:16:50 UTC, Steven Schveighoffer wrote:On Thu, 06 Mar 2014 17:05:12 -0500, captain_fid <bell.hue gmail.com> wrote:Yes Steve! Even if the title of the thread is off, the original intent was what you've shown. For a reason (probably duplicate definitions in base and child) I would end up with items in B and not visible in A. I didn't understand the syntax for performing the above. I owe you guys a beer (or something). Definitely a learning lesson.On Thursday, 6 March 2014 at 21:26:11 UTC, Ali Çehreli wrote:I think what Ali means is: class A { abstract S[] items(); } class B : A { S[] _items = [ {10, "first"}, {20, "second"}]; override S[] items() { return _items;} } What I was saying is, if you know the items are going to be stored in the object, just store them in the base: class A { S[] items; } class B : A { this() {items = [ {10, "first"}, {20, "second"}];} } This way, both the derived and the base will always see the same items, and you only store it in the object once. Obviously if you store the items elsewhere in some derivatives, Ali's idea is preferable. -SteveOn 03/06/2014 12:02 PM, Steven Schveighoffer wrote:Steve, thanks for the link and the nicely written article. Also for the assessment on pointer syntax, I'd love to avoid if possible (especially w/ limitations you noted). I had been spending time over at http://dlang.org/arrays.html and had forgotten (or never understood) dynamic arrays were passed by slices. That link only talks about passing static arrays (IIRC). Keeping track of 'what being passed how' is tough for this programmer. Your suggestion Ali (of not accessing the base member in the child was great) and it works properly. Believe if I understand what you are suggesting above is never to have the array in base? simply retrieve slice through the child member function?The best way to reference an array in a child class, especially one of astatic type,is to not have another copy in the child class :)Agreed. Alternatively, a member function in the child class could return a slice. Ali
Mar 06 2014
strangely enough, when modeling this the first time (using items as a class) and 'new item() syntax) there was no real issue. I thought using a static array of structs in the children would be more efficient when instantiating the objects. Never mind whether its true or not - Speed isn't a really a concern, learning is.this() {items = [ {10, "first"}, {20, "second"}];}
Mar 06 2014
Well, actually... take it back. When I did try this syntax, I receive(d) the following error. I then went and created this test which I thought couldn't go wrong. with both dmd and gdc ... struct S { int a; string b; } class A { S[] items; abstract void doit(); } class B: A { this() {items = [ {10, "first"}, {20, "second"}];} // line 21 override void doit() { } } (21): Error: found '}' when expecting ';' following statement (21): Error: found ',' instead of statement
Mar 06 2014
captain_fid:struct S { int a; string b; } class A { S[] items; abstract void doit(); } class B: A { this() {items = [ {10, "first"}, {20, "second"}];} // line 21 override void doit() { } } (21): Error: found '}' when expecting ';' following statement (21): Error: found ',' instead of statementFor reasons I don't know that {} syntax doesn't always work in D. So try: this() { this.items = [S(10, "first"), S(20, "second")]; } Bye, bearophile
Mar 06 2014
On Friday, 7 March 2014 at 00:10:20 UTC, bearophile wrote:captain_fid:Going to have to buy the whole bar a round. Thanks bearophile for the quick fix!struct S { int a; string b; } class A { S[] items; abstract void doit(); } class B: A { this() {items = [ {10, "first"}, {20, "second"}];} // line 21 override void doit() { } } (21): Error: found '}' when expecting ';' following statement (21): Error: found ',' instead of statementFor reasons I don't know that {} syntax doesn't always work in D. So try: this() { this.items = [S(10, "first"), S(20, "second")]; } Bye, bearophile
Mar 06 2014
On Thu, 06 Mar 2014 17:44:09 -0500, captain_fid <bell.hue gmail.com> wrote:I missed this the first time. That is a difference between my code and your code. Mine creates a new instance of an array on *object* initialization, yours creates ONE instance of an array, that all objects share. This is not necessarily a good thing. Because you've created a mutable version of the array. I believe it is initialized on startup from the heap. One really bad thing is, the same array is used if you initialize from multiple threads. And it's mutable, making it implicitly shared even though it shouldn't be. You should make the array immutable and static, or else initialize it in the constructor. I don't know your use case, so it's hard to say what you should do. -Stevestrangely enough, when modeling this the first time (using items as a class) and 'new item() syntax) there was no real issue. I thought using a static array of structs in the children would be more efficient when instantiating the objects. Never mind whether its true or not - Speed isn't a really a concern, learning is.this() {items = [ {10, "first"}, {20, "second"}];}
Mar 07 2014
On Friday, 7 March 2014 at 13:57:31 UTC, Steven Schveighoffer wrote:On Thu, 06 Mar 2014 17:44:09 -0500, captain_fid <bell.hue gmail.com> wrote:I missed this the first time. That is a difference between my code and your code. Mine creates a new instance of an array on *object* initialization, yours creates ONE instance of an array, that all objects share. This is not necessarily a good thing. Because you've created a mutable version of the array. I believe it is initialized on startup from the heap. One really bad thing is, the same array is used if you initialize from multiple threads. And it's mutable, making it implicitly shared even though it shouldn't be. You should make the array immutable and static, or else initialize it in the constructor. I don't know your use case, so it's hard to say what you should do. -Stevestrangely enough, when modeling this the first time (using items as a class) and 'new item() syntax) there was no real issue. I thought using a static array of structs in the children would be more efficient when instantiating the objects. Never mind whether its true or not - Speed isn't a really a concern, learning is.this() {items = [ {10, "first"}, {20, "second"}];}Steve, I don't think I know my use case -- So it's not you. I'm attempting to model hardware, where 'items' in this case are an static array of registers. Single threaded (for now). Mainly, this a learning opportunity to get a better understanding of D for future comparison (vs. C++).I don't know your use case, so it's hard to say what you should do.This is not necessarily a good thing. Because you've created a mutable version of the array. I believe it is initialized on startup from the heap.Lot to learn. I understand initialized from the heap, but do you mean at program startup, or object instantiation? If program, I would have expected that with __gshared (globals) only, not with this.One really bad thing is, the same array is used if you initialize from multiple threads. And it's mutable, making it implicitly shared even though it shouldn't be. You should make the array immutable and static, or else initialize it in the constructor.I appreciate your suggestions and the patience.
Mar 07 2014
On 03/06/2014 02:05 PM, captain_fid wrote:Your suggestion Ali (of not accessing the base member in the child was great) and it works properly. Believe if I understand what you are suggesting above is never to have the array in base? simply retrieve slice through the child memberfunction? Yes, but it also depends on the need. I assumed that the base class needed a slice of elements from the base class. Will the slice of elements ever change? If no, then the base could take them at construction time and use them in the future: import std.stdio; class B { const(int[]) items; this(const(int[]) items) // <-- Requires elements // during construction { this.items = items; } final void do_work() { writeln(items); } } class D : B { this() { super([ 1, 2, 3]); // Items are determined here } } void main() { auto d = new D(); d.do_work(); } Alternatively, and especially if the elements will change at run time, the derived class can hold on to the elements and can provide them as the base class needs: import std.stdio; class B { abstract const(int)[] items(); final void do_work() { writeln(items()); } } class D : B { int[] myItems; this() { myItems = [ 1, 2, 3]; } void add(int[] items) { myItems ~= items; } override const(int)[] items() { return myItems; } } void main() { auto d = new D(); d.do_work(); // 1, 2, 3 // Add more later on d.add([ 4, 5, 6 ]); d.do_work(); // 1, 2, 3, 4, 5, 6 } Ali
Mar 06 2014
Steve and Ali, Thanks for the quick helpful suggestions. In this case I probably don't need the expansion (but certainly look forward to understanding either way). I'll certainly hit that reference (Special thanks Ali for your book. I've enjoyed it over the past few months)
Mar 06 2014
On 03/06/2014 11:31 AM, captain_fid wrote:On Thursday, 6 March 2014 at 19:19:29 UTC, captain_fid wrote:You need to dereference the pointer by * and you would be using a slice: import std.stdio; import std.conv; struct S { int a; string b; } class A { S[]* pointer_to_list; void access() { foreach (e; *pointer_to_list) { // <-- NOTE * writeln(e); } } } class B: A { S[] items = [ {10, "first"}, {20, "second"}]; this() { pointer_to_list = &items; } } void main() { auto b = new B(); foreach (i; 30 .. 40) { b.items ~= S(i, i.to!string); } b.access(); } As a side note, I would make A take the slice as a reference parameter, rather that B accessing A's member directly. It is better for maintainability: class A { S[]* pointer_to_list; this(ref S[] list) // <-- BETTER { this.pointer_to_list = &list; } // ... } class B: A { // ... this() { super(items); // <-- BETTER } } AliSorry for the very basic question. Much still alludes me with this language. I appreciate the forum. struct S {Wow sorry for that. I'm a moron... don't press <tab> <enter>... struct S { int a; string b; } class A { S[]* pointer_to_list; abstract... } class B: A { S[] items = [ {10, "first"}, {20, "second"}]; this() { pointer_to_list = &items; } } My problem is in de-referencing later (seg fault). Is this even the best way? I Really need to access the array in a derived class. 'S' (I believe) really is best as a Structure. Any suggestions. Thanks in advance (and sorry for the rough start).
Mar 06 2014