Java or C++
Razii
Most people say C++ is dying. It's an ugly language. Java is the most popular
language today. Is that true?
Stefan Koennecke
What to learn? If you can, learn both.
Otherwise: for what purpose?
If you go for engineering software: there is almost no Java Soft out there.
all in C++, most still in C and fortran.
If you go for e-WhatEver: almost no way around Java.
You want an easy way, use already build APIs? Go for Java. There are more
FREE APIs published for that.
You want FREE Tools (IDEs and stuff, DOCs)? Go for Java! It's ALL on the
web!
Enjoy!
Stefan.
Razii <raz...@swbell.net> schrieb in im Newsbeitrag:
qii4dtcg9jhr32qdb...@4ax.com...
Greg Comeau
Most people also say they've seen ghosts. Is that true?
I would learn both languages if possible.
I would also lay out my needs and goals, etc.
--
Greg Comeau Comeau C/C++ 4.2.45.2 "it's so close"
ONLINE COMPILER ==> http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo! NEW: Try out our C99 mode!
com...@comeaucomputing.com http://www.comeaucomputing.com
Marco Schmidt
<st...@nb.sympatico.ca> wrote:
>If you go for engineering software: there is almost no Java Soft out there.
>all in C++, most still in C and fortran.
In Real Life, there also is a lot of Cobol software.
I'd like to add that C++ is more complex but also more powerful than
Java. A C++ programmer has to learn more to master his language or, to
put it another way, there are more errors that can be made. This
doesn't make either language better than the other.
Regards,
Marco
--
Java programming tips (last modified 2001-03-30):
http://jiu.sourceforge.net/javatips.html
Per Velschow
First of all, I hope you realize that you you are posting to language
specific newsgroups. Thus, you should expect to get at lot of biased
replies. :-)
I will try to be as unbiased as possible since I have used and like both C++
and Java a lot. I have been programming for 2-3 years in Java and a little
less than a year in C++. I had a little experience with C++ when I started
programming heavily in Java. And to tell you the truth; I loved Java so much
that I hoped I'd never return back to C++.
Alas, my boss wanted me to switch to a C++ project. I started out swearing a
lot because of all the nice things I was missing from my Java-time. Among
the major features I was missing in C++ was garbage collection, interfaces,
inner classes, and most of all the strong type-checking for exceptions. I
also missed some minor features such as "final methods", "blank final
members/variables", "try-catch-finally", the parent of all classes "Object",
in-class initialization of fields.
However, as I dwelved more and more into my C++ project, I discovered all
the nice features C++ had to offer that I didn't even know I was missing in
Java. By using destructors and smart pointers you can get a long way towards
a safe memory management discipline. Abstract classes can to some extend
implement Java's interfaces - though not completely and not as elegantly.
C++ also adds important features entirely missing in Java: templates,
operator overloading, "const" declarations, multiple inheritance (although
it is difficult to use it correctly), implicit conversions. These features
allow you to code highly generic programs with a high degree of type-safety
and to make very elegant use of user-defined datatypes.
You ask if C++ is ugly. That is of course a matter of taste. I would have to
say yes it's ugly but you will quickly get used to it. But you should not
choose Java instead of C++ because of this. In fact, one of the worst
choices that was ever made when defining the new language Java, was to
inherit the ugly syntax from C++.
What language should you learn? I'd have to say "learn both languages". If
time does not permit that, I would probably say "learn Java". This is mainly
because IMHO Java is easier to learn than C++ because it doesn't have as
many pitfalls.
Last of all, you can be absolutely sure that C++ is not about to die. I
would certainly consider Java to be more in danger of dying because it is a
newer language and partly because of Microsoft's attempt to replace Java
with its new language C#. There is alot of C++ code out there that has to be
maintained and extended - not to mention all the C-code that can quite
easily be used together with new C++ code. As far as I know, the number of
C++ programmers has grown at a constant pace ever since its invention - and
it is still growing.
Gosh... did I write all that? I must be passionate about Java and C++. :-)
Actually, I am dreaming about a language that combines all the benefits from
the two langauges (and some benefits from other languages as well) and
throws away all their disadvantages.
Bye for now. Feel free to make comments.
-- Per Velschow
Lawrence Foard
Making servlets etc. of course when all the Java using .com companies die...
On the otherhand if you want real power, and are willing to take the time
to understand it, C++. Java is like a bike with training wheels, may be
harder to fall down, but your never going to win a race.
C++ is only ugly if you use it wrong, for example when someone does
something like:
char *a = "/tmp/";
char *b = "file.tmp";
char *ptr = malloc(strlen(a) + strlen(b));
sprintf(ptr, "%s%s", a, b);
fopen(ptr,...
then they complain that it crashs, and how hard memory allocation is to deal
with. Thats because they arn't using C++ they are still using C and using it
badly.
In article <qii4dtcg9jhr32qdb...@4ax.com>,
Razii <raz...@swbell.net> wrote:
--
(: (: If miracles ain't happening it ain't a rave :) :)
POP/IMAP mail from your web phone www.2301.com
Looking for short / part time, consulting work, C++, Linux,
debugging, optimization http://www.farviolet.com/~entropy/resume2001.txt
Pete Becker
It's nonsense. Java's design decisions often prevent sound engineering.
For example, consider the problem of sorting arrays of arbitrary types.
In C we have qsort, which takes a pointer to a comparison function and
an untyped pointer that it uses to reach the actual data. You can use it
to sort the elements of an array of char, an array of double, an array
of structs, whatever. Write it once, use it everywhere. C++ has
std::sort, which can be used to sort an array of char, an array of
double, an array of objects, whatever. Write it once, use it everywhere.
In Java you have to write nine copies of the basic sort function: one
for arrays of chars, one for arrays of doubles, one for arrays of
Objects, etc. Oh, well, lots of cut and paste, and hope that when you
have to maintain it, you remember to change all nine copies. It's just a
matter of time before all this unsound engineering catches up with its
users.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Bart Kowalski
Beauty is in the eye of the beholder.
Bart.
Stefan Koennecke
I totally agree, because of my own experiences!
Except that I haven't switched back to C++ yet. But I guess I have to in a
few months.
Lets plan a new language. To bad that someone has to implement it! :-)
It's almost as good as dreaming about winning in a lottery. :)
Stefan
Per Velschow <p...@velschow.com> schrieb in im Newsbeitrag:
9atmha$2g6$1...@news.inet.tele.dk...
Stefan Koennecke
See java.lang.Compareable, java.util.Array for qsort&co.
In fact I would prefere the Java solution to that. It seems less "sensible"
to programming erros to me.
Stefan.
Pete Becker <peteb...@acm.org> schrieb in im Newsbeitrag:
3AD26031...@acm.org...
Razii
>It's nonsense. Java's design decisions often prevent sound engineering.
>For example, consider the problem of sorting arrays of arbitrary types.
>In C we have qsort, which takes a pointer to a comparison function and
>an untyped pointer that it uses to reach the actual data. You can use it
>to sort the elements of an array of char, an array of double, an array
>of structs, whatever. Write it once, use it everywhere. C++ has
>std::sort, which can be used to sort an array of char, an array of
>double, an array of objects, whatever. Write it once, use it everywhere.
>In Java you have to write nine copies of the basic sort function: one
>for arrays of chars, one for arrays of doubles, one for arrays of
>Objects, etc.
How about platform independent GUI in Java (i.e. Swing) or Network programming?
I have heard no language makes Network programming as simple as API that is part
of Java standard library. You can write GUI or Network applications once and
use it on unix, linux, windows,or mac, without making any changes to your
program.
Isn't that "write it once, use it everywhere"?
As for sorting, I think in Java you can convert int, long, double, byte, char,
etc., easily to Objects using classes like Integer, Character, Long, Double,
etc.
All objects then can by sorted using one method, not nine.
Is there anything a C++ can do that a Java programmer can't? (given the Java
programmer is allowed to use JNI and stuff). A C++ program apparently can't
create platform independent applications, but a Java programmer can. So what can
C++ programmer do that Java programmer can't?
Danil
> What language should one learn? Java or C++?
I've been learning C++ for four years, and have reached this conclusion:
C++ is hard.
I've been learning Java for a few months now - I don't know if it is hard
or not.
One advantage C++ has, which may be relevent, is a head start. My C++
library has a pretty good collection of books that describe common
problems in C++ code, why they are problems, and how to correctly
implement them.
I don't have the same confidence in my Java library - it's not even
close.
I guess that it is easier to go from nothing to "getting by" in Java.
There are a lot of classes available that can be used in interesting
projects, there are a lot of open sourced tools which will be useful in
Java development which are written in the language (you can read the
source to learn more about how the language works).
I also guess that C++ has the shorter path to "programming well" because
of the richer knowledge of idioms. As the Java community gets more
experience, that advantage may disappear.
Danil
Razii
> Java is like a bike with training wheels, may be
>harder to fall down, but your never going to win a race.
Once again, a C++ program apparently can't create platform independent
applications, but a Java programmer can. What can C++ programmer do that Java
xinfo
C++ *very* recently and it has been an interesting, and time
consuming move for myself... It's not that C++ is necessarily
hard to learn, but in the beginning it was hard for me to keep
my code from reverting back to C. Java is certainly next on
the list as I would only benefit from learning both languages.
Razii
>One advantage C++ has, which may be relevent, is a head start. My C++
>library has a pretty good collection of books that describe common
>problems in C++ code, why they are problems, and how to correctly
>implement them.
I am not sure about that. The online java tutorial that Sun has on their site
seems to be better than anything that I have seen about C++.
See: http://developer.java.sun.com/developer/onlineTraining/
Also, my local book stores seems to have more books on Java than C++.
David Ehrens
news:ar45dtob7i4q3ke15...@4ax.com...
...
> Once again, a C++ program apparently can't create platform independent
> applications, but a Java programmer can. What can C++ programmer do
that Java
> programmer can't? (given the Java programmer is allowed to use JNI and
stuff).
Creating small, fast apps; accessing OS hooks (unix, NT); sensing and
manipulating the hardware (mouse buttons to device drivers). Platform
independence is nice, but so is the ability to "touch the metal".
David Ehrens
Jon Skeet
> For example, consider the problem of sorting arrays of arbitrary types.
> In C we have qsort, which takes a pointer to a comparison function and
> an untyped pointer that it uses to reach the actual data. You can use it
> to sort the elements of an array of char, an array of double, an array
> of structs, whatever. Write it once, use it everywhere. C++ has
> std::sort, which can be used to sort an array of char, an array of
> double, an array of objects, whatever. Write it once, use it everywhere.
> In Java you have to write nine copies of the basic sort function: one
> for arrays of chars, one for arrays of doubles, one for arrays of
> Objects, etc.
This is a straw man.
In Java you can call Arrays.sort with an optional Comparator argument
(for Objects). There's a method in Arrays.sort for each type.
Yes, genericity would be nice. Hopefully it'll be coming in Tiger.
--
Jon Skeet - sk...@pobox.com
http://www.pobox.com/~skeet
If replying to the group, please don't mail me at the same time
Thomas Hansen
about a ZILLION less CPU cycles then the same solution in java...
Thomas Hansen
(...they just never do it!!...)
"Razii" <raz...@swbell.net> wrote in message
news:gou4dt4sjo4ufq9ad...@4ax.com...
Razii
Why can't Java programmer access "OS hooks (unix, NT); sensing and
manipulating the hardware (mouse buttons to device drivers)" using JNI (Java
Native Interface). If he can do this using JNI, while keeping the program
platform independent, why that is not better than C++?
Can you write GUI or Network programs in C++ that you can use on Windows, Mac,
Unix, without making any changes to your code?
Is writing network or distributed apps as easy in C++ as it is in Java?
Mike Hewson
I think "troll alert" is appropriate here.
"Razii" <raz...@swbell.net> wrote in message
news:qii4dtcg9jhr32qdb...@4ax.com...
Asger Joergensen
Razii wrote:
Well, i probably isn't qualified to answer Your question
since i only know C++ and if i should answer i would say
C++, no doubt in my mind.
In my world Java is only the latest fashion, and if one of
the two languages is going to die, i think it would be Java,
when i goes out of fashion, but that probably wont happen.
And if You can make programs in C++ You can in a month
or so learn to make programs in Java.
From where i stand Jave is mostly a huge class library
added to a amputated C++ language, and all together called
a language. Amputated: mostly because it doesn't have
pointers and templates.
If You want to be able to learn C++ in a way that is just as
easy as Jave (in many cases even easyer) You can use
a tool like Borland C++ Builder (BCB).
BCB have a very extencive class library, where most of it
is visible on a tool pallete, so You can just use drag and drop
whenever You need a button or a textfield.
And if You stick to the BCB class library You almost never
have to concern about carbage colection.
The only reason i can think of for recomending Jave is if
Your main goal is to produce application which is to run
on the internet.
Please remember that the above is written by one who
only realy know the C++ language.
Happy regards
Asger
Arnold the Aardvark
1. Programming languages never, ever die. COBOL. QED.
2. Beauty is in the eye of the beholder. I use utility as my criterion.
3. There is no such thing as a golden hammer. Learn both, and any
other languages that come your way.
I am currently learning Java. I have been resistant to it primarily because
I despise all the hype, but it turns out that there are good points and bad
points. C++, which I know well, has good points and bad points.
You should focus on the art of programming rather than the tools of the
trade.
Arnold the Aardvark
Regis Lachaume
eis responsurus sum
> C++ is only ugly if you use it wrong
Like any language. (lisp & fortran well-designed programs look terribly bad
though...)
> char *a = "/tmp/";
> char *b = "file.tmp";
> char *ptr = malloc(strlen(a) + strlen(b));
> sprintf(ptr, "%s%s", a, b);
> fopen(ptr,...
Who would code like that, except a newbie in C?
--
Régis Lachaume, PhD student at Grenoble Observatory (France)
phone: (office) 33 4 76 63 58 24 (cell phone) 33 6 63 09 80 02
e-mail: lach...@gagax6.obs.ujf-grenoble.fr
address: 270, av. A. Croizat (46A) 38400 Saint Martin d'Hères (France)
"Je ne suis pas superstitieux: la superstition, ça porte malheur."
Regis Lachaume
eis responsurus sum
> <sarcasm> Of course, since computers are so fast nowadays, speed of code
> doesn't matter. </sarcasm>
Computers need to be so fast because a hord of programmers think they can waste
memory and CPU load... Do you need 16Mo and a 100 MHz CPU to type a single
letter?
Tilo Körbs
Currently the dot.coms are dying and the internet hype too. So Java will
lose some of its popularity.
My guess is that C++ and Java will share the market 50/50 in the future.
Today it is 50/50 or maybe a little more Java. It may even be possible
that C++ and C# (MS .net) will share the market in the future.
.net is very good for internet applications. It may replace some of Java's domain.
For a newcommer it is much easier to get into Java then into C++.
But if you know C++ you can learn Java in 10 days. Java is like a subset of C++.
If you will learn C++, get a good beginners book (look at amazon) and the
get Scott Meyers: "Effective C++: 50 Specific Ways...". It's a must.
Eric
[snip]
> Is there anything a C++ can do that a Java programmer can't? (given the
Java
> programmer is allowed to use JNI and stuff). A C++ program apparently
can't
> create platform independent applications, but a Java programmer can...
Utter non-sense! With proper design you can easily write
platform-independant C++ programs. You don't need to look far to find
hundreds of programmers and companies that have done just that. Do you think
the idea and the need for developing platform-independant applications are
new? something just "born" with Java? People were writing such applications
in C++ many years before Java even existed. Then again, maybe you don't know
enough about C++ to make such a comment about it.
>... So what can C++ programmer do that Java programmer can't?
Answer: write "high-performance" 3D graphics applications. Show me a 3D Java
application that can run "as fast as" its C++ counter-part. (and please
don't tell me that "Java 3D" is "fast" or well-designed -- I've tried it, it
is not... it's limited and offers little to experienced 3D developers.)
Another point: I recently downloaded a trial version of a fully-featured
Java application for creating and using UML diagrams, it took a whopping
80MB of memory at run-time, was at times slow to a crawl, and finally made
me decide against buying the product.
So there's your answer: efficiency and performance. Those are just two
things that separate what a C++ programmer can do that a Java programmer
can't.
<FLAME ON>
One last note: I'm writing this as a result of seeing your post on
comp.lang.c++, so... Razii... buddy... this is the wrong newsgroup to be
talking trash about C++ and C++ programmers -- next time, check that you're
sending your poorly-researched opinions only to your Java buddies. OK?
</FLAME OFF>
Good day,
Eric
Eric
> What language should one learn? Java or C++?
>
> Most people say C++ is dying. It's an ugly language. Java is the most
popular
> language today. Is that true?
>
After reading this post (and many of your own replies to other repliers),
and falling into the trap by replying to one of them before realizing that I
was actually replying to the poster, it seems to me that you've already made
up your own mind! I find your post, your replies, and your cross-posting it
on the C++ and Java newsgroups at once utterly rude and inappropirate. If
you think Java is so much greater than C++ (without really knowing anything
about C++, it seems), then why ask such a question and cross-post it on both
newsgroups? But of course, I already know the answer: You're probably one of
those jerks who are more interested in starting a flame war than finding a
real answer to their "supposedly" genuine question. Your own replies clearly
show that you're even "fueling" it!
My advice to the comp.lang.c++ folks is not to send replies to this person's
post anymore -- it will be a waste of your time and valuable opinion. It was
certainly a waste of mine!
To the poster, two words: Get Lost!
Eric
Jon Skeet
> >... So what can C++ programmer do that Java programmer can't?
>
> Answer: write "high-performance" 3D graphics applications. Show me a 3D Java
> application that can run "as fast as" its C++ counter-part. (and please
> don't tell me that "Java 3D" is "fast" or well-designed -- I've tried it, it
> is not... it's limited and offers little to experienced 3D developers.)
>
> Another point: I recently downloaded a trial version of a fully-featured
> Java application for creating and using UML diagrams, it took a whopping
> 80MB of memory at run-time, was at times slow to a crawl, and finally made
> me decide against buying the product.
>
> So there's your answer: efficiency and performance. Those are just two
> things that separate what a C++ programmer can do that a Java programmer
> can't.
On the basis of two applications, you have decided that Java can't
perform decently? 3D performance I'll give you - but just because one
particular UML application performed poorly doesn't mean that Java
*can't* perform well. If that logic held, then C++ would do just as
badly, surely, as there are C++ programs which perform poorly.
Then again, maybe you don't know enough about Java to comment about it.
> <FLAME ON>
> One last note: I'm writing this as a result of seeing your post on
> comp.lang.c++, so... Razii... buddy... this is the wrong newsgroup to be
> talking trash about C++ and C++ programmers -- next time, check that you're
> sending your poorly-researched opinions only to your Java buddies. OK?
> </FLAME OFF>
I would argue that you should take your own advice.
mth...@cix.compulink.co.uk
no_direct...@NOSPAM.com (Eric) wrote:
> With proper design you can easily write
> platform-independant C++ programs.
Possible yes, but if you include GUI applications IME it is not easy (at
least not without significant compromises). The perfect portable GUI
environment is still as much a dream for C++ as it is for Java. It is
damned hard to do (and Microsoft and others seem to have teams dedicated
to keeping it difficult).
>
> So there's your answer: efficiency and performance. Those are just two
> things that separate what a C++ programmer can do that a Java programmer
> can't.
>
>
> <FLAME ON>
> One last note: I'm writing this as a result of seeing your post on
> comp.lang.c++, so... Razii... buddy... this is the wrong newsgroup to be
> talking trash about C++ and C++ programmers -- next time, check that
> you're
> sending your poorly-researched opinions only to your Java buddies. OK?
> </FLAME OFF>
>
> Good day,
Well Eric you seem to have committed the same sin as your response was
also cross posted to comp.lang.java.programmer.
It is possible to write Java applications that are efficient (sometimes
even more so than their C++ equivalents). The existence of inefficient
programs (in any language) does not prove that efficient programs in that
language do not exist or aren't possible.
So IMHO for many applications similar performance is achievable with both
C++ and Java (which is not to say that many programmers will actually
achieve it --- Java currently has an awful lot of newbies and relatively
fewer experienced campaigners).
In a smaller number of cases one language or the other has definite
advantage with current technology that no amount of programmer expertise
can overcome. I know of examples of this for both Java and C++.
Finally the Java environment is still changing rapidly (far more so than
C++), so comparisons made now may become invalid within a short space of
time.
Mark Thornton
Peter Chapin
In article <13c5dtk8v3n1p9hol...@4ax.com>,
raz...@swbell.net says...
> Is writing network or distributed apps as easy in C++ as it is in Java?
Not long ago I had to write a small test program using IPv6. This was
quite a trivial matter in C/C++ since the sockets API is largely
protocol independent. When I checked out Java's "standard" networking
support I did not see any clear way to deal with IPv6. (Is there such a
way?) I concluded that while Java's API makes life easier in some ways,
it does so by being restrictive and limiting. This is hardly surprising;
I think it is normal to buy simplicity at the expense of flexibility and
expressiveness.
As a side question: what is involved in writing IPv6 applications in
Java anyway? I might actually have to do that sometime soon.
Peter
Pavel Kuznetsov
Matt Chatterley
Razii <raz...@swbell.net> wrote in message
news:qii4dtcg9jhr32qdb...@4ax.com...
> What language should one learn? Java or C++?
>
> Most people say C++ is dying. It's an ugly language. Java is the most
popular
> language today. Is that true?
>
It depends what you want. I learnt Java several years ago, and have since
migrated to C++; despite all the raging arguments, at least one fact
remains - C++ *is* faster.
Of course, Java does have some good features - applets for instance.
If you're thinking purely about the money you can make, there is almost
certainly more cash in C++ (in my area of the UK anyhows).
But as with all language advocacy arguments, its upto the individual to
compare and contrast the features, benefits and drawbacks of each language
in order to decide what to use.
I would say, though, that C++ is most certainly not dying (think about how
much software is written in it!) - even if it *did* die tomorrow, there
would still be a massive demand for C++ engineers to maintain existing code
(heh, or at least to port it to something else). It needn't be ugly either -
poor programmers produce ugly code in any language.
-Matt
Jon Skeet
> > What language should one learn? Java or C++?
> >
> > Most people say C++ is dying. It's an ugly language. Java is the most
> popular
> > language today. Is that true?
> >
>
> It depends what you want. I learnt Java several years ago, and have since
> migrated to C++; despite all the raging arguments, at least one fact
> remains - C++ *is* faster.
That depends on what you're doing. Recent benchmarks show dynamically-
optimising JIT-compilers beating statically optimised C on *some tasks*.
(Just how much by depended on the VM in question and the compiler and
level of optimisation of the C code.)
http://www.aceshardware.com/Spades/read.php?article_id=153
(I recently ran the benchmarks myself and saw similar results in almost
all cases, IIRC.)
> Of course, Java does have some good features - applets for instance.
I'd actually say that applets are Java's bane rather than its beauty.
Server-side Java is where I find the appeal.
> I would say, though, that C++ is most certainly not dying
Agreed.
> It needn't be ugly either - poor programmers produce ugly code in any language.
Agreed again.
Ingo R. Homann
>
> But if you know C++ you can learn Java in 10 days. Java is like a subset of C++.
Hi!
I can't agree to that! One of the greatest (and most underestimated!)
strengths of java is it's *very* large API of *standardized* packages!
There are classes for nearly ANY purposes (just take a look at the
package-overview:
http://java.sun.com/j2se/1.3/docs/api/overview-summary.html)
To really be able to program in java (or in any other language), it's
not only necessary to know syntax and semantics of the *language*, but
also to have a very good knowledge of the packages that are provided
with the language! And I cannot imagine how to get more than a very raw
overview in 10 days!
<sarcasm>
OK, if the standard-libraries of C++ are not nearly as large and
powerful as the stadard-libraries of java, than it's obvious that it is
easier to learn C++! ;-)
</sarcasm>
Bye, Ingo
Patricia Shanahan
Razii wrote:
>
> What language should one learn? Java or C++?
>
> Most people say C++ is dying. It's an ugly language. Java is the most popular
> language today. Is that true?
If at all possible, learn several different languages.
Every language that attracts enough of a following for most prospective
programmers to have heard of it has something to be said in its favor.
Every language I've learned so far has disadvantages and limitations
relative to other languages.
If you must pick one, the first thing to do is to think through your
purpose in learning it. The approach to selection should be based on
utility for that purpose.
The only case in which beauty or ugliness should be a deciding factor is
if the purpose is your own esthetic pleasure. In that case, you will
have to learn several and choose among them for yourself because beauty
is in the eye of the beholder.
More practical purposes include getting a job as a programmer. For that
one, I would look at ads for entry level programmers in the location and
field in which you want a job, and see what qualifications and skills
are most requested.
Another purpose might be to get a head start on future college studies.
Look at course catalogs for the colleges you might attend, and see which
language or languages are most used.
Patricia
Pete Becker
>
> You can work around this special problem pretty easily and nicely in Java.
> See java.lang.Compareable, java.util.Array for qsort&co.
You can't use Comparable on builtin types, only types derived from
Object.
>
> In fact I would prefere the Java solution to that. It seems less "sensible"
> to programming erros to me.
>
java.util.Arrays provides nine (yes, nine) sort functions, one for each
of the fundamental types and one for Objects. That's the point: there's
no way to write that code just once, even though all of the versions for
builtin types are identical except for the types of the arguments.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Ingo R. Homann
>
> java.util.Arrays provides nine (yes, nine) sort functions, one for each
> of the fundamental types and one for Objects. That's the point: there's
> no way to write that code just once, even though all of the versions for
> builtin types are identical except for the types of the arguments.
>
> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)
Yes, that's true! But I heared, the people at sun now realized that
disadvantage (after several years!) and want to add templates to one of
the next java-versions!
Bye, Ingo
Bart Kowalski
> >
> > Most people say C++ is dying. It's an ugly language. Java is the most
> popular
> > language today. Is that true?
>
> 1. Programming languages never, ever die. COBOL. QED.
Fortran. Re-QED.
> 2. Beauty is in the eye of the beholder. I use utility as my criterion.
> 3. There is no such thing as a golden hammer. Learn both, and any
> other languages that come your way.
>
> I am currently learning Java. I have been resistant to it primarily because
> I despise all the hype, but it turns out that there are good points and bad
> points. C++, which I know well, has good points and bad points.
I fully agree. I despise the hype too. If there wasn't so much hype I would
actually be more interested in Java than I currently am, because hype is usually
a sign of instability.
> You should focus on the art of programming rather than the tools of the
> trade.
This is the best reply so far. I totally agree.
Bart.
Pete Becker
> >For example, consider the problem of sorting arrays of arbitrary types.
> >In C we have qsort, which takes a pointer to a comparison function and
> >an untyped pointer that it uses to reach the actual data. You can use it
> >to sort the elements of an array of char, an array of double, an array
> >of structs, whatever. Write it once, use it everywhere. C++ has
> >std::sort, which can be used to sort an array of char, an array of
> >double, an array of objects, whatever. Write it once, use it everywhere.
> >In Java you have to write nine copies of the basic sort function: one
> >for arrays of chars, one for arrays of doubles, one for arrays of
> >Objects, etc.
>
> How about platform independent GUI in Java (i.e. Swing) or Network programming?
How about platform independent GUI in C++ with any of the various
libraries that are out there? There are almost as many of them as there
are GUIs in Java (three that I know of <g>)
> I have heard no language makes Network programming as simple as API that is part
> of Java standard library. You can write GUI or Network applications once and
> use it on unix, linux, windows,or mac, without making any changes to your
> program.
>
> Isn't that "write it once, use it everywhere"?
>
That's certainly what the Java marketing department keeps telling folks.
From what I hear, though, in the real world it doesn't work that way.
> As for sorting, I think in Java you can convert int, long, double, byte, char,
> etc., easily to Objects using classes like Integer, Character, Long, Double,
> etc.
>
> All objects then can by sorted using one method, not nine.
>
Sure: just copy all of the elements of your int array into an Object
array, sort that, and copy the result back. Efficiency? What's that?
And, of course, the other refutation for this argument is the simple
fact that java.lang.Arrays provides nine sort functions, one for each of
the builtin types and one for Objects.
> Is there anything a C++ can do that a Java programmer can't? (given the Java
> programmer is allowed to use JNI and stuff).
Of course not. If you can't say it in Java, you switch to C or C++.
> A C++ program apparently can't
> create platform independent applications, but a Java programmer can.
Nonsense, on both ends. The Java marketing department greatly
exaggerates the difficulties of writing portable applications in C++,
and greatly exaggerates the ease of doing so in Java.
Greg Comeau
Razii <raz...@swbell.net> wrote:
>Once again, a C++ program apparently can't create platform independent
>applications, but a Java programmer can.
Notwithstanding that you are comparing programs and programmers:
Sure it can. Therefore, you may have a point, but it is not the above.
--
Greg Comeau Comeau C/C++ 4.2.45.2 "it's so close"
ONLINE COMPILER ==> http://www.comeaucomputing.com/tryitout
NEW: Try out libcomo! NEW: Try out our C99 mode!
com...@comeaucomputing.com http://www.comeaucomputing.com
Pete Becker
>
> Pete Becker <peteb...@acm.org> wrote:
>
> > For example, consider the problem of sorting arrays of arbitrary types.
> > In C we have qsort, which takes a pointer to a comparison function and
> > an untyped pointer that it uses to reach the actual data. You can use it
> > to sort the elements of an array of char, an array of double, an array
> > of structs, whatever. Write it once, use it everywhere. C++ has
> > std::sort, which can be used to sort an array of char, an array of
> > double, an array of objects, whatever. Write it once, use it everywhere.
> > In Java you have to write nine copies of the basic sort function: one
> > for arrays of chars, one for arrays of doubles, one for arrays of
> > Objects, etc.
>
> This is a straw man.
>
> In Java you can call Arrays.sort with an optional Comparator argument
> (for Objects). There's a method in Arrays.sort for each type.
Exactly: there are nine methods in Arrays.sort, precisely because you
cannot write this code generically in Java.
>
> Yes, genericity would be nice. Hopefully it'll be coming in Tiger.
>
The Java generics proposal that I'm familiar with only deals with Object
types, so it wouldn't simplify writing sort functions to handle builtin
types. Is there another one around?
Pete Becker
>
> On 9 Apr 2001 18:22:48 -0700, ent...@farviolet.com (Lawrence Foard) wrote:
>
> > Java is like a bike with training wheels, may be
> >harder to fall down, but your never going to win a race.
>
> programmer can't? (given the Java programmer is allowed to use JNI and stuff).
Once again, if you can't write it in Java, you switch to C or C++, which
is why you need "JNI and stuff".
Pete Becker
>
> On Tue, 10 Apr 2001 05:51:32 GMT, "David Ehrens" <nos...@nospam.net> wrote:
>
> >"Razii" <raz...@swbell.net> wrote in message
> >news:ar45dtob7i4q3ke15...@4ax.com...
> >...
> >> Once again, a C++ program apparently can't create platform independent
> >> applications, but a Java programmer can. What can C++ programmer do
> >that Java
> >> programmer can't? (given the Java programmer is allowed to use JNI and
> >stuff).
> >
> >Creating small, fast apps; accessing OS hooks (unix, NT); sensing and
> >manipulating the hardware (mouse buttons to device drivers). Platform
> >independence is nice, but so is the ability to "touch the metal".
>
> Why can't Java programmer access "OS hooks (unix, NT); sensing and
> manipulating the hardware (mouse buttons to device drivers)" using JNI (Java
> Native Interface). If he can do this using JNI, while keeping the program
> platform independent, why that is not better than C++?
JNI code is written in C, C++, or some other language, but not Java.
That's the point. And remember, the N in JNI stands for "Native", i.e.
not portable.
Greg Comeau
Regis Lachaume <lach...@clipper.ens.fr> wrote:
>quas litteras Lawrence Foard in continuo comp.lang.c++:526308 scripsit
>eis responsurus sum
>> C++ is only ugly if you use it wrong
>
>Like any language. (lisp & fortran well-designed programs look terribly bad
>though...)
>
>> char *a = "/tmp/";
>> char *b = "file.tmp";
>> char *ptr = malloc(strlen(a) + strlen(b));
>> sprintf(ptr, "%s%s", a, b);
>> fopen(ptr,...
>
>Who would code like that, except a newbie in C?
Lots of non-newbies.
Pete Becker
>
> Tilo Körbs wrote:
> >
> > But if you know C++ you can learn Java in 10 days. Java is like a subset of C++.
>
> Hi!
>
> I can't agree to that! One of the greatest (and most underestimated!)
> strengths of java is it's *very* large API of *standardized* packages!
> There are classes for nearly ANY purposes (just take a look at the
> package-overview:
> http://java.sun.com/j2se/1.3/docs/api/overview-summary.html)
And all, of course, carefully designed and thoroughly documented. (Let's
not mention the now-it's-deprecated now-it's-not switch in
java.lang.PrintStream, or the utter uselessness of java.InputStream.skip
if you take it's documentation seriously, or the "optional methods" in
the interfaces in the collections framework, or any of the many other
hacks in the library).
>
> To really be able to program in java (or in any other language), it's
> not only necessary to know syntax and semantics of the *language*, but
> also to have a very good knowledge of the packages that are provided
> with the language! And I cannot imagine how to get more than a very raw
> overview in 10 days!
And, of course, you have to understand the add-on libraries that you're
going to use. If they're not part of the package, then you can choose
one that fits your needs best.
Jon Skeet
> Jon Skeet wrote:
> >
> > Pete Becker <peteb...@acm.org> wrote:
> >
> > > For example, consider the problem of sorting arrays of arbitrary types.
> > > In C we have qsort, which takes a pointer to a comparison function and
> > > an untyped pointer that it uses to reach the actual data. You can use it
> > > to sort the elements of an array of char, an array of double, an array
> > > of structs, whatever. Write it once, use it everywhere. C++ has
> > > std::sort, which can be used to sort an array of char, an array of
> > > double, an array of objects, whatever. Write it once, use it everywhere.
> > > In Java you have to write nine copies of the basic sort function: one
> > > for arrays of chars, one for arrays of doubles, one for arrays of
> > > Objects, etc.
> >
> > This is a straw man.
> >
> > In Java you can call Arrays.sort with an optional Comparator argument
> > (for Objects). There's a method in Arrays.sort for each type.
>
> Exactly: there are nine methods in Arrays.sort, precisely because you
> cannot write this code generically in Java.
Indeed - but the point is that that sort code is already written, and
you only have to *remember* one thing, which is considerably easier than
the horrendous "You've got to write it all yourself, *and* write it all
9 times" picture you were painting.
> > Yes, genericity would be nice. Hopefully it'll be coming in Tiger.
>
> The Java generics proposal that I'm familiar with only deals with Object
> types, so it wouldn't simplify writing sort functions to handle builtin
> types. Is there another one around?
Nope, having just checked, you're right. At least, the JSR at
http://java.sun.com/aboutJava/communityprocess/jsr/jsr_014_gener.html
explicitly states that the proposal doesn't have to do this. Whether it
will or not is another matter.
This is a shame, but to be honest I can only think of two instances
where I would have wanted this.
Ingo R. Homann
>
> "Ingo R. Homann" wrote:
> >
> > Tilo Körbs wrote:
> > >
> > > But if you know C++ you can learn Java in 10 days. Java is like a subset of C++.
> >
> > Hi!
> >
> > I can't agree to that! One of the greatest (and most underestimated!)
> > strengths of java is it's *very* large API of *standardized* packages!
> > There are classes for nearly ANY purposes (just take a look at the
> > package-overview:
> > http://java.sun.com/j2se/1.3/docs/api/overview-summary.html)
>
> And all, of course, carefully designed and thoroughly documented. (Let's
> not mention the now-it's-deprecated now-it's-not switch in
> java.lang.PrintStream, or the utter uselessness of java.InputStream.skip
> if you take it's documentation seriously, or the "optional methods" in
> the interfaces in the collections framework, or any of the many other
> hacks in the library).
I did not say that the "java-standard-libraray" is perfect! But I think,
its better to have ONE *standardized* (but non-perfect) library which is
maintained and optimized over the time by one company (like in java)
than to have the choice of SEVERAL *non-standardised* (and also
non-perfect) libraries that you have to try out yourself just to
realized that it is too buggy (or just not really apropriate for your
purpose) so that you must switch to another library (like in C++)!
> > To really be able to program in java (or in any other language), it's
> > not only necessary to know syntax and semantics of the *language*, but
> > also to have a very good knowledge of the packages that are provided
> > with the language! And I cannot imagine how to get more than a very raw
> > overview in 10 days!
>
> And, of course, you have to understand the add-on libraries that you're
> going to use. If they're not part of the package, then you can choose
> one that fits your needs best.
But (as explained above) that's even worse in C++!
> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)
Bye, Ingo
Pete Becker
>
> Pete Becker wrote:
> >
> > java.util.Arrays provides nine (yes, nine) sort functions, one for each
> > of the fundamental types and one for Objects. That's the point: there's
> > no way to write that code just once, even though all of the versions for
> > builtin types are identical except for the types of the arguments.
> >
>
> disadvantage (after several years!) and want to add templates to one of
> the next java-versions!
>
As far as I know, Java generics won't solve this problem, because
generics only work with Object types, not builtin types. The generics
proposal provides, in essence, compiler-generated typesafe wrappers, so
you can write an implementation that deals in Objects, and from that
produce a generic version that deals, say, in MyType, and requires
MyType rather than Object in the appropriate places. Underneath, though,
it's your Object code, and not code with any particular knowledge of the
properties of MyType. So "generics" is an appropriate name, but
definitely not "templates".
Pete Becker
>
> Pete Becker <peteb...@acm.org> wrote:
> > Jon Skeet wrote:
> > >
> > > Pete Becker <peteb...@acm.org> wrote:
> > >
> > > > For example, consider the problem of sorting arrays of arbitrary types.
> > > > In C we have qsort, which takes a pointer to a comparison function and
> > > > an untyped pointer that it uses to reach the actual data. You can use it
> > > > to sort the elements of an array of char, an array of double, an array
> > > > of structs, whatever. Write it once, use it everywhere. C++ has
> > > > std::sort, which can be used to sort an array of char, an array of
> > > > double, an array of objects, whatever. Write it once, use it everywhere.
> > > > In Java you have to write nine copies of the basic sort function: one
> > > > for arrays of chars, one for arrays of doubles, one for arrays of
> > > > Objects, etc.
> > >
> > > This is a straw man.
> > >
> > > In Java you can call Arrays.sort with an optional Comparator argument
> > > (for Objects). There's a method in Arrays.sort for each type.
> >
> > Exactly: there are nine methods in Arrays.sort, precisely because you
> > cannot write this code generically in Java.
>
> Indeed - but the point is that that sort code is already written, and
> you only have to *remember* one thing, which is considerably easier than
> the horrendous "You've got to write it all yourself, *and* write it all
> 9 times" picture you were painting.
You persist in missing the point. The need to write this code nine times
is the result of a language limitation. That's a problem in Java that
shows up in many places; sorting is just one example. I chose it because
it's something most people are familiar with. You can easily write
generic code in C and in C++. You cannot do so in Java. And that makes
good engineering harder in Java than in C or C++.
>
> > > Yes, genericity would be nice. Hopefully it'll be coming in Tiger.
> >
> > The Java generics proposal that I'm familiar with only deals with Object
> > types, so it wouldn't simplify writing sort functions to handle builtin
> > types. Is there another one around?
>
> Nope, having just checked, you're right. At least, the JSR at
> http://java.sun.com/aboutJava/communityprocess/jsr/jsr_014_gener.html
> explicitly states that the proposal doesn't have to do this. Whether it
> will or not is another matter.
>
> This is a shame, but to be honest I can only think of two instances
> where I would have wanted this.
>
I see. It would be nice, but the proposal doesn't support it, but maybe
that will change, but I don't really need it anyway. JHL is a wonderful
thing.
Pete Becker
>
> Pete Becker wrote:
> >
> > "Ingo R. Homann" wrote:
> > >
> > > Tilo Körbs wrote:
> > > >
> > > > But if you know C++ you can learn Java in 10 days. Java is like a subset of C++.
> > >
> > > Hi!
> > >
> > > I can't agree to that! One of the greatest (and most underestimated!)
> > > strengths of java is it's *very* large API of *standardized* packages!
> > > There are classes for nearly ANY purposes (just take a look at the
> > > package-overview:
> > > http://java.sun.com/j2se/1.3/docs/api/overview-summary.html)
> >
> > And all, of course, carefully designed and thoroughly documented. (Let's
> > not mention the now-it's-deprecated now-it's-not switch in
> > java.lang.PrintStream, or the utter uselessness of java.InputStream.skip
> > if you take it's documentation seriously, or the "optional methods" in
> > the interfaces in the collections framework, or any of the many other
> > hacks in the library).
>
> I did not say that the "java-standard-libraray" is perfect! But I think,
> its better to have ONE *standardized* (but non-perfect) library which is
> maintained and optimized over the time by one company (like in java)
> than to have the choice of SEVERAL *non-standardised* (and also
> non-perfect) libraries that you have to try out yourself just to
> realized that it is too buggy (or just not really apropriate for your
> purpose) so that you must switch to another library (like in C++)!
And what do you do when you determine that the *standardized* library
which is maintained and optimized over time by one company is too buggy
(or just not really appropriate for your purpose) so that you must
switch to another library? Of course, you can switch from AWT to Swing
to LCDUI or whatever happens to be the fashion of the moment. But I do
think it's interesting to hear the argument that monopoly is good for
customers. JHL forever!
Ingo R. Homann
>
> And what do you do when you determine that the *standardized* library
> which is maintained and optimized over time by one company is too buggy
> (or just not really appropriate for your purpose) so that you must
> switch to another library? Of course, you can switch from AWT to Swing
> to LCDUI or whatever happens to be the fashion of the moment. But I do
> think it's interesting to hear the argument that monopoly is good for
> customers. JHL forever!
>
> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)
Well, java is maintained by one organization, but it does *not* suffer
all the disadvantages of monopoly, I think! I've heared that sun often
integrates something to the official java-release, that is NOT developed
by sun itself, but was developed by a third party, and has been proofed
to be good!
I think that combines both the advantages of monopoly (standardization,
continuity) and of diversity (flexibility, to be open, ...).
Of course, some of these advantages contradict each other somehow, but I
think that java choosed a good middle course!
On the other hand, I would agree that the competition with MS's C# might
be good for java...
Ciao, Ingo
Jim Sculley
Good timing. It looks like IPv6 has been addressed in the upcoming JDK
1.4 (Merlin) release:
http://java.sun.com/aboutJava/communityprocess/review/jsr059/merlin.pdf
14 Networking
IPv6 support
ID: 4290596 Release Driver
When the OS platform supports IP version 6, it should be accessible from
the Java 2 Platform.
Jim S.
Jon Skeet
> > Indeed - but the point is that that sort code is already written, and
> > you only have to *remember* one thing, which is considerably easier than
> > the horrendous "You've got to write it all yourself, *and* write it all
> > 9 times" picture you were painting.
>
> You persist in missing the point. The need to write this code nine times
> is the result of a language limitation. That's a problem in Java that
> shows up in many places; sorting is just one example.
Funny how in 5 years of Java programming I've only wanted to do it
twice. It may show up in a few places (and sorting *is* the most obvious
one), but I've always either had the appropriate methods available (such
as Arrays.sort) or made do without losing much time. The one time when I
thought it was actually causing me performance problems (wrapping and
unwrapping ints in Integer objects) I found that the performance
bottleneck was elsewhere, and the performance lost due to this was
minimal.
Yes, it's a defect. My point is that it's an unimportant defect that you
can work around. Much like the lack of threading support in the language
itself for C/C++ - except I view threading as rather more important.
(Yes, there are libraries to get round that limitation, but it's still a
relative pain to use them.)
There's a balancing act to achieve - neither C++ or Java is perfect -
far from it. I just happen to prefer Java's balance to C++'s. You seem
to be painting a rather bleaker picture of Java than I've experienced,
however.
> > Nope, having just checked, you're right. At least, the JSR at
> > http://java.sun.com/aboutJava/communityprocess/jsr/jsr_014_gener.html
> > explicitly states that the proposal doesn't have to do this. Whether it
> > will or not is another matter.
> >
> > This is a shame, but to be honest I can only think of two instances
> > where I would have wanted this.
>
> I see. It would be nice, but the proposal doesn't support it, but maybe
> that will change, but I don't really need it anyway. JHL is a wonderful
> thing.
The proposal doesn't *require* it. My point is that I would be
pleasantly surprised to see it, but that it isn't nearly as important to
me as the rest of the proposal. Is that really so hard to understand?
Andrew R. Thomas-Cramer
> As for sorting, I think in Java you can convert int, long, double, byte,
char,
> etc., easily to Objects using classes like Integer, Character, Long,
Double,
> etc.
>
> All objects then can by sorted using one method, not nine.
I'm working on a library now in which it may become necessary to sort an
arbitrary number of floats; in practice, up to millions. In C++, they can be
sorted in place. In Java, you suggest I copy them to an array of Floats,
sort that, then copy them back to the primitives.
Has it occurred to you that creating all of the objects increases costs in
time?
Has it occurred to you that the temporary array and its Floats increase
memory consumption _drastically_? An array of a million floats can be stored
in 4M. An array and its million Floats requires ... probably around 4M for
the array, and 16M for all the Floats (depending on virtual machine) -- for
a total of 20M.
> Is there anything a C++ can do that a Java programmer can't? (given the
Java
> programmer is allowed to use JNI and stuff).
"I can do anything in Java that you could do in C -- if I use C."
>A C++ program apparently can't
> create platform independent applications, but a Java programmer can.
What makes you think C++ programs can't be platform-independent?
>So what can
> C++ programmer do that Java programmer can't?
Write faster code in a more expressive language.
Ingo R. Homann
>
> On 10 Apr 2001 09:18:39 GMT, lach...@clipper.ens.fr (Regis Lachaume) wrote:
>
> >> <sarcasm> Of course, since computers are so fast nowadays, speed of code
> >> doesn't matter. </sarcasm>
>
> >Computers need to be so fast because a hord of programmers think they can waste
> >memory and CPU load... Do you need 16Mo and a 100 MHz CPU to type a single
> >letter?
>
> Of course not. But I guess that was a rhetoric question.
>
> I do _not_ subscribe to the conviction of many programmers that they can
> waste resources and get away with it. My blisteringly fast computer is in
> many ways a lot slower than the 7MHz computer I had ten years ago. What
> could the reason be, if not lazy or misguided programmers?
>
> --
> "By the time we've finished with him, he won't know whether
> he's Number Six or the cube root of infinity!"
Of course you are right! But on the other hand, I think spending some of
the resouces to the stability of a program must not be wrong!
As an example, Array-Bounds- and null-pointer-Checks, automatic
garbage-collection and so on which java uses, of course need some
additional resources (but even not as much as most people think)! But I
think to get a complete stacktrace on where the error occures (and not
to get a sigsegv somwhere else in the program but not where the error
occurs) is worth that overhead! It leads to more stable programs and a
much lower time to develop (and to debug!) an application!
(On the other hand, I must admit that there are much more incompetent
java-programmers as there are in C++, and so it is no miracle that most
c++-programs are faster than most java-programs. But that is another
point! If a professional formula1-driver drives faster than my grandma,
the reason must not necessarily be that he drives another car than my
grandma! :-)
Bye, Ingo
Andrew R. Thomas-Cramer
"Jon Skeet" <sk...@pobox.com> wrote in message
news:MPG.153d1b66d...@10.1.1.51...
> Pete Becker <peteb...@acm.org> wrote:
> > Exactly: there are nine methods in Arrays.sort, precisely because you
> > cannot write this code generically in Java.
>
> Indeed - but the point is that that sort code is already written, and
> you only have to *remember* one thing, which is considerably easier than
> the horrendous "You've got to write it all yourself, *and* write it all
> 9 times" picture you were painting.
But other points are that:
* Sun must maintain those nine redundant function definitions.
* If we want to write our own sort -- or other algorithms that must work on
both primitives and Objects -- we're faced with the same redundancy problem.
Phillip Lord
Pete> "Ingo R. Homann" wrote:
>> Pete Becker wrote: > > java.util.Arrays provides nine (yes,
>> nine) sort functions, one for each > of the fundamental types and
>> one for Objects. That's the point: there's > no way to write that
>> code just once, even though all of the versions for > builtin
>> types are identical except for the types of the arguments. >
>>>>
>> Yes, that's true! But I heared, the people at sun now realized
>> that disadvantage (after several years!) and want to add
>> templates to one of the next java-versions!
>>
[Apologies for quoting. Hope you can see who is who]
Actually its not entirely true. It would be possible to have
a single sort method taking only object arrays, but to use it with
primitives would require using the Object wrappers. The advantage of
this is that you could write a single method which did the wrapping
(and another doing the unwrapping of course), and reuse the sort
methods.
Obviously it would be hopelessly inefficient. Its probably
worth bearing in mind though that "primitives" are only there for
efficiency reasons in the first place, which is whats got us into this
mess.
Pete> As far as I know, Java generics won't solve this problem,
Pete> because generics only work with Object types, not builtin
Pete> types.
There have actually been several proposals which did include
the possibility of including primitives in the type system. These
required JVM alterations though.
Pete> So "generics" is an appropriate name, but definitely
Pete> not "templates".
Thats a funny use of terminology it seems to me. I would
have said that "generics" is the more er...generic term, and included
templates.
Phil
Jon Skeet
> > Pete Becker <peteb...@acm.org> wrote:
> > > Exactly: there are nine methods in Arrays.sort, precisely because you
> > > cannot write this code generically in Java.
> >
> > Indeed - but the point is that that sort code is already written, and
> > you only have to *remember* one thing, which is considerably easier than
> > the horrendous "You've got to write it all yourself, *and* write it all
> > 9 times" picture you were painting.
>
> But other points are that:
> * Sun must maintain those nine redundant function definitions.
> * If we want to write our own sort -- or other algorithms that must work on
> both primitives and Objects -- we're faced with the same redundancy problem.
Absolutely. Just as every C/C++ programmer has to face the problem that
those languages don't have any built-in threading facilities. If they
use a library, someone has to maintain that (and port it to each of the
different platforms, of course).
As ever, it's a matter of which you value more. As neither of the above
have been significant problems for me, but dealing with various thread
libraries *has*, I'm happier with the Java side of the balance.
no...@myisp.invalid
mth...@cix.compulink.co.uk wrote:
>
> In article <RyAA6.237809$tP3.3...@news1.rdc1.bc.home.com>,
> no_direct...@NOSPAM.com (Eric) wrote:
>
> > With proper design you can easily write
> > platform-independant C++ programs.
>
> Possible yes, but if you include GUI applications IME it is not easy (at
> least not without significant compromises). The perfect portable GUI
> environment is still as much a dream for C++ as it is for Java. It is
> damned hard to do (and Microsoft and others seem to have teams dedicated
> to keeping it difficult).
An open source project by the name of WxWindows
(http://www.wxwindows.org) is making this process much more managable.
Pete Becker
>
>
> Pete> As far as I know, Java generics won't solve this problem,
> Pete> because generics only work with Object types, not builtin
> Pete> types.
>
> There have actually been several proposals which did include
> the possibility of including primitives in the type system. These
> required JVM alterations though.
Which is why they are no longer under consideration, and therefore not a
possible solution to this problem.
>
> Pete> So "generics" is an appropriate name, but definitely
> Pete> not "templates".
>
> Thats a funny use of terminology it seems to me. I would
> have said that "generics" is the more er...generic term, and included
> templates.
>
Except that templates has a specific meaning in C++, and Java generics
support a small subset of what C++ templates can do.
Pete Becker
>
> "Razii" <raz...@swbell.net> wrote in message
> news:gou4dt4sjo4ufq9ad...@4ax.com...
> > create platform independent applications, but a Java programmer can.
>
> What makes you think C++ programs can't be platform-independent?
>
The Java marketing department, of course.
Pete Becker
>
>
> Yes, it's a defect. My point is that it's an unimportant defect that you
> can work around.
Yup: you can work around this particular limitation with lots of cut and
paste, and lots of prayer that when you have to maintain multiple copies
of the same code you won't leave out the edits to one of them. That's
not an unimportant problem. Java programmers spend far too much time
making copies of code. For another example, look at the documentation
for java.util.List.hashCode: it tells you what subclasses should
implement, rather than actually implementing it in one place for all
subclasses to use. That's an inherent limitation in interfaces, and once
again, the result is that you either duplicate code or distort the
design. In practice the code gets duplicated.
> Much like the lack of threading support in the language
> itself for C/C++ - except I view threading as rather more important.
> (Yes, there are libraries to get round that limitation, but it's still a
> relative pain to use them.)
Unlike Java's toy threads, where you have no way of finding out what the
thread scheduling algorithm is, and, therefore, no chance of writing
code that will work reliably on multiple platforms.
>
> There's a balancing act to achieve - neither C++ or Java is perfect -
> far from it. I just happen to prefer Java's balance to C++'s. You seem
> to be painting a rather bleaker picture of Java than I've experienced,
> however.
>
> > > Nope, having just checked, you're right. At least, the JSR at
> > > http://java.sun.com/aboutJava/communityprocess/jsr/jsr_014_gener.html
> > > explicitly states that the proposal doesn't have to do this. Whether it
> > > will or not is another matter.
> > >
> > > This is a shame, but to be honest I can only think of two instances
> > > where I would have wanted this.
> >
> > I see. It would be nice, but the proposal doesn't support it, but maybe
> > that will change, but I don't really need it anyway. JHL is a wonderful
> > thing.
>
> The proposal doesn't *require* it. My point is that I would be
> pleasantly surprised to see it, but that it isn't nearly as important to
> me as the rest of the proposal. Is that really so hard to understand?
>
Not at all. I gave an example of unsound engineering that is a direct
result of Java's limitations. Your response is that sound engineering
isn't important.
Pete Becker
>
> Andrew R. Thomas-Cramer <ar...@prism-cs.com> wrote:
>
> > > Pete Becker <peteb...@acm.org> wrote:
> > > > Exactly: there are nine methods in Arrays.sort, precisely because you
> > > > cannot write this code generically in Java.
> > >
> > > Indeed - but the point is that that sort code is already written, and
> > > you only have to *remember* one thing, which is considerably easier than
> > > the horrendous "You've got to write it all yourself, *and* write it all
> > > 9 times" picture you were painting.
> >
> > But other points are that:
> > * Sun must maintain those nine redundant function definitions.
> > * If we want to write our own sort -- or other algorithms that must work on
> > both primitives and Objects -- we're faced with the same redundancy problem.
>
> Absolutely. Just as every C/C++ programmer has to face the problem that
> those languages don't have any built-in threading facilities.
This is a completely different question. Java forces code duplication
because it doesn't not adequately support reuse.
> If they
> use a library, someone has to maintain that (and port it to each of the
> different platforms, of course).
And how, exactly, do you think that Java provides thread support? Magic?
Or is there code somewhere? Code that someone has to maintain and port
to each of the different platforms, of course.
Ingo R. Homann
>
> ... Java programmers spend far too much time
> making copies of code. For another example, look at the documentation
> for java.util.List.hashCode: it tells you what subclasses should
> implement, rather than actually implementing it in one place for all
> subclasses to use. That's an inherent limitation in interfaces, and once
> again, the result is that you either duplicate code or distort the
> design. In practice the code gets duplicated.
Slowly! I do *very* much with java and I was not forced to copy code
very often!!! And I dont understand what's your problem with the
hashCode - can you explain it again or give an example?
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)
Bye, Ingo
Ingo R. Homann
>
> what I am concerned about is deliberate wasting of resources.
> Bloating programs with features that are not necessary, graphics, etc.
>
> If only programmers were more concerned about making something useable
> instead of "cool".
Yes, I would agree to that! But that is another question. It is not a
disadvantage of the programminglanguage java!
Ingo
Phillip Lord
Andrew> "Razii" <raz...@swbell.net> wrote in message
Andrew> news:gou4dt4sjo4ufq9ad...@4ax.com...
>> As for sorting, I think in Java you can convert int, long,
>> double, byte,
Andrew> char,
>> etc., easily to Objects using classes like Integer, Character,
>> Long,
Andrew> Double,
>> etc.
>>
>> All objects then can by sorted using one method, not nine.
Andrew> I'm working on a library now in which it may become
Andrew> necessary to sort an arbitrary number of floats; in
Andrew> practice, up to millions. In C++, they can be sorted in
Andrew> place. In Java, you suggest I copy them to an array of
Andrew> Floats, sort that, then copy them back to the primitives.
Andrew> Has it occurred to you that creating all of the objects
Andrew> increases costs in time?
There are two solutions if code reuse is absolutely vital
to you here. Its is not of course necessary to create the object
wrappers upfront, you can do it as you go along. Further if you create
some new primitive wrappers which are mutable, then you can get away
with just having two wrapper objects which you continually reuse. You
would have to define the interfaces describing the unsorted data
structure carefully but it should be possible.
The alternative is to use "macro" auto generated code.
Essentially this provides you with "poor mans" generics which include
primitive data types.
Of course neither of these solutions is nice. It is a pity
that Java did not support a proper system for genericity right from
the start.
>> A C++ program apparently can't create platform independent
>> applications, but a Java programmer can.
Andrew> What makes you think C++ programs can't be
Andrew> platform-independent?
Can you do it binary compatible?
>> So what can C++ programmer do that Java programmer can't?
Andrew> Write faster code in a more expressive language.
Obviously expressiveness is a matter of opinion. Its
not necessarily a good thing either. C and C++'s everything and the
kitchen sink position does provide you with an expressive language but
personally I think this is one of C/C++'s problems.
I have to say though I find this language advocacy a little
tiresome. Of course Java is better than C++, and perl, and every other
language on the planet. But only at some things. You pays your money
you take your choice.
There's an interesting article on language advocacy that
I've linked below. The author also wrote an interesting piece on
strong typing which is worth a read.
http://www.perl.com/pub/2000/12/advocacy.html?wwwrrr_20001213.txt
Phil
Jon Skeet
> Jon Skeet wrote:
> > Yes, it's a defect. My point is that it's an unimportant defect that you
> > can work around.
>
> Yup: you can work around this particular limitation with lots of cut and
> paste, and lots of prayer that when you have to maintain multiple copies
> of the same code you won't leave out the edits to one of them. That's
> not an unimportant problem. Java programmers spend far too much time
> making copies of code. For another example, look at the documentation
> for java.util.List.hashCode: it tells you what subclasses should
> implement, rather than actually implementing it in one place for all
> subclasses to use. That's an inherent limitation in interfaces, and once
> again, the result is that you either duplicate code or distort the
> design. In practice the code gets duplicated.
Or, just possibly, people use AbstractList, which does it for them, and
subclass that... the way that all of the List implementations in the JDK
do.
> > Much like the lack of threading support in the language
> > itself for C/C++ - except I view threading as rather more important.
> > (Yes, there are libraries to get round that limitation, but it's still a
> > relative pain to use them.)
>
> Unlike Java's toy threads, where you have no way of finding out what the
> thread scheduling algorithm is, and, therefore, no chance of writing
> code that will work reliably on multiple platforms.
I'd say that not relying on any particular scheduling algorithm would
mean it would be *more* likely to work reliably on multiple platforms,
but possibly less likely to work optimally efficiently.
As soon as you start changing your threading code to work differently
with different scheduling algorithms rather than proving it to be
reliable with a single model which doesn't guarantee much, I believe
reliability will decrease.
> > The proposal doesn't *require* it. My point is that I would be
> > pleasantly surprised to see it, but that it isn't nearly as important to
> > me as the rest of the proposal. Is that really so hard to understand?
>
> Not at all. I gave an example of unsound engineering that is a direct
> result of Java's limitations. Your response is that sound engineering
> isn't important.
Where exactly did I say that? Or rather, if my response is supposedly
that sound engineering isn't important, doesn't that mean your response
about threading is equally that sound engineering isn't important?
Having threading as part of the language rather than *requiring* thread
libraries which may well have different problems on different platforms
(as I've discovered in the past when porting C) sounds like a
requirement for sound engineering to me - yet you've just dismissed it.
Ingo R. Homann
>
> Andrew> What makes you think C++ programs can't be
> Andrew> platform-independent?
>
> Can you do it binary compatible?
Why do you think, that is important? If you have to install an
interpreter (the JDK/JRE/JVM) or a compiler (e.g. the gcc) makes no
difference, I think!
> I have to say though I find this language advocacy a little
> tiresome. Of course Java is better than C++, and perl, and every other
> language on the planet.
Agreed! ;-)
SCNR
> Phil
Ingo
Andrew R. Thomas-Cramer
> > But other points are that:
> > * Sun must maintain those nine redundant function definitions.
> > * If we want to write our own sort -- or other algorithms that must work
on
> > both primitives and Objects -- we're faced with the same redundancy
problem.
>
> Absolutely. Just as every C/C++ programmer has to face the problem that
> those languages don't have any built-in threading facilities. If they
> use a library, someone has to maintain that (and port it to each of the
> different platforms, of course).
>
> As ever, it's a matter of which you value more. As neither of the above
> have been significant problems for me, but dealing with various thread
> libraries *has*, I'm happier with the Java side of the balance.
I'm happy for you. I usually like working in Java better as well. I merely
wanted to note that the problem of redundant sort implementations referenced
by Pete Becker was an example, not the problem as a whole.
Ingo R. Homann
...but only because of it's additional features (gc,
arraybound-/nullpointer-check etc.) which are worth that! (Java is not
THAT slow, most people think!)
Ingo
Pete Becker
>
> Pete Becker wrote:
> >
> > ... Java programmers spend far too much time
> > making copies of code. For another example, look at the documentation
> > for java.util.List.hashCode: it tells you what subclasses should
> > implement, rather than actually implementing it in one place for all
> > subclasses to use. That's an inherent limitation in interfaces, and once
> > again, the result is that you either duplicate code or distort the
> > design. In practice the code gets duplicated.
>
> Slowly! I do *very* much with java and I was not forced to copy code
> very often!!!
Once is enough to prove that the problem exists. I've implemented the
java core library, and there's far too much code duplication.
> And I dont understand what's your problem with the
> hashCode - can you explain it again or give an example?
>
Interfaces can't have implementation code. So rather than being able to
write
interface List
{
public int hashCode()
{
int code = 0;
Iterator iter = iterator();
while (iter.hasNext())
code += iter.next().hashCode();
return code;
}
}
you have to document what hashCode is supposed to do:
interface List
{
public int hashCode();
/* derived classes should implement this:
int code = 0;
Iterator iter = iterator();
while (iter.hasNext())
code += iter.next().hashCode();
return code;
*/
}
And now, every class that implements List must have its own copy of that
code. List is supposed to define the interface to a list object, but it
can't enforce it.
--
Jon Skeet
> > Absolutely. Just as every C/C++ programmer has to face the problem that
> > those languages don't have any built-in threading facilities.
>
> This is a completely different question. Java forces code duplication
> because it doesn't not adequately support reuse.
And how much code duplication occurs in *practice* due to C/C++ not
having any threading in the language? In *theory* of course, there could
be just a single library and everyone using it. In practice, because the
"standard libraries" aren't as standard in C/C++ as they are in Java, I
suspect lots of people have built up their own bits on top of pthreads
etc.
(In fact, this is a criticism you can lay at Java as well, in that
although threading is part of the language, a bit more library support
would help as well. I don't know why there isn't a Semaphore class in
there somewhere. It's dead easy to write, of course, but having it there
to start with would be nicer.)
> > If they
> > use a library, someone has to maintain that (and port it to each of the
> > different platforms, of course).
>
> And how, exactly, do you think that Java provides thread support? Magic?
> Or is there code somewhere? Code that someone has to maintain and port
> to each of the different platforms, of course.
Indeed. So it's a shared problem for a few people. Of course, I don't
have nearly the headaches using Java's threading that I did using
pthreads a while ago. Maybe things have improved magically, but I
suspect not.
Any chance of you starting to get some balance in your posts, btw,
instead of taking this black and white approach?
Jon Skeet
The problem with hashCode is a reasonably legitimate one, in that the
*interface* List (which, as an interface can't give any implementation)
specifies in the documentation how you should implement hashCode.
Of course, the solution is to use an abstract class - which is one of
the reasons AbstractList exists. Due to multiple inheritence of
interface but not implementation, it's nice to have List *as well*, but
if you implement List (and want to put these new Lists in a Hashtable -
if you don't, hashCode is irrelevant) you should follow the specced
implementation.
Of course if you *did* have multiple inheritence of implementation,
you'd have to consider the situation where two different classes wanted
you to have two *different* implementations of hashCode.
Ingo R. Homann
>
> >...but only because of it's additional features (gc,
> >arraybound-/nullpointer-check etc.) which are worth that! (Java is not
> >THAT slow, most people think!)
>
> to a halt while the GUI was redrawing.
Do you mean "GUI-stuff is slow in general (in every language)"? - then
it's no java-problem!
Do you mean "GUI-stuff is slow in general in java but not in C++"? -
Than you must distinguish:
- AWT is *not* slow
- Swing *was* *very* slow in its first versions
- Swing is *not* *very* slow when you use a current Version (1.3)
- Swing *is* somehow slower that a native GUI, *but*: Swing has
Pluggable-Look-And-Feels, is portable and looks the same way on every
system - if you want to achieve that with a C++-libraray, it would be
slow too! If you dont need these 'wonderful' features of Swing, than you
should use AWT! If you shoot with canons on sparrows (sorry, I
translated that directly from german :-) you should not wonder, that you
waste resources!
Ingo
Pete Becker
>
> Pete Becker <peteb...@acm.org> wrote:
> > Jon Skeet wrote:
> > > Yes, it's a defect. My point is that it's an unimportant defect that you
> > > can work around.
> >
> > Yup: you can work around this particular limitation with lots of cut and
> > paste, and lots of prayer that when you have to maintain multiple copies
> > of the same code you won't leave out the edits to one of them. That's
> > not an unimportant problem. Java programmers spend far too much time
> > making copies of code. For another example, look at the documentation
> > for java.util.List.hashCode: it tells you what subclasses should
> > implement, rather than actually implementing it in one place for all
> > subclasses to use. That's an inherent limitation in interfaces, and once
> > again, the result is that you either duplicate code or distort the
> > design. In practice the code gets duplicated.
>
> Or, just possibly, people use AbstractList, which does it for them, and
> subclass that... the way that all of the List implementations in the JDK
> do.
Yup. So what's the point of having List, if every class should subclass
AbstractList instead?
>
> > > Much like the lack of threading support in the language
> > > itself for C/C++ - except I view threading as rather more important.
> > > (Yes, there are libraries to get round that limitation, but it's still a
> > > relative pain to use them.)
> >
> > Unlike Java's toy threads, where you have no way of finding out what the
> > thread scheduling algorithm is, and, therefore, no chance of writing
> > code that will work reliably on multiple platforms.
>
> I'd say that not relying on any particular scheduling algorithm would
> mean it would be *more* likely to work reliably on multiple platforms,
> but possibly less likely to work optimally efficiently.
It's not a matter of relying on a particular scheduling algorithm, but
of avoiding problems that arise from particular algorithms in a
particular application. Good luck writing multi-threaded code that won't
run into problems regardless of the scheduling algorithm that's used.
>
> As soon as you start changing your threading code to work differently
> with different scheduling algorithms rather than proving it to be
> reliable with a single model which doesn't guarantee much, I believe
> reliability will decrease.
How are you going to "prove it to be reliable with a single model which
doesn't guarantee much"? Write once, test everywhere, right?
>
> > > The proposal doesn't *require* it. My point is that I would be
> > > pleasantly surprised to see it, but that it isn't nearly as important to
> > > me as the rest of the proposal. Is that really so hard to understand?
> >
> > Not at all. I gave an example of unsound engineering that is a direct
> > result of Java's limitations. Your response is that sound engineering
> > isn't important.
>
> Where exactly did I say that? Or rather, if my response is supposedly
> that sound engineering isn't important, doesn't that mean your response
> about threading is equally that sound engineering isn't important?
> Having threading as part of the language rather than *requiring* thread
> libraries which may well have different problems on different platforms
> (as I've discovered in the past when porting C) sounds like a
> requirement for sound engineering to me - yet you've just dismissed it.
>
I'm confused. How is threading in Java exempt from having "different
problems on different platforms"?
Ingo R. Homann
>
> Once is enough to prove that the problem exists. I've implemented the
> java core library, and there's far too much code duplication.
>
> > And I dont understand what's your problem with the
> > hashCode - can you explain it again or give an example?
>
> Interfaces can't have implementation code. So rather than being able to
> write
>
>
> And now, every class that implements List must have its own copy of that
> code. List is supposed to define the interface to a list object, but it
> can't enforce it.
>
> --
> Pete Becker
OK, you are right in that case! I would like to use templates in java,
too! (But I just dont think that the 'standard-programmer' (who is NOT
implementing the core-library) needs templates so often! (I know, that
is no argument for not supporting that feature when designing a new
language...))
Ingo
Phillip Lord
Pete> Jon Skeet wrote:
>> Andrew R. Thomas-Cramer <ar...@prism-cs.com> wrote:
>>
>> > > Pete Becker <peteb...@acm.org> wrote: > > > Exactly: there
>> are nine methods in Arrays.sort, precisely because you > > >
>> cannot write this code generically in Java. > > > > Indeed - but
>> the point is that that sort code is already written, and > > you
>> only have to *remember* one thing, which is considerably easier
>> than > > the horrendous "You've got to write it all yourself,
>> *and* write it all > > 9 times" picture you were painting. > >
>> But other points are that: > * Sun must maintain those nine
>> redundant function definitions. > * If we want to write our own
>> sort -- or other algorithms that must work on > both primitives
>> and Objects -- we're faced with the same redundancy problem.
>>
>> Absolutely. Just as every C/C++ programmer has to face the
>> problem that those languages don't have any built-in threading
>> facilities.
Pete> This is a completely different question. Java forces code
Pete> duplication because it doesn't not adequately support reuse.
>> If they use a library, someone has to maintain that (and port it
>> to each of the different platforms, of course).
Pete> And how, exactly, do you think that Java provides thread
Pete> support? Magic? Or is there code somewhere? Code that someone
Pete> has to maintain and port to each of the different platforms,
Pete> of course.
What you mean in the same way that a C threading library
depends on support from the OS kernal. And at some level support from
the chipset. And the compiler to use these different libraries.
The issue here is about code reuse surely? Of course someone
has to write the JVM. But I don't have to write it which is the main
thing.
Phil
Phillip Lord
Pete> Phillip Lord wrote:
>>
Pete> As far as I know, Java generics won't solve this problem,
Pete> because generics only work with Object types, not builtin
Pete> types.
>> There have actually been several proposals which did include the
>> possibility of including primitives in the type system. These
>> required JVM alterations though.
Pete> Which is why they are no longer under consideration, and
Pete> therefore not a possible solution to this problem.
I just mentioned them for informational purposes.
Some of the methods were pretty interesting.
>>
Pete> So "generics" is an appropriate name, but definitely not
Pete> "templates".
>> Thats a funny use of terminology it seems to me. I would have
>> said that "generics" is the more er...generic term, and included
>> templates.
>>
Pete> Except that templates has a specific meaning in C++, and Java
Pete> generics support a small subset of what C++ templates can do.
Okay I see what you are getting at. Personally I would have
say that Java is (hoping to) achieve genericity using a paramaterised
typing mechanism. Again generics being the more generic term, of which
the proposal for java is a specific example.
Still its a terminological argument. I think we both see what
the other means which is the main thing.
Phil
Pete Becker
>
> > > If they
> > > use a library, someone has to maintain that (and port it to each of the
> > > different platforms, of course).
> >
> > And how, exactly, do you think that Java provides thread support? Magic?
> > Or is there code somewhere? Code that someone has to maintain and port
> > to each of the different platforms, of course.
>
> Indeed. So it's a shared problem for a few people. Of course, I don't
> have nearly the headaches using Java's threading that I did using
> pthreads a while ago. Maybe things have improved magically, but I
> suspect not.
You're comparing apples and oranges. pthreads is a low-level thread
interface. There are libraries that sit on top of pthreads and provide
the same sort of capabilities as Java threads.
>
> Any chance of you starting to get some balance in your posts, btw,
> instead of taking this black and white approach?
>
Any chance of sticking to technical issues rather than ad hominem
arguments?
Andrew R. Thomas-Cramer
"Phillip Lord" <p.l...@hgmp.mrc.ac.uk> wrote in message
news:okofu4e...@proline.sbc.man.ac.uk...
> There are two solutions if code reuse is absolutely vital
> to you here. Its is not of course necessary to create the object
> wrappers upfront, you can do it as you go along. Further if you create
> some new primitive wrappers which are mutable, then you can get away
> with just having two wrapper objects which you continually reuse. You
> would have to define the interfaces describing the unsorted data
> structure carefully but it should be possible.
You're right.
Another approach would be use of java.lang.reflect.Array.get() in the sort
implementation; it automatically wraps primitive array members in objects.
I don't know what the constant-factor costs are in these approaches.
> Of course neither of these solutions is nice. It is a pity
> that Java did not support a proper system for genericity right from
> the start.
Agreed. However, if Java's generic types will be easier to use than C++'s,
it will be worth the wait.
> Andrew> What makes you think C++ programs can't be
> Andrew> platform-independent?
>
> Can you do it binary compatible?
I don't have any need for binary-compatible code.
Stefan Koennecke
Types? That's why I mentionend java.utils.Array. In this class you can find
a qsort for every primitive. Looks like everything is covered.
Stefan.
Pete Becker <peteb...@acm.org> schrieb in im Newsbeitrag:
3AD30538...@acm.org...
> Stefan Koennecke wrote:
> >
> > You can work around this special problem pretty easily and nicely in
Java.
> > See java.lang.Compareable, java.util.Array for qsort&co.
>
> You can't use Comparable on builtin types, only types derived from
> Object.
>
> >
> > In fact I would prefere the Java solution to that. It seems less
"sensible"
> > to programming erros to me.
> >
>
> java.util.Arrays provides nine (yes, nine) sort functions, one for each
> of the fundamental types and one for Objects. That's the point: there's
> no way to write that code just once, even though all of the versions for
> builtin types are identical except for the types of the arguments.
>
Jon Skeet
> > Or, just possibly, people use AbstractList, which does it for them, and
> > subclass that... the way that all of the List implementations in the JDK
> > do.
>
> Yup. So what's the point of having List, if every class should subclass
> AbstractList instead?
See another response for a couple of reasons.
> > I'd say that not relying on any particular scheduling algorithm would
> > mean it would be *more* likely to work reliably on multiple platforms,
> > but possibly less likely to work optimally efficiently.
>
> It's not a matter of relying on a particular scheduling algorithm, but
> of avoiding problems that arise from particular algorithms in a
> particular application. Good luck writing multi-threaded code that won't
> run into problems regardless of the scheduling algorithm that's used.
Give me an example which would cause a problem. I haven't found any yet.
Feel free to choose the most bizarre scheduling algorithm and an odd
example to be coded - but if you could make the example at least easy to
understand, it would help. (Of course, the scheduling algorithm must be
"at least good enough" to make an implementation of the JVM feasible.)
You may be able to do it - but I haven't had any problems so far. I'd be
interested to see what you can throw at me (or rather, at Java).
I'd rather code for just that guarantee than write different code for
each of the scheduling algorithms I might come up against on the
different platforms I want my code to run on.
> > As soon as you start changing your threading code to work differently
> > with different scheduling algorithms rather than proving it to be
> > reliable with a single model which doesn't guarantee much, I believe
> > reliability will decrease.
>
> How are you going to "prove it to be reliable with a single model which
> doesn't guarantee much"? Write once, test everywhere, right?
Test everywhere is certainly a good idea anyway - but if you *only* use
what *is* guaranteed (which has been enough for me so far, at least) you
should be okay.
> > Where exactly did I say that? Or rather, if my response is supposedly
> > that sound engineering isn't important, doesn't that mean your response
> > about threading is equally that sound engineering isn't important?
> > Having threading as part of the language rather than *requiring* thread
> > libraries which may well have different problems on different platforms
> > (as I've discovered in the past when porting C) sounds like a
> > requirement for sound engineering to me - yet you've just dismissed it.
>
> I'm confused. How is threading in Java exempt from having "different
> problems on different platforms"?
Because *I* don't have the problems. Someone who knows more about
threading implementation has them, and is likely to do a better job with
them. And if *I* don't have the problems, that means a lot of people in
my situation won't have the problems. (They'll have other problems,
certainly, just because threading is an inherently tricky beast, but I
think they'll usually be simpler. I suspect that *almost* any inherent
complexity in a Java threading problem would also be present using
pthreads, and you'd have to deal with the other problems I ran into as
well.)
Pete Becker
And in C++ you don't have to write a threads library either. The
differences are that in C++ you can choose a library that fits what you
need to do. In Java you get the one that comes with Java, with whatever
flaws it may have on whatever VM you're running with.
Jon Skeet
> too! (But I just dont think that the 'standard-programmer' (who is NOT
> implementing the core-library) needs templates so often! (I know, that
> is no argument for not supporting that feature when designing a new
> language...))
On that I disagree - many times I've wanted to have some way of doing
C++-template-like things in Java. An awful lot of code in Java uses
Vectors and Hashtables, for instance, and I suspect 99% of the time the
elements or keys and values in them have a common base type below
object. It's an ugliness, and some people have bugs in their code
because of it. (I've been lucky/careful, and never tried to cast
something from a Vector to the wrong type, but I believe others have.)
(Similarly I'd like to see const-like behaviour (or a better version of
it) in Java, which is why I've voted for the RFE on it.)
Ingo R. Homann
>
> > I don't
> > have nearly the headaches using Java's threading that I did using
> > pthreads a while ago. Maybe things have improved magically, but I
> > suspect not.
>
> You're comparing apples and oranges. pthreads is a low-level thread
> interface. There are libraries that sit on top of pthreads and provide
> the same sort of capabilities as Java threads.
That is something that I hear *very* often when arguing with a C++-fan
which language is 'better'! :-)
Of course you are right somehow...
BUT: One of the great advantages of java IS the fact that it has got an
*integrated* high-level, standardised library and an *integrated*
garbage-collection and an *integrated* nullpointer-/arraybounds-check!
C++-programmers often refer to "But you *can* have all that in C++, if
you want so..." but the problem is that it is not standardised, that
means when I work in another job, I have to learn to program with a
completely new library. And even worse, when trying to find a (e.g.)
garbage-collector- or smart-pointer-implementation for C++, I have to
look at 10 different implementations, compile them, try them and
learn-by-trial-and-error, that unfortunately, my CORBA-distribution
works with the MIT-implementation of pthreads which is unfortunately not
compatible with the boehm-garbage-collector! I spend SEVERAL hours and
days to find a memory-management-tool with works in my environment, and
I found NONE! *That* is very frustrating and unproductive, and I think
that all is a result of the fact that there is no 'monopolistic'
organisation that cares about the language! Anyway, you don't have such
problems (or at least not half that hard problems) with java.
Ingo
Pete Becker
>
> Well, all classes in Java are derived from Object. You think about Primitive
> Types? That's why I mentionend java.utils.Array. In this class you can find
> a qsort for every primitive. Looks like everything is covered.
>
Sigh. Yes, I know. I've implemented all nine copies of sort, nine copies
of binarySearch, nine copies of equals, and eighteen copies of fill.
sort was an example of a problem in Java. In C and C++ you can write a
single version of a sort function that will handle all types. In Java
you cannot. And that problem arises whenever you need to be able to do
something for various primitive types. You cannot write it just once in
Java. So while it was very nice of Sun to help you avoid this problem
when you want to sort, search, compare, and fill arrays, they treated a
symptom of the problem and not the problem itself.
Phillip Lord
>>>>> "Pete" == Pete Becker <peteb...@acm.org> writes:
>> Much like the lack of threading support in the language itself
>> for C/C++ - except I view threading as rather more important.
>> (Yes, there are libraries to get round that limitation, but it's
>> still a relative pain to use them.)
Pete> Unlike Java's toy threads, where you have no way of finding
Pete> out what the thread scheduling algorithm is, and, therefore,
Pete> no chance of writing code that will work reliably on multiple
Pete> platforms.
I think what you mean is that you have no chance to write code
which will work identically on multiple platforms. Whether it works
reliably on all platforms of course depends on the programmer.
Phil
Jon Skeet
> > Indeed. So it's a shared problem for a few people. Of course, I don't
> > have nearly the headaches using Java's threading that I did using
> > pthreads a while ago. Maybe things have improved magically, but I
> > suspect not.
>
> You're comparing apples and oranges. pthreads is a low-level thread
> interface. There are libraries that sit on top of pthreads and provide
> the same sort of capabilities as Java threads.
Hmm... I'll take your word for that. Unfortunately, I didn't know about
such libraries when I had to help port an application.
(Windows/Tru64/Solaris/Linux/HPUX - all reasonably mainstream.)
Evidently the original authors either didn't know about such libraries
or had reasons for not using them. Anything which would have helped me
build it reliably and quickly would have been very welcome, I assure
you.
In other words, for me, C not having a single standard thread library
(or language support) was an issue - it made my life harder.
I firmly believe that having multithreading support in the language is a
benefit, in and of itself. Do you disagree? (Note that in saying that,
I'm not saying you should have support which doesn't allow you to find
out about thread scheduling algorithms, etc.)
> > Any chance of you starting to get some balance in your posts, btw,
> > instead of taking this black and white approach?
>
> Any chance of sticking to technical issues rather than ad hominem
> arguments?
I just find plain advocacy gets tedious very quickly. Discussing how
each language could take lessons from another, and debating pros and
cons sensibly (rather than ever admitting a single point) is much more
interesting. Please excuse me for wanting this thread to be of some use
to someone, rather than the equivalent of shouting at each other whilst
holding our fingers in our ears.
Jon Skeet
> And in C++ you don't have to write a threads library either. The
> differences are that in C++ you can choose a library that fits what you
> need to do. In Java you get the one that comes with Java, with whatever
> flaws it may have on whatever VM you're running with.
You can, however, choose which VM you use if one has a more suitable
threading implementation for you than another. Some VMs have options for
different thread implementations within the same VM, too.
I agree, however, that the VM choice and the threading choice are very
tightly bound.
Phillip Lord
Ingo> Phillip Lord wrote:
>>
Andrew> What makes you think C++ programs can't be
Andrew> platform-independent?
>> Can you do it binary compatible?
Ingo> Why do you think, that is important? If you have to install an
Ingo> interpreter (the JDK/JRE/JVM) or a compiler (e.g. the gcc)
Ingo> makes no difference, I think!
It is important yes.
For example my local network provides NFS mounted
directories. I can stick my Java applications in one place, and then
both the linux, and IRIX boxes that we use can read these applications
and run them quite happily. We do not have to maintain two separate
binary trees.
Its the same as the situation for perl for instance. For
quite a while now Perl has come with perlcc which is a GCG front end
which generates binaries from the perl. Given that this means you
don't have the overhead of the perl parser it makes sense that most
people would use perlcc. The reality is though most perl scripts
remain just that..scripts. They are not compiled because then they are
"binary" compatible.
Of course for some people, and in some circumstances binary
compatibility is not terribly relevant. As I say you have to make your
choices.
>> I have to say though I find this language advocacy a little
>> tiresome. Of course Java is better than C++, and perl, and every
>> other language on the planet.
Ingo> Agreed! ;-)
Oh dear. I wish you hadn't quoted in that way. Someone is
bound to flame me now having read the quote but not the original
post!
Phil
Pete Becker
>
> Pete Becker wrote:
> >
> > > I don't
> > > have nearly the headaches using Java's threading that I did using
> > > pthreads a while ago. Maybe things have improved magically, but I
> > > suspect not.
> >
> > You're comparing apples and oranges. pthreads is a low-level thread
> > interface. There are libraries that sit on top of pthreads and provide
> > the same sort of capabilities as Java threads.
>
> That is something that I hear *very* often when arguing with a C++-fan
> which language is 'better'! :-)
>
> Of course you are right somehow...
>
> BUT: One of the great advantages of java IS the fact that it has got an
> *integrated* high-level, standardised library
which is in many places poorly designed, and in many places inadequately
documented, but that doesn't seem to bother Java fans...
> and an *integrated*
> garbage-collection
> and an *integrated* nullpointer-/arraybounds-check!
which you cannot shut off, even if you want to. Why is it that Java
programmers think that it's good to ship a debugger as part of every
application?
> C++-programmers often refer to "But you *can* have all that in C++, if
> you want so..." but the problem is that it is not standardised, that
> means when I work in another job, I have to learn to program with a
> completely new library.
And if you program in Java you only have half a dozen libraries to worry
about, since your application runs with whatever library happens to be
on the target machine. So if you really want to make your Java
application portable, you'll write to the 1.0 specification.
> And even worse, when trying to find a (e.g.)
> garbage-collector- or smart-pointer-implementation for C++, I have to
> look at 10 different implementations, compile them, try them and
> learn-by-trial-and-error, that unfortunately, my CORBA-distribution
> works with the MIT-implementation of pthreads which is unfortunately not
> compatible with the boehm-garbage-collector! I spend SEVERAL hours and
> days to find a memory-management-tool with works in my environment, and
> I found NONE! *That* is very frustrating and unproductive, and I think
> that all is a result of the fact that there is no 'monopolistic'
> organisation that cares about the language! Anyway, you don't have such
> problems (or at least not half that hard problems) with java.
>
Sure, if the version of the jdk that you're coding to happens to be the
same as the one on your target system.
Pete Becker
>
> Pete Becker <peteb...@acm.org> wrote:
> > And in C++ you don't have to write a threads library either. The
> > differences are that in C++ you can choose a library that fits what you
> > need to do. In Java you get the one that comes with Java, with whatever
> > flaws it may have on whatever VM you're running with.
>
> You can, however, choose which VM you use if one has a more suitable
> threading implementation for you than another. Some VMs have options for
> different thread implementations within the same VM, too.
Which, of course, gets right back to testing to find out which thread
implementation is the best fit for you application. Now, how is that
better than C++? <g>
Pete Becker
>
> Agreed. However, if Java's generic types will be easier to use than C++'s,
> it will be worth the wait.
Java's generic types are essentially typesafe wrappers. That's a trivial
use of templates in C++, and very easy to do.
Phillip Lord
>>>>> "Pete" == Pete Becker <peteb...@acm.org> writes:
Pete> Interfaces can't have implementation code. So rather than
Pete> being able to write
Pete> interface List { public int hashCode() { int code = 0;
Pete> Iterator iter = iterator(); while (iter.hasNext()) code +=
Pete> iter.next().hashCode(); return code; } }
Pete> you have to document what hashCode is supposed to do:
Pete> interface List { public int hashCode(); /* derived classes
Pete> should implement this: int code = 0; Iterator iter =
Pete> iterator(); while (iter.hasNext()) code +=
Pete> iter.next().hashCode(); return code; */ }
Pete> And now, every class that implements List must have its own
Pete> copy of that code.
This is where you use Object composition. You write
the code once, and then have your subclasses reuse it. Object
composition is a fairly powerful thing, and it often makes sense to
use it even in languages which do allow multiple inheritance of
implementation.
Pete> List is supposed to define the interface to a list object, but
Pete> it can't enforce it.
This is true of implementation inheritance as well. It is
possible to override the super class implementation in a way which
breaks the super class contract.
You could get around this by some form of design by contract
(assuming that you could inherit and provide contract implementation
in interfaces).
It is true that by allowing implementation inheritance you
have a good reference implementation. In other words the super class
implementation provides a good way of expressing what the method
contract is. But even this is a poor thing, because the implementation
is heavily dependant on the internal workings of the super class.
In a nutshell I think what you are complaining about is the
inability to express exactly what the method contract is. As I say
this affects C++ and Java equally.
Phil
Steven E. Harris
> Abstract classes can to some extend implement Java's interfaces -
> though not completely and not as elegantly.
Why not completely? A class consisting solely of pure virtual methods
is equivalent to a Java interface. It just doesn't waste a keyword
declaring it.
If anything, the frequent Java newbie "interface v. abstract class"
questions show that Java's interface dichotomy is more confusing.
F'up set.
--
Steven E. Harris :: steven...@tenzing.com
Tenzing :: http://www.tenzing.com
David Ehrens
news:13c5dtk8v3n1p9hol...@4ax.com...
...
> Why can't Java programmer access "OS hooks (unix, NT); sensing and
> manipulating the hardware (mouse buttons to device drivers)" using JNI
(Java
> Native Interface). If he can do this using JNI, while keeping the
program
> platform independent, why that is not better than C++?
Why? I believe that was a question asked of James Gosling in regard to
Java's handling of right-clicked mouse buttons. But Java is also
prevented from determining system memory (JVM is all it knows about),
environment variables (deprecated), and accessing the hardware directly
(streng verboten), so it is not suitable for writing device drivers. I
am not saying that C++ is better than Java, but it can be used for more
things, while Java seems to be better for writing some kinds of
applications, particularly because of the J2EE framework.
David Ehrens
Phillip Lord
>>>>> "Pete" == Pete Becker <peteb...@acm.org> writes:
>> The issue here is about code reuse surely? Of course someone has
>> to write the JVM. But I don't have to write it which is the main
>> thing.
>>
Pete> And in C++ you don't have to write a threads library
Pete> either. The differences are that in C++ you can choose a
Pete> library that fits what you need to do. In Java you get the one
Pete> that comes with Java, with whatever flaws it may have on
Pete> whatever VM you're running with.
In other words there are many threads libraries in C++.
Of course this is an advantage in some ways. But not in
others. Programmers will have to spend more time learning the
different libraries.
Naturally there is nothing to prevent Java from supporting
multiple libraries, either built on top of the core libraries or
provided externally.
Still this all comes down to the point that Java and C++ are
designed to do different things. Its not surprising that they have
strengths and weaknesses.
Phil
Pete Becker
>
> >>>>> "Pete" == Pete Becker <peteb...@acm.org> writes:
>
> Pete> Interfaces can't have implementation code. So rather than
> Pete> being able to write
>
> Pete> interface List { public int hashCode() { int code = 0;
> Pete> Iterator iter = iterator(); while (iter.hasNext()) code +=
> Pete> iter.next().hashCode(); return code; } }
>
> Pete> you have to document what hashCode is supposed to do:
>
> Pete> interface List { public int hashCode(); /* derived classes
> Pete> should implement this: int code = 0; Iterator iter =
> Pete> iterator(); while (iter.hasNext()) code +=
> Pete> iter.next().hashCode(); return code; */ }
>
> Pete> And now, every class that implements List must have its own
> Pete> copy of that code.
>
> This is where you use Object composition. You write
> the code once, and then have your subclasses reuse it. Object
> composition is a fairly powerful thing, and it often makes sense to
> use it even in languages which do allow multiple inheritance of
> implementation.
Yup. And that's the response that I always got from the Pascal folks
when I worked at Borland: "you don't need multiple inheritance, just use
[properties]" (replace properties with your favorite hackaround).
Composition can be powerful, but it's overkill for hashCode:
class ImplementHashCode
{
public int hashCode(List list)
{
// code goes here
}
}
public class UseHashCode
implements List
{
public int hashCode() { return new ImplementHashCode().hashCode(this); }
}
So now, instead of inheriting from a single implementation, every
subclass needs to implement this version of hashCode. Granted, it's more
maintainable than actually implementing hashCode in the subclass
directly, but it's an awful lot of mechanism for something that ought to
be simple.
>
>
> Pete> List is supposed to define the interface to a list object, but
> Pete> it can't enforce it.
>
> This is true of implementation inheritance as well. It is
> possible to override the super class implementation in a way which
> breaks the super class contract.
Nope. In Java you'd make it final, in C++ non-virtual.
Phillip Lord
Andrew> "Phillip Lord" <p.l...@hgmp.mrc.ac.uk> wrote in message
Andrew> news:okofu4e...@proline.sbc.man.ac.uk...
>> There are two solutions if code reuse is absolutely vital to you
>> here. Its is not of course necessary to create the object
>> wrappers upfront, you can do it as you go along. Further if you
>> create some new primitive wrappers which are mutable, then you
>> can get away with just having two wrapper objects which you
>> continually reuse. You would have to define the interfaces
>> describing the unsorted data structure carefully but it should be
>> possible.
Andrew> You're right. Another approach would be use of
Andrew> java.lang.reflect.Array.get() in the sort implementation; it
Andrew> automatically wraps primitive array members in objects. I
Andrew> don't know what the constant-factor costs are in these
Andrew> approaches.
With automatic code generation there is no constant
factor cost. Or rather the cost is the once per JVM instantiation cost
of loading and storing the classes. With the mutable object wrapper,
its a couple of objects. Relatively trivial for any large
sort. Obviously though libraries which work in way have not, to my
knowledge, been written.
>> Of course neither of these solutions is nice. It is a pity that
>> Java did not support a proper system for genericity right from
>> the start.
Andrew> Agreed. However, if Java's generic types will be easier to
Andrew> use than C++'s, it will be worth the wait.
The last time I read the proposal the type system was
relatively simple, but there were certain operations that you might
want to perform which were quite nasty. For instance it was not
possible to use a paramaterised type to instantiation an array...so
public class Blah<A>
{
public void method( A param )
{
A[] array = new A[ 40 ];
}
}
would not work. You had to do some nasty things like
public void method( A param, A[] template )
{
A[] array = Generic.getArray( template, 40 );
}
the point is that the first array called template can be
used to determine the runtime type and produce a new array. As far as
I could see the only reason for this is that there appears to be no
way given a Class object to get the Class object for the arrays of
that type. Perhaps they will change the Class class to allow this to
happen which would solve this problem.
Andrew> What makes you think C++ programs can't be
Andrew> platform-independent?
>> Can you do it binary compatible?
Andrew> I don't have any need for binary-compatible code.
Really? Do you write platform independent code. If not
then binary compatibility would be useless. If so then would my
previous example of only having to maintain a single binary for
different OS'es sharing a common network file system be useful to you?
Phil