 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / January 2006why java does not support pointers
hai any one tell me why java doesn't support pointers.instead it will do the same(means storing address,not arithematic operations on address) using reference variables.can any one plese clarify my doubt thanks regards chandu Well, it's debatable whether Java does or doesn't support pointers. Some would say that everything (well, every reference type) in Java is a pointer -- hence, the ever-familiar NullPointerException. But certainly, these reference types do not give one the sort of direct interaction with memory that we're familiar with from pointers in, e.g., C. The decision to have it this way has to do with the design principles of Java. Security and portability are probably two of the main ones. In Java, can you access uninitialized or deallocated memory? Well, that's because of the lack of pointers. Like it or lump it, that's Java. Luke The Java Language Specification defines a reference as: "An object is a class instance or an array. The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object." From http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#106237 Java supports pointers. However, Java doesn't support pointer arithmetic (well, it does, as of Java 1.5, but I'm not interested in telling you how). It doesn't support converting an int to a pointer either. This is much better, because we can now write code that won't cause segfaults or General Protection Faults. Instead we get a nasty old NullPointerException, for different reasons. Recent Usenet addicts will note that I haven't taken this delightful opportunity to post a link to a certain article.. Cheers. > hai > any one tell me why java doesn't support pointers.instead it will do > the same(means storing address,not arithematic operations on address) > using reference variables.can any one plese clarify my doubt > thanks regards Java references are pointers, but they're not much like C or C++ pointers, so a different term was used. (Of course, Java references are nothing like C++ references either...) Java 1.5 really supports pointer arithmetic? How? > Java 1.5 really supports pointer arithmetic? How? why must you know? >> Java 1.5 really supports pointer arithmetic? How? > > why must you know? I don't *have* to know, but I'm curious. (I thought I knew all the new features in 1.5). Apologies to people who fear this, but: http://www.jguru.com/faq/view.jsp?EID=448031 It's all about the sun.misc.Unsafe class, which you shouldn't use in code you intend to be portable. > Apologies to people who fear this, but: > > http://www.jguru.com/faq/view.jsp?EID=448031 > > It's all about the sun.misc.Unsafe class, which you shouldn't use in > code you intend to be portable. Hi ricky.clarkson ;) On 1 Jan 2006 16:01:35 -0800, "ricky.clarkson@gmail.com" <ricky.clarkson@gmail.com> wrote, quoted or indirectly quoted someone who said : >It's all about the sun.misc.Unsafe class, which you shouldn't use in >code you intend to be portable. Think about how serialisation builds new objects. Have a peek at the code.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Apologies to people who fear this, but: > > http://www.jguru.com/faq/view.jsp?EID=448031 > > It's all about the sun.misc.Unsafe class, which you shouldn't use in > code you intend to be portable. I'm missing what this has to do with R5; JNI code has always been able to play tricks with memory allocation. > any one tell me why java doesn't support pointers.instead it will do >the same(means storing address,not arithematic operations on address) >using reference variables.can any one plese clarify my doubt >thanks regards Java has references. They are just tame pointers under the hood. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >Java has references. They are just tame pointers under the hood. There is not even a »hood«; JLS3 explicitly states »(...) reference values (...) are pointers« in the second sentence of 4.3.1. > »(...) reference values (...) are pointers« Actually they are not necessarily. They are sufficiently abstract they would be implemented with handles, pointers to pointers. The fact that NullPointerException still exists indicates the term "reference" came late in the game to avoid confusion with C's wild pointers. The problem is that Java bashers use this to try to fool people into thinking that Java can't do the things you do with pointers in C. You can do nearly everything but tinker with platform specific hardware, e.g. vga REGEN buffers. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green might have written, quoted or indirectly quoted something like: >>»(...) reference values (...) are pointers« >Actually they are not necessarily. They are sufficiently abstract >they would be implemented with handles, pointers to pointers. By your own definition, handles are also pointers (because pointers to pointers are pointers.) To me, the JLS /defines the meaning/ of words regarding the field of the programming language Java. So, to me, a "pointer" in Java is as the word "pointer" is used in the JLS. For example, an "object" in C++ in something quite different to an object in Java. So to know what an "object" is in Java, I'd have to consult the JLS. So when the JLS said as quoted above, to me, in /can not be wrong/ by my assumption that the JLS defines the terminology for Java. >The problem is that Java bashers use this to try to fool people >into thinking that Java can't do the things you do with >pointers in C. Just today I had a pointer-problem that I could have solved easily in C, but I was not able to solve in Java. I was building five tuples using my own tuple class. The code was shortened for this posting to: final Tuple t0 = new Tuple( "alpha", "beta" ); final Tuple t1 = new Tuple( "alpha", "gamma" ); final Tuple t2 = new Tuple( "alpha", "beta" ); final Tuple t3 = new Tuple( "alpha", "beta" ); final Tuple t4 = new Tuple( "alpha", "delta" ); Now, I wanted to try my new "Identificator". It is supposed to return the same reference for two equal objects. So: TupleIdentificator tupleIdentificator = new TupleIdentificator(); and then final Tuple v0 = tupleIdentificator.valueOf( t0 ); final Tuple v1 = tupleIdentificator.valueOf( t1 ); final Tuple v2 = tupleIdentificator.valueOf( t2 ); final Tuple v3 = tupleIdentificator.valueOf( t3 ); final Tuple v4 = tupleIdentificator.valueOf( t4 ); Now the references v0, v2, and v3 are expected to be equal, while the references v1 and v4 should differ. To get a quick debug output, in C, I'd written: printf( "%p\n",( void * )v0 ); printf( "%p\n",( void * )v1 ); printf( "%p\n",( void * )v2 ); printf( "%p\n",( void * )v3 ); printf( "%p\n",( void * )v4 ); What would be the equivalent in Java to get a quick debug output of the five reference values? I am aware of "System.identityHashCode", but this still gives me no strict guarantee to have the same behavior as the actual references in this regard. So, yes, Java supports pointers, but it does not seem to support converting them to any external representation. > Roedy Green might have written, quoted or indirectly quoted > something like: [quoted text clipped - 8 lines] > field of the programming language Java. So, to me, a "pointer" > in Java is as the word "pointer" is used in the JLS. Indeed. It would be hard, anyway, to define "pointer" as excluding the indirect pair of memory addresses that Roedy calls "handles". After all, C and C++ are both also defined so as to permit such an implementation of pointers. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >Indeed. It would be hard, anyway, to define "pointer" as excluding the=20 >indirect pair of memory addresses that Roedy calls "handles". After=20 >all, C and C++ are both also defined so as to permit such an=20 >implementation of pointers. Pointer vs handle was pretty firmly established terminology when I was working on Pascal Lisa/Mac development circa 1980. You were constantly aware of the difference since you needed handles to find something and pointers work on it. Your pointers went stale during a memory allocation/shuffle, but your handles did not. I have also seen the term handle used for an index into a table rather than an address. e.g. in DOS. In C, a pointer's value is the machine address of the thing pointed to, even if another pointer. It has no internal hidden indirection. A reference is a woolier term meaning "a set of bits that will find you the corresponding object". The precise mechanism by which it does so is unspecified as are the meaning of the bits in the reference. Potentially a reference could encode facts about the object or could be several layers of indirection, e.g. to an out of ram backup. Because all details of how it works are hidden, that gives maximum flexibility for implementors. In Sun's current JVM a reference is just the machine address of the object. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > In C, a pointer's value is the machine address of the thing pointed > to, even if another pointer. It has no internal hidden indirection. The specification makes no guarantee of that fact. > Potentially a reference could encode facts about the object or could > be several layers of indirection, e.g. to an out of ram backup. > Because all details of how it works are hidden, that gives maximum > flexibility for implementors. Yep, that's true of pointers in C, too. Signaturewww.designacourse.com The Easiest Way To Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation >> In C, a pointer's value is the machine address of the thing pointed >> to, even if another pointer. It has no internal hidden indirection. > >The specification makes no guarantee of that fact. I think you would find it does in practice.. If you add 1 to a C pointer you get the next byte. If the pointer were implemented as a handle you would get gibberish. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >>> In C, a pointer's value is the machine address of the thing pointed >>> to, even if another pointer. It has no internal hidden indirection. [quoted text clipped - 4 lines] > pointer you get the next byte. If the pointer were implemented as a > handle you would get gibberish. "pointer + 1" is an idiom that does the right thing, not a simple integer addition. That's why, in a naive implementation, struct a { char[100]c }; struct a *ptr; ptr++; /* increments ptr by 100 */ while ptr = (struct a*)((int)ptr + 1); /* undefined */ might do almost anything, >>>> In C, a pointer's value is the machine address of the thing pointed >>>> to, even if another pointer. It has no internal hidden indirection. [quoted text clipped - 18 lines] > > might do almost anything, Which was an annoyance when I wanted to manipulate bits in a double. I had to cast through a void pointer to an unsigned char pointer to be able to access the individual bytes. Fortunately (although later I realized also intuitively) there was no additional work done in the assembly. The stupid "protection" kept me from just directly casting to a pointer. In retrospect, I should have just written that routine in assembly. -- LTP :) >>>>> In C, a pointer's value is the machine address of the thing pointed >>>>> to, even if another pointer. It has no internal hidden indirection. [quoted text clipped - 25 lines] > stupid "protection" kept me from just directly casting to a pointer. In > retrospect, I should have just written that routine in assembly. I don't follow you; double d; char *ptr = (char *)&d; should work fine in either C or C++. >I don't follow you; > double d; > char *ptr = (char *)&d; >should work fine in either C or C++. At least for C, it is said in ISO/IEC 9899:1999 (E): "When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object.", 6.3.2.3, #7 >>>>>> In C, a pointer's value is the machine address of the thing pointed >>>>>> to, even if another pointer. It has no internal hidden indirection. [quoted text clipped - 32 lines] > > should work fine in either C or C++. It did not allow me to do that - of course I was using a microsoft compiler. SignatureLTP :) >> I don't follow you; >> [quoted text clipped - 5 lines] > It did not allow me to do that - of course I was using a microsoft > compiler. Was it .NET Managed C++? I know I've done things like this in the old VC++ days. And a real compiler (gcc) has no trouble with it. >>> I don't follow you; >>> [quoted text clipped - 8 lines] > Was it .NET Managed C++? I know I've done things like this in the old > VC++ days. And a real compiler (gcc) has no trouble with it. Oh you can do it, you just have to use an intermediary (void *) cast. I didn't mean to imply it couldn't be done, only that it was annoying. I think you have to use a volatile double as well to prevent the compiling from assuming that the doble value hasn't changed. (Usually this wasn't a problem, but I didn't want a no-aliasing optimization turned on and messing it up.) SignatureLTP :) >>>> I don't follow you; >>>> [quoted text clipped - 10 lines] > > Oh you can do it, you just have to use an intermediary (void *) cast. Not in GCC, which is why I was curious which compir required that. >>>>> I don't follow you; >>>>> [quoted text clipped - 12 lines] > > Not in GCC, which is why I was curious which compir required that. Ask old Billy Boy. I suppose it is to prevent the coder from mistakenly thinking he has cast the value, not just the address. SignatureLTP :) >>>>>> I don't follow you; >>>>>> [quoted text clipped - 15 lines] > Ask old Billy Boy. I suppose it is to prevent the coder from mistakenly > thinking he has cast the value, not just the address. Even if I had his ear, I don't think he'd know which compiler you were using :-) >>>>>>> I don't follow you; >>>>>>> [quoted text clipped - 18 lines] > Even if I had his ear, I don't think he'd know which compiler you were > using :-) Sorry - I misunderstood. It was Microsoft Visual Studio C++ 6.0 Professional. -- LTP :) > What would be the equivalent in Java to get a quick debug > output of the five reference values? > > I am aware of "System.identityHashCode", but this still gives > me no strict guarantee to have the same behavior as the > actual references in this regard. Slightly off-topic, but... If I really only wanted a quick hack for debugging then I'd be quite happy to depend on identityHashCode(), if not -- i.e. I needed a /guaranteed/ unique identifier associated with each of my objects -- then I'd code that explicitly. -- chris > hai > any one tell me why java doesn't support pointers.instead it will do > the same(means storing address,not arithematic operations on address) > using reference variables.can any one plese clarify my doubt Yes, java does not allow pointer arithmatic, but you can consider references in Java to be as good as C++ pointers, rather than C++ references. Pointer arithmatic is a source of many hard-to-find bugs. Java was designed to be "safe", and hence the need to remove extra complexity. > Yes, java does not allow pointer arithmatic, but you can consider > references in Java to be as good as C++ pointers, rather than C++ > references. Well, Java sacrifices some flexibility for safety. Java references are more limited than C++ pointers in more ways than one. > Pointer arithmatic is a source of many hard-to-find bugs. When used improperly. Pointer arithmetic is a mechanism appropriate to low-level memory manipulation. If that's the domain you're working in, it's the perfect tool. Problems arise when people use the right tool for the wrong job. Java abstracts most aspects of memory management away from you, so there's real need for this kind of manipulation. > Java was designed to be "safe", and hence the need to remove extra > complexity. s/complexit/efficienc/ ;) Luke Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.