I have been pondering on this question for quite few days now. As we all know that JAVA aint got no pointers, but why ? I read in a book which says "if JAVA had pointers then it would have lost the platform independency it has" Well... lemme put it in another way. ( a complete amateur writing here, so plz correct me if i'm wrong :p ). If we look in depth; all variables, let it be any language or whatsoever, are memory locations, aren't they ? So when we manipulate variables we ACCESS its MEMORY LOCATION and then we either read that MEMORY LOCATION or write on that ADDRESS. And I guess, these are all handled by the compiler while we programmers enjoy a pretty nice life . So it's quite obvious that JAVA interpreter/VM ( whatever ) handles MEMORY LOCATIONS too. Then what's the problem in providing POINTERS to the programmers cuz the VM eventually does the "POINTER LIKE" operation all the time, perhaps on every varaibles we declare. anywayz, A COMPLETE AMATEUR WRITING THIS... so plz corret me if i'm wrong Edited by - felisandria on December 21, 2001 3:08:10 PM

Pointers do not spoil platform independence; however, they do allow you to write non-portable code in some instances .

Here is a listing of the operations that you can perform on a pointer in C++, and whether or not they are guaranteed by the language standard to work on any implementation (in other words, whether or not they are portable).

portable: ->, +, -, ==, !=, --, ++
non-portable: <, >, <=, >=

You can find more detailed information near the end of the recent "c++ vs. java" thread.

I would like to add that the preceding was not strictly accurate. You can still write stupid code snippets that are not portable. However, when used as they were intended - with arrays, sizeof operator, etc. - they can be completely portable.

Here is a snippet that will work on any C++ implementation:

int main(){  int a[10]; // declare an array of 10 integers, from 0...9  *(a + 5) = 0; // works fine, sets sixth element regardless of element size  int* p1 = a  + 7; // p1 now points to eighth element  int* p2 = p1 - 3; // p2 now points to fifth  element  while( p2 != p1 ) *p2++ == 0; // set integers from p2...p1-1 to zero}  

Note also that all casting of pointers is non-portable, except to and from void* and when navigating within an inheritance hierarchy.

Edited by - null_pointer on December 21, 2001 1:59:16 PM

The amateur again...

Well... as far as i know every operating system (platform) has got itz own VM. And the primary work of allllll JAVA compilers are to compile the codes into general BYTE CODES which are then compiled to NATIVE CODES by the VM prior to running. And the kind of NATIVE CODE the VM generates depends of what platform it''s lying on. Hence, if java had pointers; the pointer related codes could have been tranlated into a general BYTE CODE when then could further be translated to NATIVE CODES depending on the machine/platform itz working on.

any comments ?

Sorry for the offtopic but:

quote:But I do know that a lack of pointers pretty much ruins Java for me.

It is a different programming language, if all programming languages presented the same tools and commands and so on just with a different syntax, then they are really just the same language.

Trying is the first step towards failure.

Java references are basically the same thing as C pointers with a couple of exceptions: you get no pointer arithmetic & you do not have to call delete.

As for platform independence, Java can run on anything from smart cards to mainframes. These memory architectures can be vastly different. The Java VM guarantees a standard, uniform way to allocate, track, and release memory.

"So crucify the ego, before it''s far too late. To leave behind this place so negative and blind and cynical, and you will come to find that we are all one mind. Capable of all that''s imagined and all conceivable."
- Tool
------------------------------

quote:Original post by WayfarerX

As for platform independence, Java can run on anything from smart cards to mainframes. These memory architectures can be vastly different. The Java VM guarantees a standard, uniform way to allocate, track, and release memory.

As for platform independence, C can run on anything from smart cards to mainframes. These memory architectures can be vastly different. C guarantees a standard, uniform way to allocate, track, and release memory.

As for platform independence, C++ can run on anything from smart cards to mainframes. These memory architectures can be vastly different. C++ guarantees a standard, uniform way to allocate, track, and release memory.

As for platform independence, <insert favorite programming language here> can run on anything from smart cards to mainframes. These memory architectures can be vastly different. <insert favorite programming language here> guarantees a standard, uniform way to allocate, track, and release memory.

quote:Original post by browny

Well... as far as i know every operating system (platform) has got itz own VM. And the primary work of allllll JAVA compilers are to compile the codes into general BYTE CODES which are then compiled to NATIVE CODES by the VM prior to running. And the kind of NATIVE CODE the VM generates depends of what platform it's lying on. Hence, if java had pointers; the pointer related codes could have been tranlated into a general BYTE CODE when then could further be translated to NATIVE CODES depending on the machine/platform itz working on.

You are correct: the existance of pointers in the language does not make the language non-portable. Remember, though, that some operations involving pointers are not guaranteed to work (i.e., they may not be portable).

Look at the following code snippet:

struct data{  int x;  short n;  float f;  char c;};int main(){  data d;  d.x = 10;  d.n = 5;  d.f = 1.25f;  d.c = '?';  data* p = new data;  p->x = 10;  p->n = 5;  p->f = 1.25f;  p->c = '?';  delete p;  return 0;} 

...and now we will dissect each section and you will learn how the language standard says that code should interpreted. First up is the data structure.

struct data{  int x;  short n;  float f;  char c;}; 

Question #1: How large are the members?

The language does not guarantee any particular bit size for int, short, float, or char. It does guarantee that sizeof(char) == 1 and that other types are multiples of char, but it does not define what "1 byte" means. On some machines, 1 byte is not 8 bits.

Now, when the language does not guarantee something, that means that how it is implemented depends entirely on the implementation (i.e., the compiler, platform, etc.). In other words, the compiler is free to assign whatever sizes it wishes to assign.

Question #2: What is the memory layout of the structure?

The language does not guarantee a particular memory layout. It does not guarantee that the members will be stored in order, or how large they will be, or whether the size of the members is equal to the size of the struct. Some machines assign padding bytes to align the members of the struct on certain memory boundaries for faster access.

Now we will look at the first line of the function:

int main(){  data d; 

Question #3: How is this memory allocated?

The language does not guarantee the location of the memory that is allocated for the struct. The language says that such a declaration d is of storage-class "auto", which means that the system will manage the memory in whatever way seems fit. On most systems this is through the system stack, but it could just as well be allocated using some other method on systems that do not have a stack.

To reiterate: the only thing that the language says is that the system will manage the memory for you. That is the only fundamental difference between instantiating variables and objects normally and using new/delete: with new you must manage the memory yourself.

  d.x = 10;  d.n = 5;  d.f = 1.25f;  d.c = '?'; 

Question #4: How does a program access the members of a struct?

On most systems, the struct's name is basically a pointer to the beginning of the struct's memory. Members are accessed by calculating their offsets from the beginning, based upon the sizes of the members and padding bytes, and whatever else the compiler cares to throw in there.

The point is, since the memory layout and storage are not guaranteed, the compiler is the only one who is guaranteed to know how to access the struct, and so the compiler must specify how these operations are to be performed in machine code. In other words, it is portable.

Let us look at the final snippet:

  data* p = new data;  p->x = 10;  p->n = 5;  p->f = 1.25f;  p->c = '?';  delete p; 

Question #5: What is the difference between d and p?

The only real difference here is that p refers to memory that is managed manually, whereas d refers to memory that is managed automatically. From the programmer's perspective, both d and p accomplish the same thing:

"Allocate memory to hold a struct containing an int named x, a short named n, a float named f, and a char named c. Set x to 10, set n to 5, set f to 1.25, and set c to ?."


Edited by - null_pointer on December 22, 2001 12:44:48 PM