ECMA-262-3 in detail. Chapter 8. Evaluation strategy.

[Dmitry A. Soshnikov]

Hi Dmitry,

Hi Jorge (aka Ry Nohryb),

1.- In the section "General Theory" you could as well say that the
order in which the arguments are evaluated in well specified in ES
(unlike in other languages, notably, C), it is from left to right.
This is of great importance if you happen to code something like this:
foo(a++, a+b);

Yep, fair enough. But it doesn't relate much to exactly passing from
the outside strategy. More, it e.g. can differ in evaluation if-
conditions. But it depends also on complier version. E.g. in MS studio
2005 I have the same result for evaluation this code -- both (C++ and
SpiderMonkey) evaluate it from left to right:

// JS

function testFn(a, b) {
alert([a, b])
}

var a = 10;
var b = 20;

testFn(a++, a + b); // 10, 31

// C++, MS studio 2005 compiler

void testFn(int a, int b)
{
cout << a << ", " << b;
}

int a = 10;
int b = 20;

testFn(a++, a + b); // 10, 31

I guess you've expected to see 11, 31? Then, in both (discussing)
languages we should use prefix-increment operation:

testFn(++a, a + b);

That's it.

2.- Pass-by-xxx and call-by-xxx can be used interchangeably. I would
stick to one of them. In the "Introduction" you use the term passed by
but in the sections you use call by. I for one would prefer "pass by"
everywhere as it's used more commonly than "call by", and I find it
more intuitive.

Yes, also true. Other descriptions use "call-by-xxx". So in my article
I (for this particular case) I make this terms equal, meaning that it
is possible to name with this and that term. If to use only "pass-by-
xxx", readers can be confused when will find similar description but
with "call-by-xxx" terminology. But yea, in everyday discussions we
usually use "pass-by-xxx".

3.- Wrt the behaviour described in "Call by reference", let me tell
you that the behaviour when passing by reference an object in C is
exactly the same as in ECMAScript [*1].

No, actually, no. I'll show an example below.

C's behaviour has always been
called pass by reference, even though the reference is passed by
value. E.g. the wikipedia article about this says : "Even among
languages that don't exactly support call-by-reference, many,
including C and ML, support explicit references (objects that refer to
other objects), such as pointers (objects representing the memory
addresses of other objects), and these can be used to effect or
simulate call-by-reference (but with the complication that a
function's caller must explicitly generate the reference to supply as
an argument).". I would add, "and with the complication that the
pointer has to be  dereferenced explicitly in order to access the
object".

Well, C/C++ has call-by-reference "sugar". And in this case formal
parameter will be direct alias of the object from the outside. It
doesn't require dereferencing operation. And assigning to the
reference -- change object completely, but not assign this name to the
new address as it would be in case of by-pointer/by-sharing.

4.- "Call by sharing" would be the best way to call it, were it not
for the fact that the semantics it describes get different names
depending on where you come from, some call it pass-by-reference and
some call it pass-by-value, because in fact it's both of them at the
same time: it's a "call-by-value, where the value is implied to be a
reference to the object". Exactly what C does, and what we've been
calling to pass by reference for ~ 4 decades.

Yes, but let me remind, that my articles mostly theoretical. And the
main objective of this chapter 8 is to show where the roots of these
evaluation strategies.

Regarding C/C++ (but regardless, that its implementation is just "one
of") -- yeah, we say that we deal with reference in both case: with
passing by pointer and with passing by reference. Moreover, as I
mentioned above, by-reference -- is just a syntactic sugar which is
useful in case when we want to affect object of the caller inside the
function but without using dereferencing operation.

void foo(int &bar) {
bar = 20; // it is not a pointer, but reference -- an alias
}

int x = 10;
foo(x); // pass by reference

cout << x; // 20

But, as it is a sugar, it's the same as:

void foo(int *bar) {
*bar = 20; // it is a pointer, not reference
}

int x = 10;

foo(&x); // by pointer value - address
cout << x; // 20

5.- In "Terminology versions" you say
<quote>
The statement "objects are passed in function by reference" formally
is not related with ECMAScript and is incorrect.
</quote>
It is not anymore incorrect than saying that "in C objects can be
passed by reference" or "in Ruby objects are passed by reference" or
"in Java objects are passed by value, where the value is a reference".

In C it is possible to pass by-reference and by-pointer. In both cases
it is possible to say: "we deal with the address, with the reference".
But semantics of that strategies differ. Assigning in first -- changes
the value of the outside object, assigning in second -- binds it to
the new address (but assigning with dereferencing -- also changes the
value).

I think that this matter is turning into a kind of holy war. If I were
to write on this matter, I would avoid any attempt to force a
terminology for as you should see there are good reasons for using any
of them, and different people coming from different languages are used
to call it differently, and none of them is wrong.

Yes, as I said, the main purpose of the theoretical article is to
clarify deeply some aspects (including terminological). It is not
about everyday speaking where we can say that object is passed by
reference (meaning that we can change it's properties inside the
function).

But often (very often) there are questions on forums like the "wtf,
why can't I change object inside the function? I read - it passed by
reference!", and then we see the code:

function foo(bar) {
bar = {x: 20}
}

var bar = {x: 10};
foo(bar);

"Why the heck bar still has {x: 10} ?"

alert(bar.x); // 10

I saw similar question many times on forums. Please notice, in case of
C++ by-reference we would have {x: 20}. But in case of C++ by-pointer
(which is by-sharing) -- would not (excluding dereferencing, i.e. a
"safe pointer").

[*1] If you're interested, I can provide you an example that proves
this point. What you say in "By sharing and pointers" :
<quote>
Regarding ó/ó++, this strategy is ideologically similar to passing by
pointer values, but with one important difference -- that it is
possible to dereference the pointer and to change the object
completely.
</quote>
is wrong.

No, it is correct. See example below.

In C, an argument that is a pointer is a copy of a

reference, just as an argument that is a reference in ES. When a
function receives an argument that is a pointer, it can either change
the argument's value alltogether and make it point to somewhere/
something else (in ES that would be the equivalent of assigning a
completely different value to the argument, as in reference= {}, or
reference= "fjh", or reference= 27, or reference= null, or reference=
youNameIt) or touch the contents of the object that the pointer points
to using a dereferencing operator, either pointer->property= value or
(*pointer).property= value, exactly as you'd do in ES, the only
difference being that in ES there's no need to dereference explicitly:
reference.property= value would do.

That's exactly I wrote -- but in case of a *pointer*, not the
*reference*. I repeat, regardless that reference-concept is just a
sugar for the pointer in C++, and regardless that in both cases we
have a "reference is an address" definition.

There's *nothing* that can be done
in C when passing an object by reference (as in f(&object) ),

If this is a function definition (or prototype), then it is a
"reference" (then call of this "f" function would be just f(object),
when object will be an "alias"). If f(&object) is already a call, then
it is a by-pointer, i.e. address *value*. It is the very subtle
difference, but nevertheless is a difference.

that
can't be done in ES. Their behaviours are identical.

Yes, there is. In ES we can't change object of the caller completely
assigning a new value to it (as we can in C++ in case of by-reference
strategy).

And again. This
behaviour has been called "to pass by reference" for decades.

There are exact distinctions between "by-value", "by-reference" and
"by-pointer"/"by-sharing". Again, my article is mostly about theory,
but not just about everyday talks when we can omit this deep analysis
and name it as "by-reference" but -- only meaning that we can change
object's properties but not the object itself.

Moreover, as I wrote, if to consider only abstraction level provided
by ECMA-262-3, then in every algorithm we see concept of a "value".
And discussing from this viewpoint (from this level of abstraction) we
can not even to think about that "reference", "not-a-reference",
"pointer" and so on. But. Of course, if we want to understand it
deeply, then we should consider the implementation level, where we see
pass by a safe pointer or (in the theory) -- by sharing.

And "sharing" (which is named by Liskov) is when several binding names
can be bound to the same memory block (to the same memory address). Is
it so in ES? Absolutely:

var foo = {x: 10};

bar = foo;
baz = bar;

// etc.

So this three binding names *share* this single object {x: 10}. And
absolutely the same strategy in this case when passing that values to
function arguments.

The example I mentioned above (I wrote it before in private email
discussion with one programmer): <URL: http://gist.github.com/364525>

Dmitry.

 

[Ry Nohryb]

Hi Jorge (aka Ry Nohryb),


Yep, fair enough. But it doesn't relate much to exactly passing from
the outside strategy. More, it e.g. can differ in evaluation if-
conditions. But it depends also on complier version.

http://dmitrysoshnikov.com/ecmascript/chapter-8-***evaluation***strategy***/
http://en.wikipedia.org/wiki/Evaluation_strategy
<quote>
In computer science, an evaluation strategy is a set of (usually
deterministic) rules for evaluating expressions in a programming
language. Emphasis is typically placed on functions or operators: an
evaluation strategy defines when *and*in*what*order*the arguments to a
function are evaluated
</quote>

It couldn't be any more directly related to function calls. The point
is that in JavaScript the order of evaluation of the arguments of a
function call is specified by the ECMA specs, unlike in other
languages such as C whose specs leave it at the discretion of the
implementers.

(...)
Then, in both (discussing)
languages we should use prefix-increment operation:

testFn(++a, a + b);

That's it.

No Dmitry that's not it, with left to right evaluation you get a thing
and with right to left evaluation you'd get a different thing. That's
it. It has nothing to do with pre/postfix incrementing.

(...)

I'll reply to the rest in a separate post.

 

[Ry Nohryb]

Hi Jorge (aka Ry Nohryb),
(...)

3.- Wrt the behaviour described in "Call by reference", let me tell
you that the behaviour when passing by reference an object in C is
exactly the same as in ECMAScript [*1].

No, actually, no. I'll show an example below.

C's behaviour has always been
called pass by reference, even though the reference is passed by
value. E.g. the wikipedia article about this says : "Even among
languages that don't exactly support call-by-reference, many,
including C and ML, support explicit references (objects that refer to
other objects), such as pointers (objects representing the memory
addresses of other objects), and these can be used to effect or
simulate call-by-reference (but with the complication that a
function's caller must explicitly generate the reference to supply as
an argument).". I would add, "and with the complication that the
pointer has to be �dereferenced explicitly in order to access the
object".

Well, C/C++ has call-by-reference "sugar". And in this case formal
parameter will be direct alias of the object from the outside. It
doesn't require dereferencing operation. And assigning to the
reference -- change object completely, but not assign this name to the
new address as it would be in case of by-pointer/by-sharing.

No, C does *not* have a reference datatype, void f (type &param)
{ ... } is not valid C syntax.

Yes, but let me remind, that my articles mostly theoretical. And the
main objective of this chapter 8 is to show where the roots of these
evaluation strategies.

I'd say that in order to be truly objective, it would be better to
stick to the facts and rather than to attempt to enforce your
preferences, you should just explain why they've got several different
and valid although apparently conflicting names.

Regarding C/C++ (but regardless, that its implementation is just "one
of") -- yeah, we say that we deal with reference in both case: with
passing by pointer and with passing by reference.

There's no reference type in plain C, K&R-C nor ANSI-C. I'd have to
check it for C-99, but I'd say off the top of my head that neither.

Moreover, as I
mentioned above, by-reference -- is just a syntactic sugar which is
useful in case when we want to affect object of the caller inside the
function but without using dereferencing operation.

void foo(int &bar) {
bar = 20; // it is not a pointer, but reference -- an alias
}

int x = 10;
foo(x); // pass by reference

cout << x; // 20

But, as it is a sugar, it's the same as:

void foo(int *bar) {
*bar = 20; // it is a pointer, not reference
}

(type &param) is not the same as (type *param). And beyond the fact
that the former is not valid C, the semantics differ.

int x = 10;

foo(&x); // by pointer value - address
cout << x; // 20


In C it is possible to pass by-reference and by-pointer.

Again, no.

In both cases
it is possible to say: "we deal with the address, with the reference".
But semantics of that strategies differ. Assigning in first -- changes
the value of the outside object, assigning in second -- binds it to
the new address (but assigning with dereferencing -- also changes the
value).
ACK.


Yes, as I said, the main purpose of the theoretical article is to
clarify deeply some aspects (including terminological). It is not
about everyday speaking where we can say that object is passed by
reference (meaning that we can change it's properties inside the
function).

A theoretical article that attempts to enforce your own preferences on
the reader.

But often (very often) there are questions on forums like the "wtf,
why can't I change object inside the function? I read - it passed by
reference!", and then we see the code:

function foo (bar) {
bar = {x: 20}
}

var bar = {x: 10};
foo(bar);

"Why the heck bar still has {x: 10} ?"

alert(bar.x); // 10

Because the code above is broken. It's possible to change the outer
bar from inside foo, just not so. (but never mind, I got what you
mean)

I saw similar question many times on forums. Please notice, in case of
C++ by-reference we would have {x: 20}. But in case of C++ by-pointer
(which is by-sharing) -- would not (excluding dereferencing, i.e. a
"safe pointer").

I know. That's why in my post C++ wasn't mentioned, not even once.

[*1] If you're interested, I can provide you an example that proves
this point. What you say in "By sharing and pointers" :

<quote>
Regarding C, C++, this strategy is ideologically similar to passing by
pointer values, but with one important difference -- that it is
possible to dereference the pointer and to change the object
completely.
</quote>

is wrong.

No, it is correct. See example below.

It is not, not for C.

And C (not C++) is the language that I've chosen to reason about this
because it dates back to 1973, because it's been probably the most
influential language ever, because it's a model of reference, and
because the semantics that you (and apparently a new wave of young
programmers) believe that shouldn't be called "to pass by reference"
have been being called so for almost 4 decades now by the the elder C
programmers.

 

[Ry Nohryb]

Hi Jorge (aka Ry Nohryb),


Yep, fair enough. But it doesn't relate much to exactly passing from
the outside strategy. More, it e.g. can differ in evaluation if-
conditions.

The title of your article is **evaluation**strategy**

See what the wikipedia says about it:

http://en.wikipedia.org/wiki/Evaluation_strategy
<quote>
In computer science (...) evaluation strategy defines when
*and*in*what*order*the arguments to a function are evaluated

But it depends also on complier version. E.g. in MS studio
2005 I have the same result for evaluation this code -- both (C++ and
SpiderMonkey) evaluate it from left to right:

My point being that it does *not* depend on the compiler version, for,
unlike in C, in JS the order is specified in the ECMA-262 specs. IOW,
you can rest on the fact that it's going to be left to right, ever, in
every JS engine.

(...)

No Dmitry that's not it, with left to right evaluation you get a thing
and with right to left evaluation you get a different thing. That's
it. It has nothing to do with pre/postfix incrementing. That's why
knowing what the order is is important. And that's why knowing that
it's always going to be the same, because it's in the ECMA specs, is
important too.

 

[Dmitry A. Soshnikov]

Dmitry A. Soshnikov wrote:


No, C does *not* have a reference datatypevoid f (type &param)
{ ... } is not valid C syntax.

Excuse me? Why this code isn't valid? If you want to provide some
quote from C-specification, -- no, sorry, I'm not interested in
current case. But this code is valid and means "call-by-reference".

There's no reference type in plain C, K&R-C nor ANSI-C. I'd have to
check it for C-99, but I'd say off the top of my head that neither.

It doesn't matter in discussing question.

(type &param) is not the same as (type *param).

Thanks you, I know. If you want to nit-picking to words, sorry -- not
with me Once again, C/C++ implementation is just "one of". But on
this implementation we can see theoretical description of by-reference
and by-pointer/sharing.

Again, no.

Jorge, you don't think that I will participate in useless holy wars on
several pages of c.l.js topics with nit-picking to irrelevant
concepts, yes? Ok. There are a lot of here, and without me

A theoretical article that attempts to enforce your own preferences on
the reader.

Well, that your choice how to see and treat it.

I know. That's why in my post C++ wasn't mentioned, not even once.

That's exactly I'm telling you. But I don't see any sense to talk
about "no, it is not for C", when you meant C++. I think such
arguments are irrelevant and just robs our time, don't you think so?
I'm not interested in C/ANSI C/C++ or whatever in this case. We talked
about "by-reference" and "by-sharing/pointer" and just use C/C++ (all
of them! -- regardless your useless nit-picking to "K&R, ANSI") to
show an example. That's it. No more, no less.

[*1] If you're interested, I can provide you an example that proves
this point. What you say in "By sharing and pointers" :
<quote>
Regarding C, C++, this strategy is ideologically similar to passing by
pointer values, but with one important difference -- that it is
possible to dereference the pointer and to change the object
completely.
</quote>
is wrong.

No, it is correct. See example below.

It is not, not for C.

Again. It doesn't matter for me "not for C" or "not for C++". Really.
But, I think we already understand each other, right?

Dmitry.

 

[Dmitry A. Soshnikov]

In computer science (...) evaluation strategy defines when
*and*in*what*order*the arguments to a function are evaluated

Yes, OK, maybe I'll add this sentence in the article; will be useful.

No Dmitry that's not it, with left to right evaluation you get a thing

Thanks, I know, and was talking about *only this* type -- left to
right in both cases.

and with right to left evaluation you get a different thing. That's
it.

Yep, I know, thanks.

Dmitry.

 

[John G Harris]

I repeat, regardless that reference-concept is just a
sugar for the pointer in C++,

<snip>

That isn't true. In C++ a reference is a synonym. The compiler doesn't
have to use a pointer. If it's possible and if it wants to it can treat
it like a macro instead. (See 'frog', use 'jump').

John

 

[Dmitry A. Soshnikov]

On Sun, 25 Apr 2010 at 11:25:31, in comp.lang.javascript, Dmitry A.

Soshnikov wrote:



  <snip>

That isn't true. In C++ a reference is a synonym. The compiler doesn't
have to use a pointer. If it's possible and if it wants to it can treat
it like a macro instead. (See 'frog', use 'jump').

It doesn't matter. Moreover, I don't see any sense (and I object) to
make a big irrelevant discussion. It doesn't matter what exactly does
*any version* of C/C++. Because we talk about theoretical evaluation
strategies. I myself use concept of an *alias* (i.e. synonym) when
described by-reference strategy. The case that in C by-reference is
just a sugar -- it is more abstractly to show that the same we can do
with dereferencing a pointer. Meanwhile, I do not know what exactly is
going on at preprocessing and compiling stages of *some* C/C++-
implementation.

The reference at assignment in C++ behaves like a dereferenced
pointer. That exactly I meant when said that it's kind of syntactic
sugar. Although, I don't know -- maybe it is even so at implementation
stage, I didn't read C++ specification. But repeat, it is irrelevant.
Nevertheless, John, if you know C++ spec deeply, let me know is it so
or not, it will be useful to know for future discussions.

Dmitry.

 

[Dmitry A. Soshnikov]

Yes, OK, maybe I'll add this sentence in the article; will be useful.

Ok, I added this sentence:

"Also the order in which arguments are being evaluated is important —
in ECMAScript it is left-to-right. In other languages and their
implementations the reverse evaluation order (i.e. right-to-left) can
be used."

Please, correct wording mistakes if there are.

Dmitry.

 

[Ry Nohryb]

Excuse me? Why this code isn't valid? If you want to provide some
quote from C-specification, -- no, sorry, I'm not interested in
current case. But this code is valid and means "call-by-reference".



It doesn't matter in discussing question.

It's pivotal to the argument.

Thanks you, I know. If you want to nit-picking to words, sorry -- not
with me Once again, C/C++ implementation is just "one of". But on
this implementation we can see theoretical description of by-reference
and by-pointer/sharing.

OMG please stop throwing them together again and again as if they were
the same thing. It hurts.

Again, no.

Jorge, you don't think that I will participate in useless holy wars on
several pages of c.l.js topics with nit-picking to irrelevant
concepts, yes? Ok. There are a lot of here, and without me

A theoretical article that attempts to enforce your own preferences on
the reader.

Well, that your choice how to see and treat it.

I know. That's why in my post C++ wasn't mentioned, not even once.

That's exactly I'm telling you. But I don't see any sense to talk
about "no, it is not for C", when you meant C++. I think such
arguments are irrelevant and just robs our time, don't you think so?
I'm not interested in C/ANSI C/C++ or whatever in this case. We talked
about "by-reference" and "by-sharing/pointer" and just use C/C++ (all
of them! -- regardless your useless nit-picking to "K&R, ANSI") to
show an example. That's it. No more, no less.

[*1] If you're interested, I can provide you an example that proves
this point. What you say in "By sharing and pointers" :
<quote>
Regarding C, C++, this strategy is ideologically similar to passing by
pointer values, but with one important difference -- that it is
possible to dereference the pointer and to change the object
completely.
</quote>
is wrong.
No, it is correct. See example below.

It is not, not for C.

Again. It doesn't matter for me "not for C" or "not for C++". Really.
But, I think we already understand each other, right?

No, we don't. But this has taught me a couple things about you. First
that you can't stand being corrected, and 2nd that you're a young
programmer (time will cure that) with no experience in C (this you can
cure yourself). That in you mind C == C++ (!). Let me tell you a
secret: C++ sucks [*1]. Instead, C is -still- a model of reference,
after so many years. That's why I chose it for my reasoning, not C++.

I've got somewhere a couple or 3 notes I've taken about your CH4
article "Scope chain". There's an important mistake in it (that I
wonder why nobody has told you yet). Do you want to know ? Or just
don't want any further constructive criticisms ?

[*1]
http://www.google.com/search?q=why+c+++sucks

Even Linus Torvalds has said so recently:
<quote>
From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String
Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (2 years, 33 weeks, 1 day, 11 hours and
31 minutes ago)

When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
it's BS.

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a
lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even
if
the choice of C were to do *nothing* but keep the C++ programmers
out,
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've
come
to the conclusion that any programmer that would prefer the project to
be
in C++ over C is likely a programmer that I really *would* prefer to
piss
off, so that he doesn't come and screw up any project I'm involved
with.

C++ leads to really really bad design choices. You invariably start
using
the "nice" library features of the language like STL and Boost and
other
total and utter crap, that may "help" you program, but causes:

- infinite amounts of pain when they don't work (and anybody who
tells me
that STL and especially Boost are stable and portable is just so
full
of BS that it's not even funny)

- inefficient abstracted programming models where two years down the
road
you notice that some abstraction wasn't very efficient, but now
all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level
and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that
people
don't screw that up, and also means that you get a lot of programmers
that
do actually understand low-level issues and don't screw things up with
any
idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a
primary
objective, the "advantages" of C++ is just a huge mistake. The fact
that
we also piss off people who cannot see that is just a big additional
advantage.

If you want a VCS that is written in C++, go play with Monotone.
Really.
They use a "real database". They use "nice object-oriented
libraries".
They use "nice C++ abstractions". And quite frankly, as a result of
all
these design decisions that sound so appealing to some CS people, the
end
result is a horrible and unmaintainable mess.

But I'm sure you'd like it more than git.

Linus
</quote>

 

[John G Harris]

Even Linus Torvalds has said so recently:
<quote>
From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String
Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (2 years, 33 weeks, 1 day, 11 hours and
31 minutes ago)

When I first looked at Git source code two things struck me as odd:
1. Pure C as opposed to C++. No idea why. Please don't talk about
portability,
it's BS.

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a
lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it.
...

Linus
</quote>

Now read
<http://www2.research.att.com/~bs/blast.html>

Among other sensible things it says :

"I consider a large portion of the bashing of C++ and the C++ users
unwarranted, ill-informed, self-serving, and intellectually dishonest."

and

"As someone remarked: There are only two kinds of programming languages:
those people always bitch about and those nobody uses. "

John

 

[John G Harris]

It doesn't matter.

<snip>

Spreading misinformation always matters.

The reference at assignment in C++ behaves like a dereferenced
pointer. That exactly I meant when said that it's kind of syntactic
sugar.

<snip>

Funnily enough, so does assignment to a variable. Some languages expect
programs to dereference a pointer every time they access a variable, but
not C++.

John

 

[Dmitry A. Soshnikov]

you can't stand being corrected, and 2nd that you're a young
programmer (time will cure that)

OK, I "appreciate" it. Nice try, but unfortunately for you, I have
immunity for such weak trolling So, let's omit it.

I've got somewhere a couple or 3 notes I've taken about your CH4
article "Scope chain". There's an important mistake in it (that I
wonder why nobody has told you yet). Do you want to know ? Or just
don't want any further constructive criticisms ?

Yes, you may, I'm opened for any good addition/correction. So you can
post it here or anywhere else.

Dmitry.

 

[Dmitry A. Soshnikov]

  <snip>

Funnily enough, so does assignment to a variable. Some languages expect
programs to dereference a pointer every time they access a variable, but
not C++.

I have no any idea what the goal of your addition? Why do we talk
about C/C++? How you guys here like to talk about some nit-picking
irrelevant stuff on 10 pages. I'm sorry, I can't help you with that.

I told, that C/C++ is a good language to show in action some strategy.
That's it. No more, no less. I didn't talk about implementations or
sort of. Moreover, I told, it doesn't matter for me will it be C or C+
+. Also I said that I know that in both cases (having as argument a
reference or a pointer) we have concept of a "reference". But all this
doesn't matter.

By the way, in early first version of this article there was no
section with comparing with C/C++ pointers, I added it later. And
think that is needed.

I'm not interested at the moment in nit-picking.

So, what are you trying to say to me? What's the main objective of
your words?

Dmitry.

 

[Ry Nohryb]

Now read
  <http://www2.research.att.com/~bs/blast.html>
(...)

Nah, here's his most truly enlightening talk :
http://artlung.com/smorgasborg/Invention_of_Cplusplus.shtml

 

[Dmitry A. Soshnikov]

Although, I don't know -- maybe it is even so at implementation
stage, I didn't read C++ specification.

I checked in MS 2005 compiler. It is so, C++ reference concept *is
just a syntactic sugar* for a pointer. I can statement it now
precisely.

Example to check: <URL: http://gist.github.com/380515>

1 C++ source:
2
3 void call_by_reference(int& x)
4 {
5 x = 20;
6 }
7
8 void call_by_pointer(int* x)
9 {
10 *x = 20;
11 }
12
13 void by_value(int x)
14 {
15 x = 20;
16 }
17
18 int _tmain(int argc, _TCHAR* argv[])
19 {
20 int y = 0;
21
22 call_by_reference(y);
23 call_by_pointer(&y);
24 by_value(y);
25
26 return 0;
27 }
28
29 Disassembly:
30
31 The most important lines are 50-51 (by-reference) and 55-56 (by-
pointer)
32 as we see, the same -- load effective address and push to stack.
33
34 int _tmain(int argc, _TCHAR* argv[])
35 {
36 00F81480 push ebp
37 00F81481 mov ebp,esp
38 00F81483 sub esp,0CCh
39 00F81489 push ebx
40 00F8148A push esi
41 00F8148B push edi
42 00F8148C lea edi,[ebp-0CCh]
43 00F81492 mov ecx,33h
44 00F81497 mov eax,0CCCCCCCCh
45 00F8149C rep stos dword ptr es:[edi]
46 int y = 0;
47 00F8149E mov dword ptr [y],0
48
49 call_by_reference(y);
50 00F814A5 lea eax,[y]
51 00F814A8 push eax
52 00F814A9 call call_by_reference (0F81005h)
53 00F814AE add esp,4
54 call_by_pointer(&y);
55 00F814B1 lea eax,[y]
56 00F814B4 push eax
57 00F814B5 call call_by_pointer (0F8100Fh)
58 00F814BA add esp,4
59 by_value(y);
60 00F814BD mov eax,dword ptr [y]
61 00F814C0 push eax
62 00F814C1 call by_value (0F8100Ah)
63 00F814C6 add esp,4
64
65 return 0;
66 00F814C9 xor eax,eax
67 }

P.S.: Also, C++ creator Straustrup also notice that at implementation
level, a reference is just a sugar for the pointer. And this pointer
is dereferenced every time when we deal with a reference operation.

Dmitry.

 

[Dmitry A. Soshnikov]

  <snip>

Spreading misinformation always matters.

Now who from us a two is spreading misinformation? I'm waiting.

Dmitry.

 

[Dmitry A. Soshnikov]

I checked in MS 2005 compiler.

Sorry, typo, even in 2008.

Dmitry.

 

[Ry Nohryb]

...and after reading that truly enlightening interview, it may be a good
idea to read this: <http://www2.research.att.com/~bs/bs_faq.html#IEEE>

Nah, soon after the interview he realized he had gone too far, and
that "of course not" is just a lame attempt at retracting his earlier
statements.

 

[John G Harris]

Why do we talk
about C/C++?

You're the one who started talking about C++ and syntactic sugar.

I told, that C/C++ is a good language to show in action some strategy.
That's it. No more, no less.

There's nothing wrong with saying a pointer is a way of supplying a
reference variable in a function call.

What's wrong is saying that C++ references always work that way. They
aren't required to and in some optimising compilers in suitable
circumstance they don't.

By the way, in early first version of this article there was no
section with comparing with C/C++ pointers, I added it later. And
think that is needed.

Will that really help readers who know no C++ ?

So, what are you trying to say to me? What's the main objective of
your words?

I object to even more misinformation polluting the internet. There's too
much already.

John