On Tue, 2006-06-13 at 09:13 -0600, Bryan Sant wrote: > On 6/12/06, Michael L Torrie <[EMAIL PROTECTED]> wrote: > >Methinks Java's implicit pass by reference, and > > apparent lack of statically allocated objects, has poisoned a lot of > > programmers thinking. > > What? No mention of C# or a zillion other 4GL that do the same thing > :-)? When moving back and forth between Java and C++ this is an > oddity. Or if you learned to program in Java, but are writing > something in C++, you'll expect things to work differently (wrongly > from a C++ programmers perspective). I agree that this can get > naughty. > > But just to clear things up. Java doesn't pass by reference > implicitly. It ALWAYS passes by value. So when you pass any > primitive value, it works just like you would expect in C/C++ -- it > makes a copy of the var passed into a function (be it a byte, char, > short, int, double, etc.). However, when you pass an object REFERENCE > into a function, it happily copies the reference (4-byte pointer on a > 32-bit arch) and does not make a wasteful memory copy of object data + > vtable pointers. And since the Java heap + garbage collector works > essentially like a stack, you always get the benefit of a stack even > when allocating on the "heap". It's not quite that simple, there's a > lot of multi-generational GC magic, but it's typically that > efficient. Anyway, when dealing with all but the most trivial > objects/structs in C/C++ you typically pass those objects around by > reference or pointer anyway. So the approach in Java and C++ really > isn't that different after all.
I don't know enough Java to really comment. All I do know is that Java pattern of always doing instance = new ClassName(blah); Really messes up C++ programmers in CS 240. So much that they have huge memory leaks and pointer corruption. Most of which would be avoided by allocating the objects on the stack (a static allocation, but one that is automatically destroyed when it goes out of scope). On the other hand, C++ programmers generally do not have the same kinds of problems going to Java. Somehow I guess the mindset is more transferable one way than the other. > > BTW if you really want a copy of an object, you can use a copy > constructor, or implement the clone() method. > > As far as statically allocated objects, Java does have theses: > > public static String bob = "What do you get when you spell bob backwards?"; > > There you go. A static object -- allocated at startup and never again. I'm not quite using my terms right. As you say, a static thing is generally something that is allocated once and only once. I'm talking about something different. In C++ you can allocate objects in a non- dynamic fashion (ie "ClassName instance(blah)") and it is allocated on the stack, not the heap, and has a strictly controlled lifetime. Because of this the likelihood of a leak is much reduced. How do you statically allocate on the stack a more complicated object that requires several parameters in the constructor? Michael > > -Bryan > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
