Differences between C++ and Java

A

AndyRB

Thomas said:
AndyRB said something like:
Thomas said:
AndyRB said something like:
...[rip]...

No, in c++ you cannot use pointer arithmetic to point to anywhere
within the address space, it is explicitly undefined behaviour
(consider a segmented memory model).

Of course! But that happens /after/ the compiler accepts the attempt to set
the pointer [anywhere] and when that part of the code is executed.

Who says that the compiler accepts the code and that the code even gets
executed.
It is undefined behaviour so technically you cannot assume anything
about what will happen or even what will be attempted.
 
O

Oliver Wong

AndyRB said:
Of course! But that happens /after/ the compiler accepts the attempt to
set
the pointer [anywhere] and when that part of the code is executed.

Who says that the compiler accepts the code and that the code even gets
executed.
It is undefined behaviour so technically you cannot assume anything
about what will happen or even what will be attempted.

While I haven't read the C++ spec, based on my experience of reading
specifications for other languages, generally when they say "undefined
behaviour", they mean "undefined runtime behaviour". It is almost always
very well defined whether or not something will get accepted by the
compiler.

In other words, the "behaviour" they are referring to is the behaviour
of the program you're writing, not the behaviour of the compiler.

- Oliver
 
T

Thomas G. Marshall

Bjorn Abelli said something like:
...

That's what you get for mixing up lingos for different contexts...

In that sentence I didn't mean "reference" as the explicit C++ construct,
but rather on a more general level as I tried to explain that it was
*possible* to change something at the caller's side, in a way that you
can't
in Java.


Well, I said somewhere else that it was many, many years since I
programmed
in C/C++... ;-)

void bear::with(me *arg);

If my memory serves me right I believe in C++ I sometimes even used
"references to pointers"... ;-)

All manner of crap has been used in C++ that just boggles
the^H^H^Heveryone's mind.
 
T

Thomas G. Marshall

AndyRB said something like:
Thomas said:
AndyRB said something like:
Thomas G. Marshall wrote:
AndyRB said something like:
...[rip]...

No, in c++ you cannot use pointer arithmetic to point to anywhere
within the address space, it is explicitly undefined behaviour
(consider a segmented memory model).

Of course! But that happens /after/ the compiler accepts the attempt to
set
the pointer [anywhere] and when that part of the code is executed.

Who says that the compiler accepts the code and that the code even gets
executed.
It is undefined behaviour so technically you cannot assume anything
about what will happen or even what will be attempted.


We're going woefully astray here. But for yucks, I'll answer this part:
Undefined behavior is /always/ a definition of what happens at run time.
The compiler is in complete control of itself, and such a notion need not
exist at compile time. It is not, for example, ok for the compiler to spit
how "holy @#$% !!!" just because the behavior of an idiom/construct is
listed undefined in the specification.
 
C

Chris Smith

Roedy Green said:
The point is words mean what people decide they mean. The Java
community through consensus came to define call by reference and call
by value in such a way that Java always passes by value. Everything
makes sense if you are consistent about this definition.

I'd modify that. The computer science field has come to define those
words in certain ways. Although there is a small step involved in apply
the definition to each individual language (namely, defining the term
"assignment operation" in the context of that language), the definition
is consistent and widely accepted at least among those who practice
language design and theory.

The Java community has come to understand that definition as it applies
to the Java programming language.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
T

Thomas Hawtin

Thomas said:
We're going woefully astray here. But for yucks, I'll answer this part:
Undefined behavior is /always/ a definition of what happens at run time.
The compiler is in complete control of itself, and such a notion need not
exist at compile time. It is not, for example, ok for the compiler to spit
how "holy @#$% !!!" just because the behavior of an idiom/construct is
listed undefined in the specification.

So, are these features of C++ not undefined behaviour (if my memory serves):

o Platform dependent restrictions on the length of identifiers.

o Platform dependent restrictions on the depth of recursion of
template instantiation.

o Platform dependent #includes of one C++ standard header file from
another (not allowed for the C headers).

o Spitting out of platform dependent warnings.

Tom Hawtin
 
A

AndyRB

Thomas said:
AndyRB said something like:
Thomas said:
AndyRB said something like:
Thomas G. Marshall wrote:
AndyRB said something like:

...[rip]...

No, in c++ you cannot use pointer arithmetic to point to anywhere
within the address space, it is explicitly undefined behaviour
(consider a segmented memory model).

Of course! But that happens /after/ the compiler accepts the attempt to
set
the pointer [anywhere] and when that part of the code is executed.

Who says that the compiler accepts the code and that the code even gets
executed.
It is undefined behaviour so technically you cannot assume anything
about what will happen or even what will be attempted.


We're going woefully astray here. But for yucks, I'll answer this part:
Undefined behavior is /always/ a definition of what happens at run time.
The compiler is in complete control of itself, and such a notion need not
exist at compile time. It is not, for example, ok for the compiler to spit
how "holy @#$% !!!" just because the behavior of an idiom/construct is
listed undefined in the specification.

Undefined behaviour does not have to be diagnosed at compile-time, but
it is very much OK for a conforming compiler to spit out "holy @#$%
!!!" if it encounters a construct that is undefined behaviour.
From the c++ standard definition...
"[Note: permissible
undefined behavior ranges from ignoring the situation completely with
unpredictable results, to
behaving during translation or program execution in a documented manner
characteristic of the environment
(with or without the issuance of a diagnostic message), to terminating
a translation or execution
(with the issuance of a diagnostic message)."

Note the explicit references made to translation in the above
definition.
 
A

AndyRB

Oliver said:
AndyRB said:
Of course! But that happens /after/ the compiler accepts the attempt to
set
the pointer [anywhere] and when that part of the code is executed.

Who says that the compiler accepts the code and that the code even gets
executed.
It is undefined behaviour so technically you cannot assume anything
about what will happen or even what will be attempted.

While I haven't read the C++ spec, based on my experience of reading
specifications for other languages, generally when they say "undefined
behaviour", they mean "undefined runtime behaviour". It is almost always
very well defined whether or not something will get accepted by the
compiler.
So you are making assumptions about c++ based on the specifications of
entirely different languages?
In other words, the "behaviour" they are referring to is the behaviour
of the program you're writing, not the behaviour of the compiler.
From the /C++/ standard definition...
"[Note: permissible
undefined behavior ranges from ignoring the situation completely with
unpredictable results, to
behaving during translation or program execution in a documented manner
characteristic of the environment
(with or without the issuance of a diagnostic message), to terminating
a translation or execution
(with the issuance of a diagnostic message)."

Note the explicit references made to translation in the definition
above.
 
A

AndyRB

Roedy said:
That is not the issue. The issue is whether there are mechanisms to
detect the error or you simply get undefined results.

Think for example writing C code where you failed to initialise a
variable. This was legal. Most of the time it was initialised to 0.
But sometimes it was not, leading to a need for a timeout in a padded
cell.
and what sounds like undefined behaviour. Uninitialised variables are
legal, using uninitialised variables is undefined...however, I don't
think this affects the point I think you are trying to make.
It STRONGLY matters if the compiler/run time can detect the
error.
I don't think I have ever said anything to the contrary?
It is almost irrelevant if the given code is technically legal.

It is irrelevant as far as erroneous code is erroneous, but that was
not the point I was making.

The point I am trying to make is that you can't attach expectations to
undefined behaviour, so what I am saying is that a statement along the
following lines is incorrect:

In c++ you can write <replace with some code that is undefined
behaviour> in order to <replace with some expected output>.

If the code is undefined behaviour you can say absolutely nothing about
what the code should do. It is on that basis that I said some of your
statements (e.g. pointer arithmetic)were incorrect.
 
O

Oliver Wong

AndyRB said:
So you are making assumptions about c++ based on the specifications of
entirely different languages?

Yes. Sort of like when I encounter a new programming language and see
the statement "x = y + z;", I assume that the + is an operator (and not,
say, a variable name) that does something semantically equivalent to
"addition" on the "y" and "z", which I assume are variable names (and not,
say, operators). This interpretation is so widespread, it almost seems like
a defacto standard, and from a utilitarian perspective, it is MORE useful to
just make that assumption, and then correct yourself when you find out that
you are wrong, than to sort of be blocked from proceeding further and
acknowledging that you don't actually really know what the statement means.
In other words, the "behaviour" they are referring to is the
behaviour
of the program you're writing, not the behaviour of the compiler.
From the /C++/ standard definition...
"[Note: permissible
undefined behavior ranges from ignoring the situation completely with
unpredictable results, to
behaving during translation or program execution in a documented manner
characteristic of the environment
(with or without the issuance of a diagnostic message), to terminating
a translation or execution
(with the issuance of a diagnostic message)."

Note the explicit references made to translation in the definition
above.

Noted. I'm very surprised that this is the stance on what is accepted
when something is said to have "undefined behaviour", but if that's what it
says, so be it. I stand corrected.

- Oliver
 
A

Alvin Ryder

Roedy said:
A link to an essay on the differences between C++ and Java in the Java
glossary has died, so I concocted this little essay to replace it at
http://mindprod.com/jgloss/cpp.html

In Java, the sizes of int, long etc. are rigidly defined in terms of
bits. In C++ they are platform-dependent.

In Java, the JVM behaves at if it were big endian, even if internally
it is actually little-endian. In C++, the endianness is platform
dependent.

In Java, garbage collection of unreferenced objects is automatic. In
C++, you manually manage memory.

In Java, references are constrained to point only to the beginnings of
objects. In C++, you can do arithmetic on pointers and make pointers
point anywhere in the address space.

In Java you cannot overload operators. In C++, you can.

In Java, by default methods are virtual (overrideable). In C++, by
default, methods are non-virtual.

Java object code (class files containing JVM byte codes) will run
unmodified on any platform. C++ object code must be first linked to
produce an executable containing platform-specific machine
instructions. It will run only on one platform.

Java checks all subscripts that they are in bounds and all casts for
validity. C++ does not.

Java requires a JVM to execute. C++ programs are usually freestanding.
Java does not use a preprocessor. C++ makes extensive use of a macro
preprocessor.

Anything else important to say?

Hi,

You've covered many good points, in addition most of my points aren't
language related per se but they are certainly important and an
inevitable part of using each language.

Culture.
Java has a culture of "let's make it easy and cool to use" while C++'s
culture is "hey if you can't hang with the big boys, that's your
problem (... try VB)".

Java: "You need an API, yea, we'll build it, you can have it ... for
free" ;-)
C++: "You need an API, great go build it yourself ... or buy it" ;-|

Growth.
JCP - moves pretty quickly. New JDK every year.
ANSI C++ - moves slowly, to "gc" or "not to gc"... meantime the world
has moved on.

Support.
Sun makes huge effort to sign everyone up for Java support (remember
those days).
C++ leaves participation open to happen-stance.

JDBC is just one fruit of that almost unanimous and uniform support,
while in C++ talking to databases is still on a case by case basis.

Enterprise integration. Java has J2EE, C++ say's "that's your problem
not ours".

C++: A case of a language and a compiler, *all* the rest is up to you.
Java: We'll make all the pieces of the jigsaw puzzle and we'll make
them fit, you only need to make the app.

Style.
Java encourages "ease" thus clarity thus verbosity, happyTyingFolks (
).
C++ is terse. htf ( ). (Of course that's only a cultural tendency not
an intrinsic language feature..)

Java: A class must be in a file of the same name. File location must
match package structure.
C++: Put it where you want, name it how you want (=mess).

Cheers.
 
T

Thomas G. Marshall

AndyRB said something like:
Thomas said:
AndyRB said something like:
Thomas G. Marshall wrote:
AndyRB said something like:
Thomas G. Marshall wrote:
AndyRB said something like:

...[rip]...

No, in c++ you cannot use pointer arithmetic to point to anywhere
within the address space, it is explicitly undefined behaviour
(consider a segmented memory model).

Of course! But that happens /after/ the compiler accepts the attempt
to
set
the pointer [anywhere] and when that part of the code is executed.

Who says that the compiler accepts the code and that the code even gets
executed.
It is undefined behaviour so technically you cannot assume anything
about what will happen or even what will be attempted.


We're going woefully astray here. But for yucks, I'll answer this part:
Undefined behavior is /always/ a definition of what happens at run time.
The compiler is in complete control of itself, and such a notion need not
exist at compile time. It is not, for example, ok for the compiler to
spit
how "holy @#$% !!!" just because the behavior of an idiom/construct is
listed undefined in the specification.

Undefined behaviour does not have to be diagnosed at compile-time, but
it is very much OK for a conforming compiler to spit out "holy @#$%
!!!" if it encounters a construct that is undefined behaviour.
From the c++ standard definition...
"[Note: permissible
undefined behavior ranges from ignoring the situation completely with
unpredictable results, to
behaving during translation or program execution in a documented manner
characteristic of the environment
(with or without the issuance of a diagnostic message), to terminating
a translation or execution
(with the issuance of a diagnostic message)."

Note the explicit references made to translation in the above
definition.

Hmmm ok, thanks. I'll have to ponder on this---IMO there's a nuance to this
that /still/ doesn't seem quite right in this thread's context. But in any
case, Chris Uppal rephrased it properly already.
 
D

Dimitri Maziuk

Roedy Green sez:
....
Please at least read the JVM spec and also study how parameters are
passed in various language

I have, and I much prefer Delphi language guide that says object
references are "pointers that are automatically dereferenced" in
the "objects" section and that if you wnat to, you can var any
formal parameter
procedure myfunc( var o:Myobj )
(in the "methods" section).

JLS says that there are three "reference types" and that reference types
are *not* primitive types. It says that "reference values" are pointers
to objects. Then you trace down the three "reference types" and work out
that in the end they're all instantiated as objects, so "reference values"
is what you're interested in.

In 2.10 JLS says that for every parameter, a new variable is created and
initialized when method is invoked. Thankfully, I know enough about
stack-based languages to understand what they mean by that.

So it's the same as Delphi sans var parameters and clarity of documentation.
... before you
continue with your crusade.

What crusade? -- I'm just keepin' up a polite conversation. Prompted
by your statement that "Java references point to the beginnings of
objects, in C++ you can do pointer arithmetics..." It's bad, OK?

Because

1. Java "reference values (often just _references_)" are pointers
to objects and there are only two things you can do with them: point
one to an object and access object's members via it (basically; there's
also comparisons which may or may not be done by object's members,
instanceof and string concatenation). They don't point to "the beginnings
of objects" -- that's simply meaningless in Java context -- they point
to objects.

2. Unlike Java reference values, C pointers are just memory addresses.
Modern compilers give you syntactic icing on top, like remembering the
type of data poined to and various cast operations, but you're pretty
much free to discard all that sugar and do whatever you want with them
(e.g. work out the address of the second byte in the third field of the
fifth element of an array of records. Sorry, structs.).

C++ also has references, in addition to pointers. C++ references are
nothing at all like Java reference values. They are more like references
in Comp. Sci. definition. You cannot re-point a reference and whatever
you do to the reference you're doing to underlying data.

Both pointers and refences in C++ can point to/reference any data
type (including pointers), not just objects.

Dima
 
T

Thomas G. Marshall

Dimitri Maziuk said something like:

....[rip]...
1. Java "reference values (often just _references_)" are pointers
to objects and there are only two things you can do with them: point
one to an object and access object's members via it (basically; there's
also comparisons which may or may not be done by object's members,
instanceof and string concatenation). They don't point to "the beginnings
of objects" -- that's simply meaningless in Java context -- they point
to objects.

While this is obviously correct, I believe that the layman explanation of
references pointing to solely the beginnings of objects is not a terrible
one. In C, for example, when you have a pointer to a struct, you have a
pointer to it's first location in memory. So it's an understood programming
idiom.

In java, you cannot take the address of, say, the third int in an object.

Hmmm, I'm guessing here, but a C99 purist might be able to argue that the C
pointer to a struct is not to the first location of a struct but to the
struct itself, because you cannot do anything legal but dereference the
entire struct or sub components of it with "->". You can *obviously* do
much more, but it all would require modifying the pointer by casting it to
something else. {shrug}. If so, I don't see much the point in pedantically
pointing it out.

On the flip side of all this, I don't believe that the point of C and Java's
PbV is a pedantic one, but this reopens a (hopefully) dead issue in this
thread.


....[rip]...
C++ also has references, in addition to pointers. C++ references are
nothing at all like Java reference values.

No one is contesting that. Even the JLS refers to the reference as a
pointer.

....[rip]...
 
C

Chris Smith

Dimitri Maziuk said:
I have, and I much prefer Delphi language guide that says object
references are "pointers that are automatically dereferenced"

And that's Delphi. It doesn't make sense to say that in Java. In Java,
a reference is only dereferenced if you apply an operation that
dereferences it. Those operations include the "." and "[]" symbols, and
Java 1.5's unboxing conversions. Otherwise, there is no dereferencing
that takes place.
JLS says that there are three "reference types" and that reference types
are *not* primitive types. It says that "reference values" are pointers
to objects.

Well, to be precise, it says that a reference value is either a pointer
to an object, or null.
Then you trace down the three "reference types" and work out
that in the end they're all instantiated as objects, so "reference values"
is what you're interested in.

I'm a little lost by your use of words here. References are just
values. Creating a reference doesn't necessarily imply instantiating an
object. You seem to be talking about something that you call
instantiating a reference type... for which I can't find any logical
meaning. In any case, it's not normal Java terminology.
In 2.10 JLS says that for every parameter, a new variable is created and
initialized when method is invoked. Thankfully, I know enough about
stack-based languages to understand what they mean by that.

I see that language in 4.12.3 in the JLS 3rd edition, and 4.5.3 in the
JLS 2nd edition. Are you sure you're reading the same JLS as the rest
of us?

In any case, I don't know whether you understand this or not. In any
case, this language in the spec doesn't imply a stack. It may or may
not be implemented with the CPU stack (though it obviously is most of
the time for performance reasons). It is similar to, but not quite, an
implementation of the generic computer science concept of stacks --
differing only in that local variables within the current stack frame
may be accessed in any order.

It means just what it says. Every time a method is called, the actual
parameters are copied into the formal parameters, which function as
separate variables. This is pretty close to exactly the definition of
pass by value, as it turns out.
So it's the same as Delphi sans var parameters and clarity of
documentation.

I don't know much about Delphi, but the language above about references
being automatically dereferenced suggests that it's not exactly the
same. If use of a reference as an lvalue in Delphi modifies the object
and not the reference, then it is different in precisely the way that is
needed in order to make Delphi qualify as pass by reference in a way
that Java does not.

Incidentally, if you're look for documentation that makes intuitive
sense to you, then the language spec may not be the place the look.
There are good books on Java, including for example Bruce Eckel's which
is free online. However, if you're looking for precise definition of
language behavior, the spec is the place to look.
What crusade? -- I'm just keepin' up a polite conversation. Prompted
by your statement that "Java references point to the beginnings of
objects, in C++ you can do pointer arithmetics..." It's bad, OK?

I agree that the statement you're quoting is a poor description. It
mixes implementation with specification (in much the same way as the
stack comment above).
2. Unlike Java reference values, C pointers are just memory addresses.
Modern compilers give you syntactic icing on top, like remembering the
type of data poined to and various cast operations, but you're pretty
much free to discard all that sugar and do whatever you want with them
(e.g. work out the address of the second byte in the third field of the
fifth element of an array of records. Sorry, structs.).

I'm sure someone will jump in and point out that the above is only true
if you're willing to achieve undefined behavior according to the C
standard. Nevertheless, your point remains true.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
D

Dimitri Maziuk

Chris Smith sez:
Dimitri Maziuk said:
I have, and I much prefer Delphi language guide that says object
references are "pointers that are automatically dereferenced"

And that's Delphi. It doesn't make sense to say that in Java. In Java,
a reference is only dereferenced if you apply an operation that
dereferences it. Those operations include the "." and "[]" symbols, and
Java 1.5's unboxing conversions. Otherwise, there is no dereferencing
that takes place.

What they mean by "automatically dereferenced" is you don't write
(using C syntax as it's probably more familiar) myobj->myfunc(),
you write myobj.myfunc(). It doesn't make sense in Java because
there is no "->" in Java, yet if reference values are pointers
(as per JLS) "." must involve dereferencing behind the scenes.
I see that language in 4.12.3 in the JLS 3rd edition, and 4.5.3 in the
JLS 2nd edition. Are you sure you're reading the same JLS as the rest
of us?

Sun's website, 1.5 docs, JLS 3rd edition, #4.3 "reference types and
values" and #8.4 "formal parameters".
I don't know much about Delphi, but the language above about references
being automatically dereferenced suggests that it's not exactly the
same. If use of a reference as an lvalue in Delphi modifies the object
and not the reference, then it is different in precisely the way that is
needed in order to make Delphi qualify as pass by reference in a way
that Java does not.

No, it's just that Delphi documentation is written for people who are
used to regular meaning of certain terms -- as opposed to Java meaning.

In Delphi "by reference" means "var parameter". The default is by
value and language guide explains that "by value" involves making
a copy of the variable. Like in Java, assignment to a "class type
variable" (Java "reference value") re-points the pointer. You can't
change that because like Java Delphi does not allow operator
overloading. (I'm assuming by "lvalue" you mean "can be assigned to").

What makes the comparison interesting is that both languages were
developed at the same time and both teams came up with the same
way of handling objects.

Dima
 
C

Chris Smith

Dimitri Maziuk said:
What they mean by "automatically dereferenced" is you don't write
(using C syntax as it's probably more familiar) myobj->myfunc(),
you write myobj.myfunc(). It doesn't make sense in Java because
there is no "->" in Java, yet if reference values are pointers
(as per JLS) "." must involve dereferencing behind the scenes.

Depends on what you mean by "behind the scenes". The Java "." operator
is a dereferencing operator. It no more dereferences pointers behind
the scenes than the + operator adds two numbers behind the scenes.
Rather, it does it in plain view.

Granted, some confusion is caused by its looking the same as a C
operator that does not dereference pointers... but that's nothing more
than a common mistake.
Sun's website, 1.5 docs, JLS 3rd edition, #4.3 "reference types and
values" and #8.4 "formal parameters".

I was just confused because the language you mentioned doesn't appear in
section 4.3 (which is, indeed, titled "Reference Types and Values" so we
must be looking at the same thing. It really doesn't matter, since the
language does appear in two other places in the specification.
No, it's just that Delphi documentation is written for people who are
used to regular meaning of certain terms -- as opposed to Java meaning.

By this, do you mean people who expect the "." to act in the same way it
does in C? I would be terribly confused by someone describing Java
references as being "automatically" dereferenced. I'm certainly glad
the specification doesn't do so. This would imply that dereferencing of
a reference should happen in all places where references are used, such
as during assignment or comparison. That would cause references to be
essentially aliases, far more akin to C++ than Java.

Instead, dereferencing happens in the three places I mentioned: use of
the "." or "[]" operators, or during Java 1.5 unboxing conversions.
(I'll add that dereferencing may also occur behind the scenes in String
conversion, if the reference is non-null and its type is not already
String.)
What makes the comparison interesting is that both languages were
developed at the same time and both teams came up with the same
way of handling objects.

By which you mean that objects are in control of their own lifetimes and
can't be stored in variables, and that they can only be accessed through
references? This is certainly not new to Java nor Delphi, but is in
fact an essential component of any truly object-oriented programming
language. C++ was more groundbreaking in ignoring it than Java or
Delphi in keeping it.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
R

Roedy Green

By this, do you mean people who expect the "." to act in the same way it
does in C? I would be terribly confused by someone describing Java
references as being "automatically" dereferenced.

In C/C++ you are constantly very much aware of all the levels of
derferenencing. It is like balancing plates. In Java, you can just
close your eyes and forget about it. It all happens effortlessly. I
think that is where the idea got started there must be some behind the
scenes magic. The "magic" is really just pruning to the essential
addressing support.
 
D

Dimitri Maziuk

Chris Smith sez:
Depends on what you mean by "behind the scenes". The Java "." operator
is a dereferencing operator. It no more dereferences pointers behind
the scenes than the + operator adds two numbers behind the scenes.
Rather, it does it in plain view.

Heh, you're right. I guess I got a little distracted by that C trap.

....
By this, do you mean people who expect the "." to act in the same way it
does in C?

Pretty much, yes, except it's a Pascal-derived language. So you have

x : value
x.y : access y member of x
x^ : pointer (IIRC -- it's been a while)
x^.y : access y member of x via pointer (dereferencing)

But

obj : "class type", a special kind of pointer
obj.y: access y member of obj, automatic dereferencing (no '^')
By which you mean that objects are in control of their own lifetimes and
can't be stored in variables, and that they can only be accessed through
references?

No, that all objects are dynamically allocated on the heap and accessed
only via a special kind of pointer -- with all attendant baggage, and
the syntax for them looks like they're stack-based values.

As opposed to C++ where you have a choice of allocating on stack or heap,
with different syntax, and "pass by value" does not mean "except if you're
passing an object in which case you're passing the pointer by value and
the subroutine can modify the object via the pointer".

Dima
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top