 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2007Strings...immutable?
I read in a book that String objects are immutable, yet a few lines later they show some code in which a String object is added to by using the '+' operation. I must be misunderstanding what is meant by immutable becuase it seems to me that String s = 'hello'; s += 'good-bye'; should result in a compiler error if in fact the string is immuatable. Can anyone clarify this for me? >I read in a book that String objects are immutable, yet a few lines > later they show some code in which a String object is added to by [quoted text clipped - 6 lines] > should result in a compiler error if in fact the string is > immuatable. Can anyone clarify this for me? http://mindprod.com/jgloss/interned.html > I read in a book that String objects are immutable, yet a few lines > later they show some code in which a String object is added to by [quoted text clipped - 6 lines] > should result in a compiler error if in fact the string is > immuatable. Can anyone clarify this for me? s is not a String object, it is a reference variable that can either be null or point to a String object. The += changes s from pointing to the "hello" String object to instead point to a String object with value "hello"+"good-bye". It does not change the "hello" object. You can test it with this program: public class Concatenate { public static void main(String[] args) { String s = "hello"; String x = s; s += "good-bye"; System.out.println(x); } } which shows that "hello" is unaffected by the +=. Patricia >> String s = 'hello'; >> s += 'good-bye'; > s is not a String object, it is a reference variable that can either be > null or point to a String object. [quoted text clipped - 6 lines] > String x = s; > s += "good-bye"; Yup. To clarify just a bit more, in your original example, the original object "hello" is tossed away. There's no reference to it, so it's just left on the heap, and it'll be garbage-collect later. In Patricia's example, there's a reference to "hello" retained in x, so this time the "hello" object will stick around, and it's usable later, like for printing out. > Yup. To clarify just a bit more, in your original example, the original > object "hello" is tossed away. There's no reference to it, so it's just > left on the heap, and it'll be garbage-collect later. Actually it won't get garbage collected unless the class is also garbage collected. There is, in effect, a hidden reference from the class to all literal Strings declared in it. Mark Thornton > Actually it won't get garbage collected unless the class is also garbage > collected. There is, in effect, a hidden reference from the class to all > literal Strings declared in it. I don't believe this. First it doesn't make any sense from a design view-point. And second where is one class gonna keep references to 1000 or more odd unused strings? Where did you hear this? >> Actually it won't get garbage collected unless the class is also garbage >> collected. There is, in effect, a hidden reference from the class to all [quoted text clipped - 4 lines] >First it doesn't make any sense from a design view-point. And second >where is one class gonna keep references to 1000 or more odd unused strings? I wouldn't expect many classes to have thousands of string literals in them. From a design viewpoint, keeping the string literals around as cached String objects makes sense since you can just reuse those objects every time a new instance of the class is created. Cheers Bent D  SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs Mark Thornton wrote: >> Actually it won't get garbage collected unless the class is also >> garbage collected. There is, in effect, a hidden reference from the >> class to all literal Strings declared in it. > I don't believe this. It's true. > First it doesn't make any sense from a design view-point. And second > where is one class gonna keep references to 1000 or more odd unused > strings? In its "pool of strings, initially empty, ... maintained privately by the class String." The number of such strings is determined by the number of literal strings in your program. Such strings could be in ROM, theoretically. > Where did you hear this? From the JLS. <http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.10.5> > String literals-or, more generally, strings that are the values of constant expressions (§15.28)-are "interned" so as to share unique instances, using the method String.intern. jupiter wrote: >> Wowza-roni! >> >> Are you sure about that? I think this one slipped past some of the >> big brains who have written some very good books on the subject. It didn't. >> Nice catch. If that's true then it might indicate why profilers >> are showing kabillions of String objects that supposedly should not >> be there any more. Oh well, I guess if you never ran out of heap >> in an inglorious crash you wouldn't care about this. Mostly the interned strings are computed at compile time, so there is no impact on dynamic memory usage. If you explicitly use the String.intern() method <http://java.sun.com/javase/6/docs/api/java/lang/String.html#intern()> then the canonical representation of the string will be in a "pool of strings, initially empty, ... maintained privately by the class String." Since there are negligibly few situations where one calls intern() explicitly, and presumably then only for frequently reused values, this mechanism was never responsible for when "you ... ran out of heap in an inglorious crash". -- Lew > Mark Thornton wrote: >> >>> Actually it won't get garbage collected unless the class is also >>> garbage collected. There is, in effect, a hidden reference from the >>> class to all literal Strings declared in it. >> Where did you hear this? > [quoted text clipped - 3 lines] >> constant expressions (§15.28)-are "interned" so as to share unique >> instances, using the method String.intern. Ah! Ok, string literals. I miss-read Mr. Thornton's original statement and assumed that he meant all strings, not just literals. This makes much more sense. I don't mind asking stupid questions, it's how I lurn stuff. ;-) Mark Thornton wrote: > Actually it won't get garbage collected unless the class is also garbage > collected. There is, in effect, a hidden reference from the class to all > literal Strings declared in it. =========8< snip! =============== > That used to be true, but the implementation of interning was modified > to use WeakReference. > Mark Thornton So the first statement isn't really true either. If the interned strings are using weak references, then they will be garbage collected if the GC needs extra memory (and no other strong references are being held to them). So the last time my JVM yacked up a virtual hairball on the digital carpet in the form of an Out Of Memory error, it presumably at least considered the pool of interned strings for deletion before deciding it was well and truly out of memory... >> Mark Thornton wrote: >>> [quoted text clipped - 37 lines] > the pool of interned strings for deletion before deciding it was well and > truly out of memory... Yes, but the string constants are held by hard references from the class. So unless the class itself is also eligibile for garbage collection, the intern'd string pool doesn't shrink any. -- Adam Maass > > Actually it won't get garbage collected unless the class is also garbage > > collected. There is, in effect, a hidden reference from the class to all [quoted text clipped - 5 lines] > where is one class gonna keep references to 1000 or more odd unused > strings? It is, however, true. I wouldn't have phrased it quite as Mark Thornton did, but I'm sure he meant the same as I would have done if I had (if you see what I mean ;-) The essential points are that the JLS requires that string literals are treated specially in various ways. One of them is that if the same (character by character) string literals occurs more than once anywhere in the Java source, then there must be a /single/ String object which is the value of /all/ of those expressions. There is some extra stuff to tie that fundamental requirement together with the String interning stuff -- it is required that for any String which is the value of a string literal: someString = "whatever; // a string literal expression someString == someString.intern(); someString = "whatever" + " " + "else"; // another string literal expression someString == someString.intern(); At the implementation level (below the level visible from Java, or even JNI), this is connected with the "constant pool" in each .CLASS file. That holds a good deal of information; notably, the values of all non-trivial literals in the source, including the values of all string literals. -- chris >>>Actually it won't get garbage collected unless the class is also garbage >>>collected. There is, in effect, a hidden reference from the class to all [quoted text clipped - 10 lines] > I wouldn't have phrased it quite as Mark Thornton did, but I'm sure he meant > the same as I would have done if I had (if you see what I mean ;-) Your explanation is much longer than mine! :-) Mark Thornton >> Yup. To clarify just a bit more, in your original example, the >> original object "hello" is tossed away. There's no reference to [quoted text clipped - 6 lines] > > Mark Thornton Wowza-roni! Are you sure about that? I think this one slipped past some of the big brains who have written some very good books on the subject. Nice catch. If that's true then it might indicate why profilers are showing kabillions of String objects that supposedly should not be there any more. Oh well, I guess if you never ran out of heap in an inglorious crash you wouldn't care about this. >> Yup. To clarify just a bit more, in your original example, the >> original object "hello" is tossed away. There's no reference to it, [quoted text clipped - 3 lines] > garbage collected. There is, in effect, a hidden reference from the > class to all literal Strings declared in it. Do you have a reference for that? My understanding is that string literals live in the pool of interned Strings, which is JVM-wide. When a class that contains a "hello" literal is loaded, during its initialization it looks for "hello" in the interned strings, and creates it only if it's not already present. Since the interned strings aren't collected for the life of the JVM. There's no need for the class to maintain a reference to it. And as a result, "hello" won't be collected even if all of the classes which reference it are collected. >>>Yup. To clarify just a bit more, in your original example, the >>>original object "hello" is tossed away. There's no reference to it, [quoted text clipped - 13 lines] > for the class to maintain a reference to it. And as a result, "hello" won't > be collected even if all of the classes which reference it are collected. That used to be true, but the implementation of interning was modified to use WeakReference. http://mindprod.com/jgloss/interned.html http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4035345 Fixed in 1.2beta. Mark Thornton >>> String s = 'hello'; >>> s += 'good-bye'; [quoted text clipped - 16 lines] > "hello" object will stick around, and it's usable later, like for > printing out. I didn't mention what would happen to "hello" because I thought it would bring up the intern issue, and be more confusing than enlightening. After watching this thread for a bit, I think I was right. Patricia > After watching this thread for a bit, I think I was right. ;-) and we haven't got to the question of when do classes get garbage collected yet (or which version of Java changed this behaviour)! Mark >> After watching this thread for a bit, I think I was right. > > ;-) and we haven't got to the question of when do classes get garbage > collected yet [...] My experiences with servlet containers leads me to answer "never, no matter how hard you work to allow it to happen" :-) Mike Schilling wrote : >>> After watching this thread for a bit, I think I was right. >> [quoted text clipped - 3 lines] > My experiences with servlet containers leads me to answer "never, no matter > how hard you work to allow it to happen" :-) No, they do get GC. I have a timer which gathers the memory footprint every ten minutes and stores it for 24 hours. The graphical display of the memory utilization footprint looks like a saw tooth (even when the server is idling): * * ** ** *** *** **** **** *********** When I do image manipulation, the graph spikes. After several images the utilization reaches about 80%, at which time the GC runs and the utilization drops back to the minimal value. No idea why the grapgh looks like that. I did expect it to flat-line when nothing is happening. SignatureWojtek :-) >Mike Schilling wrote : >> [quoted text clipped - 5 lines] >the memory utilization footprint looks like a saw tooth (even when the >server is idling): What Mike is referring to is garbage collection of instances of the "Class" class. What you are seeing is probably garbage collection of more mundane objects: String, byte[], Dimension, etc. Cheers Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs >>Mike Schilling wrote : >>> [quoted text clipped - 10 lines] > "Class" class. What you are seeing is probably garbage collection of > more mundane objects: String, byte[], Dimension, etc. Yeah. In theory the entire [classloader X/classes loaded by X/instances of classes loaded by X] hairball can get collected together, and I can build an example that demonstrates this. In theory, it should occur in a servlet container when a web application is unloaded; in practice, *something* always gets in the way. > > printdude1...@gmail.com wrote: > >> String s = 'hello'; [quoted text clipped - 16 lines] > "hello" object will stick around, and it's usable later, like for > printing out. Hmmm... my understanding is that after line 2 of your example, there are two reference variables referring to the same object... some object called "hello". Furthermore, I would expect that if you printed x and s, they would both say "hello good-bye" because, since both x and s refer to the same object, then what happens to one happens to the other? Are you saying this isn't the way it works? Geeesh.... this is getting harder every day to figure out.. >> > printdude1...@gmail.com wrote: >> >> String s = 'hello'; [quoted text clipped - 20 lines] > are two reference variables referring to the same object... some > object called "hello". It may be better not to have added what the object is called and simply left it "two reference variables referring to the same object". That object has a String value of "hello". > Furthermore, I would expect that if you > printed x and s, they would both say "hello good-bye" because, since > both x and s refer to the same object, then what happens to one > happens to the other? Are you saying this isn't the way it works? > Geeesh.... this is getting harder every day to figure out.. No, that is not the way it works because the third line (s += "good-bye") does not mutate the Object to which the reference variable named "s" refers. The line creates a new String object with the value "hellogood-bye" and assigns a reference to the new object to the variable named "s". The variable names "x" still refers to the same Object as before (which has not be changed). If the third line mutated the value of the Object to which the variable named "s" referred, then other references to the same object would see the mutated value. >I read in a book that String objects are immutable, yet a few lines > later they show some code in which a String object is added to by [quoted text clipped - 6 lines] > should result in a compiler error if in fact the string is > immuatable. Can anyone clarify this for me? http://mindprod.com/jgloss/string.html Have a look at the following code String s = " hallo "; // notice the blanks before and after the word "hello" s.trim(); // expect that the spaces disapear? The string represented by the referece "s" is not changed (that means immutable). But most String-Mehtods return a new object containing the expeced result. String s1, s2; s1 = " hallo "; s2 = s1.trim(); Or shorter String s = " hello "; s = s.trim(); Now you could say that s has changed! This is true, the reference "s" now points to the result of the trim() Method, which is a new object! The old object " hello " still remains in memory, but is no longer pointed to by "s". This makes you think, the string has changed. This is not true! Only the reference s points to a new object. greets phi > I read in a book that String objects are immutable, yet a few lines > later they show some code in which a String object is added to by [quoted text clipped - 6 lines] > should result in a compiler error if in fact the string is > immuatable. Can anyone clarify this for me? >I read in a book that String objects are immutable, yet a few >lines [quoted text clipped - 8 lines] > should result in a compiler error if in fact the string is > immuatable. Can anyone clarify this for me? Heap and stack are two different memory storage spaces. One is for Object and one is for references to Object. It helped me to "see" in my mind that a String is put on the heap as an Object, while references remain only on the stack pointing to the Object address. So, s starts out being a reference and remains a reference. When it points to "hello" it points to the "hello" Object on the heap. When s points to "hellogoodbye" it's pointing to a new heap Object. So they are different objects, and nothing has been mutated. I think that's right. Is that right? I think somebody will correct me if not. > Heap and stack are two different memory storage spaces. One is > for Object and one is for references to Object. [quoted text clipped - 10 lines] > I think that's right. Is that right? I think somebody will > correct me if not. The memory management in the JVM is much more complicated than that (I don't know much about, so anyone correct me if I get something wrong). There is the basic stack frame (per thread?), which stores all of the local variables, Object references, etc. Then there is the heap space, which stores the actual objects. There is also a separate space for the class references and internal String references -- String's interns are NOT stored in the heap. So, the "hello" object has a pointer on the stack frame, a reference to the String variable in the heap, a reference to the class AND the interned String in the other memory space. As two asides: 1. a java.lang.OutOfMemoryError: heap space cannot be due to having too many String interns, it can only be due to using too much data. 2. This should return true, using the Sun JVM: public class Foo { final static String bar1 = "Hello"; final static String bar2 = "Hello"; public static boolean equal() { return bar1 == bar2; } } > 2. This should return true, using the Sun JVM: > [quoted text clipped - 6 lines] > } > } It must return true, given anyone's JVM. > * Literal strings within the same class (§8) in the same package (§7) represent references to the same String object (§4.3.1). > * Literal strings within different classes in the same package represent references to the same String object. > * Literal strings within different classes in different packages likewise represent references to the same String object. > * Strings computed by constant expressions (§15.28) are computed at compile time and then treated as if they were literals. > * Strings computed by concatenation at run time are newly created and therefore distinct. -- Lew >> 2. This should return true, using the Sun JVM: >> [quoted text clipped - 21 lines] > > -- Lew Why is it that every time I ask a seemingly harmless question, it turns out to be a debate/discussion that far surpasses my original question? :-) Not that there is anything wrong with what's being talked about now but my question was answered 3 or 4 replies after my original post... so now we are talking about garbage collection? After doing a bit more studying, I've learned that it's the contents of the string object that are subject to change, not the string itself, hence the idea/rule that strings are immutable. Is this a correct interpretation or do I need to go back to the books again? ... > After doing a bit more studying, I've learned that it's the contents of > the string object that are subject to change, not the string itself, > hence the idea/rule that strings are immutable. Is this a correct > interpretation or do I need to go back to the books again? No, the contents of a String object can never change. Returning to a program I posted earlier in this thread: 1 public class Concatenate { 2 public static void main(String[] args) { 3 String s = "hello"; 4 String x = s; 5 s += "good-bye"; 6 System.out.println(x); 7 } 8 } A reference variable such as s or x is either null, or a pointer to some object. At line 3, s is assigned a pointer to the object representing the String literal "hello". At line 4, that pointer is copied to x. They now both point to the same object. Line 5 is equivalent to 's = s + "good-bye";'. The JVM creates a String object representing the concatenation of the String object s references and the one representing "good-bye". s is assigned a pointer to that object. The output at line 6 shows the value of the object x references, the original, unmodified "hello". No String objects where modified in the course of this program. Patricia >No, the contents of a String object can never change. Could it be pulled off by playing with reflection in a suitably lax security manager? Cheers Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs >>No, the contents of a String object can never change. > > Could it be pulled off by playing with reflection in a suitably lax > security manager? Yes. This was proved years ago in this very forum. The short response from the group was: DON'T DO THAT! The reasons: 1) Many programs depend on the immutability of String; if all of a sudden they aren't, there's trouble brewing. 2) Using reflection this way is a violation of the spirit of the facility. 3) A reflection-based String mutator is going to be very brittle, dependant on the exact implementation of String. Since the implementation of String isn't specified (nor should it be!), the code isn't guaranteed to work as expected in all VMs. 4) This kind of code is going to depend on a security manager allowing it to happen. Just because it works in some VMs does not mean that will work in others with higher security standards. (Even if it's the same revision of the same VM from the same vendor on the same platform.) -- Adam Maass >>>No, the contents of a String object can never change. >> [quoted text clipped - 6 lines] > >DON'T DO THAT! Indeed. Nevertheless, it can be interesting to do it just to see the many intriguing ways in which the program falls apart when you do :-) Cheers Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs >> No, the contents of a String object can never change. > > Could it be pulled off by playing with reflection in a suitably lax > security manager? Is this something we really need to discuss when trying to help someone who does not seem to be quite clear yet on the difference between a reference variable and the object it references? There are few statements that can be made about the behavior of any Java class given inappropriate use of reflection with a lax security manager. Are we going to qualify every statement we make? Patricia >> Could it be pulled off by playing with reflection in a suitably lax >> security manager? > >Is this something we really need to discuss when trying to help someone >who does not seem to be quite clear yet on the difference between a >reference variable and the object it references? Well, no, technically, we don't really need to discuss anything at all. >There are few statements that can be made about the behavior of any Java >class given inappropriate use of reflection with a lax security manager. And yet, the few that _can_ be made are probably interesting ones. >Are we going to qualify every statement we make? I am not sure how this question is particularly relevant. Cheers Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs > > In article <etkqb9$lr...@ihnp4.ucsd.edu>, > >> No, the contents of a String object can never change. [quoted text clipped - 11 lines] > > Patricia How does my question about the immutablility of strings lead you to believe that I am not clear on "...the difference between a reference variable and the object it references". While I respect your knowledge and wisdom, I don't appreciate being spoken of like I'm not here because I AM. Seriously though, I do understand the difference between a ref var and the object... I was just a bit unclear about the reason why my book was telling me that Strings are immutable yet showing code that does exactly that. Perhaps people who write these books could make what they are saying a bit clearer. I don't need to be spoon fed, but if you were in my shoes you'd say "hmmmmm... they just told me it was against the law to break into a bank and steal all the money but now they are telling me how to do it?" That's the way I read it, not in those terms of course, but I think you get my drift. > ... > [quoted text clipped - 21 lines] > At line 3, s is assigned a pointer to the object representing the String > literal "hello". Pointers in Java? Ok.. I follow so far > At line 4, that pointer is copied to x. They now both point to the same > object. Yup.. gotcha > Line 5 is equivalent to 's = s + "good-bye";'. The JVM creates a String > object representing the concatenation of the String object s references > and the one representing "good-bye". s is assigned a pointer to that > object. I understand the concept of concatenation. Is 's' now a new String or is the old one reused? > The output at line 6 shows the value of the object x references, the > original, unmodified "hello". But that doesn't make sense. If x and s are both pointing to the same chunk of memory in which is contained a string "hello", my reading has lead me to believe that if you change s, x is changed as well. so if you were to say s += "hello"; and then output x, you would get the same thing as if you output s. Me going to try it now... public class Concatenate { public static void main(String[] args) { String s = "hello"; System.out.println("Before assignment s is: " + s); String x = s; System.out.println("After assignment s is: " + s); s += "good-bye"; System.out.print("After concat s is: " + s); System.out.println(" and x is: " + x); } } Output ---- Before assignment s is: hello After assignment s is: hello After concat s is: hellogood-bye and x is: hello > No String objects where modified in the course of this program. So where the hell did I get the idea that x would change along with s? Surely I didn't come up with it on my own? > Patricia If x and s are both pointing to the same > chunk of memory in which > is contained a string "hello", my reading has lead me to believe that > if you change s, x is > changed as well. so if you were to say s += "hello"; and then output > x, you would get the > same thing as if you output s. You are confusing the reference with the object to which it points. When you say s += "hello"; you are NOT changing the object to which s first pointed. You are creating a /brand-new/ object and point s to it. x continues to point to the old object. s = "hello"; // pretend the literal has an "address" of 1 // s contains the "address" 1 x = s; // x contains the "address" 1 s += "goodbye"; // s contains the "address" 2 There are now two string objects out there, the first one at "address" 1: "hello" and the second one at "address" 2: "hellogoodbye" These are TWO SEPARATE OBJECTS. They reside in different memeoy locations. s points to the second one, x to the first one. -- Lew > printdude1...@gmail.com wrote: > [quoted text clipped - 30 lines] > > -- Lew This is the exact explanation(IMHO), probably should had come at the beginning of the thread. -- Ck http://www.gfour.net >> ... >> [quoted text clipped - 22 lines] > > Pointers in Java? Ok.. I follow so far I think a lot of confusion has been caused by the developers of Java, at least in the early stages, avoiding talking much about pointers. Java reference variables are pointers in the sense in which the term was used e.g. in the Pascal Report. Unfortunately, C added a lot of baggage such as arithmetic and conversions to/from integer types. There may have been a concern that if Java references were called pointers people would think they were as dangerous as C pointers. A lot of Java behavior, including this topic and some aspects of parameter passing, are much easier to understand in terms of pointers. >> At line 4, that pointer is copied to x. They now both point to the same >> object. [quoted text clipped - 9 lines] > is > the old one reused? s is now a pointer to a new String object, containing the contents of the one previously referenced by s followed by "good-bye". It has to be a different one because the old one still contains "hello", as did when created and will go on doing until it is GC'd or the program terminates. I'm not sure we are using "concatenation" exactly the same way. For purposes of Java, concatenating two String objects results in a reference to a String object containing the concatenation of their contents. It does not mean changing one of them by inserting the characters from the other. >> The output at line 6 shows the value of the object x references, the >> original, unmodified "hello". [quoted text clipped - 6 lines] > x, you would get the > same thing as if you output s. x and s being pointers to the same object is just like intX and intX being ints with the same value in the following code: int intS = 3; int intX = intS; intS = 7; You would expect intX to go on being 3, even though intS now contains 7. In just the same way, x goes on referencing the "hello" object regardless of any assignments to s. > So where the hell did I get the idea that x would change along with > s? Surely I didn't come up with it on my own? Unfortunately, I don't know. If I knew where the idea came from, I could probably write exactly the right explanation.... Patricia [ snip ] > > Pointers in Java? Ok.. I follow so far > [quoted text clipped - 10 lines] > A lot of Java behavior, including this topic and some aspects of > parameter passing, are much easier to understand in terms of pointers. Strongly agreed! So many things only began to make sense to me when I understood that any variable that wasn't a primitive type was a reference, and that "reference" could be read as "pointer without some of the properties that can cause trouble". [ snip ] > >> Line 5 is equivalent to 's = s + "good-bye";'. The JVM creates a String > >> object representing the concatenation of the String object s references [quoted text clipped - 26 lines] > > x, you would get the > > same thing as if you output s. No. If you change *the object pointed to by s*, then you are right that *the object pointed to by x* changes as well, since they're the same object. But as Patricia says, concatenating two String objects produces a new String object rather than modifying one of the existing objects. Further, assigning a value to a reference variable (such as s in the example) just makes the variable point to a different object, or makes it null. It doesn't change the object itself. > x and s being pointers to the same object is just like intX and intX > being ints with the same value in the following code: [quoted text clipped - 9 lines] > > So where the hell did I get the idea that x would change along with > > s? Surely I didn't come up with it on my own? Well .... If there were a way to change String objects .... Here's another example, using the StringBuffer class, which is *not* immutable: StringBuffer sb = new StringBuffer("hello"); StringBuffer sbCopy = sb; sb.append("goodbye"); System.out.println(sb); System.out.println(sbCopy); Here there's a single StringBuffer object, which both sb and sbCopy (not the best name, I admit, but a better one isn't occurring to me) point to. sb.append actually changes the object, and .... What do you think is printed? > Unfortunately, I don't know. If I knew where the idea came from, I could > probably write exactly the right explanation.... SignatureB. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor. > I think a lot of confusion has been caused by the developers of Java, at > least in the early stages, avoiding talking much about pointers. Java > reference variables are pointers in the sense in which the term was used > e.g. in the Pascal Report. I've coded in Pascal and Delphi but have never heard of Pascal Report? > Unfortunately, C added a lot of baggage such as arithmetic and > conversions to/from integer types. There may have been a concern that if [quoted text clipped - 3 lines] > A lot of Java behavior, including this topic and some aspects of > parameter passing, are much easier to understand in terms of pointers. I thought the idea of pointers was taboo in Java? And yes, I read that one too :-) > s is now a pointer to a new String object, containing the contents of > the one previously referenced by s followed by "good-bye". It has to be > a different one because the old one still contains "hello", as did when > created and will go on doing until it is GC'd or the program terminates. So when ever you do a concatenation of a previously created String object the old "contents" are left on the heap or stack until System.gc() is invoked or the JVM does its own garbage collection. > I'm not sure we are using "concatenation" exactly the same way. For > purposes of Java, concatenating two String objects results in a > reference to a String object containing the concatenation of their > contents. It does not mean changing one of them by inserting the > characters from the other. I understand it now.. thank you... > Unfortunately, I don't know. If I knew where the idea came from, I could > probably write exactly the right explanation.... > > Patricia I posted what I think is an explanation for my confusion. Reading one book and then getting confuddled when I read another... >> I think a lot of confusion has been caused by the developers of Java, at >> least in the early stages, avoiding talking much about pointers. Java >> reference variables are pointers in the sense in which the term was used >> e.g. in the Pascal Report. > > I've coded in Pascal and Delphi but have never heard of Pascal Report? The Pascal Report was the foundational document for Pascal: http://www.moorecad.com/standardpascal/Wirth-PascalRevisedReport.pdf >> Unfortunately, C added a lot of baggage such as arithmetic and >> conversions to/from integer types. There may have been a concern that if [quoted text clipped - 6 lines] > I thought the idea of pointers was taboo in Java? And yes, I read > that one too :-) The idea of pointers is not taboo in Java. Indeed, it is the most pointer-dependent language I have ever used. The taboo is only against calling pointers "pointers", and even that is broken in a few places, such as NullPointerException. Patricia >>I've coded in Pascal and Delphi but have never heard of Pascal Report? >The Pascal Report was the foundational document for Pascal: I just ran into two people claiming to have studied computer science and never heard of »The Art of Computer Programming« (but instead they have learned Java, sigh). >The idea of pointers is not taboo in Java. Indeed, it is the most >pointer-dependent language I have ever used. The taboo is only against >calling pointers "pointers", and even that is broken in a few places, >such as NullPointerException. I do not consider it a »taboo«, when (since) the JLS itself says: »reference values (...) are pointers (...)« JLS3, 4.3.1 Patricia Shanahan wrote : > The idea of pointers is not taboo in Java. Indeed, it is the most > pointer-dependent language I have ever used. The taboo is only against > calling pointers "pointers", and even that is broken in a few places, > such as NullPointerException. Yes, but the use of pointers is hidden from view. If you use pointers, then you should be able to have an array of pointers. Which means that you should be able to do pointer arithmetic. There are no pointers to pointers. Each Java object reference "points" to an actual object, not a reference to that object. So while yes Java uses pointers beneath the hood, they are not exposed to the developer. SignatureWojtek :-) > Patricia Shanahan wrote : > [quoted text clipped - 4 lines] > > Yes, but the use of pointers is hidden from view. Hardly: that different variables can refer to the very same object is an inescapable part of the language. > If you use pointers, then you should be able to have an array > of pointers. Which you can. > Which means that you should be able to do pointer arithmetic. The former doesn't imply the latter. > There are no pointers to pointers. That's sort-of true. > Each Java object reference "points" to an actual object, not > a reference to that object. Yes. > So while yes Java uses pointers beneath the hood, they are not exposed > to the developer. Java doesn't expose /C-style/ pointers to the programmer. Neither do Wirth's Pascal nor Algol 68 nor Lisp. That doesn't make its pointers somehow pointer non grata. SignatureChris Dollin RIP John "BNF, Fortran, FP" Backus 3Dec1924 - 17Mar2007 Chris Dollin wrote : >> Patricia Shanahan wrote : >> [quoted text clipped - 16 lines] > > The former doesn't imply the latter. What I meant by allowing an array of pointers is (in C/C++) that you can move through the array either by index or by an offset from the pointer. In Java you can only use an index in the array. >> There are no pointers to pointers. > > That's sort-of true. Explain please. I can set a reference to an object. I cannot set a reference to a reference. Object a = new Object(); Object b = a; a = null; b still holds a reference to the new Object. In C/C++ with pointer to pointer referencing, b would point to nothing. >> Each Java object reference "points" to an actual object, not >> a reference to that object. [quoted text clipped - 7 lines] > do Wirth's Pascal nor Algol 68 nor Lisp. That doesn't make its > pointers somehow pointer non grata. While a reference to an object is actually a pointer (which I am NOT arguing), you cannot manipulate that reference. Other than re-asigning it. Whereas in C/C++ move it through an array using pointer arithmetic. SignatureWojtek :-) > Chris Dollin wrote : ... > Object a = new Object(); > Object b = a; > a = null; > > b still holds a reference to the new Object. In C/C++ with pointer to pointer referencing, b would point to nothing. Could you post what you consider to be the equivalent C or C++ code? I would expect something like: Object *a = new Object(); Object *b = a; a = null; > While a reference to an object is actually a pointer (which I am NOT > arguing), you cannot manipulate that reference. Other than re-asigning > it. Whereas in C/C++ move it through an array using pointer arithmetic. I think we need to clarify what we all agree about and what, if anything, we disagree about. Here is my position: 1. Java does have pointers, and it impossible to work with arrays or objects without using them. 2. Java does not have pointer arithmetic as introduced in C and continued in C++. 3. Pointers without arithmetic existed in at least one published language definition, the Pascal Report, when C was still being developed. 4. Some Java behavior is much easier understood and explained in terms of pointers than by hiding them. If you disagree with any of these statements, please indicate which. For anyone who disagrees with #4, please provide your explanation of the behavior of the following program: public class CallByQuestion { static StringBuffer x; public static void main(String[] args) { StringBuffer myBuf = new StringBuffer(); x = myBuf; System.out.println("Before call:"); System.out.printf(" x==myBuf is %b%n",x==myBuf); System.out.printf(" myBuf contents: %s%n", myBuf.toString()); myMethod(myBuf); System.out.println("After call:"); System.out.printf(" x==myBuf is %b%n",x==myBuf); System.out.printf(" myBuf contents: %s%n", myBuf.toString()); } private static void myMethod(StringBuffer myBuf) { StringBuffer y = myBuf; myBuf = new StringBuffer("Some data"); System.out.println("Inside myMethod:"); System.out.printf(" x==myBuf is %b%n",x==myBuf); System.out.printf(" myBuf contents: %s%n", myBuf.toString()); y.append("Some other data"); } } Patricia > I think we need to clarify what we all agree about and what, if > anything, we disagree about. Here is my position: [quoted text clipped - 10 lines] > 4. Some Java behavior is much easier understood and explained in terms > of pointers than by hiding them. As usual, Patricia has ruined a perfectly good argument by making things overly clear :-) > I think we need to clarify what we all agree about and what, if > anything, we disagree about. Here is my position: ... > 4. Some Java behavior is much easier understood and explained in > terms of pointers than by hiding them. > > If you disagree with any of these statements, please indicate > which. For anyone who disagrees with #4, please provide your > explanation of the behavior of the following program: I would just say that the variables have the same value or that they have a different value. Usually I would shorten this even further: when talking about the values of x and y I would just say that x and y are different, or are the same. Pointer talk is needed only to explain how this is implented. > public class CallByQuestion { > static StringBuffer x; > public static void main(String[] args) { > StringBuffer myBuf = new StringBuffer(); > x = myBuf; Now x and myBuf are the same object. > System.out.println("Before call:"); > System.out.printf(" x==myBuf is %b%n",x==myBuf); [quoted text clipped - 6 lines] > > private static void myMethod(StringBuffer myBuf) { Now myBuf and myBuf are the same object. (These are the myBuf of main and myBuf of myMethod.) > StringBuffer y = myBuf; Now y and myBuf are also the same object. (Either myBuf: they are the same.) > myBuf = new StringBuffer("Some data"); No y and myBuf are the same object, and y and myBuf are different objects, and myBuf and myBuf are different objects. The confusing part is that there are two different variables with the same name. Pointer talk is not less confusing: myBuf and myBuf point to different objects; the values of myBuf and myBuf point to different objects; the pointers that are the values of myBuf and myBuf point to different objects; nothing helps but keeping myBuf-of-main separate from myBuf-of-myMethod, and that is not a pointer issue. > System.out.println("Inside myMethod:"); > System.out.printf(" x==myBuf is %b%n",x==myBuf); > System.out.printf(" myBuf contents: %s%n", myBuf.toString()); Since x and myBuf are different objects, there is nothing surprising in their having a different state. (That is the myBuf of myMethod.) > y.append("Some other data"); Since y is still the same object as the myBuf, this changes the state of myBuf. (That is the myBuf of main.) > } > } The output of that program does not distinguish between variables, by the way. All references to x are to the same variable while references to myBuf are not. I've always found this easy to understand, having got used to it in Common Lisp and Scheme. Objects retain their identity when they are passed around and stored in data structures. Pointer talk explains the implementation but is not so useful (to me) for understanding program behaviour. What matters is object identity. Oh yes, there is another use for pointer talk: to explain this to people who come from the other kind of languages where you do have the choice of passing either a pointer or "the object itself", but there, confusingly, "the object itself" does _not_ retain its identity when it's passed or stored somewhere. A copy is made. That's when _I_ get confused. > Pointer talk is needed only to explain how this is implented. I think it goes further than that. For one thing, there is no requirement that Java's object references be /implemented/ as classical (C/Pascal-style) "pointers" -- i.e. memory locations containing the addresses of other memory locations. The "pointer" concept is more general than that (even in C or Pascal), and is more about the logical properties of a specific kind of "thing", than of bit-level implementation details. However the terminology ./does/ convey a strong image of an implementation, and that picture (I think) helps a lot in understanding what's going on. In particular, it helps explain what's going on with variables, and the things the variables refer /to/. Without some concept that is functionally equivalent to pointers (without arithmetic) , the distinction between reference and referent will and must remain unclear. Note that it is by no means obvious that a language has to work the way Java does. For instance in older versions of PHP (as I understand it) all "things" were values -- even if compound. > I've always found this easy to understand, having got used to it in > Common Lisp and Scheme. Objects retain their identity when they are > passed around and stored in data structures. Yes, but Lisp/Scheme have very specific notions of (a) variables, and (b) the lack thereof. You just wouldn't hit the problem of understanding the difference between references and values in a referentially-transparent context. I'm not saying that I think the way that Java works is difficult or obscure in the slightest, but it doesn't seem to be as obvious to everyone as all that. (As an aside, there seems to be a tradition of expecting pointers (even without pointer arithmetic) to be somehow difficult for beginners to understand, and some books and teachers go to enormous lengths to try to explain them. They draw complicated pictures full of boxes and arrows. My personal suspicion is that the /only/ reason anyone ever has any difficulty with pointers is that the teachers confuse the Hell out of them with all the boxes and arrows....) -- chris > I would just say that the variables have the same value or that they > have a different value. Usually I would shorten this even further: > when talking about the values of x and y I would just say that x and y > are different, or are the same. > > Pointer talk is needed only to explain how this is implented. That breaks down when Java's call-by-value semantics and primitive arguments versus object arguments. While I prefer 'reference' to 'pointer', it greatly helps to have that general concept available when explaining why: f(x) cannot alter the value of x if it's a primitive, but can alter the 'value' of x if it's an object. Note the quotes - I know it's not altering the value of x - which is a reference to an object whose value may change as a result of the call. f() can't change the reference, but unless x is immutable it most likely can change the value of the object being referenced. How does one explain this without introducing the concept of a reference (pointer)? The use of references in languages that don't have pointer arithmetic has been around forever (forget Pascal, that's a newbie in this area!). SignatureSteve Wampler -- swampler@noao.edu The gods that smiled on your birth are now laughing out loud. > The use of references in languages that don't have pointer arithmetic > has been around forever (forget Pascal, that's a newbie in this > area!). FORTRAN. -- Lew >> The use of references in languages that don't have pointer arithmetic >> has been around forever (forget Pascal, that's a newbie in this >> area!). > > FORTRAN. I know Fortran has call-by-reference, and plenty of other ways of getting into trouble, but I didn't think it got pointers, or anything equivalent, until Fortran 90? Patricia >>> The use of references in languages that don't have pointer arithmetic >>> has been around forever (forget Pascal, that's a newbie in this [quoted text clipped - 5 lines] > getting into trouble, but I didn't think it got pointers, or anything > equivalent, until Fortran 90? The statement was in response to "The use of references ..." above. I did not say they were pointers. -- Lew > >> The use of references in languages that don't have pointer arithmetic > >> has been around forever (forget Pascal, that's a newbie in this [quoted text clipped - 5 lines] > getting into trouble, but I didn't think it got pointers, or anything > equivalent, until Fortran 90? I think you're right, if it's standard Fortran you're talking about, but as I understand it there was at least one nonstandard extension providing something pointer-like, namely "Cray pointers". Never worked with them, don't know much about them, but have heard them discussed often and am pretty sure they came before Fortran 90. My two cents' worth, and worth about that, maybe. SignatureB. L. Massingill ObDisclaimer: I don't speak for my employers; they return the favor. >> I would just say that the variables have the same value or that >> they have a different value. Usually I would shorten this even [quoted text clipped - 17 lines] > value of the object being referenced. How does one explain this > without introducing the concept of a reference (pointer)? I see no problem whatsoever. Primitives like boolean, int and double are immutable. Some objects are mutable, so you can change them if you have access to them. You can only assign to a variable if you have access to the variable, not just to the value it has or once had. "Alter the value of x" is ambiguous: do we talk about the object or do we talk about the variable? Often it is clear from the context and there is no problem. To disambiguate, I think I would say that f can alter the object but cannot refer to the variable at all. { int [] x = { 1 }; f(x); // f may have altered the array // but it is still the same array: f had no access to the variable } > The use of references in languages that don't have pointer > arithmetic has been around forever (forget Pascal, that's a newbie > in this area!). Yes. Lisp goes back to 1960 and has always been that way. > Pointer talk is needed only to explain how this is implented. > [quoted text clipped - 3 lines] >> StringBuffer myBuf = new StringBuffer(); >> x = myBuf; That was Patricia's point, save for the "only", right? > The confusing part is that there are two different variables with the > same name. Pointer talk is not less confusing: myBuf and myBuf point > to different objects; the values of myBuf and myBuf point to different > objects; the pointers that are the values of myBuf and myBuf point to > different objects; nothing helps but keeping myBuf-of-main separate > from myBuf-of-myMethod, and that is not a pointer issue. All your verbiage with the pattern "... point to ..." seems to explain things quite clearly. -- Lew > 3. Pointers without arithmetic existed in at least one published > language definition, the Pascal Report, when C was still being developed. Even earlier, in PL/I. SignatureJohn W. Kennedy "Never try to take over the international economy based on a radical feminist agenda if you're not sure your leader isn't a transvestite." -- David Misch: "She-Spies", "While You Were Out" * TagZilla 0.066 * http://tagzilla.mozdev.org > > 3. Pointers without arithmetic existed in at least one published > > language definition, the Pascal Report, when C was still being developed. > > Even earlier, in PL/I. Even earlier, in IPL and LISP. but I have three contemporary (i.e., pre-1970) references[1] that claim that the concept of explicit list processing originated with Newell, Shaw, and Simon in a 1956 paper (with first implementation as IPL-II in 1957), where the concept of a pointer was known as a link. (There is a an article on IPL at http://en.wikipedia.org/wiki/Information_Processing_Language .) Clearly, the concept was well established with the implementation of LISP in 1960. And the use of the term pointer was emerging at least as early as 1964, probably earlier than that. The addition of pointers to PL/I seems to have occurred in 1967 with the introduction of based storage. To address some of the other issues that have arisen in this thread, the concept of pointer was also extant in BCPL vectors[2] as of 1967[3]. So, both Thompson and Ritchie would have had exposure to both PL/I and BCPL as part of their work on Multics in the 1960s. I do not happen to know of an earlier language that provided arithmetic operations on pointers as implemented in C. BCPL's notion that an lvalue locates a storage element rather than just a hardware address in clearly a step in that direction. - dmw [1] Saul Rosen, 1967; Kramer, Kosinski, and Robinson, 1967; Jean Sammet, 1969. [2] BCPL's 'let x = v*[i]' is analogous to C's 'x = p[i]' [3] Martin Richards, MIT Project MAC M-352, 1967. Signature. Douglas Wells . Connection Technologies . . Internet: -sp9804- -at - contek.com- . > Chris Dollin wrote : > [quoted text clipped - 3 lines] > > Explain please. Since any Java object can contain a reference to another object, a pointer may pointer to (an object containing) a pointer. > Object a = new Object(); > Object b = a; > a = null; > > b still holds a reference to the new Object. In C/C++ with pointer to > pointer referencing, b would point to nothing. Yes, it's true that Java is not C or C++. >> Java doesn't expose /C-style/ pointers to the programmer. Neither >> do Wirth's Pascal nor Algol 68 nor Lisp. That doesn't make its [quoted text clipped - 3 lines] > arguing), you cannot manipulate that reference. Other than re-asigning > it. Whereas in C/C++ move it through an array using pointer arithmetic. Yes, it's true that Java pointers and C or C++ pointers each have operations the other doesn't. They both, however, have the characteristic that makes them pointers - they point to things, and several different pointer variables may point to the same thing. The pointers are exposed to the programmer. They just don't have the API you seem to want. SignatureChris Dollin RIP John "BNF, Fortran, FP" Backus 3Dec1924 - 17Mar2007 Chris Dollin wrote : >> Chris Dollin wrote : >> [quoted text clipped - 7 lines] > object, a pointer may pointer to (an object containing) a > pointer. That is not a pointer pointing to a pointer. That is a pointer to an object, which just happens to contain other pointers. A pointer to a pointer in C would look like: **ptr; Where the first level point to a pointer, and the second level points to an object. Java does not have this. > The pointers are exposed to the programmer. They just don't > have the API you seem to want. Not me. I am quite happy without pointers. SignatureWojtek :-) > Chris Dollin wrote : >> Since any Java object can contain a reference to another object, a >> pointer may pointer to (an object containing) a >> pointer. > > That is not a pointer pointing to a pointer. That is a pointer to an > object, which just happens to contain other pointers. Just repeating sense of one unanswered question from this thread, what's the difference? > A pointer to a pointer in C would look like: > > **ptr; > > Where the first level point to a pointer, and the second level points to > an object. Java does not have this. Really? Pointers are low-level objects. Objects pointed by pointer objects, might be other pointers, or different objects. Technically there is no significant difference between them. The same happens in Java when one object points to another object holding reference to it. One important difference between "pointers" in Java, and C (or C++) is in management over all "pointers" in Java performed by JVM -- which cost a bit, of course -- but thanks to that, there is no possibility to point something which is not an object or nothing (null), that's all. >> The pointers are exposed to the programmer. They just don't >> have the API you seem to want. > > Not me. I am quite happy without pointers. You are probably happy with different syntax for using pointers, management of them for you, and restricted available set of operations available on them -- just like in Java -- aren't you? Without pointers you have to decide to use Java build-in primitive types only, quite sad perspective IMHO... ;) piotr Piotr Kobzda wrote : >> Chris Dollin wrote : > [quoted text clipped - 21 lines] > The same happens in Java when one object points to another object holding > reference to it. Because with a pointer to a pointer, both "point" to the SAME object, albet with one level of separation. But a pointer to an object which contains a pointer to another object, there is different object, not the same object. That is a BIG difference. Otherwise you could say that with a HashMap, the reference to that HashMap "points" to potentially 100's of objects. It does not. It refers to one object which just happens to have references to other objects. > One important difference between "pointers" in Java, and C (or C++) is in > management over all "pointers" in Java performed by JVM -- which cost a bit, [quoted text clipped - 9 lines] > of them for you, and restricted available set of operations available on them > -- just like in Java -- aren't you? I programmed in C for over a decade. I am very comfortable with pointers, structs and unions containing pointers, pointers to pointers (to pointers), passing around pointers to functions, etc. Levels of indirection do not bother me at all. Moving to Java was a bit of a learning curve (no, not the OO part) since I did not have some of the language capabilities of C. But overall I prefer Java, for a number of reasons. > Without pointers you have to decide to use Java build-in primitive types > only, quite sad perspective IMHO... ;) What? I can design my own types (classes) and use them. I then have references to those instantiated classes (objects). That is not using primitives only. SignatureWojtek :-) >Chris Dollin wrote : >>> There are no pointers to pointers. >> >> That's sort-of true. > >Explain please. The most obvious case in the API is when you have a pointer to a SoftReference, which itself is little more than a glorified pointer to yet another object. > I can set a reference to an object. I cannot set a >reference to a reference. You can set a reference to a wrapped reference though. Why is the difference significant? Cheers Bent D SignatureBent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd powered by emacs ... >> I can set a reference to an object. I cannot set a >> reference to a reference. > > You can set a reference to a wrapped reference though. Why is the > difference significant? I think it may be a reflection of the view that C pointers are the ultimate definition of what a pointer should be. C pointers can point to pointers, without them being wrapped in a struct or array. Java references cannot point to other unwrapped Java references, so Java pointers are not C pointers. It goes along with the argument that Java references are not really pointers because Java does not support pointer arithmetic. Here's a question for people holding that view: Why should the particular, and arguably peculiar, cluster of features that C associated with pointers be the ultimate definition of pointerness? Patricia >C pointers can point to pointers, without them being wrapped in a struct >or array. In C, a compound statement might be: { int * a = 0; int * b = &a; } Therein, b points to a, without a being wrapped in a struct or an array. >Here's a question for people holding that view: Why should the >particular, and arguably peculiar, cluster of features that C >associated with pointers be the ultimate definition of >pointerness? These people might say »Because C was there first«, or C (A, B, BCPL) people (Dennis Ritchie) /coined/ it: »This was Dennis's contribution, and he in fact coined the term "pointer" as an innocuous sounding name for a truly malevolent construct.« http://www.elsop.com/wrc/humor/unixhoax.htm http://google.to/search?q=%22coined+the+term+pointer%22&filter=0 However, since this source is filed under »humor«, I'm not sure, whether this part is true. At least one can confirm early usage: http://cm.bell-labs.com/cm/cs/who/dmr/chist.html http://cm.bell-labs.com/cm/cs/who/dmr/hist.html »Finally, the B and BCPL model implied overhead in dealing with pointers: the language rules, by defining a pointer as an index in an array of words, forced pointers to be represented as word indices. Each pointer reference generated a run-time scale conversion from the pointer to the byte address expected by the hardware.« http://www.lysator.liu.se/c/chistory.ps »B and BCPL had notions of pointers, which were names of storage cells, but on a byte oriented machine in particular and also one in which the -- had 16-bit words and -- I don't think it did originally, but they were clearly intending to have 32-bit and 64-bit floating point numbers. So that there all these different sizes of objects, and B and BCPL were really only oriented toward a single size of object. From a linguistic point of view that was the biggest limitation of B; not only the fact that all objects were the same size but also that just the whole notion of pointer to object didn't fit well with« http://www.princeton.edu/~mike/expotape.htm To show that they /coined/ it, still would need to show that no one else already used it for this purpose in those days. > In C, a compound statement might be: > > { int * a = 0; int * b = &a; } Shouldn't that be "int ** b = &a;"? Either way, it's an example of Patricia's point that C pointers to pointers need not be wrapped in a struct or array. -- Lew Supersedes to remove a part regarding pointees not being wrapped in a struct or an array. Supersedes: <pointer-20070321134133@ram.dialup.fu-berlin.de> >Here's a question for people holding that view: Why should the >particular, and arguably peculiar, cluster of features that C >associated with pointers be the ultimate definition of >pointerness? These people might say »Because C was there first«, or C (A, B, BCPL) people (Dennis Ritchie) /coined/ it: »This was Dennis's contribution, and he in fact coined the term "pointer" as an innocuous sounding name for a truly malevolent construct.« http://www.elsop.com/wrc/humor/unixhoax.htm http://google.to/search?q=%22coined+the+term+pointer%22&filter=0 However, since this source is filed under »humor«, I'm not sure, whether this part is true. At least one can confirm early usage: http://cm.bell-labs.com/cm/cs/who/dmr/chist.html http://cm.bell-labs.com/cm/cs/who/dmr/hist.html »Finally, the B and BCPL model implied overhead in dealing with pointers: the language rules, by defining a pointer as an index in an array of words, forced pointers to be represented as word indices. Each pointer reference generated a run-time scale conversion from the pointer to the byte address expected by the hardware.« http://www.lysator.liu.se/c/chistory.ps »B and BCPL had notions of pointers, which were names of storage cells, but on a byte oriented machine in particular and also one in which the -- had 16- |
Enable EMail Alerts
Start New Thread
Reply to this Message