Java vs C++

  • Thread starter Lawrence D'Oliveiro
  • Start date
J

Joshua Cranmer

No, it isn’t.

You need to brush up on your reading skills then.
My point exactly.

You failed to completely comprehend what I was getting at.

The specification requires them to be distinct classes--which implies
with distinct code implementations; an implementation can only forgo
that requirement if and only if the code does not actually check to make
sure that it is the case.
So where did it say whether distinct types had to be implemented with the
same or different code?

"Every program shall contain exactly one definition of every non-inline
function or object that is used in that program; no diagnostic
required." (§3.2, clause 3) The specification also goes so far as to
specifically call out that "It is unspecified whether such a variable
has an address distinct from that of any other object in the program."
Given such a statement, it is reasonable to assume that the spec intends
for distinct definitions to correspond to distinct objects unless
otherwise mentioned.

Suffice to say, it is required, in Java, for two instantiations of a
generic type with the same raw type to share the same code, whereas in
C++, there are cases where this simply cannot be the case, and the spec
intends for it to never be the case, so far as the program can tell.
 
A

Andreas Leitgeb

What's so dubious about that statement? Looks perfectly valid to me.
In case you saw a question-mark in his last line, that was a "smaller
or equal"-sign.

The whole discussion resolves quickly, when you distinguish two
separate points:
1) availability of a language on a platform
2) The actual effort of making a particular set of code
run on a particular platform once it fulfills "1)"

Obviously, Lawrence talks about "1)", while you (Arne) seem to
have "2)" in mind.
 
A

Andreas Leitgeb

Arne Vajhøj said:
There are other reasons to not have type erasure.
Generics are also about not knowing the parameter types
beforehand (except that it derives from some upper bound
class). Thus, the compiler wouldn't be able to determine
availability of an appropriate constructor at compile-time.
Thus, it would once again be a runtime-thing.

If generics were re-compiled for each used parametrisation,
like C++'s templates are, then this argument would be voided,
but I don't know if any current proposals for getting
reifiability into Java go all that far.
general reflection
is a runtime-thing.
method overload
If this is a problem, then there was a problem in design
phase. Such overloaded methods would just as well prohibit
using abstract base types for variables. (i.o.w.: would be
bad even aside of generics)
 
A

Andreas Leitgeb

Can you give an example of where introduction of reifiable type
would cause not getting a compile time error but a runtime error
instead?

Bad programmers :)
They might then (without other need) cast a List<String> to a bare List,
relying on runtime-checks to prevent non-Strings to get actually added.
 
H

Heike Svensson

Sulfide Eater said:
Get real. Those were using COBOL on Vaxen. Half of them
still are. Everybody knows this.

Smack that brutish Arne around a bit!
[insult deleted]s like Sulfide Eater [false accusation
deleted], Arne.

What does your classic erroneous presupposition have to
do with OS/2, trolloon?

Give that nasty tholenbot a taste of its own medicine!
 
M

Mister Scott

So, how do you all like my usenet troll bots? They were actually not
that hard to program, the basic underlying principle is a Markov chain
of configuarble response scraps that are stitched together based upon
a hierarchy of rules.

Ah. About what I figured. The tholenbot never struck me as being
particularly sophisticated. Aye, with 23rd-century technology a child
could cobble it together.
On top of that I built a string analyzer - it usually handles one
sentence at a time, but can analyze up to 30 lines of text at once
(30 is just an arbitrary #, by the way, it can easily be expanded
to more).

That'd be the threshold between "what does that have to do with OS/2"
and "what does any of that have to do with OS/2", I take it?
I am especially proud of my "nicknamesult analyzer" It uses a noise
analysis algorithm, of my own devising, on each word to determine
whether the non-bot poster is attempting a "nicknamesult" or whether
the replier is just a poor speller, technically braindead, etc.

Aye, it seems to be not too bad at recognizing "trollenbot" etc. as insults.
(For example, a "nicknamesult" for Arnold would be Assnold or some
crap).

"Arnhole" would seem to be a bit more clever. It implies, you see,
without quite stooping to explicit vulgarity.
I will be happy to sell you my botLib for $50usd.

Sell me? Up your shaft. I could write something like that in me sleep!
Open source the wee bugger and then I may be interested.
It works on usenet and all html-based forums

Aye, it's been sighted at a blog called Against Monopoly as well as
hereabouts.
includes a Bot Manager to easily permit fine-tuning of targets,
direction of trolling and personalized responses for all deployed bots
through one, while not simple, at least reasonably clear and beginner
friendly interface. Flash-based forum targeting is coming soon.

How did ye get it to recognize certain, er, pop culture references,
laddie? That's the one bit that's a wee bit sophisticated.
$2,000.00usd to remove your newsgroup from the bot's reply list.

Why, ye low-down, extortionate, bollocks-licking numpty scrote sack! I
ought ta report ya tae Scotland Yard, ye wee miserable nyaff! Now git
outta me sight, ye bum-scratching bampot, before I start makin' phone calls!

Del Murgatroid, indeed -- more like Dull Murkytroll, if ye ask me.
*shakes head*
 
A

Arved Sandstrom

What's so dubious about that statement? Looks perfectly valid to me.
In case you saw a question-mark in his last line, that was a "smaller
or equal"-sign.

The whole discussion resolves quickly, when you distinguish two
separate points:
1) availability of a language on a platform
2) The actual effort of making a particular set of code
run on a particular platform once it fulfills "1)"

Obviously, Lawrence talks about "1)", while you (Arne) seem to
have "2)" in mind.
I also (rather clearly I thought) have (2) in mind. Code portability to
me is a measure of the amount of modifications that have to be made to a
corpus of user code (application, library etc) written in language X in
order to execute it successfully on a number of different platforms. No
modifications -> completely portable code, few modifications -> highly
portable code, extensive modifications -> nearly unportable code.

In the case of the .NET CLR and the JVM and scripting language
interpreters, those _are_ the platforms. Question (1) then translates to
the availability of the platform on a given OS. But question (2) for
languages based on the CLR and JVM and scripting language interpreters
is very black and white - code portability with respect to OS A is zero
while the language platform is unavailable, and then becomes close to
100% when the language platform _is_ available.

In essence your question (1) has to do with _language_ portability.
Question (2) has to do with _code_ portability, which is what I thought
we were talking about.

C, OTOH, has been very good wrt question (1) for a long time. But it
requires varying degrees of work wrt question (2), on a _case by case_
basis, which means that

Java _code_ portability > C _code_ portability

I don't think Lawrence is consciously talking about (1), I suspect he
does not understand the distinctions here. Unless he's an infrastructure
programmer (and based on other threads I hope to God he's not) he ought
to be concerned about code portability first and foremost.

As another example, I've been writing fairly complicated C# 3.0/C# 4.0
apps on Mac OS X 10.6 (mono 2.8), Ubuntu 10.10 (mono 2.6.7) and Windows
XP (latest stuff from MS), including ASP.NET MVC stuff and doing lots of
DB access. The various apps are as close to WORA between the platforms
as one can imagine, in terms of _code_ portability. I would not expect
to be writing C code that accomplishes the same things, and be able to
plunk it into gcc or VS on all those platforms, and watch it compile and
link without any mods.

AHS
 
C

ClassCastException

But that's the point. With reifiable types, that cast would fail. The
code would never get as far as trying to add non-Strings to the list.

Reifyable types wouldn't make a compile time difference in the case of
unsafe use of the raw type. At run time, the effect would be to throw
when the code tried to add a non-String, rather than the non-String
lurking in the list like a roadside bomb and blowing up later in some
innocent traversing method's face, masking the true source of the bug.
 
J

Joshua Cranmer

What's so dubious about that statement? Looks perfectly valid to me.
In case you saw a question-mark in his last line, that was a "smaller
or equal"-sign.

The whole discussion resolves quickly, when you distinguish two
separate points:
1) availability of a language on a platform
2) The actual effort of making a particular set of code
run on a particular platform once it fulfills "1)"

Obviously, Lawrence talks about "1)", while you (Arne) seem to
have "2)" in mind.

There is also point 3) The effort of getting a binary to run on many
different platforms.

Java excels quite nicely at 3, while I'd love to see someone try to get
a C-based i386 Win16 program to run on my shiny ARM7 processor running
Linux.
 
A

Andreas Leitgeb

Arved Sandstrom said:
In the case of the .NET CLR and the JVM and scripting language
interpreters, those _are_ the platforms.

That's funny, because by that definition, Java apps (and .NET and scripts)
would be entirely *unportable* - i.e., work only on that one "platform" ;)
C, OTOH, has been very good wrt question (1) for a long time. But it
requires varying degrees of work wrt question (2), on a _case by case_
basis...

I do have the impression of a violent agreement here.
Lawrence perhaps sees the difference not all that large as many
others do, though.
I would not expect
to be writing C code that accomplishes the same things, and be able to
plunk it into gcc or VS on all those platforms, and watch it compile and
link without any mods.

Depends on what libs you build upon in C (or C++).
Those libs likely have lots of #ifdef'ery inside,
but just as likely so do the native methods in the JSL.
 
T

tholen

137> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

137> Get real. They were using COBOL on Vaxen. Half of them still
are.
137> Everybody knows this.

On what basis do you speak for "everybody", Eater?

By the way, you don't speak for me, Eater.
 
T

tholen

45> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

45> Smack that brutish Arne around a bit!

What does your directive have to do with OS/2, Svensson?

45> Give that nasty tholenbot a taste of its own medicine!

Who is "tholenbot", Svensson? There is nobody in this newsgroup
using that alias.
 
T

tholen

12> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,rec.games.roguelike.development

12> Ah. About what I figured. The tholenbot never struck me as being
12> particularly sophisticated. Aye, with 23rd-century technology a
child
12> could cobble it together.

Who is "tholenbot", Mister Scott? There is nobody in this
newsgroup using that alias.

12> That'd be the threshold between "what does that have to do with OS/
2"
12> and "what does any of that have to do with OS/2", I take it?

Your take it wrong, Mister Scott.

12> Aye, it seems to be not too bad at recognizing "trollenbot" etc.
as insults.

Who is "trollebot", Mister Scott? There is nobody in this
newsgroup using that alias.

12> "Arnhole" would seem to be a bit more clever. It implies, you
see,
12> without quite stooping to explicit vulgarity.

What does that have to do with OS/2, Mister Scott?

12> Sell me? Up your shaft. I could write something like that in me
sleep!
12> Open source the wee bugger and then I may be interested.

What does your question have to do with OS/2, Mister Scott?

12> Aye, it's been sighted at a blog called Against Monopoly as well
as
12> hereabouts.

What does that have to do with OS/2, Mister Scott?

12> How did ye get it to recognize certain, er, pop culture
references,
12> laddie? That's the one bit that's a wee bit sophisticated.

What does your question have to do with OS/2, Mister Scott?

12> Why, ye low-down, extortionate, bollocks-licking numpty scrote
sack! I
12> ought ta report ya tae Scotland Yard, ye wee miserable nyaff! Now
git
12> outta me sight, ye bum-scratching bampot, before I start makin'
phone calls!

What does that have to do with OS/2, Mister Scott?

12> Del Murgatroid, indeed -- more like Dull Murkytroll, if ye ask
me.
12> *shakes head*

What does that have to do with OS/2, Mister Scott?
 
A

Andreas Leitgeb

Peter Duniho said:
But that's the point. With reifiable types, that cast would fail.

Would it, or would it not? Who can tell?

I agree, that for certian implementations of reifyability there may not
exist an example as requested by Arne, or at least not one that I could
anticipate now without knowing the actual implementation.
 
S

Sulfide Eater

137> Newsgroups:
comp.lang.java.programmer,comp.os.os2.advocacy,comp.text.tex

137> Get real. They were using COBOL on Vaxen. Half of them still
are.
137> Everybody knows this.

On what basis do you speak for "everybody", Eater?

I am not claiming to do so, tholenoid; merely making a statement of fact
regarding a particular other fact being common knowledge, trollen.
By the way, you don't speak for me, Eater.

You don't speak at all, thalidomide, nor will you until your developer
decides to add a voice synthesis feature to your program, tholenbot.
Though I can't imagine why he would, thallium -- perhaps to turn you
loose on an unsuspecting VOIP-using populace, trillium?
 
M

Mister Scott

12> That'd be the threshold between "what does that have to do with OS/
12> 2" and "what does any of that have to do with OS/2", I take it?

Your take it wrong, Mister Scott.

Well, I'll be -- Dull Murkytroll even programmed ye to lie, tholenbot!
 
A

Andreas Leitgeb

Peter Duniho said:
I don't understand the question. By definition, a reified generic
incorporates the entire type (generic type along with type parameters)
within the type.

I admit maybe being a bit naive about this. Just like you could
probably still assign an ArrayList<String> to an Object-typed
variable, I meant, that you could also assign it to a bare List
type as being some sort of imaginary superclass/interface of the
correctly parameterized one.
See the C# generic system for an example.

Learning C# is currently not on my todo-list, and all I know
about it happens to be what I gathered here in c.l.j.p
... Being a unique type in and of
itself, it would be subject to all the same rules of casting and
assignment that every other type has in Java.

yep, had that in mind.
 
A

Arved Sandstrom

That's funny, because by that definition, Java apps (and .NET and scripts)
would be entirely *unportable* - i.e., work only on that one "platform" ;)
[ SNIP ]

In a weird kind of way that's quite true - good point. :) I guess we
could argue whether Java has either zero portability or very high
portability, depending on how you define "platform".

AHS
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,813
Messages
2,569,696
Members
45,484
Latest member
MasqueradeOfSilence

Latest Threads

Top