"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 will
access
> the 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.

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.
>
>

"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.
>
>
>
> > 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.
> >
> >
>
>

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...
> > 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.
>
> I did consider that approach, but the downside of it is it makes array slicing impractical.
>
>

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...
> > 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.
>
> I did consider that approach, but the downside of it is it makes array slicing impractical.
>
>

"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 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..

Give it a try, and see how far you can make it go.

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

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
>
>

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.  :(

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 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.  :(
>
>