Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25484 > unrolled thread

Re: Java vs C++

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-07 15:08 +1300
    Re: Java vs C++ Arne Vajhøj <arne@vajhoej.dk> - 2011-02-06 21:19 -0500
      Re: Java vs C++ Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-02-09 01:07 +0800
      Re: Java vs C++ Arne Vajhøj <arne@vajhoej.dk> - 2011-02-07 19:44 -0500
      Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-07 15:53 +1300
        Re: Java vs C++ Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-02-08 10:25 +0000
          Re: Java vs C++ Lew <noone@lewscanon.com> - 2011-02-08 07:53 -0500
        Re: Java vs C++ Esmond Pitt <esmond.pitt@bigpond.com> - 2011-02-08 10:26 +1100
          Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-08 16:17 +1300
            Re: Java vs C++ Esmond Pitt <esmond.pitt@bigpond.com> - 2011-02-08 16:51 +1100
        Re: Java vs C++ Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-02-06 22:06 -0500
        Re: Java vs C++ "Mike Schilling" <mscottschilling@hotmail.com> - 2011-02-06 22:42 -0800
        Re: Java vs C++ Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-02-07 21:20 -0500
        Re: Java vs C++ Arne Vajhøj <arne@vajhoej.dk> - 2011-02-06 22:07 -0500
          Re: Java vs C++ Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-07 19:07 +1300

#25484 — Re: Java vs C++

In message <4d4f43d9$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 18:28, Lawrence D'Oliveiro wrote:
>
>> In message<iil9uk$b6m$1@news.eternal-september.org>, Joshua Cranmer
>> wrote:
>>
>>> Try, for example, implementing both List<String>  and List<Character> 
>>> in the same class. Java will tell you that you cannot do it. C++, on the
>>> other hand, wouldn't bat an eye.
>>
>> Why does Java impose such a pointless restriction?
> 
> 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.

[toc] | [next] | [standalone]

#25497

On 06-02-2011 21:08, Lawrence D'Oliveiro wrote:
> In message<4d4f43d9$0$23755$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 18:28, Lawrence D'Oliveiro wrote:
>>> In message<iil9uk$b6m$1@news.eternal-september.org>, Joshua Cranmer
>>> wrote:
>>>> Try, for example, implementing both List<String>   and List<Character>
>>>> in the same class. Java will tell you that you cannot do it. C++, on the
>>>> other hand, wouldn't bat an eye.
>>>
>>> Why does Java impose such a pointless restriction?
>>
>> It is given by the use of type erasure.
>
> 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

[toc] | [prev] | [next] | [standalone]

#25545

On 2/8/11 8:53 PM, Lew wrote:
> The problem with reifiable types is that it's too easy to do a
> half-assed job of your type analysis, thus resulting in the runtime
> errors to which Andreas alludes. Besides, all you need to do to get
> runtime typing is to include a runtime type token as a final member of
> your class and Bob's your uncle. Like so much else in Java, that just
> means you have to *think* and act for yourself, and type a few extra
> lines of code. Don't sprain your finger with that extra typing, whiners!

I agree that type erasure is not a huge liability in Java.  As long as 
you always use the generic type as a generic rather than raw type, 
compile time checking will do the job.

However, type erasure does limit what you can do via reflection, which 
is something very important at times.  Another advantage of reified 
types is the ability to use generics efficiently with value types, 
rather than having to box them.

Of course, Java doesn't have user-defined value types, but it would be 
potentially useful even for the built-in ones.

As in all cases, it's not _universally_ useful.  But they are worth 
having reified types, IMHO.

Pete

[toc] | [prev] | [next] | [standalone]

#25713

On 07-02-2011 01:07, Lawrence D'Oliveiro wrote:
> In message<4d4f61fb$0$23756$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> On 06-02-2011 21:53, Lawrence D'Oliveiro wrote:
>>> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>>> As explained numerous times then Java generics and C++ templates
>>>> are somewhat different.
>>>
>>> The only differences arise from limitations of Java, nothing more.
>>
>> No. The differences arise from different decisions on what they
>> wanted.
>
> The Java designers wanted everything that C++ templates offered. The only
> parts they omitted were the ones they couldn’t have.

Why do you think that?

They implemented something very different.

Arne

[toc] | [prev] | [next] | [standalone]

#25821

In message <4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

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

The only differences arise from limitations of Java, nothing more.

[toc] | [prev] | [next] | [standalone]

#25912

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> Because the whole “raw types” concept detracts from and weakens
> the coherence of the type system.

The "problem" about type-erasure is over-rated.

Suppose, an instance created so: Object o = new ArrayList<String>();
actually "knew" that it was an ArrayList of Strings (and not just
that it was an ArrayList, as it does now).
Then you would get a *runtime*-Error, if you tried to cast "o" to
ArrayList<Integer>, later.  But generics aren't about runtime errors.
They are about being able to prevent some runtime-errors, by turning
them into compile-time errors. So, giving *still runtime*-errors for
casting between generic types of incompatible parametrizations is only
little win over giving runtime-errors on element-use.

[toc] | [prev] | [next] | [standalone]

#26189

Andreas Leitgeb wrote:
> The "problem" about type-erasure is over-rated.
>
> Suppose, an instance created so: Object o = new ArrayList<String>();
> actually "knew" that it was an ArrayList of Strings (and not just
> that it was an ArrayList, as it does now).
> Then you would get a *runtime*-Error, if you tried to cast "o" to
> ArrayList<Integer>, later.  But generics aren't about runtime errors.
> They are about being able to prevent some runtime-errors, by turning
> them into compile-time errors. So, giving *still runtime*-errors for
> casting between generic types of incompatible parametrizations is only
> little win over giving runtime-errors on element-use.

I'm very glad you made that point.  I am glad we have type erasure in Java. 
It forces you to deal with type assertions at compile time.

The problem with reifiable types is that it's too easy to do a half-assed job 
of your type analysis, thus resulting in the runtime errors to which Andreas 
alludes.  Besides, all you need to do to get runtime typing is to include a 
runtime type token as a final member of your class and Bob's your uncle.  Like 
so much else in Java, that just means you have to *think* and act for 
yourself, and type a few extra lines of code.  Don't sprain your finger with 
that extra typing, whiners!

-- 
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

[toc] | [prev] | [next] | [standalone]

#25941

On 7/02/2011 5:07 PM, Lawrence D'Oliveiro wrote:
> The Java designers wanted everything that C++ templates offered.

It should be obvious from the design that they wanted a great deal more 
than that. They wanted a coherent type system for a start, which C++ 
templates don't have, and they wanted compile-time safety, which 
*requires* a coherent type system. That's what all the T super X and T 
extends Y stuff is for - so the compiler can do type algebra. None of 
this appears in C++ whatsoever.

It is totally and utterly wrong misleading to think of Java Generics and 
C++ templates as similar. They are really polar opposites. C++ templates 
generate new types. Java Generics restrict existing types.

[toc] | [prev] | [next] | [standalone]

#26081

In message <4d507f8a$0$32793$c30e37c6@exi-reader.telstra.net>, Esmond Pitt 
wrote:

> On 7/02/2011 5:07 PM, Lawrence D'Oliveiro wrote:
>
>> The Java designers wanted everything that C++ templates offered.
> 
> It should be obvious from the design that they wanted a great deal more
> than that. They wanted a coherent type system for a start, which C++
> templates don't have ...

In that case, they went backwards. Because the whole “raw types” concept 
detracts from and weakens the coherence of the type system.

> That's what all the T super X and T extends Y stuff is for - so the
> compiler can do type algebra. None of this appears in C++ whatsoever.

What one hand giveth, the other taketh away...

[toc] | [prev] | [next] | [standalone]

#26199

On 8/02/2011 2:17 PM, Lawrence D'Oliveiro wrote:
> In that case, they went backwards. Because the whole “raw types” concept
> detracts from and weakens the coherence of the type system.

It provides backwards compatibility. Without that the product would be 
unusable. It is possible to wish that the entire product was designed at 
the same time, but it wasn't. In any case your contention was mistaken.

The designers also went forwards a very considerable distance by 
providing generic classes that have provable type relationships among 
them. C++ simply doesn't have that. You need to stop overlooking this point.

[toc] | [prev] | [next] | [standalone]

#25972

On 02/06/2011 09:53 PM, Lawrence D'Oliveiro wrote:
> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> As explained numerous times then Java generics and C++ templates
>> are somewhat different.
>
> The only differences arise from limitations of Java, nothing more.

That is not an assertion you can make. Java generics and C++ templates 
are different because their designers wanted them to be different. It 
would totally have been possible to implement C++ templates in Java--but 
the designers decided that was not what they wanted to do. I don't know 
what they would have done if they had added generics from the start, but 
given all of the issues seen with templates, I am willing to guess that 
it would still act nothing like templates do (i.e., as Java generics do 
know, just with fully reified types).

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#25976

"Lawrence D'Oliveiro" <ldo@geek-central.gen.new_zealand> wrote in message 
news:iio27n$g2f$2@lust.ihug.co.nz...
> In message <4d4f61fb$0$23756$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>
>> On 06-02-2011 21:53, Lawrence D'Oliveiro wrote:
>>
>>> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj 
>>> wrote:
>>>
>>>> As explained numerous times then Java generics and C++ templates
>>>> are somewhat different.
>>>
>>> The only differences arise from limitations of Java, nothing more.
>>
>> No. The differences arise from different decisions on what they
>> wanted.
>
> The Java designers wanted everything that C++ templates offered.

"God, if only we could have gotten code bloat and terminally confused the 
separation between compiler and linker!"
 

[toc] | [prev] | [next] | [standalone]

#25981

On 02/07/2011 01:07 AM, Lawrence D'Oliveiro wrote:
> The Java designers wanted everything that C++ templates offered. The only
> parts they omitted were the ones they couldn’t have.

No, it is very possible to have fully implemented C++ templates. As C++ 
templates are basically a semantically-aware macro processor whose code 
is created at instantiation as opposed to definition, you just have to 
generate the class files at template instantiation as opposed to class 
definition. That basically boils down to "twiddle a few bits in the 
class file", so it's no more invasive than generics was.

If you argue that wasn't an option because they didn't want to rewrite 
the collections API (which .NET decided to do), it's still possible to 
leverage roughly the same effect with more invasive modifications to the 
bytecode. You can get reified types by creating a new method info 
structure which captures the generic arguments passed into the method 
(for constructors, this would be the generic class passed in), which you 
could store in an appropriate synthetic variable. You could even get the 
duck typing nature of templates with invokedynamic (well, it wouldn't 
work for primitive types, but generics already through those out the 
window).

They could have had all of C++ templates. Clearly, they did not feel the 
benefits of full template support would be worth the cost of implementation.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [next] | [standalone]

#26080

On 06-02-2011 21:53, Lawrence D'Oliveiro wrote:
> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>> As explained numerous times then Java generics and C++ templates
>> are somewhat different.
>
> The only differences arise from limitations of Java, nothing more.

No. The differences arise from different decisions on what they
wanted.

Arne

[toc] | [prev] | [next] | [standalone]

#26169

In message <4d4f61fb$0$23756$14726298@news.sunsite.dk>, Arne Vajhøj wrote:

> On 06-02-2011 21:53, Lawrence D'Oliveiro wrote:
>
>> In message<4d4f56ac$0$23758$14726298@news.sunsite.dk>, Arne Vajhøj wrote:
>>
>>> As explained numerous times then Java generics and C++ templates
>>> are somewhat different.
>>
>> The only differences arise from limitations of Java, nothing more.
> 
> No. The differences arise from different decisions on what they
> wanted.

The Java designers wanted everything that C++ templates offered. The only 
parts they omitted were the ones they couldn’t have.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web