www.digitalmars.com         C & C++   DMDScript  

D - Why arrays are not Objects?

reply "Andres Rodriguez" <rodriguez ai.sri.com> writes:
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
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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
parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
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
next sibling parent reply "Andres Rodriguez" <rodriguez ai.sri.com> writes:
 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.


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 do


the

 trick:


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
parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
"Andres Rodriguez" <rodriguez ai.sri.com> wrote in message
news:bvjsae$11g6$1 digitaldaemon.com...

 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.


 Indeed, if I understand D correctly, that is my point: arrays already have
 reference semantics.


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.


 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 do


 the

 trick:


 Agreed again.  The problem, I cannot seem to make templates work for me,
 see my earlier posting:

 "How to instantiate a template? Bug?"


Hmm. I don't know what is going wrong. The example I gave compiled fine on
my machine.


 Thanks for your help,

 Andres
Feb 01 2004
parent "Andres Rodriguez" <rodriguez ai.sri.com> writes:
 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
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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
parent Georg Wrede <Georg_member pathlink.com> writes:
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
prev sibling parent Georg Wrede <Georg_member pathlink.com> writes:
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
prev sibling next sibling parent reply "davepermen" <davepermen hotmail.com> writes:
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 01 2004
next sibling parent Vathix <vathix dprogramming.com> writes:
 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.



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
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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.
Feb 01 2004
next sibling parent "davepermen" <davepermen hotmail.com> writes:
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.
Feb 01 2004
prev sibling parent reply "davepermen" <davepermen hotmail.com> writes:
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.
Feb 01 2004
parent "Walter" <walter digitalmars.com> writes:
"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.
Feb 01 2004
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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
parent reply "davepermen" <davepermen hotmail.com> writes:
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
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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
parent "davepermen" <davepermen hotmail.com> writes:
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.  :(
Feb 03 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"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 this


in

 the 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
parent reply "Andres Rodriguez" <rodriguez ai.sri.com> writes:
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
parent "Walter" <walter digitalmars.com> writes:
"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.
Feb 01 2004