Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Java vs C++

Reply
Thread Tools

Java vs C++

 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      02-06-2011
In message <iijrj2$i0g$(E-Mail Removed)-september.org>, Joshua Cranmer wrote:

> My copy of the C++0x draft reference standard, i.e. the copy sent out
> for a ballot by national bodies, consisted of no fewer than 1300
> numbered pages.


Yeah, so C++ continues to leap ahead into even greater complexity.

> Also take into consideration the fact that the C++ standard does not try
> to pin stuff down into unambiguous interoperable statements, e.g., a
> precise size definition for size_t.


It seems to me that’s another drawback of Java, that it explicitly defines
the sizes of things from the viewpoint of 32-bit architectures like those
current in the 1990s. Some of those decisions look less wonderful on current
64-bit architectures.

> So 684 pages of well-written, easily-understood text ...


Not quite so “well-written, easily-understood”, as I have pointed out
elsewhere. The mistakes seem particularly concentrated in the parts
describing the newer language features.
 
Reply With Quote
 
 
 
 
Lawrence D'Oliveiro
Guest
Posts: n/a
 
      02-06-2011
In message <iil5ed$10m$(E-Mail Removed)-september.org>, Joshua Cranmer wrote:

> On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
>
>> In message<4d4d8322$0$41117$(E-Mail Removed)4all.nl>, Silvio wrote:
>>
>>> ... templates and gener[ic]s are completely different beasts.

>>
>> “Completely” as in “having nothing in common”? Or is this some usage of
>> “completely” that I wasn’t aware of?
>>
>> Please explain.

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


They are different things in Java as well. The only time they become the
same thing is in “erasures” and “raw types”, which are backward-
compatibility mechanisms introduced to avoid breaking existing code that
doesn’t know about generics. The use of the name “Foo” without parameters is
explicitly deprecated, with a bold warning that says it may go away in the
future, you have been warned.

And then, of course, the language goes on to use exactly that deprecated
syntax as the recommended way of accessing static members.

(Exercise for the reader: it turns out there’s another way of accessing
static members. But that’s deprecated as well. What is it?)

> Generics in Java are basically compile-time syntactic sugar to ensure
> type-safety of container types at compile time instead of waiting until
> you hit the code at runtime to get that dreaded ClassCastException.


Same sort of thing in C++.

> About the only thing they share in common is the syntax ...


Yeah, funny that. If Java didn’t want to be seen as copying C++, why did it
reuse exactly the same syntax?
 
Reply With Quote
 
 
 
 
Joshua Cranmer
Guest
Posts: n/a
 
      02-06-2011
On 02/05/2011 11:13 PM, Lawrence D'Oliveiro wrote:
> They are different things in Java as well.


The hell they aren't. In Java, there is only one instance of
LinkedList::add(T object). In C++, there are as many instances of
std::list<T>::front as times you use it.

Try, for example, implementing both List<String> and List<Character> in
the same class. Java will tell you that you cannot do it. C++, on the
other hand, wouldn't bat an eye.

> The only time they become the
> same thing is in “erasures” and “raw types”, which are backward-
> compatibility mechanisms introduced to avoid breaking existing code that
> doesn’t know about generics.


I think Java would likely have gone with much the same syntax even if
generics had been introduced in the beginning.

> And then, of course, the language goes on to use exactly that deprecated
> syntax as the recommended way of accessing static members.


It's not the same syntax. List<String> is the type of a specific
instance, while the class still remains List.

>> About the only thing they share in common is the syntax ...

>
> Yeah, funny that. If Java didn’t want to be seen as copying C++, why did it
> reuse exactly the same syntax?


Propose a different syntax for Java generics. Note that it cannot be
syntactically ambiguous with any other Java construct, and that, since
it will be used a fair amount, it must be on the shorter side. There
aren't many characters you can really use; < and > are about the only
thing that fits the bill.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Joshua Cranmer
Guest
Posts: n/a
 
      02-06-2011
On 02/05/2011 11:06 PM, Lawrence D'Oliveiro wrote:
> It seems to me that’s another drawback of Java, that it explicitly defines
> the sizes of things from the viewpoint of 32-bit architectures like those
> current in the 1990s. Some of those decisions look less wonderful on current
> 64-bit architectures.


I would venture a guess that most C or C++ code isn't as easily portable
to 64-bit platforms as you would think, since people make assumptions
about the sizes of various types. If you don't define de jure type
sizes, people will follow the de facto standards (i.e., 32-bit) and will
then get horrible breakages when the platform it runs on does not match
the standards.

Also, I might add, the main benefit 64-bit holds right now is the
increased access to memory space, i.e., 64-bit addressability of
pointers. Since Java does not let you manipulate pointer addresses
directly, the implementation is easily able to adjust the size of an
Object pointer and still conform to the specification. So you basically
get access to as much memory as your host will allow without the messy
bits about the size of integral operands being essentially undefined.

> Not quite so “well-written, easily-understood”, as I have pointed out
> elsewhere. The mistakes seem particularly concentrated in the parts
> describing the newer language features.


If you think it is so difficult to understand, you must not have voyaged
deeply into the world of specifications. Java is easily understandable
compared to some of the stuff I've read.

--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      02-06-2011
Lew wrote:
>> C++ doesn't have generics. It has templates. They aren't the same thing.
>>
>> C# has generics. Java has (different) generics. C++ doesn't.
>>
>> Lawrence is trolling.


Silvio wrote:
> Hello Lew,
>
> You are correct, templates are a completely different thing. However, since
> they try to achieve a similar goal (albeit in very different ways) they are
> often compared and spoken of in combination.
>
> I suspected he is trolling also but could not resist correcting a false
> statement.


That's funny, because the statement wasn't false and you didn't correct it.
You even said it was correct.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|
 
Reply With Quote
 
Silvio
Guest
Posts: n/a
 
      02-06-2011
On 02/06/2011 06:15 AM, Lew wrote:
> Lew wrote:
>>> C++ doesn't have generics. It has templates. They aren't the same thing.
>>>
>>> C# has generics. Java has (different) generics. C++ doesn't.
>>>
>>> Lawrence is trolling.

>
> Silvio wrote:
>> Hello Lew,
>>
>> You are correct, templates are a completely different thing. However,
>> since
>> they try to achieve a similar goal (albeit in very different ways)
>> they are
>> often compared and spoken of in combination.
>>
>> I suspected he is trolling also but could not resist correcting a false
>> statement.

>
> That's funny, because the statement wasn't false and you didn't correct
> it. You even said it was correct.
>


Lawrence said "C++ had this from the beginning" referring to Java having
added generics afterwards. That was a false statement.

I pointed out that in C++ this was also a later addition. I just made
the mistake of referring to templates as generics.
 
Reply With Quote
 
Silvio
Guest
Posts: n/a
 
      02-06-2011
On 02/06/2011 05:06 AM, Lawrence D'Oliveiro wrote:
> In message<iijrj2$i0g$(E-Mail Removed)-september.org>, Joshua Cranmer wrote:
>
>> My copy of the C++0x draft reference standard, i.e. the copy sent out
>> for a ballot by national bodies, consisted of no fewer than 1300
>> numbered pages.

>
> Yeah, so C++ continues to leap ahead into even greater complexity.
>
>> Also take into consideration the fact that the C++ standard does not try
>> to pin stuff down into unambiguous interoperable statements, e.g., a
>> precise size definition for size_t.

>
> It seems to me that’s another drawback of Java, that it explicitly defines
> the sizes of things from the viewpoint of 32-bit architectures like those
> current in the 1990s. Some of those decisions look less wonderful on current
> 64-bit architectures.
>
>> So 684 pages of well-written, easily-understood text ...

>
> Not quite so “well-written, easily-understood”, as I have pointed out
> elsewhere. The mistakes seem particularly concentrated in the parts
> describing the newer language features.


Oh, I remember how well C++ and its undefined sizes of things served us
when we had to port heaps of code from 16-bit to 32-bit.

 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      02-06-2011
On 11-02-06 12:39 AM, Ken Wesson wrote:
[ SNIP good overview ]

> In reality, Java's static types and checked exceptions will throw a fair
> amount of syntactic salt into this, barring a hefty (and again Haskell-
> like) infusion of type inference. Java could lose out in the long run to
> JVM hosted languages designed to be functional from the ground up. Of
> these the frontrunners seem to be Clojure and Scala, with Scala's non-
> Lispy syntax giving it an edge in familiarity (and especially with
> management) and Clojure's macros (and consequent ability to reify
> boilerplate patterns into things you can name and call and not
> reimplement over and over again) giving it an edge in expressivity.
>
> Both are gaining traction even with management types, especially when
> stuff coded in them can be bundled into jars and deployed on application
> servers in a manner identical to deploying Java code. It doesn't look or
> feel any different to management than deploying Java; the coders are
> pushing different symbols around in their text editors and IDEs but
> they're still using IDEA or NetBeans or Eclipse and still producing .jar
> files that behave the same way when put on the server. So if the coders
> are typing stuff that looks incomprehensible in a different way than it
> did before, and seem a bit happier, and are suddenly making their
> deadlines instead of missing them, and nothing has stopped working or
> started working differently at a level management notices, management
> won't rock the boat. At most they'll want to be assuaged about
> intellectual property rights, mainly that a) the company still owns its
> code and b) they aren't going to get sued for using this stuff. Both
> languages in question have, if anything, less stringent license
> requirements than Java itself.

[ SNIP ]

I'm currently pushing Scala (nothing against Clojure really, I am just
considerably more familiar with Scala) quietly, in-house and also on
some client projects, with similar thinking in mind. It _is_ a fact that
management truly doesn't care that this chunk of opcodes was originally
Java source, and that other chunk of opcodes was originally Scala
source. If a project development team can incrementally introduce user
libraries into a Java EE environment that happen to be written in Scala,
and they are developed faster and we end up with more reliable code,
nobody is going to complain.

AHS
--
We must recognize the chief characteristic of the modern era - a
permanent state of what I call violent peace.
-- James D. Watkins
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      02-06-2011
On 11-02-06 12:06 AM, Lawrence D'Oliveiro wrote:
> In message<iijrj2$i0g$(E-Mail Removed)-september.org>, Joshua Cranmer wrote:
>
>> My copy of the C++0x draft reference standard, i.e. the copy sent out
>> for a ballot by national bodies, consisted of no fewer than 1300
>> numbered pages.

>
> Yeah, so C++ continues to leap ahead into even greater complexity.
>
>> Also take into consideration the fact that the C++ standard does not try
>> to pin stuff down into unambiguous interoperable statements, e.g., a
>> precise size definition for size_t.

>
> It seems to me that’s another drawback of Java, that it explicitly defines
> the sizes of things from the viewpoint of 32-bit architectures like those
> current in the 1990s. Some of those decisions look less wonderful on current
> 64-bit architectures.
>
>> So 684 pages of well-written, easily-understood text ...

>
> Not quite so “well-written, easily-understood”, as I have pointed out
> elsewhere. The mistakes seem particularly concentrated in the parts
> describing the newer language features.


You haven't actually pointed out any mistakes. Now, if your intent is to
point out parts of the JLS that you find hard to understand, and your
argument is that if _you_ are having problems then so are many others,
then a more productive approach would be (1) to phrase it that way, and
(2) offer a suggestion or two that you think is better. But you haven't
located any flat-out mistakes yet.

I find the various versions of the JLS to be considerably better than
most other language or API specs I've had to wade through.

AHS

--
We must recognize the chief characteristic of the modern era - a
permanent state of what I call violent peace.
-- James D. Watkins
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      02-06-2011
On 05-02-2011 23:06, Lawrence D'Oliveiro wrote:
> In message<iijrj2$i0g$(E-Mail Removed)-september.org>, Joshua Cranmer wrote:
>> Also take into consideration the fact that the C++ standard does not try
>> to pin stuff down into unambiguous interoperable statements, e.g., a
>> precise size definition for size_t.

>
> It seems to me that’s another drawback of Java, that it explicitly defines
> the sizes of things from the viewpoint of 32-bit architectures like those
> current in the 1990s. Some of those decisions look less wonderful on current
> 64-bit architectures.


There are nothing in defining the size of the simple data types
that are tied to 32 bit architecture.

Why shoudl 8, 16, 32 and 64 bit integers be more 32 bit than
64 bit centric??

>> So 684 pages of well-written, easily-understood text ...

>
> Not quite so “well-written, easily-understood”, as I have pointed out
> elsewhere. The mistakes seem particularly concentrated in the parts
> describing the newer language features.


As far as I have seen all your so called mistakes is not problems
in the JLS but you not understanding the text, because you have
started reading the JLS without starting with a very basic tutorial
about Java.

Arne

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Hot Requirements: 1.Sr Java Developer,2.Java Developer (Java with EJB) Isaac Java 0 01-20-2011 08:41 PM
hey i am just started java,, can anyone tell me the use ,application, why java , importance of java.. manish sahu Java 3 02-14-2008 12:00 AM
[JAVA] [EVALUATION] - The Java Failure (Sorry: The Java(tm) Failure) Ilias Lazaridis Java 0 02-01-2005 10:32 AM
JAVA VIRTUAL MUCHINE OR SUN JAVA Fernando Kohan Firefox 1 11-14-2004 02:04 AM
Job to convert Java App 1.3.1 to Java Newest of Java Michael Kintner Java 0 11-30-2003 04:42 AM



Advertisments