why () is () and [] is [] work in other way?

[Adam Skutt]

On Apr 28, 7:26 am, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 4/27/2012 19:15, Adam Skutt wrote:
> > On Apr 27, 11:01 am, Kiuhnm<kiuhnm03.4t.yahoo.it>  wrote:
> >> The abstraction is this:
> >> - There are primitives and objects.
> >> - Primitives are not objects. The converse is also true.
> >> - Primitives can become objects (boxing).
> >> - Two primitives x and y are equal iff x == y.
> >> - Two objects x and y are equal iff x.equals(y).
> >> - Two objects are the same object iff x == y.
> >> - If x is a primitive, then y = x is a deep copy.
> >> - If x is an object, then y = x is a shallow copy.
> >> - ...
>
> > This is not an abstraction at all, but merely a poor explanation of
> > how things work in Java.  Your last statement is totally incorrect, as
> > no copying of the object occurs whatsoever.  The reference is merely
> > reseated to refer to the new object. If you're going to chide me for
> > ignoring the difference between the reference and the referent object,
> > then you shouldn't ignore it either, especially in the one case where
> > it actually matters!  If we try to extend this to other languages,
> > then it breaks down completely.
>
> With shallow copy I meant exactly that. I didn't think that my using the
> term with a more general meaning would cause such a reaction.

It has a very strict, well-defined meaning in these contexts,
especially in languages such as C++.

>
> So you're saying that I said that "Primitive constructs are references".
> Right...

No, still wrong.  What I said is correct, "References are a form of
primitive construct".  In C, an int is a primitive but not a
reference.  An int* is a pointer (reference), and is also
(essentially) a primitive.

>
> >  While true, it's still a bad way
> > to think about what's going on.  It breaks down once we add C++ /
> > Pascal reference types to the mix, for example.
>
> ?

Assignment to a C++ reference (T&) effects the underlying object, not
the reference itself.  A reference can never be reseated once it is
bound to an object.  Comparing equality on two references directly is
the same as comparing two values (it calls operator==).  Comparing
identity requires doing (&x == &y), like one would do with a value.
However, unlike a value, the object is not destroyed when the
reference goes out of scope.  Most importantly, references to base
classes do not slice derived class objects, so virtual calls work
correctly through references.

As a result, normally the right way to think about a value is as a
"temporary name" for an object and not worry about any of the details
about how the language makes it work.

>
> >> Equality or equivalence is a relation which is:
> >> - reflexive
> >> - symmetric
> >> - transitive
> >> Everything else... is something else. Call it semi-equality,
> >> tricky-equality or whatever, but not equality, please.
>
> > Sure, but then it's illegal to allow the usage of '==' with floating
> > point numbers, which will never have these properties in any usable
> > implementation[1].
>
> ???
>

The operator == is called the equality operator.  Floating-point
numbers don't really obey those properties in any meaningful fashion.
The result is that portions of your view contradict others.  Either we
must give '==' a different name, meaning what you consider equality is
irrelevant, or we must use method names like 'equals', which you find
objectionable.

> >>> If anything, you have that backwards.  Look at Python: all variables
> >>> in Python have pointer semantics, not value semantics.
>
> >> When everything is "white", the word "white" becomes redundant.
> >> So the fact that everything in Python have reference semantics means
> >> that we can't stop thinking about value and reference semantics.
>
> > Nope. The behavior of variables is absolutely essential to writing
> > correct programs.  If I write a program in Python that treats
> > variables as if they were values, it will be incorrect.
>
> You misunderstood what I said. You wouldn't treat variables as if they
> were values because you wouldn't even know what that means and that
> that's even a possibility.

Well, one hopes that is true.  I think we have a misunderstanding over
language: you said "value and reference semantics" when you really
meant "value vs. reference semantics".

> I've never heard an old C programmer talk about "value semantics" and
> "reference semantics". When everything is a value, your world is pretty
> simple.

Except if that were true, the comp.lang.c FAQ wouldn't have this
question and answer: http://c-faq.com/ptrs/passbyref.html, and several
others.

Much as you may not like it, most code doesn't care about a pointer's
value, doesn't need to know anything about it, and would just as soon
pretend that it doesn't exist.  All it really wants is a controlled
way to mutate objects in different scopes.  Which is precisely why
references are preferred over pointers in C++, as they're a better
expression of programmer intent, and far safe as a result.

Peaking under the covers in an attempt to simplify the definition of
'==' is silly.  As I've hopefully shown by now, it's pretty much a
fool's errand anyway.

>
> >>>   In imperative
> >>> languages, pointers have greater utility over value types because not
> >>> all types can obey the rules for value types.  For example, I don't
> >>> know how to give value semantics to something like a I/O object (e.g,
> >>> file, C++ fstream, C FILE), since I don't know how to create
> >>> independent copies.
>
> >> By defining a copy constructor.
>
> > Then write me a working one.  I'll wait. To save yourself some time,
> > you can start with std::fstream.
>
> Will you pay me for my time?

No, because you'll never finish.  There's a reason why std::fstream
lacks one, and it isn't because the committee is lazy.

>
> Your problem is that you think that copy semantics requires real
> copying. I really don't see any technical difficulty in virtualizing the
> all thing.

Then you would have written one already.  They do require real
copying, though.

Adam