D - Why arrays are not Objects?
- Andres Rodriguez (16/16) Feb 01 2004 One of the only "practicalities" of Java is making arrays Objects. I sa...
- Sean L. Palmer (31/31) Feb 01 2004 At a time when compilers routinely do global flow optimization, I see no
- Ben Hinkle (22/53) Feb 01 2004 If everything was an Object (in D's current definition of Object) then i...
- Andres Rodriguez (13/19) Feb 01 2004 Indeed, if I understand D correctly, that is my point: arrays already ha...
- Ben Hinkle (9/29) Feb 01 2004 it
- Andres Rodriguez (11/16) Feb 01 2004 So making arrays objects will not be the cleanest of all solutions, but ...
- Sean L. Palmer (100/100) Feb 01 2004 See, that's the problem. Reference semantics should be in usage code, n...
- Georg Wrede (3/41) Feb 03 2004 The quality of discussion in this newsgroup has risen tremendously
- Georg Wrede (5/8) Feb 03 2004 This would obviously lead to a major rethink of parts of the
- davepermen (41/57) Feb 01 2004 i hope walter reads this.
- Vathix (9/13) Feb 01 2004 You can't do that unless you always want to copy the array.
- Walter (5/9) Feb 01 2004 access
- davepermen (8/17) Feb 01 2004 as i said.. it was late..
- davepermen (13/22) Feb 01 2004 i'm interested in two things..
- Walter (4/9) Feb 01 2004 of
- Sean L. Palmer (89/89) Feb 02 2004 A) the size messes up the array alignment, causing wasted space
- davepermen (10/99) Feb 03 2004 alignment is a non-issue actually. for most types, you only store refere...
- Sean L. Palmer (25/25) Feb 03 2004 Think about the situation you're allocating an array of objects which
- davepermen (6/31) Feb 03 2004 as i said. there is shifted aligned allocation. use it to align to 16-by...
- Walter (9/23) Feb 01 2004 in
- Andres Rodriguez (9/15) Feb 01 2004 I assume you are saying (2) is true, if (1) is done, because if arrays
- Walter (12/29) Feb 01 2004 It can be done with either of the two methods I listed, and there may be
One of the only "practicalities" of Java is making arrays Objects. I say that it is a practicality because it is not very elegant, and I believe it was done to take advantage of the fact that arrays are already described by a pointer, therefore they can be passed as parameters anywhere an Object is required. Making arrays an Object in D would allow strings 'char[]' to behave like objects, but stay arrays. This opens a little can of worms at the Object end, because now you have a special type of Objects that are not really objects, but it is so useful, I think it's worth the "non-orthogonality" in the language. Has any thought been given to this? I could not find discussion of this in the forum (although it is hard to search). Thanks in advance, Andres
Feb 01 2004
At a time when compilers routinely do global flow optimization, I see no reason why the lowest level of values can't be treated the same semantically as every other type in the language. In this way, arrays, ints, functions, and everything else should be Objects too. For that matter, the language could also automatically move values to the stack when their lifetime is compile-time-deterministic. Having this split between basic types and user-defined types just causes problems for the programmers, and doesn't save much if any work for the compiler vendors. This has been discussed before, and it probably won't be changed at this late stage. One can hope though. Sean Andres Rodriguez wrote: | One of the only "practicalities" of Java is making arrays Objects. I | say that it is a practicality because it is not very elegant, and I | believe it was | done to take advantage of the fact that arrays are already described | by | a pointer, therefore they can be passed as parameters anywhere an | Object is required. | | Making arrays an Object in D would allow strings 'char[]' to behave | like objects, but stay arrays. This opens a little can of worms at | the Object end, because now you have a special type of Objects that | are not | really objects, but it is so useful, I think it's worth the | "non-orthogonality" | in the language. | | Has any thought been given to this? I could not find discussion of | this in the forum (although it is hard to search).
Feb 01 2004
If everything was an Object (in D's current definition of Object) then it would have to have reference semantics. In particular ints and arrays would change behavior. For int the change would be drastic. Templates should take care of the places where Java needs arrays to be Objects (eg, a Vector of arrays). A simple wrapper (box/unbox) should do the trick: class ObjBox(T) { public T value; this(T x) { value = x; } } int main() { ObjBox!(int) x = new ObjBox!(int)(7); printf("%d\n", x.value); return 0; } -Ben "Sean L. Palmer" <palmer.sean verizon.net> wrote in message news:bvjnc7$ote$1 digitaldaemon.com...At a time when compilers routinely do global flow optimization, I see no reason why the lowest level of values can't be treated the samesemanticallyas every other type in the language. In this way, arrays, ints,functions,and everything else should be Objects too. For that matter, the language could also automatically move values to the stack when their lifetime is compile-time-deterministic. Having this split between basic types and user-defined types just causes problems for the programmers, and doesn't save much if any work for the compiler vendors. This has been discussed before, and it probably won't be changed at this late stage. One can hope though. Sean Andres Rodriguez wrote: | One of the only "practicalities" of Java is making arrays Objects. I | say that it is a practicality because it is not very elegant, and I | believe it was | done to take advantage of the fact that arrays are already described | by | a pointer, therefore they can be passed as parameters anywhere an | Object is required. | | Making arrays an Object in D would allow strings 'char[]' to behave | like objects, but stay arrays. This opens a little can of worms at | the Object end, because now you have a special type of Objects that | are not | really objects, but it is so useful, I think it's worth the | "non-orthogonality" | in the language. | | Has any thought been given to this? I could not find discussion of | this in the forum (although it is hard to search).
Feb 01 2004
If everything was an Object (in D's current definition of Object) then it would have to have reference semantics. In particular ints and arrayswouldchange behavior. For int the change would be drastic.Indeed, if I understand D correctly, that is my point: arrays already have reference semantics. And coming from Java I can tell you that you can almost do everything you want to do with object arrays and a little boxing here and there as you have shown. Templates are much better of course, since they are much more efficient (time wise, and space wise it depends on the implementation) and compile-time type safe.Templates should take care of the places where Java needs arrays to be Objects (eg, a Vector of arrays). A simple wrapper (box/unbox) should dothetrick:Agreed again. The problem, I cannot seem to make templates work for me, see my earlier posting: "How to instantiate a template? Bug?" Thanks for your help, Andres
Feb 01 2004
"Andres Rodriguez" <rodriguez ai.sri.com> wrote in message news:bvjsae$11g6$1 digitaldaemon.com...itIf everything was an Object (in D's current definition of Object) thenArrays sort-of have reference semantics. An array (internally) is a struct of a length field and a pointer to the data. So the array data pointer has reference semantics but the array length has value semantics.would have to have reference semantics. In particular ints and arrayswouldchange behavior. For int the change would be drastic.Indeed, if I understand D correctly, that is my point: arrays already have reference semantics.And coming from Java I can tell you that you can almost do everything you want to do with object arrays and a little boxing here and there as you have shown. Templates are much better of course, since they are much more efficient (time wise, and space wise it dependsonthe implementation) and compile-time type safe.Hmm. I don't know what is going wrong. The example I gave compiled fine on my machine.Templates should take care of the places where Java needs arrays to be Objects (eg, a Vector of arrays). A simple wrapper (box/unbox) should dothetrick:Agreed again. The problem, I cannot seem to make templates work for me, see my earlier posting: "How to instantiate a template? Bug?"Thanks for your help, Andres
Feb 01 2004
Arrays sort-of have reference semantics. An array (internally) is a struct of a length field and a pointer to the data. So the array data pointer has reference semantics but the array length has value semantics.So making arrays objects will not be the cleanest of all solutions, but a practical and useful one. As I said in my original posting, it's a compromise, adding something somewhat ugly, because it's terribly useful. From the compiler point of view I think it's pretty straight forward.Hmm. I don't know what is going wrong. The example I gave compiled fine on my machine.The example you gave does not make use of the template type, it's very simple template code. If I am trying to build a more generic template library, I am going to want to do more complex things (as in the example I gave). Cheers and thank for your answers, Andres
Feb 01 2004
See, that's the problem. Reference semantics should be in usage code, not an inherent property of Object. C++ is proof that this is viable. You should be able to subclass int just like you can subclass any other class. I run into this in C++ alot. I want to make a sort of streaming adapter template, with decorated objects that act like some other type but know how to stream themselves to and from binary files, but I cannot inherit from int, thus I have to break the illusion that my adapter *is* the kind of object and the user code has to go thru another level of indirection, cluttering up the entire program, *or* forcing me to make special cases for every single builtin type, of which there are many in C++, including pointers which can be to any user-defined type. Needless to say, this makes decorating types in a generic manner an unnecessarily painful endeavor. With modern day optimizing compilers, we *should* be able to treat every object semantically as if it were a heap object, and have the compiler "optimize" the object down onto the stack or into registers when it can safely do so. And once we're treating all objects uniformly, we can stop having to explicitly specify that they go "on the heap" and just use objects in a simple way, letting the compiler take care of the details of where and how to allocate them. As has been said by others many times, the language should be defined by its semantics. Such semantics should be chosen so that efficient implementations can be made, without exposing the programmer to the gory details of such implementations. The less explicit you force the programmers to be, the less opportunity they have to screw up, and the more opportunity the compiler vendor has to do things The Right Way. Boxing/unboxing is an ugly implementation detail that has "escaped" and flutters about distracting programmers from the task at hand. It is a sign of bad language design. Likewise with memory allocation. If you want programs that never leak, express memory allocation and deallocation in a way that can't possibly leak. If you want programs that never crash, find ways to do things that can't possibly crash, (checking at runtime is a poor substitute for *proving* the program cannot misbehave). This is one area where I fear Walter may actually be too stuck in the old-school mindset to innovate. That doesn't mean D won't be a good language, it just means it won't be a cutting-edge language. There is a revolution brewing, and I feel a language will have to be very solidly designed to survive. Adding some patches to C won't be enough. Sean Ben Hinkle wrote: | If everything was an Object (in D's current definition of Object) | then it would have to have reference semantics. In particular ints | and arrays would change behavior. For int the change would be drastic. | | Templates should take care of the places where Java needs arrays to be | Objects (eg, a Vector of arrays). A simple wrapper (box/unbox) should | do the trick: | | class ObjBox(T) { | public T value; | this(T x) { value = x; } | } | | int | main() | { | ObjBox!(int) x = new ObjBox!(int)(7); | printf("%d\n", x.value); | return 0; | } | | -Ben | | "Sean L. Palmer" <palmer.sean verizon.net> wrote in message | news:bvjnc7$ote$1 digitaldaemon.com... || At a time when compilers routinely do global flow optimization, I || see no reason why the lowest level of values can't be treated the || same semantically as every other type in the language. In this way, || arrays, ints, functions, and everything else should be Objects too. || For that matter, the language could also automatically move values || to the stack when their lifetime is compile-time-deterministic. || || Having this split between basic types and user-defined types just || causes problems for the programmers, and doesn't save much if any || work for the compiler vendors. || || This has been discussed before, and it probably won't be changed at || this late stage. One can hope though. || || Sean || || Andres Rodriguez wrote: ||| One of the only "practicalities" of Java is making arrays Objects. ||| I say that it is a practicality because it is not very elegant, and ||| I believe it was ||| done to take advantage of the fact that arrays are already described ||| by ||| a pointer, therefore they can be passed as parameters anywhere an ||| Object is required. ||| ||| Making arrays an Object in D would allow strings 'char[]' to behave ||| like objects, but stay arrays. This opens a little can of worms at ||| the Object end, because now you have a special type of Objects that ||| are not ||| really objects, but it is so useful, I think it's worth the ||| "non-orthogonality" ||| in the language. ||| ||| Has any thought been given to this? I could not find discussion of ||| this in the forum (although it is hard to search).
Feb 01 2004
In article <bvjtdl$13d7$1 digitaldaemon.com>, Sean L. Palmer says...See, that's the problem. Reference semantics should be in usage code, not an inherent property of Object. C++ is proof that this is viable. You should be able to subclass int just like you can subclass any other class. I run into this in C++ alot. I want to make a sort of streaming adapter template, with decorated objects that act like some other type but know how to stream themselves to and from binary files, but I cannot inherit from int, thus I have to break the illusion that my adapter *is* the kind of object and the user code has to go thru another level of indirection, cluttering up the entire program, *or* forcing me to make special cases for every single builtin type, of which there are many in C++, including pointers which can be to any user-defined type. Needless to say, this makes decorating types in a generic manner an unnecessarily painful endeavor. With modern day optimizing compilers, we *should* be able to treat every object semantically as if it were a heap object, and have the compiler "optimize" the object down onto the stack or into registers when it can safely do so. And once we're treating all objects uniformly, we can stop having to explicitly specify that they go "on the heap" and just use objects in a simple way, letting the compiler take care of the details of where and how to allocate them. As has been said by others many times, the language should be defined by its semantics. Such semantics should be chosen so that efficient implementations can be made, without exposing the programmer to the gory details of such implementations. The less explicit you force the programmers to be, the less opportunity they have to screw up, and the more opportunity the compiler vendor has to do things The Right Way. Boxing/unboxing is an ugly implementation detail that has "escaped" and flutters about distracting programmers from the task at hand. It is a sign of bad language design. Likewise with memory allocation. If you want programs that never leak, express memory allocation and deallocation in a way that can't possibly leak. If you want programs that never crash, find ways to do things that can't possibly crash, (checking at runtime is a poor substitute for *proving* the program cannot misbehave).The quality of discussion in this newsgroup has risen tremendously during January. This is an excellent example of it!This is one area where I fear Walter may actually be too stuck in the old-school mindset to innovate. That doesn't mean D won't be a good language, it just means it won't be a cutting-edge language. There is a revolution brewing, and I feel a language will have to be very solidly designed to survive. Adding some patches to C won't be enough.
Feb 03 2004
In article <bvjq6d$tuq$1 digitaldaemon.com>, Ben Hinkle says...If everything was an Object (in D's current definition of Object) then it would have to have reference semantics. In particular ints and arrays would change behavior. For int the change would be drastic.This would obviously lead to a major rethink of parts of the language. If we were to do it, then we could consider having different assignment operators for references and values. Heron does this right, I think.
Feb 03 2004
i hope walter reads this. the half-ref,half-copy semantic of arrays can be rather irritating, and lead to "D is strange" views just as C has with its only static arrays that lead to tons of overflow bugs today.. currently, an array is just struct array { type* data; uint size; } how about this? struct Array { uint size; type[] data; // this is an extension of c++ existing in vc6 and 7 } typedef Array^ array; // the ^ indicates its a gc pointer, as in c++.net 2.0 (withbey) heh.. without tons of microsoft c++ extensions, what i think is not expressable in c really.. in simple words: just put the size at the beginning of the actual array, instead beside the pointer. 99% of the time, where you need to access the size, you will access the array as well anyways, so the indirect pointer => cache issues are negitible. the gain would be, an array would get 100% reference semantic. this would be much more understandable to all users. arrays would then be objects. any reasons why not? (except the, as said, negitible performance issue) oh, and static arrays don't have problems with that as well.. so allocator(type[]) = type[] (uint count) { void* data = malloc(uint.size + count*type.size); *(uint*)data = count; gc.takeCareOfThisHehe(data); return cast(type[])data; } something like this. it's very late, and i have to get up very early.. i hope you get the idea. it would be really helpful, i guess. "Andres Rodriguez" <rodriguez ai.sri.com> schrieb im Newsbeitrag news:bvjffn$bu2$1 digitaldaemon.com...One of the only "practicalities" of Java is making arrays Objects. I say that it is a practicality because it is not very elegant, and I believe it was done to take advantage of the fact that arrays are already described by a pointer, therefore they can be passed as parameters anywhere an Object is required. Making arrays an Object in D would allow strings 'char[]' to behave like objects, but stay arrays. This opens a little can of worms at the Object end, because now you have a special type of Objects that are not really objects, but it is so useful, I think it's worth the "non-orthogonality" in the language. Has any thought been given to this? I could not find discussion of thisinthe forum (although it is hard to search). Thanks in advance, Andres
Feb 01 2004
just put the size at the beginning of the actual array, insteadbeside thepointer. 99% of the time, where you need to access the size, you willaccessthe array as well anyways, so the indirect pointer => cache issues are negitible.You can't do that unless you always want to copy the array. char[] foo = "hello"; char[] bar = foo[0 .. 2]; Instead of having a slice in foo, you have to allocate memory so that the length can be stored before it. The nature of a dynamic array is to just have a slice of any old memory. If you want to always copy the values, create your own type (class).
Feb 01 2004
"davepermen" <davepermen hotmail.com> wrote in message news:bvk04p$190v$1 digitaldaemon.com...just put the size at the beginning of the actual array, instead beside the pointer. 99% of the time, where you need to access the size, you willaccessthe array as well anyways, so the indirect pointer => cache issues are negitible.I did consider that approach, but the downside of it is it makes array slicing impractical.
Feb 01 2004
as i said.. it was late.. damn anyways, thanks for reading.. damn slicing. :D "Walter" <walter digitalmars.com> schrieb im Newsbeitrag news:bvk3es$1fcv$2 digitaldaemon.com..."davepermen" <davepermen hotmail.com> wrote in message news:bvk04p$190v$1 digitaldaemon.com...thejust put the size at the beginning of the actual array, instead besidepointer. 99% of the time, where you need to access the size, you willaccessthe array as well anyways, so the indirect pointer => cache issues are negitible.I did consider that approach, but the downside of it is it makes array slicing impractical.
Feb 01 2004
i'm interested in two things.. 1) are the templates of D powerful enough, together with overloaded new/delete, and this and ~this, to emulate that behaviour to realise sort of objects just like that (without the double indirect access to the actual data, that is).. it would be nice for a vector! class, for example.. 2) i guess storing two pointers, start and end, wouldn't help as well.. hm no i guess not :( sorta depressing.. would be too cool to have them as real objects.. not that i have problems (heck, i learned c++.. i know lowlevel hacks stressing highlevel languages:D), but it would be nice.. "Walter" <walter digitalmars.com> schrieb im Newsbeitrag news:bvk3es$1fcv$2 digitaldaemon.com..."davepermen" <davepermen hotmail.com> wrote in message news:bvk04p$190v$1 digitaldaemon.com...thejust put the size at the beginning of the actual array, instead besidepointer. 99% of the time, where you need to access the size, you willaccessthe array as well anyways, so the indirect pointer => cache issues are negitible.I did consider that approach, but the downside of it is it makes array slicing impractical.
Feb 01 2004
"davepermen" <davepermen hotmail.com> wrote in message news:bvkmpq$2enq$1 digitaldaemon.com...i'm interested in two things.. 1) are the templates of D powerful enough, together with overloaded new/delete, and this and ~this, to emulate that behaviour to realise sortofobjects just like that (without the double indirect access to the actual data, that is).. it would be nice for a vector! class, for example..Give it a try, and see how far you can make it go.
Feb 01 2004
A) the size messes up the array alignment, causing wasted space B) that method can't do slicing I agree, the reference semantics of arrays will cause problems. No such thing as a "const array" in D. :( Sean davepermen wrote: | i hope walter reads this. | | the half-ref,half-copy semantic of arrays can be rather irritating, | and lead to "D is strange" views just as C has with its only static | arrays that lead to tons of overflow bugs today.. | | currently, an array is just | | struct array { | type* data; | uint size; | } | | how about this? | | struct Array { | uint size; | type[] data; // this is an extension of c++ existing in vc6 and 7 | } | | typedef Array^ array; // the ^ indicates its a gc pointer, as in | c++.net 2.0 (withbey) | | heh.. without tons of microsoft c++ extensions, what i think is not | expressable in c really.. | | in simple words: | | just put the size at the beginning of the actual array, instead | beside the pointer. 99% of the time, where you need to access the | size, you will access the array as well anyways, so the indirect | pointer => cache issues are negitible. | | the gain would be, an array would get 100% reference semantic. this | would be much more understandable to all users. | | arrays would then be objects. | | any reasons why not? (except the, as said, negitible performance | issue) | | oh, and static arrays don't have problems with that as well.. | | | so | | allocator(type[]) = type[] (uint count) { | void* data = malloc(uint.size + count*type.size); | *(uint*)data = count; | gc.takeCareOfThisHehe(data); | return cast(type[])data; | } | | | something like this. it's very late, and i have to get up very | early.. i hope you get the idea. | | it would be really helpful, i guess. | | "Andres Rodriguez" <rodriguez ai.sri.com> schrieb im Newsbeitrag | news:bvjffn$bu2$1 digitaldaemon.com... || One of the only "practicalities" of Java is making arrays Objects. || I say that it is a practicality because it is not very elegant, and || I believe it was || done to take advantage of the fact that arrays are already described || by || a pointer, therefore they can be passed as parameters anywhere an || Object is required. || || Making arrays an Object in D would allow strings 'char[]' to behave || like objects, but stay arrays. This opens a little can of worms at || the Object end, because now you have a special type of Objects that || are not || really objects, but it is so useful, I think it's worth the || "non-orthogonality" || in the language. || || Has any thought been given to this? I could not find discussion of || this in the forum (although it is hard to search). || || Thanks in advance, || || Andres
Feb 02 2004
alignment is a non-issue actually. for most types, you only store references in the array, they are 4bytes, just as the size, wich is 4bytes, and have same alignment. for others, just be 4bytes in front of the needed alignment (if you install intel c++ you get some alignment-malloc, where you can specify a shift, too.. so it's doable) const arrays would be a non-issue eighter. B is the only point. the slicing. "Sean L. Palmer" <palmer.sean verizon.net> schrieb im Newsbeitrag news:bvmkl8$2kjb$1 digitaldaemon.com...A) the size messes up the array alignment, causing wasted space B) that method can't do slicing I agree, the reference semantics of arrays will cause problems. No such thing as a "const array" in D. :( Sean davepermen wrote: | i hope walter reads this. | | the half-ref,half-copy semantic of arrays can be rather irritating, | and lead to "D is strange" views just as C has with its only static | arrays that lead to tons of overflow bugs today.. | | currently, an array is just | | struct array { | type* data; | uint size; | } | | how about this? | | struct Array { | uint size; | type[] data; // this is an extension of c++ existing in vc6 and 7 | } | | typedef Array^ array; // the ^ indicates its a gc pointer, as in | c++.net 2.0 (withbey) | | heh.. without tons of microsoft c++ extensions, what i think is not | expressable in c really.. | | in simple words: | | just put the size at the beginning of the actual array, instead | beside the pointer. 99% of the time, where you need to access the | size, you will access the array as well anyways, so the indirect | pointer => cache issues are negitible. | | the gain would be, an array would get 100% reference semantic. this | would be much more understandable to all users. | | arrays would then be objects. | | any reasons why not? (except the, as said, negitible performance | issue) | | oh, and static arrays don't have problems with that as well.. | | | so | | allocator(type[]) = type[] (uint count) { | void* data = malloc(uint.size + count*type.size); | *(uint*)data = count; | gc.takeCareOfThisHehe(data); | return cast(type[])data; | } | | | something like this. it's very late, and i have to get up very | early.. i hope you get the idea. | | it would be really helpful, i guess. | | "Andres Rodriguez" <rodriguez ai.sri.com> schrieb im Newsbeitrag | news:bvjffn$bu2$1 digitaldaemon.com... || One of the only "practicalities" of Java is making arrays Objects. || I say that it is a practicality because it is not very elegant, and || I believe it was || done to take advantage of the fact that arrays are already described || by || a pointer, therefore they can be passed as parameters anywhere an || Object is required. || || Making arrays an Object in D would allow strings 'char[]' to behave || like objects, but stay arrays. This opens a little can of worms at || the Object end, because now you have a special type of Objects that || are not || really objects, but it is so useful, I think it's worth the || "non-orthogonality" || in the language. || || Has any thought been given to this? I could not find discussion of || this in the forum (although it is hard to search). || || Thanks in advance, || || Andres
Feb 03 2004
Think about the situation you're allocating an array of objects which require 16-byte alignment (SSE registers maybe), you may waste up to 16-4=12 bytes. Not a huge deal, but not completely insignificant either. Sean davepermen wrote: | alignment is a non-issue actually. for most types, you only store | references in the array, they are 4bytes, just as the size, wich is | 4bytes, and have same alignment. | | for others, just be 4bytes in front of the needed alignment (if you | install intel c++ you get some alignment-malloc, where you can | specify a shift, too.. so it's doable) | | const arrays would be a non-issue eighter. | | B is the only point. the slicing. | | "Sean L. Palmer" <palmer.sean verizon.net> schrieb im Newsbeitrag | news:bvmkl8$2kjb$1 digitaldaemon.com... || A) the size messes up the array alignment, causing wasted space || || B) that method can't do slicing || || I agree, the reference semantics of arrays will cause problems. No || such thing as a "const array" in D. :(
Feb 03 2004
as i said. there is shifted aligned allocation. use it to align to 16-byte - 4bytes. this is provided by the intel libraries. "Sean L. Palmer" <palmer.sean verizon.net> schrieb im Newsbeitrag news:bvnp64$22p2$1 digitaldaemon.com...Think about the situation you're allocating an array of objects which require 16-byte alignment (SSE registers maybe), you may waste up to16-4=12bytes. Not a huge deal, but not completely insignificant either. Sean davepermen wrote: | alignment is a non-issue actually. for most types, you only store | references in the array, they are 4bytes, just as the size, wich is | 4bytes, and have same alignment. | | for others, just be 4bytes in front of the needed alignment (if you | install intel c++ you get some alignment-malloc, where you can | specify a shift, too.. so it's doable) | | const arrays would be a non-issue eighter. | | B is the only point. the slicing. | | "Sean L. Palmer" <palmer.sean verizon.net> schrieb im Newsbeitrag | news:bvmkl8$2kjb$1 digitaldaemon.com... || A) the size messes up the array alignment, causing wasted space || || B) that method can't do slicing || || I agree, the reference semantics of arrays will cause problems. No || such thing as a "const array" in D. :(
Feb 03 2004
"Andres Rodriguez" <rodriguez ai.sri.com> wrote in message news:bvjffn$bu2$1 digitaldaemon.com...One of the only "practicalities" of Java is making arrays Objects. I say that it is a practicality because it is not very elegant, and I believe it was done to take advantage of the fact that arrays are already described by a pointer, therefore they can be passed as parameters anywhere an Object is required. Making arrays an Object in D would allow strings 'char[]' to behave like objects, but stay arrays. This opens a little can of worms at the Object end, because now you have a special type of Objects that are not really objects, but it is so useful, I think it's worth the "non-orthogonality" in the language. Has any thought been given to this? I could not find discussion of thisinthe forum (although it is hard to search).Giving arrays Object semantics like Java would have some repercussions: 1) Each array would need to have a virtual table pointer added and a slot for a monitor. 2) I doubt it could be made to interact cleanly with C style arrays. 3) If (1) is not done, the alternative is for every Object reference, code must be executed to attempt to distinguish an array from an Object.
Feb 01 2004
I assume you are saying (2) is true, if (1) is done, because if arrays stay the same, then (2) would not be true. More questions: 1) Do you know how it's done in Java? 2) Could the class hierarchy be jiggered such that there is a "MonitorableObject" on top of Object that does contain a monitor slot? 3) Why the vtable pointer? What happens if it simply does not exist? Thanks.Giving arrays Object semantics like Java would have some repercussions: 1) Each array would need to have a virtual table pointer added and a slot for a monitor. 2) I doubt it could be made to interact cleanly with C style arrays. 3) If (1) is not done, the alternative is for every Object reference, code must be executed to attempt to distinguish an array from an Object.
Feb 01 2004
"Andres Rodriguez" <rodriguez ai.sri.com> wrote in message news:bvk5or$1j0v$1 digitaldaemon.com...I assume you are saying (2) is true, if (1) is done, because if arrays stay the same, then (2) would not be true. More questions: 1) Do you know how it's done in Java?It can be done with either of the two methods I listed, and there may be more ways to do it. I'll also point out that Java arrays cannot be resized, are not compatible with C arrays, cannot be allocated on the stack or in static data, cannot be rectangular, cannot be sliced, and are incompatible with Java Strings. They do have Object semantics, though one cannot derive from a Java array.2) Could the class hierarchy be jiggered such that there is a "MonitorableObject" on top of Object that does contain a monitor slot?I thought it would be simpler to just include it.3) Why the vtable pointer? What happens if it simply does not exist?It has no polymorphic functionality without a vptr.Thanks.slotGiving arrays Object semantics like Java would have some repercussions: 1) Each array would need to have a virtual table pointer added and acodefor a monitor. 2) I doubt it could be made to interact cleanly with C style arrays. 3) If (1) is not done, the alternative is for every Object reference,must be executed to attempt to distinguish an array from an Object.
Feb 01 2004