«

Arne Vajhøj wrote:
> Daniel Pitts wrote:
>> Arne Vajhøj wrote:
>>> Donkey Hot wrote:
>>>> Wow. Well I'll be damned, because I'm still with 1.4.2 with my day
>>>> work..
>>>>
>>>> But still. TreeList does not "extend" List, it implements it.
>>>> Generics is hard. Maybe harder than C++ templates?
>>>
>>> Possible, but safer to use.
>> Actually, its easier than C++ templates, and less safe to use
>>
>> C++ templates allow much more flexibility and expressiveness (you can
>> create a specialization, for example), but are therefor more
>> complicated and confusing.
>
First, in-case I didn't make it clear, I'm not actually saying one is
better than the other. I think they both have advantages and
disadvantages. As well as the fact that they work better for the
context they're designed for, not the context of the other language

> C++ templates can be very complex. But they can also be very simple. And
> the simple ones does not have the Java "how do I get rid of this
> warning" problems.
>
>> Java Generics are simply extra run-time information that you can
>> choose to ignore at compile time,
>
> That description does not exactly match my understanding of type
> erasure.
You're right, I meant to say it a different way, but it came out wrong.
>
>> and therefor run the risk of runtime
>> ClassCastException (when used incorrectly), where C++ templates are
>> expressed and enforced at compile time, so you'll get a compiler error
>> isntead.
>
> I can not right away think of a case where Java compile time check
> is weaker than C++ compile time check.
>
> Arne
Java programmers can use raw types. Template parameters on classes are
never optional*, and so you always have compile-time static checking.


* default values can be optionally specified, but the value itself is
always there.
--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts wrote:
> Arne Vajhøj wrote:
>> I can not right away think of a case where Java compile time check
>> is weaker than C++ compile time check.

> Java programmers can use raw types. Template parameters on classes are
> never optional*, and so you always have compile-time static checking.
>
> * default values can be optionally specified, but the value itself is
> always there.

You mean ArrayList, HashMap in pre-1.5 syntax ?

Arne

Arne Vajhøj wrote:
> Daniel Pitts wrote:
>> Arne Vajhøj wrote:
>>> I can not right away think of a case where Java compile time check
>>> is weaker than C++ compile time check.
>
>> Java programmers can use raw types. Template parameters on classes are
>> never optional*, and so you always have compile-time static checking.
>>
>> * default values can be optionally specified, but the value itself is
>> always there.
>
> You mean ArrayList, HashMap in pre-1.5 syntax ?
>
> Arne
I mean any raw type, but those are good examples.
In c++, you can't have a std::map without specifying key/value types.
Of course, you can't do that in Java and support legacy code.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

Daniel Pitts wrote:
> Arne Vajhøj wrote:
>> Daniel Pitts wrote:
>>> Arne Vajhøj wrote:
>>>> I can not right away think of a case where Java compile time check
>>>> is weaker than C++ compile time check.
>>
>>> Java programmers can use raw types. Template parameters on classes
>>> are never optional*, and so you always have compile-time static
>>> checking.
>>>
>>> * default values can be optionally specified, but the value itself is
>>> always there.
>>
>> You mean ArrayList, HashMap in pre-1.5 syntax ?

> I mean any raw type, but those are good examples.
> In c++, you can't have a std::map without specifying key/value types. Of
> course, you can't do that in Java and support legacy code.

Java choose to make <Object> default for backwards compatibility, but
you can specify a restriction on the template parameter so that is
not possible.

And C++ does have Object. It is called void*.

It is not exactly type safety that characterize this code:

#include <iostream>
#include <vector>
#include <string>

using namespace std;

int main()
{
int iv = 123;
double xv = 123.456;
string sv = "ABC";
vector<void *> v;
v.push_back(&iv);
v.push_back(&xv);
v.push_back(&sv);
cout << *((int*)v[0]) << endl;
cout << *((double*)v[1]) << endl;
cout << *((string*)v[2]) << endl;
return 0;
}

But I admit that C++ does not default to void* like Java
default to Object.

The curse of backwards compatibility.

And you do get a warning on it.

Arne

Arne Vajhøj wrote:
> Daniel Pitts wrote:
>> Arne Vajhøj wrote:
>>> Daniel Pitts wrote:
>>>> Arne Vajhøj wrote:
>>>>> I can not right away think of a case where Java compile time check
>>>>> is weaker than C++ compile time check.
>>>
>>>> Java programmers can use raw types. Template parameters on classes
>>>> are never optional*, and so you always have compile-time static
>>>> checking.
>>>>
>>>> * default values can be optionally specified, but the value itself
>>>> is always there.
>>>
>>> You mean ArrayList, HashMap in pre-1.5 syntax ?
>
>> I mean any raw type, but those are good examples.
>> In c++, you can't have a std::map without specifying key/value types.
>> Of course, you can't do that in Java and support legacy code.
>
> Java choose to make <Object> default for backwards compatibility, but
> you can specify a restriction on the template parameter so that is
> not possible.
List<Object> is not the same as a raw List.
>
> And C++ does have Object. It is called void*.
Different concepts. void * an untyped pointer. Object is a base class.
They have similar uses, but are fundamentally different.
>
> It is not exactly type safety that characterize this code:
>
> #include <iostream>
> #include <vector>
> #include <string>
>
> using namespace std;
>
> int main()
> {
> int iv = 123;
> double xv = 123.456;
> string sv = "ABC";
> vector<void *> v;
> v.push_back(&iv);
> v.push_back(&xv);
> v.push_back(&sv);
> cout << *((int*)v[0]) << endl;
> cout << *((double*)v[1]) << endl;
> cout << *((string*)v[2]) << endl;
> return 0;
> }
This code is broken for many reasons. The chances of seeing this in
production code *should* be zero. For one thing, you should use
dynamic_cast, or using boost::any instead of void *

> But I admit that C++ does not default to void* like Java
> default to Object.
>
> The curse of backwards compatibility.
Indeed. Thank god I can still compile Java 1.1 source code today
>
> And you do get a warning on it.
Yes, you do.

--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Donkey Hot schreef:
| Donkey Hot <> wrote in
| news:Xns9AB647A18320SH15SGybs1ysmajw54s5@194.100.2 .89:
|
|> Donkey Hot <> wrote in
|> news:Xns9AB63E015976SH15SGybs1ysmajw54s5@194.100.2 .89:
|>
|>> wrote in news:67e0720b-9863-4b69-b820-f2d8a8608da3
|>> @h1g2000prh.googlegroups.com:
|>>
|>>> I am new to Java 5 Programming and I am facing an issue with Generics
|>>> as below
|>>>
|>>> In my java application , My main class is as below (I have
| replicated
|>>> the original scenario in the test program here )
|>>>
|>>> import java.util.ArrayList;
|>>>
|>>> public class TestGeneric {
|>>> public static void main(String args[]) {
|>>>
|>>> ArrayList al = new ArrayList ();
|>>> TestClass tc = new TestClass();
|>>> al = tc.getList();
|>>> System.out.println(al);
|>>>
|>>> }
|>>> }
|>>>
|>>>
|>>> And the TestClass is as below
|>>>
|>>> import java.util.ArrayList;
|>>>
|>>> public class TestClass {
|>>>
|>>> public ArrayList getList() {
|>>>
|>>> ArrayList list1 = new ArrayList();
|>>> list1.add("Hello1");
|>>> list1.add("Hellow1");
|>>> ArrayList list2 = new ArrayList ();
|>>> list2.add("Hello2");
|>>> list2.add("Hellow2");
|>>> ArrayList list3 = new ArrayList ();
|>>>
|>>> list3.add(list1);
|>>> list3.add(list2);
|>>> return list3;
|>>>
|>>> }
|>>>
|>>> }
|>>>
|>>> The method getList in TestClass returns as ArrayList of ArrayLists .
|>>> If I need to implement the above two class using Generics , how Can I
|>>> go about it .
|>>>
|>>> Will it be ArrayList <ArrayList > al = new ArrayList <ArrayList>
|>>> (); in the main program ? or
|>>> ArrayList <Object > al = new ArrayList <Object> ();
|>>> Please help
|>>>
|>>> Thanks
|>>> Sam
|>>>
|>>>
|>> ArrayList<ArrayList<String>>
|>>
|>>
|> Actually:
|>
|> List<List<String>> al = new List<List<String>>() ;
|>
|> ArrayList is the implementation, but you could use the interface List
| in
|> the variable declaration.
|>
|>
|>
|
| Sorry
|
| List<List<String>> al = new ArrayList<TreeList<String>>() ;

No, you meant

List<List<String>> al = new ArrayList<List<String>>();

and then when you instantiate one of the lists to go into that
ArrayList, you can still choose between ArrayList and TreeList.

A more informative name than ‘al’ would be good, though.

H.
- --
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4-svn0 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFITQXpe+7xMGD3itQRAj6fAJ0XF//Y2Xw8PIikWWFg1EeUY5y6FQCeIKL8
VxZITRUh8+Pgc3LgtTDeztk=
=S14+
-----END PGP SIGNATURE-----

Daniel Pitts wrote:
> Arne Vajhøj wrote:
>> Daniel Pitts wrote:
>>> Arne Vajhøj wrote:
>>>> Daniel Pitts wrote:
>>>>> Arne Vajhøj wrote:
>>>>>> I can not right away think of a case where Java compile time check
>>>>>> is weaker than C++ compile time check.
>>>>
>>>>> Java programmers can use raw types. Template parameters on classes
>>>>> are never optional*, and so you always have compile-time static
>>>>> checking.
>>>>>
>>>>> * default values can be optionally specified, but the value itself
>>>>> is always there.
>>>>
>>>> You mean ArrayList, HashMap in pre-1.5 syntax ?
>>
>>> I mean any raw type, but those are good examples.
>>> In c++, you can't have a std::map without specifying key/value types.
>>> Of course, you can't do that in Java and support legacy code.
>>
>> Java choose to make <Object> default for backwards compatibility, but
>> you can specify a restriction on the template parameter so that is
>> not possible.
> List<Object> is not the same as a raw List.

True.

But for all the simple usage it is.

>>
>> And C++ does have Object. It is called void*.
> Different concepts. void * an untyped pointer. Object is a base class.
> They have similar uses, but are fundamentally different.

Given the differences between Java and C++ I think they are as
close as they can be.

>> It is not exactly type safety that characterize this code:
>>
>> #include <iostream>
>> #include <vector>
>> #include <string>
>>
>> using namespace std;
>>
>> int main()
>> {
>> int iv = 123;
>> double xv = 123.456;
>> string sv = "ABC";
>> vector<void *> v;
>> v.push_back(&iv);
>> v.push_back(&xv);
>> v.push_back(&sv);
>> cout << *((int*)v[0]) << endl;
>> cout << *((double*)v[1]) << endl;
>> cout << *((string*)v[2]) << endl;
>> return 0;
>> }
> This code is broken for many reasons. The chances of seeing this in
> production code *should* be zero. For one thing, you should use
> dynamic_cast, or using boost::any instead of void *

The example is a bit unrealistic.

But it is valid C++ so it does show that C++ templates
are not necessarily type safe.

Arne

On Sat, 07 Jun 2008 17:59:30 -0400, Arne Vajhøj <>
wrote, quoted or indirectly quoted someone who said :

>> Java Generics are simply extra run-time information that you can choose
>> to ignore at compile time,
>
>That description does not exactly match my understanding of type
>erasure.

Generics are purely a compile time phenomenon. At run time there is
on type information, at least not in JDK 1.5 and 1.6. It may come in
1.7.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Roedy Green wrote:
> On Sat, 07 Jun 2008 17:59:30 -0400, Arne Vajhøj <>
> wrote, quoted or indirectly quoted someone who said :
>>> Java Generics are simply extra run-time information that you can choose
>>> to ignore at compile time,
>> That description does not exactly match my understanding of type
>> erasure.
>
> Generics are purely a compile time phenomenon. At run time there is
> on type information, at least not in JDK 1.5 and 1.6. It may come in
> 1.7.

Which is the opposite of what was written.

(and which Daniel also acknowledged that he got worded
wrong 2 weeks ago)

Arne