Java vs C++

[Lawrence D'Oliveiro]

dynamic_cast<foo>(bar) can throw this if bar is not really a foo. But
C++ lets you use the unsafe old (foo)bar cast from C, and if bar is not
really a foo, welcome to undefined behaviorville.

The fact remains, there IS an equivalent to ClassCastException in C++.

 

[Lawrence D'Oliveiro]

On 05-02-2011 23:13, Lawrence D'Oliveiro wrote:

In message<[email protected]>, Joshua Cranmer
wrote:

On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:


... templates and gener[ic]s are completely different beasts.

“Completely†as in “having nothing in common� Or is this some usage
of “completely†that I wasn’t aware of?

Please explain.

Templates in C++ are basically advanced macros--each invocation of a
template type regenerates the class, so a Foo<int> and a Foo<double>
are two completely different things.

They are different things in Java as well.

No. Same code.

Same code in C++ too, then.

No.

C++ will generate two classes with two sets of code.

(at least that is what common compilers do - I don't know if
the standard actually requires it to)

See, it’s clear you’re hung up on specifics of particular implementations,
not on how the language feature is defined at all.

 

[Arne Vajhøj]

What is long?

A simple data type.

But it is still a characteristics of array not of long.

Arne

 

[Arne Vajhøj]

But not “andâ€, “or†and “notâ€.

True.

But since practically none uses them in C++, then ...

Arne

 

[Lawrence D'Oliveiro]

It is given by the use of type erasure.

Which is purely a backward-compatibility mechanism. If I were to take two
copies of the definition of List<E>, and in one take out <E> and replace E
with String, and in the other replace it with Character, Java would have no
problem letting me declare a class that implements both interfaces. But try
doing it directly with the generic, and it won’t.

Java draws a distinction between the two cases where there really shouldn’t
be any distinction. That’s what generics are for, after all—they’re there to
save work for the programmer, not create it.

See, Java started out as not wanting to be like C++: it would take the good
stuff from C++, and leave the rest behind.

But now, with the addition of generics, it’s clear Java wants to be more
like C++ after all. The only thing holding it back is not deliberate design
choices over functionality, but the dead hand of backward compatibility.

 

[Lawrence D'Oliveiro]

True.

But since practically none uses them in C++, then ...

I use them in all my C++ code.

 

[Lawrence D'Oliveiro]

A simple data type.

But it is still a characteristics of array not of long.

Which is a limitation that comes from a fixation on 32-bit architectures,
without a thought for 64-bit ones.

 

[Arne Vajhøj]

Most of the C/C++ code I deal with is open-source, and essentially all of
that is portable between 32-bit and 64-bit nowadays. As well as across non-
x86 architectures, for that matter.

Without ifdef's ????

Ironic, isn’t it, that the early Java slogan was "write once, run
everywhereâ€...

anywhere not everywhere

Arne

 

[Joshua Cranmer]

List<String> is a class, not an instance. In something like

List<String> L;

it is L that is the instance.

L is an instance of a class. List<String> is an instance of a type, a
type that is distinct from List (the raw type or the class type).

If you're having this much problems understanding me, I'm sure you'll be
having lots of fun when it comes to capture conversion. Just because two

See, how can you try to tell me what the difference is between Java and C++,
when you don’t understand it yourself?

I do very much understand it myself. My problem is that you have such a
broken understanding of Java that the terminology I normally use to
explain stuff is lost on you. Java is not C++, so don't come in with
your preconceived notions of C++ and argue that they should apply to Java.

 

[Arne Vajhøj]

It is 8086 architecture not 80286 architecture.

By “16-bit†I take it you specifically mean “Windows/Intel 16-bitâ€, i.e. the
segmented 80286 architecture (spit). That was the only major 16-bit
architecture I’m aware of that made portability difficult.

Windows has nothing to do with CPU architecture.

And the problem Silvio talks about (undefined sizes) is
not related to segmented memory.

Arne

 

[Joshua Cranmer]

See, it’s clear you’re hung up on specifics of particular implementations,
not on how the language feature is defined at all.

No, it's in the definition of C++ templates. And I quote §14, clause 1:
A template defines a family of classes, functions, or concept maps, or
an alias for a family of types.

As far as the standard is concerned, Foo<int> and Foo<long> would be
very distinct types. It might be that the compiler makes them one single
entity, but it can only do that under §1.9, clause 1:

The semantic descriptions in this International Standard define a
parameterized nondeterministic abstract machine. This International
Standard places no requirement on the structure of conforming
implementations. In particular, they need not copy or emulate the
structure of the abstract machine. Rather, conforming implementations
are required to emulate (only) the observable behavior of the abstract
machine as explained below.

i.e., "you don't have to actually implement this specification so long
as a valid program can't tell that you aren't."

See, it's clear you really haven't read the specs you're trying to
language lawyer with us on.

 

[Arne Vajhøj]

Which is purely a backward-compatibility mechanism.

Which does not change the fact - it just explains it.

If I were to take two
copies of the definition of List<E>, and in one take out<E> and replace E
with String, and in the other replace it with Character, Java would have no
problem letting me declare a class that implements both interfaces. But try
doing it directly with the generic, and it won’t.

Java draws a distinction between the two cases where there really shouldn’t
be any distinction. That’s what generics are for, after all—they’re there to
save work for the programmer, not create it.

Backward compatibility limit the available option.

See, Java started out as not wanting to be like C++: it would take the good
stuff from C++, and leave the rest behind.

But now, with the addition of generics, it’s clear Java wants to be more
like C++ after all.

Not really.

As explained numerous times then Java generics and C++ templates
are somewhat different.

Arne

 

[Arne Vajhøj]

I use them in all my C++ code.

I believe that.

With your language understanding that would be a good guess.

Arne

 

[Joshua Cranmer]

You seem to be confusing one particular way of implementing
generics/templates with the way the language feature is specified. Java
generics could be implemented by a preprocessor that spat out first-edition
Java code, for that matter. In fact, it effectively does, since the JVM
seems to know nothing about generics. Would you then say that third-edition
Java is nothing more than a “macro generator�

I make a minor distinction between syntactic sugar--a language feature
which is designed to replace specific syntax features for ease of coding
(e.g., for-each loops)--and macro processing, which is generally
unrestricted code or text generation. Generics are syntactic sugar, in
that it only generates code in a "few" select places as opposed to
wholesale code production.

 

[Joshua Cranmer]

I use them in all my C++ code.

And you, sir, are why we cannot have nice things. ;-)

 

[Arne Vajhøj]

Which is a limitation that comes from a fixation on 32-bit architectures,
without a thought for 64-bit ones.

It is not an assumption about 32 bit architecture. 32 bit
architecture limits it more than the Java rule.

It is a bad assumption about memory availability in general.

Arne

have set the limit far lower than it is

 

[Arne Vajhøj]

You seem to be confusing one particular way of implementing
generics/templates with the way the language feature is specified. Java
generics could be implemented by a preprocessor that spat out first-edition
Java code, for that matter.

Java generics could have been defined that way.

But they were not.

A generic Java class get compiled to a single
set of byte code.

Arne

 

[Arne Vajhøj]

On 05-02-2011 23:13, Lawrence D'Oliveiro wrote:
In message<[email protected]>, Joshua Cranmer
wrote:
On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:

... templates and gener[ic]s are completely different beasts.

“Completely†as in “having nothing in common� Or is this some usage
of “completely†that I wasn’t aware of?

Please explain.

Templates in C++ are basically advanced macros--each invocation of a
template type regenerates the class, so a Foo<int> and a Foo<double>
are two completely different things.

They are different things in Java as well.

No. Same code.

Same code in C++ too, then.

No.

C++ will generate two classes with two sets of code.

(at least that is what common compilers do - I don't know if
the standard actually requires it to)

See, it’s clear you’re hung up on specifics of particular implementations,
not on how the language feature is defined at all.

The language feature is what allows it.

That behavior would not be allowed in Java.

Arne

 

[Lawrence D'Oliveiro]

Java generics could have been defined that way.

But they were not.

See, you cannot even distinguish between “defined†and “implementedâ€.

 

[Lawrence D'Oliveiro]

I make a minor distinction between syntactic sugar--a language feature
which is designed to replace specific syntax features for ease of coding
(e.g., for-each loops)--and macro processing, which is generally
unrestricted code or text generation.

In that case, C++ templates are most certainly not macros.