• Post Reply Bookmark Topic Watch Topic
  • New Topic

Pass-by-reference  RSS feed

 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not trying to belabor this, but some things I've read are just plain wrong. I've read java passes everything by value. So if you have a big old 3.5 megabyte picture in memory, java passes that by value. Wrong. It passes the starting address of the 3.5 magabyte picture. It doesn't copy the 3.5 megabytes - I know because it works too fast for that to be possible. I've read documentation that says its a separate copy. Thats wrong. Its not a separate copy. You have a copy of the the remote control, the address, the pointer - whatever you want to call it but java did not pass 3.5 megabytes by value. It didn't happen.

And that's a very important consideration when writing a program, because I believed the documentation, and was very nervous about passing large objects to methods. But no, the objects aren't separate copies.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:On a register level, they work exactly the same. Is there a technology on the horizon where computers are going to be register free? That's the part I was criticizing, like it somehow looks different than any other language when its spit out into assembly.

Now that I'd like to see. The only "assembler" that you're likely to see in Java is the output of the javap command, and it's called p-code. And although I'm no expert on it (mainly because, after 14 years, I can still count the number of times I've needed to look at it on one hand), I can tell you that you won't see a single register.

The fact is that the only people who need to know about how Java programs work on a particular machine or platform are the geeks that write JVMs for us - and once you get used to that fact it's very liberating: No pointers, no char*'s, no mallocs or frees, no needing to know what objects "look like" in memory or how "big" they are. You create objects; you use 'em; you let 'em go out of scope - it's as simple as that (well, 98% of the time it is).

I came from the C world as well, and it took me quite a while to make the jump, but now I'd sooner have my eyeballs lanced with hot pokers than go back to all that byte and pointer and memory twiddling,

Maybe in time you'll feel the same...or maybe not...but give it a chance.

Winston
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:Well what do you think they are? How do you suppose the CPU finds the data without using an address register?

Don't care; haven''t needed to in 14 years; and hope I never do. It's simply not relevant to a Java programmer.

The only thing I need to know is that a reference points to (and, for most purposes, IS) an object. How it does it? Simply not important.

Winston
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:Wrong. It passes the starting address of the 3.5 magabyte picture.

Wrong. It passes the reference to that picture, and you have no idea what that is, because you have no idea how that object is mapped in memory. You might guess, but that fact is that you don't need to - and it might change in the next release of Java, or indeed on a machine with different architecture.

And that's a very important consideration when writing a program, because I believed the documentation, and was very nervous about passing large objects to methods. But no, the objects aren't separate copies.

And that's because you're bringing C terminology to the Java table.

In Java, you NEVER get to access an object directly; you access them via variables, and those variables are references. So it stands to reason that when you call myMethod(myObject) the compiler is going to pass a copy of the reference, since that's the only thing you ever use.

HIH

Winston
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It passes the reference to that picture, and you have no idea what that is, because you have no idea how that object is mapped in memory.


You don't care how it comes and yet you scoff that I know how it comes. Well it doesn't come by telegraph. The CPU pushes a memory address (A POINTER) into an address register and that's how the data is accessed. Is not mystical. It been the same flow for 40 years.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An NO double NO NO a reference isn't an object. Its an address of an object. No amount of philosophy is going to change that fact.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


You say you work in C? You've never heard of a register variable? What do you think that is? In C you can work directly with resisters an also incorporate straight assembly code.
 
Paul Clapham
Sheriff
Posts: 22835
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:A reference isn't an object. Its an address of an object. No amount of philosophy is going to change that fact.


Abstractly speaking a reference is an "address" of an object. But it may or may not be implemented as a 32-bit (or 64-bit) quantity which contains the actual memory address of the object; it may be more complicated than that, for example to support garbage collection. It's entirely up the writers of the JVM to make that decision. But yes, from the abstract point of view a reference is an address.

Hopefully you don't consider an abstraction to be "philosophy". It's a very important tool in the design of computer languages and demanding to know how things actually work inside the abstraction is not especially useful when trying to understand modern computer languages.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:
Shawn Lau wrote:A reference isn't an object. Its an address of an object. No amount of philosophy is going to change that fact.


Abstractly speaking a reference is an "address" of an object. But it may or may not be implemented as a 32-bit (or 64-bit) quantity which contains the actual memory address of the object; it may be more complicated than that, for example to support garbage collection. It's entirely up the writers of the JVM to make that decision. But yes, from the abstract point of view a reference is an address.

Hopefully you don't consider an abstraction to be "philosophy". It's a very important tool in the design of computer languages and demanding to know how things actually work inside the abstraction is not especially useful when trying to understand modern computer languages.


It might be in a table, but its an address and its wrong to give the impression a copy of the object is being passed to a function - er METHOD( pass by value, i.e. pass a copy of the data) when it doing the same thing that happens when you pass a pointer in C or a reference in C++. What happens on the assembly level is exactly the same. It pushing an address and fetching the data from that address. Its NOT making a copy of the data. Whether the address comes from an array or a table or is big endian or little endian, 16 bit,32,bit 64bit, its the same flow.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:You don't care how it comes and yet you scoff that I know how it comes. Well it doesn't come by telegraph. The CPU pushes a memory address (A POINTER) into an address register and that's how the data is accessed. Is not mystical. It been the same flow for 40 years.

About as long as I've been programming then.

What I'm saying is that in Java you simply don't know what an object looks like in memory (and if you don't believe me, check the JVM spec), and you don't need to know. Furthermore, you have no control over how or where the JVM maps objects, so even if you did know, it wouldn't do you any good - unless you were planning on writing a garbage collector, in which case you probably wouldn't be using Java anyway.

These things simply aren't important to a Java programmer, and are actually a distraction in most cases; so if that's what rocks your boat then I doubt that Java is the language for you. But if you can let go of that micro-managing side of things, you'll discover that there's an awful lot of stuff that you can do much more easily than in C.

However, it doesn't appear that I'm going to convince you, so I wish you luck trying to converse with Java bods in C-speak. It does strike me as the equivalent of insisting on using feet and inches when everybody else has gone metric though.

Winston
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:An NO double NO NO a reference isn't an object. Its an address of an object. No amount of philosophy is going to change that fact.

But in Java, the only thing you have is a reference. There is no myObject and &myObject (not to mention *myObject), there is ONLY myObject and it is a reference. So syntactically references and objects are basically the same thing, since you never get to see the latter directly.

Winston
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To be more specific, when it follows a period it matches anything that follows - like load("mypic.*"); That's just the common use of the wild card and to use it differently is eccentric.


The only thing where .* would match everything would be a regular expression, because the '.' means a single character and the '*' means 0 or more times. But wildcards are used in many more places than just regular expressions, so don't assume that every use will behave exactly like a regular expression.

I have no idea what the load method you quoted is, or whether or not its a real thing or just an example you made up. However if it is loading files from a file system I definitely would not expect '.*' to behave like a regular expression.

Similarly, if I was on Linux and typed

I would expect to get a directory listing of the /etc/init.d/ directory. I would not expect the '.' to represent any character because it isn't a regular expression, and I would not expect to get a listing of all sub directories of init .d because the * does not traverse sub directories.

 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You've never heard of a register variable? What do you think that is


You cannot work directly with registers in Java. The JVM has no registers, and uses a stack based architecture. How this gets translated into machine code is not strictly defined, but it isn't required that it must run on a register based chip.

How we got here from a question about import though I have no idea!
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not trying to belabor this, but some things I've read are just plain wrong. I've read java passes everything by value. So if you have a big old 3.5 megabyte picture in memory, java passes that by value. Wrong. It passes the starting address of the 3.5 magabyte picture.


Java passes everything by value. There is no getting around that fact.

But Java is also not C++.



That creates a MyType object and passes it to myFunc by value. But that code has absolutely no correlation in Java.

In Java objects are not values that can be placed on the stack. Objects cannot be 'passed' at all. Variables only ever hold references to objects. The references are copied when you pass them to a method.

That is why



does not affect the calling site of the method.

Call them pointers if you wish, but realise that they will not behave like a C++ pointer. They also will not behave like a C++ reference.
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:. . . Whats the practical difference between a method and a function? Reference - pointer? Any difference? . . .
A reference may hide a handle rather than a pointer. A pointer must point to the exact memory address. You use direct indexing for one and you use indirect indexing for the other. And that is not a philosophical statement. The fact that Java® fortunately hides all those details from you doesn't mean they don't exist.

I think a lot of this has been said already. I also think this discussion is no longer suitable for the “beginning” forum and I shall move it.
 
Stephan van Hulst
Saloon Keeper
Posts: 7992
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The point is that even if some day somebody finds a way to make genies do our bidding, and give them the task to magically dereference the reference without the use of pointers, it would make absolutely no difference to how you write Java code, because Java references work the same, regardless of how they are implemented. In C, you wouldn't be able to do the same, because pointers *are* memory addresses.

It's like saying if-statements are really JZ instructions, because they are implemented that way. It's not philosophical; an abstraction is a useful tool that helps us be productive instead of worrying whether the code runs on x86 or a crystal ball.
 
salvin francis
Bartender
Posts: 1663
37
Eclipse IDE Google Web Toolkit Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn, I would admit, around 9 years ago, when i was very enthusiastic about C programming, I hated java. I hated Oops. Now I love it
 
Campbell Ritchie
Marshal
Posts: 56570
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That might be because of the difficulty many people have moving from procedural programming to thinking in object.
 
Stephan van Hulst
Saloon Keeper
Posts: 7992
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The first time I learned about constructors, in Turbo Pascal, I remember thinking "What the heck do I need these for, if I can do the same with procedures?"

I'm ashamed that it only clicked when I learned Java at Uni, even after working with Delphi for a good year.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Java passes everything by value. There is no getting around that fact. "


I'm embarrassed by how steadfast I was in this thread. I should not post after a few beers. But this just isn't true. I'm working with very big graphics objects in java, and its physically impossible they are being passed by value.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:That might be because of the difficulty many people have moving from procedural programming to thinking in object.
It is difficult.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:
Shawn Lau wrote:. . . Whats the practical difference between a method and a function? Reference - pointer? Any difference? . . .
A reference may hide a handle rather than a pointer. A pointer must point to the exact memory address. You use direct indexing for one and you use indirect indexing for the other. And that is not a philosophical statement. The fact that Java® fortunately hides all those details from you doesn't mean they don't exist.

I think a lot of this has been said already. I also think this discussion is no longer suitable for the “beginning” forum and I shall move it.


I agree, I went off on a tangent and I apologize. This is a valuable resource and I have no intention or creating a disruption.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm embarrassed by how steadfast I was in this thread. I should not post after a few beers. But this just isn't true. I'm working with very big graphics objects in java, and its physically impossible they are being passed by value.


I understand exactly why you think that. But the truth is that objects cannot be values in java. By this I mean that objects cannot be stored in variables in Java.

This is fundamentally different to c++ where objects are values and can be stored in variables. When you pass those variables as parameters then the object is passed by value and copied.

That cannot happen in Java. A variable in Java holds the value of a Java reference (which is most similar to a c++ pointer, not a c++ reference). When you pass that reference the value in the reference is copied into the parameter.

If Java was not pass-by-value it would be possible to assign a new object to a parameter and expect the calling site of the method to see the new object. This is possible in c++ because it let's you pick whether to use pass-by-value or not.

This will become more important when Java introduces value types in one of the upcoming releases. This will let objects be values, stored directly in variables. Java will still be pass-by-value, so these objects will be copied when you pass them.

I think this was all explained better in my previous post with the code example, but I'm on my phone at the minute so posting code is not so easy.
 
Stephan van Hulst
Saloon Keeper
Posts: 7992
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following two are roughly equivalent, if we ignore memory leaks.

Java:

C++:

In both cases, after calling foo(), the variable baz will still be null, because it's passed by value. The variable bar contains a copy of the value. In both cases, the value is a memory address (although in Java it can be a magical lamp).

In C++, you can also pass by reference:

In C++, you can also pass an object by value:


The last two code snippets have no equivalent in Java, because Java always passes references by value. You can not pass anything by reference, and modify the call site variable. You also cannot pass an object by value, because Java has no direct access to objects. All reference type variables hold references, not objects.

Don't be confused by the usage of the word 'reference'. In C++, 'reference' means an alias for a variable. In Java, 'reference' means a handle to an object. It would have been more clear if instead of calling it "pass-by-reference", they had called it "pass-alias".
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(although in Java it can be a magical lamp).


Or a television remote!
 
Stephan van Hulst
Saloon Keeper
Posts: 7992
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn, I hope this has made it clear why we say Java passes everything by value? The thing is that the only values Java can pass are primitives and references. Passing an object by reference is different from passing a reference by value, as I've tried to explain with my examples.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:Shawn, I hope this has made it clear why we say Java passes everything by value? The thing is that the only values Java can pass are primitives and references. Passing an object by reference is different from passing a reference by value, as I've tried to explain with my examples.


For me it was confusing, and I think its misstated. When something is passed by value, a copy is passed. Saying its passed by value because a copy of its location is passed, is a loop hole. If I pass something to a method by value, that method should not change the variable I passed whether the variable is an integer or an object. The fact that it does shows it is not passed by value, but its location is passed by value. That's very thin ice to claim everything is passed by value. With that loop hole, any language could make that claim. The problem with misstating what is really happening, is it has you changing the way you design things because you take it at its word that is going to be copying your giant object, and that would be a performance issue. But the fact is it doesn't copy the giant object. It just claims it does. It copies the giant objects address or location which is exactly what C does.


And to further clarify, Java DOES pass thing like integers and strings by value. It DOESN'T pass objects by value, and I know a String is an object so there is some sort of voodoo going on behind the scenes. But it really doesn't pass everything by value if passing by value means making a unique copy of the data, nota copy of its address.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a rough example:

int a = 10;

doStufftoInt( a);

System.out.println(a) and it print 10 no matter what dostuff() did.

Oh but if

BufferedImage bi; // bi is null

myLoadImage(bi) // bi now contains an image.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Here's a better way to describe it, but I have to do it on an assembly level. When you declare local variables, they go into memory area of ram called the stack. In my day, the size of the stack was pretty small and you could actually set the size of the stack in your compiler. But if you exceeded it, say by trying to initialize a 32kb array when your stack was only 16kb, you 'd get a stack overflow ( the beginnings of a web site) error. Passing a variable by value works like this.

a = 10;

An address in the stack area of ram holds that value of ten.

dosomething(a);

The value of a - in this case 10, is put into a data register and a function ( er method) is called. There is no more connection with that stack area that put the 10 into the data register. That's why the local variable a can't be changed. There is no connection to it after the value is put into the data register. It was passed by value. Its just a value in a data register that will be lost when the function ends. The data register has no idea where it got it. But when you pass something by reference or pointer, you don't copy something into a data register, but you copy the location of the data into an address register. In this case, the data survives AFTER the function. Its in ram, not in a data register. It might be on the stack, but it might be somewhere else- like a global or some other functions stack. It can be changed by the the method it is used in, because it is not in a data register, but in ram. The changes are pushed into ram and are permanent changes, not function life changes.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Firstly, I think this discussion has completely diverged from import statements now so we probably should take this discussion to a new thread.

However, now to address the points you've made.



Shawn Lau wrote:For me it was confusing, and I think its misstated. When something is passed by value, a copy is passed. Saying its passed by value because a copy of its location is passed, is a loop hole.


It isn't a loop hole. You really need to understand how Java works (and not compare it to other languages, that work fundamentally differently). Java does not work like C++. In C++ objects are values unless you specify otherwise. In Java objects are never values (true at the time of writing). It is not possible for an object to be a value. In this context, a value is something that is stored in a variable. In C++ objects can be stored in variables. When you pass that variable to a method using pass-by-value semantics then the entire object is copied into the parameter. Java does not work this way.

In java all variables hold either primitive values, or reference values. The use of the term reference in Java is completely and fundamentally unrelated to the use of the word reference in C++, and is much more closely related to the concept of pointers in C++ as both Stehpan and I mentioned in earlier posts. When you call a method, either the primitive variable or the reference variable are passed by value into the method. This means that the method cannot alter the contents of the variable. There is just no way in Java to write a method that alters the contents of the variable that was passed to it by manipulating the parameter that is was passed into.

To understand the last point I made above you need to understand that variables are not objects. They are references to objects. Changing the contents of the object is not the same as changing the contents of the variable that was passed into the method.

Shawn Lau wrote:If I pass something to a method by value, that method should not change the variable I passed whether the variable is an integer or an object. The fact that it does shows it is not passed by value, but its location is passed by value.


This sentence shows you do not yet understand that sentence I wrote above. In Java, variables are not objects. When you pass a reference variable to a method that method cannot change the variable that was passed in to the method. Changing the object is not the same thing as changing the variable. It may seem like I'm splitting hairs, but I really am not. It is an important distinction to make.

Shawn Lau wrote:That's very thin ice to claim everything is passed by value. With that loop hole, any language could make that claim. The problem with misstating what is really happening, is it has you changing the way you design things because you take it at its word that is going to be copying your giant object, and that would be a performance issue. But the fact is it doesn't copy the giant object. It just claims it does. It copies the giant objects address or location which is exactly what C does.


Java never claimed it would copy your object, it claimed it would copy your variable. You cannot directly pass objects to a method in Java, you can only pass reference variables. Reference variables are copied by value. Objects cannot be values (yet).


And to further clarify, Java DOES pass thing like integers and strings by value. It DOESN'T pass objects by value, and I know a String is an object so there is some sort of voodoo going on behind the scenes. But it really doesn't pass everything by value if passing by value means making a unique copy of the data, nota copy of its address.

 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:Here's a rough example:

int a = 10;

doStufftoInt( a);

System.out.println(a) and it print 10 no matter what dostuff() did.

Oh but if

BufferedImage bi; // bi is null

myLoadImage(bi) // bi now contains an image.


And this is the misunderstanding that arises when you fail to understand that variables are not objects, and when you fail to believe that variables are always passed by value.

I would like you to write an implementation of myLoadImage(...) such that the local variable bi is updated.

In Java it is not possible to write such a method (because bi is passed by value), but until you see that for yourself I'm not sure you're going to believe me.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:Here's a better way to describe it, but I have to do it on an assembly level.


You can't describe Java at an assembly level. Java is an abstraction on top of the machine it is running on, and there is no single assembly implementation that describes how Java works. You can write any number of different JVM's that all work differently at assembler level, but if they follow the Java Language Specification they are still Java.

Shawn Lau wrote:Passing a variable by value works like this.

a = 10;

An address in the stack area of ram holds that value of ten.

dosomething(a);

The value of a - in this case 10, is put into a data register and a function ( er method) is called. There is no more connection with that stack area that put the 10 into the data register. That's why the local variable a can't be changed. There is no connection to it after the value is put into the data register. It was passed by value. Its just a value in a data register that will be lost when the function ends. The data register has no idea where it got it. But when you pass something by reference or pointer, you don't copy something into a data register, but you copy the location of the data into an address register. In this case, the data survives AFTER the function. Its in ram, not in a data register. It might be on the stack, but it might be somewhere else- like a global or some other functions stack. It can be changed by the the method it is used in, because it is not in a data register, but in ram. The changes are pushed into ram and are permanent changes, not function life changes.


You are missing out a whole level of abstraction here. Passing something by-value does not mean the value goes directly onto a register and passing something by-reference does not mean that a memory-address goes directly onto a register. If you have an object in C++ that is 1MB in size (for example because it holds an array that is 1MB in size) you can still pass that object by-value, but it certainly is not being placed directly onto a register since registers aren't big enough to hold 1MB of data. You really can't go down to the processor level when talking about Java though, since Java will behave in exactly the same way no matter what processor it runs on. You can run Java on a processor that uses stacks instead of registers and it will still behave the same way. Nothing in the Java language specification details how Java behaves on the processor, so Java is free to change its implementation at that level at will.

I'll write an example from C++ and Java that shows that Java is pass-by-value and cannot do what C++ does when it uses pass-by-reference:



 
Dave Tolls
Ranch Foreman
Posts: 3065
37
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Every time I see this discussion I think "surely this is the last time", but it seems to reappear every few years.
I've been living in hope for over 15 years.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You'd miss it if it was gone ;)
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave Tolls wrote:Every time I see this discussion I think "surely this is the last time", but it seems to reappear every few years.
I've been living in hope for over 15 years.


And why do you think that is? Something isn't being presented quite right or people who have been programming for decades on very low levels don't understand the difference between passing by value and passing a memory location?
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
but it certainly is not being placed directly onto a register since registers aren't big enough to hold 1MB of data


no. its placed onto the stack and its memory location on the stack is sent to the function. If as in the old days, you had 32 kilobyte stack, trying to initialize a 1mb array would gain you a stack overflow error. So now, lets say you have an unlimited or gigabyte stacks. When a function is done, the stack ( for that function) is GONE. Its not a permanent thing, it lasts as long as the function.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:
Dave Tolls wrote:Every time I see this discussion I think "surely this is the last time", but it seems to reappear every few years.
I've been living in hope for over 15 years.


And why do you think that is? Something isn't being presented quite right or people who have been programming for decades on very low levels don't understand the difference between passing by value and passing a memory location?


I think I understand your misunderstanding now. It is not a choice between pass-by-value and pass-by-memory-location, it is a choice between pass-by-value and pass-by-reference. Pointers are simply values. They can be passed-by-value or passed-by-reference if the language supports those semantics.

And this dichotomy applies to C++, not to C. To the best of my knowledge C does not have references and everything is passed by value. You can pass pointers by value, or you can pass
values by value. But you can't pass anything by reference.
 
Mike. J. Thompson
Bartender
Posts: 689
17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Shawn Lau wrote:
but it certainly is not being placed directly onto a register since registers aren't big enough to hold 1MB of data


no. its placed onto the stack and its memory location on the stack is sent to the function. If as in the old days, you had 32 kilobyte stack, trying to initialize a 1mb array would gain you a stack overflow error. So now, lets say you have an unlimited or gigabyte stacks. When a function is done, the stack ( for that function) is GONE. Its not a permanent thing, it lasts as long as the function.


You have latched on to the least important part of what I said. I was only trying to show that pass-by-value and pass-by-reference semantics have nothing to do with where things are placed in registers.

However I think this debate will be best solved by asking you to do one thing, basesd on your code snippet from before.



This is based on your example above. I have fleshed it out but the names and calling semantics remain the same.

Your challenge is to implement the method myLoadImage such that the main method does not end in a NullPointerException. You cannot change the code anywhere else. You cannot use a return from the method, and you cannot make the local variable a class field. I'm also ruling out anything to do with JNI or anything from the unsafe packages since they are nothing to do with the method calling semantics.
 
Shawn Lau
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can I do it in processing?

 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!