On Java and C++

[Roedy Green]

"Will come to"? I'd say it more like this: We have been regretting type
erasure in generics for the last year and a half.

You and I have certainly, and a number of others. By "we" I mean the
entire Java community including Sun an the inventors of generics.

 

[v4vijayakumar]

if you need power and performance from a language then you can expect
it to be simpler.

java scores in free and special purpose libraries.

 

[v4vijayakumar]

if you need power and performance from a language then you can expect
it to be simpler.

java scores in free and special purpose libraries.

 

[Tony Morris]

Language design is complicated, with lots of tradeoffs. I don't know any

language that doesn't contain at least one stupid feature its designer
should have known better about.

I know a couple.
Granted, these people had very clear objectives the day they set out to
write their language, and every choice can be traced back to those
objectives. However, Java and C++ have nothing at all to do with programming
language theory. It's strange what the critical mass prefer, even if it
violates their interest (but appears not to). I suspect some sociology can
explan that a bit better than I can with thought experiments.

 

[peter koch]

Roedy Green wrote:
[snip]

For C++ I think I would nail down the names and sizes in bits of each
primitive the way Java does.

Why? If a CPU does not have a 32-bit integer or an 8-bit char or a IEEE
floating point you could then not write C++ programs on it. That seems
a severe restriction to me.
If you want to restrict yourself to "fixed-bit" ints, you simply need
to include a small include file (standard in C - if not available with
your compiler you can create one in no time).

I would see what could be done to reduce
the number of addressing modes and operators.

It's time to come out of the bush. What adressing mode is not needed?
Anyone with a reasonable knowledge of C++ knows theyre all necesarry.

I would either define
some additional operators to use in overloading or allow users to
specify the new operators so that you don't have ambiguity. C++
reuses the same operators for unrelated functions. I have always found
reusing the shift operator for I/O offensive.

I agree that it is unfortunate that you use the same operator here. But
remember: in C++ >> and << are stream, not shift operators.

/Peter

 

[al pacino]

hi ltp,
heard of STL, tempelates (...generic programming)?
and dont you think for once writing your own code for the sake of
practising at least,
improve your programming skills and what better tool to do that than
using c++.

for your vouching for java the same things can be said about python et
al.
and for the gui thing these folks seem to like making the front end
than
writing the actual code!(actually its flaw in them ,not in java ,

 

[=?ISO-8859-15?Q?Martin_Vejn=E1r?=]

// Java

void func()
{
ClassWithPossibleResource cwpr = new ClassWithPossibleResource();

try
{
doSomethingWith(cwpr);
}
finally
{
cwpr.dispose();
}
}

Could you please give me equivalent Java code for this...

// C++
func()
{
class_with_possible_ressource cwpr, cwpr2;
dosomethingwith(cwpr, cwpr2);
}

....and for this?

// C++
func()
{
class_with_possible_ressource cwprs[1000];
dosomethingwith(cwprs);
}

 

[peter koch]

I am sure there are many application for which that is true, e.g.
device drivers, JVMs, Microsoft utilities, matrix math packages.

Also lots and lots of applications.

However, I know C++ is not the best choice for many others. I know
from first hand, rather than second hand experience. For a start,
there is not even such an animal as a C++ Applet. There is nothing
comparable to rich set of GUARANTEED PRESENT class libraries. C++ is
hopeless at platform-independent code.

I do agree that Java probably should be used for client side web-based
programming.
That said there is ATL which COM which is used extensively in those
area - resulting in platform dependent code, of course.

/Peter

 

[Bent C Dalager]

I know all about that. Point is that it was asserted that C++ is not
as good as Java because Java binary code will run on some processors
but C++ source code won't.

That is an assertion that may exist inside your head, but you will not
actually find it in this thread.

Cheers
Bent D

 

[Roedy Green]

Why? If a CPU does not have a 32-bit integer or an 8-bit char or a IEEE
floating point you could then not write C++ programs on it. That seems
a severe restriction to me.

the two are not mutually exclusive.



You could do it by saying for example that int32 is a built-in type
and must have precisely 32 bits. That does not stop you from having
some other type

 

[Roedy Green]

It's time to come out of the bush. What adressing mode is not needed?
Anyone with a reasonable knowledge of C++ knows theyre all necesarry

C++ has more addressing modes than other languages except for
assemblers. So obviously they are not "necessary" in some absolute
sense. They are only necessary in the legacy sense. Java has only one
addressing operator.

 

[Roedy Green]

improve your programming skills and what better tool to do that than
using c++.

You might find the work of W. Edwards Deming interesting. He was the
man who taught the art of quality control to the Japanese.

He argues there is no point in exhorting people to be better. You
have to change the environment so they naturally and without
additional effort produce better results.

C++ allows well made programs but does little to insist on or even
encourage them. The beautiful quality remains a theoretical goal
rarely achieved. It is a bit like an impressive high wire act.

You can see the effect. If you look over C++ code you will see a huge
range of quality. If you look at Java code it is much more uniform.
The artisan in you yearns for the sporadic brilliance, but the manager
prefers the uniformity.

As a programmer you see the effect. In Java, a higher percentage of
trouble is caught at compile time. Once you have the compiler happy,
usually the code works. Because of the null pointer checks, enforced
initialisation and subscript checks, if a program works at all there
is a higher probability it is working correctly than the equivalent
C++ program. That means a poor programmer who writes buggy code has a
bigger safety net with Java to watch over him to catch these errors.

 

[Oliver Wong]

I don't see how your assertion applies to my quoted statement above.
If you want to be understood I suggest you make your point more
clearly.

I think Roedy is saying that when you work in a team, there are certain
things you can't do (e.g. ignore the conventions of the team). Java helps
you not do those things (by establishing a convention, as opposed to having
each team coming up with their own, so you have to relearn conventions when
switching teams). Or something along those lines.

I also don't see how my quoted statement above would lead one to
believe I have never worked in a team...but whatever. It is clear you
don't have any good, and valid, arguments for you assertion that Java
is better than C++. This is frankly not surprising to me as such
assertions are always riddled with illogic and falacy.

I don't think Roedy asserted that "Java is better than C++". See
http://en.wikipedia.org/wiki/Psychological_projection

- Oliver

 

[Oliver Wong]

I'm still looking for the can. You listed all the thing Java *can't*
do but haven't come with anything it can. I don't see much advantage
in *can't*.

That you can't shoot yourself in the foot (or at least not as easily as
in some other languages) seems like a big advantage to me.

- Oliver

 

[Noah Roberts]

See
http://en.wikipedia.org/wiki/Psychological_projection

Ahhh yes, the last ditch attack from the weak. I grant you that it
appears to be a big gun as there is no way to argue against it...any
such attempt is of course also projecting. But only the unintelligent
cannot see it for what it is; I'll count you among them.

 

[Noah Roberts]

However, I know C++ is not the best choice for many others. I know
from first hand, rather than second hand experience. For a start,
there is not even such an animal as a C++ Applet.

Holy crap, you people actually comming up with a can??!! Almost
anyway...I'll count it.

Took you long enough...damn!!!

There is nothing
comparable to rich set of GUARANTEED PRESENT class libraries.

Of course there is something comparable. The whole second half of the
C++ standard specifies the GUARANTEED PRESENT class (and other object
type) libraries.

C++ is
hopeless at platform-independent code.

Not even remotely true.

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, peter koch
<[email protected]>
wrote

The Ghost In The Machine skrev:

[snip]

"finally" is to RAII as manual transmission is to
automatic, from the looks of things.

Not at all. RAII is to finally what a printing machine is to a pen.
RAII simplifies a nontrivial and tedious task. Or do you always check
for your objects being of the IDisposable type before deciding if you
can leave their destruction to the garbage collector or if you will
have to destroy them manually?
If not - how will your program cope with classes that change?
Also - how do you write generic code if you do not know if you will
have to destroy your objects - except than by using run-time
information?

How indeed? The best Java can do in that department is
a dispose() method (Swing) -- and that's not supported
in the language, unlike C++'s virtual destructor. finalize()
is overridable but it's never clear exactly when that will
be called.

[.sigsnip]

 

[Noah Roberts]

I would think anyone who had ever worked on a team was familiar with
the ego battles that go on especially over how code should be
formatted. You would have seen the necessity of deciding on project
coding conventions to keep people from each others' throats.

You made several comments of form "conventions are like a
straightjacket", which indicated you had never experienced a situation
where you needed them or where pre-existing conventions eased the
tensions.

You appeared to believe they had no value at all.

You also sounded independent and argumentative, not the type of person
who can stand working in a corporate team environment for very long.
You have to bite your tongue till it bleeds.

This entire avenue of argument is not only riddled with ego and
argumentative remarks but it is also entirely beside the point even if
true.

 

[Chris Smith]

Could you please give me equivalent Java code for this...

// C++
func()
{
class_with_possible_ressource cwpr, cwpr2;
dosomethingwith(cwpr, cwpr2);
}

...and for this?

// C++
func()
{
class_with_possible_ressource cwprs[1000];
dosomethingwith(cwprs);
}

No. I think you already know the answer. The latter would generally
be done by modifying the structure a bit. If there's really a need to
hold all those resources open at the same time, then some kind of
aggregate class could be written whose close method attempts to close
all of the resources in a collection.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Mishagam]

Yes, large standard library helps. However Perl, Python, C# have
something close.
I would give additional benefits (for me).
a) You don't have to think should you include fields of have variables
as objects or references or pointers. It is decided for you usually
close to optimal way (closest to references).
b) You don't have to bother to use auto_pointer (not working with
collections) or new delete or automatic destructor. It is decided for
you to use something like auto_ptr but much better.
c) You don't have to decide about programming style. Sun provided
standard Java style.
d) You don't have to decide about naming of files and classes - they are
the same.
e) Logical package directory structure is forced on you.
f) You don't have to choose between char *, string, CString ... - String
is better (or same) than either of them and it is only choice.
g) you don't have to choose between long int, unsigned int, WORD, DWORD,
size_t .... - close to optimal choice if forced on you.
h) You don't decide do you use internal or external functions
definitions, or do you use macro. - close to optimal choice if only one
possible.
i) You don't have to decide if you use methods or define new operators.
Java choice is sometimes more verbose, but usually more clear.
...
As you can guess, I can continue.
Dropping all these choices first - makes programming easier, you have
less things to bother about, second - makes language smaller and more
easy to understand. Of course such approach could lead to very bad
language - but Java luckily has good design. And I thing C++ standard
committee just made bad design - introducing complexities which doesn't
add enough benefits to justify them.

And of course one of main items:
j: In Java you generally don't have to think how to report error - you
throw Exception. In C++ you have different conventions for different
systems changing over time. Some programs return NULL or 0 or -1 or
SIGNALS ..., Microsoft COM programs returned HRESULT, lately C++ started
using exceptions, but I am sure it is still only one of choices. I don't
know, but doubt that C++ exceptions are as convenient as in Java. Of
course this result of Java being designed later when exceptions already
were well known .