4 ms·

You'll always need a pointer to the objects, no matter the language. But you'll save on having to store a pointer from those objects to a string object, which w

You'll always need a pointer to the objects, no matter the language. But you'll save on having to store a pointer from those objects to a string object, which with 2 unicode characters (assuming Java strings are null terminated) saves you a total of (I believe Java still uses 64-bit pointers no?), 8bytes for the pointer to the string, 16 for the string, 24 bytes per object minus the int which is 4 bytes so 20 bytes per object. Assuming these are transaction objects, that's a crap-ton if you have lots of transactions.

fauigerzigerk 16y ago
Let's leave the string issue aside. It has nothing to do with the point I was trying to make. Consider the example I gave in another reply: class Point { int x; int y; } class Rect { Point a; Point b; } List<Rect> list ... In Java, this list of Rect objects contains three pointers that a functionally equivalent list in C++, C# or Go would not have to hold.
- elblanco 16y ago
  Are you talking about pointers to objects? Are there any languages that allow you to have objects that aren't pointed to? Maybe C-style structs? Is that what you are talking about? Complaining about pointers to objects is like complaining about the wasted byte at the end of a null-terminated string. There's a general move away from structs for some reason. My guess is that structs do have a problem with platform independence if you rely too much on the primitive types being consistent across platforms. An int being a 4-byte chunk of memory isn't always true (actually, if memory serves, an int was supposed to be standardized as the word length of the local system, so it could be all kinds of oddball lengths, like 24-bits). So my guess is that most modern languages looked at this problem and decided that cross-platform compatibility is more important. But to be honest, with a virtualized run-time, like the JVM, you can define the primitive types as a standardized abstraction on-top of the runtime system...so in that sense it doesn't really make all the much sense to not have them, except maybe to adhere to principles of data hiding or some such. However, strictly speaking, the code you provided would probably be a similar pointerfest in C++ or C# since you aren't using structs, I don't know enough about Go to reply intelligently about that language.
  - brown9-2 16y ago
    I think fauigerzigerk might be referring to "value types" in C# (http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx), so structs basically.
  - scott_s 16y ago
    The problem is not that the pointers waste space. The problem is that they introduce irregular memory layout. If you want to, say, offload your data to a GPU, then having a structure memory layout is a huge benefit. But you'll kill performance if you have to chase pointers to first get the data in a format the GPU can handle. Other optimizations - such as SIMD on conventional processors - can apply. And, for the record, C++ would not use pointers. In C++, if you place one object inside the definition of another, the whole object will be there, not a pointer. You control memory layout in C++. And if your objects are plain old data (POD), then it behaves just as C does. A C++ class that does not have any virtual members is laid out like a struct.
    - elblanco 16y ago
      >The problem is that they introduce irregular memory layout. Good point. I thought that the original thread was about pointers eating up space. My understanding is that C++ class definitions, because they themselves may contain function references...even just constructors/destructors and access methods, would represent the object with a pointer on the call stack to the location of the object (and all its data + method pointers) on the heap (which like you said could end up anywhere resulting in an irregular memory layout). Otherwise, suppose a class is defined as a collection of objects (which are defined as collections of objects on down etc.) some of which may of arbitrary length...ergo you'd never know how much memory to allocate a priori to hold these irregular data structured. Far easier to just allocate a bunch of word length pointers pointing to whatever random blobs of address space the OS gives back on malloc requests. But yeah, if it's just POD then one would assume an easy optimization the compiler could make would be to just create the objects as contiguous blocks of object-sized memory. I'm all rusty on some of this stuff (last time I seriously used C++ Borland was still a major player in the compiler business and templates were highly experimental) so I'm sure I'm quite out of date these days.

fauigerzigerk 16y ago

Let's leave the string issue aside. It has nothing to do with the point I was trying to make. Consider the example I gave in another reply: class Point { int x; int y; } class Rect { Point a; Point b; } List<Rect> list ... In Java, this list of Rect objects contains three pointers that a functionally equivalent list in C++, C# or Go would not have to hold.

elblanco 16y ago
Are you talking about pointers to objects? Are there any languages that allow you to have objects that aren't pointed to? Maybe C-style structs? Is that what you are talking about? Complaining about pointers to objects is like complaining about the wasted byte at the end of a null-terminated string. There's a general move away from structs for some reason. My guess is that structs do have a problem with platform independence if you rely too much on the primitive types being consistent across platforms. An int being a 4-byte chunk of memory isn't always true (actually, if memory serves, an int was supposed to be standardized as the word length of the local system, so it could be all kinds of oddball lengths, like 24-bits). So my guess is that most modern languages looked at this problem and decided that cross-platform compatibility is more important. But to be honest, with a virtualized run-time, like the JVM, you can define the primitive types as a standardized abstraction on-top of the runtime system...so in that sense it doesn't really make all the much sense to not have them, except maybe to adhere to principles of data hiding or some such. However, strictly speaking, the code you provided would probably be a similar pointerfest in C++ or C# since you aren't using structs, I don't know enough about Go to reply intelligently about that language.
- brown9-2 16y ago
  I think fauigerzigerk might be referring to "value types" in C# (http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx http://msdn.microsoft.com/en-us/library/s1ax56ch.aspx), so structs basically.
- scott_s 16y ago
  The problem is not that the pointers waste space. The problem is that they introduce irregular memory layout. If you want to, say, offload your data to a GPU, then having a structure memory layout is a huge benefit. But you'll kill performance if you have to chase pointers to first get the data in a format the GPU can handle. Other optimizations - such as SIMD on conventional processors - can apply. And, for the record, C++ would not use pointers. In C++, if you place one object inside the definition of another, the whole object will be there, not a pointer. You control memory layout in C++. And if your objects are plain old data (POD), then it behaves just as C does. A C++ class that does not have any virtual members is laid out like a struct.
  - elblanco 16y ago
    >The problem is that they introduce irregular memory layout. Good point. I thought that the original thread was about pointers eating up space. My understanding is that C++ class definitions, because they themselves may contain function references...even just constructors/destructors and access methods, would represent the object with a pointer on the call stack to the location of the object (and all its data + method pointers) on the heap (which like you said could end up anywhere resulting in an irregular memory layout). Otherwise, suppose a class is defined as a collection of objects (which are defined as collections of objects on down etc.) some of which may of arbitrary length...ergo you'd never know how much memory to allocate a priori to hold these irregular data structured. Far easier to just allocate a bunch of word length pointers pointing to whatever random blobs of address space the OS gives back on malloc requests. But yeah, if it's just POD then one would assume an easy optimization the compiler could make would be to just create the objects as contiguous blocks of object-sized memory. I'm all rusty on some of this stuff (last time I seriously used C++ Borland was still a major player in the compiler business and templates were highly experimental) so I'm sure I'm quite out of date these days.