nielsm posted:

"C++ doesn't need garbage collection, because it doesn't produce garbage."

Brecht posted:

You appear to have a fundamental misunderstanding of type systems, and/or a crippling lack of specificity in your language. There is no "terminology system" in which "An object is a classifying description of a variable" is true as a general statement.

quote:

There are two kinds of types in the Java programming language: primitive types and reference types. There are, correspondingly, two kinds of data values that can be stored in variables, passed as arguments, returned by methods, and operated on: primitive values and reference values.

Vanadium posted:

This whole discussion would be moot if more people realised that when you say Object variable; in C# you're saying Object^ variable; in C++/CLI which is fundamentally different.

Internet Janitor posted:

Cloneable is fundamentally a problem because Object.clone() Doesn't specify deep or shallow copy semantics.

edit: No, we are not having a "mutable state is a horror" rant.

Eggnogium posted:

Here's a horror: Scrolling past your avatar in IE9 slows the browser down to a crawl.

nielsm posted:

But apparently C# Struct var; is equivalent to something like:
char buffer[sizeof(Struct)];
Struct &var = *(Struct*)(void*)buffer;

baquerd posted:

In Java there are objects and there are primitives. I've been with Java since 1997 and the terminology did not start out as ambiguous though recent revisions have practically made everything a bit muddled. I don't see what's so hard to understand why you can have object types and non-object types, from booleans to doubles to... (ok it's not a long list) but anything out there that does not support methods or member variables can be thought of as a non-object, then there are objects, then there are structs which are a sort of specialized object in Java...

edit (from Sun):


What they are calling reference values are of course, references to objects.

nielsm posted:

But apparently C# Struct var; is equivalent to something like:
char buffer[sizeof(Struct)];
Struct &var = *(Struct*)(void*)buffer;

1337JiveTurkey posted:

That's the same as how it works in C except it's impossible to make a reference or pointer to a struct.

nielsm posted:

But apparently C# Struct var; is equivalent to something like:
char buffer[sizeof(Struct)];
Struct &var = *(Struct*)(void*)buffer;

baquerd posted:

Vanadium posted:

So the real horror here is that C++ gives you the option of defining a default constructor for on-the-stack, value, non-reference types? Cripes!

GrumpyDoctor posted:

What? You can totally make a pointer to a struct. (In C, yeah, no references, but you can't make references to anything in C because they don't exist.)

Jethro posted:

code:

[fixed]i[/fixed], [fixed]foo[/fixed], and [fixed]bar[/fixed] 
are [i]variables[/i]. Variables are not [i]objects[/i]. 
Variables have [i]values[/i].  
The value of [fixed]i[/fixed] is [fixed]1[/fixed].
The value of [fixed]foo[/fixed] is a [i]reference[/i] 
to an object with [i]type[/i] [fixed]Object[/fixed].
[fixed]foo[/fixed] is not the object that we created, 
it is a variable whose value is a reference to that object.  
[fixed]bar[/fixed] has no value, since it is uninitialized,
 but it can hold a value which is a reference to an 
object of type [fixed]Object[/fixed].  
It is not an uninitialized object, since it is not an object.  
If the next line of code was this [fixed]bar = foo;[/fixed],
 then both [fixed]foo[/fixed] and [fixed]bar[/fixed] would 
be variables that contain references to the same (unnamed) object created above.

Jethro posted:

bar has no value, since it is uninitialized, but it can hold a value which is a reference to an object of type Object.

baquerd posted:

Variables have names, types, and values.

quote:

An object (not Object in this usage) can be thought of as one potential "meta-type" of a variable, and a variable can therefore be an object in the colloquial tongue.

Toady posted:

bar doesn't hold a reference a stack-allocated Object?

Brecht posted:

Yes; not really (the type is a property of the thing the variable refers to, not the variable itself); and not really (same).

A variable refers to an object (in the weak sense of refers). A variable is not the object. It's not a trivial distinction.

Brecht posted:

A variable refers to an object (in the weak sense of refers). A variable is not the object. It's not an unimportant distinction.

Eggnogium posted:

In C# and Java, yes. And in C++ with pointers. But what about (C++):

code:

Bar bar;

That seems like a variable that is also an object.

Brecht posted:

code:

bar1 = bar2; // same variable different object

Brecht posted:

code:

Bar bar1("cake dogg");
Bar bar2("present cat");
bar1 = bar2; // same variable different object

baquerd posted:

No, by any sense of the world variable those are different. They only share a type.

1337JiveTurkey posted:

Object.clone() has the additional feature that it does return a new instance of the object being cloned but no constructor is ever actually called.

baquerd posted:

No, by any sense of the world variable those are different. They only share a type.

Eggnogium posted:

Oh. Wow, my college professors really failed at explaining C++.

Brecht posted:

Yes, exactly: bar1 is different than bar2. The point is that the variable bar1, as an entity, refers to two different objects, on line 1 vs. on line 3. The variable is therefore not the same as the object it refers to.

baquerd posted:

I see what you mean and your definition from that point of reference is valid. It is equally valid to say the variable is not the same because the value that is referenced by the variable has changed, it's inferred from the context which meaning is intended.

Brecht posted:

Brecht posted:

No, it is not equally valid, it is not valid at all to say that, this is not what the word or concept variable means and this exactly the point that many people are trying to make clear to you.

Brain Candy posted:

Object.clone() is basically just an alias for memcpy.http://ideone.com/LVj2Z

Brecht posted:

Well, I'm being a bit vague to illustrate my point. If you get into the details, line 3 invokes cake dogg's operator= (with present cat as the const Bar& parameter) and the behavior of that is totally up to the implementation of the Bar class. Assuming Bar is a struct (ie. class) type, by default it will do a shallow copy of all of present cat's members "into" the same memory that was allocated (on the stack) in line 1 to cake dogg. So by default they're "different object"s in the sense that [any sane] operator== would return false, but no new allocations would take place. Of course you can override any and all of that with a custom operator=.

Eggnogium posted:

Actually I take it back then. If the default behavior is to do a shallow copy then I think bar1 is the same object throughout that code. Changing a field in a mutable object does not make it a new object, that's dumb.

Brecht posted:

Yes, exactly: bar1 is different than bar2. The point is that the variable bar1, as an entity, refers to two different objects, on line 1 vs. on line 3. The variable is therefore not the same as the object it refers to.

baquerd posted:

So you are saying that the object reference must change in order to have a distinct object? What if we allow for the mutable object to contain a unique value as part of a programmatically enforced unique collection (set)? Each object is clearly distinct, does the memory location matter or is it not this unique identifier that "defines" the object?

Words can do the most interesting things...

Brecht posted:

No, it is not equally valid, it is not valid at all to say that, this is not what the word or concept variable means and this exactly the point that many people are trying to make clear to you.

Eggnogium posted:

Sure, that definition could be valid but mine more accurately represents the real-world analogy for objects. If I scratch out the VIN on my car and carve a new one that doesn't magically make it a "new" car.