On Java and C++

[Bent C Dalager]

(...)

Wow, given that list I would feel more comfortable paying a monkey to
code my apps. Why pay a human just to follow the banana around when I
can get chimps to do it for less.

The day we have a programming language that is so good a monkey could
produce quality software with it is the day we have won.

Until then, we'll just have to get by with incremental steps along the
way.

Cheers
Bent D

 

[Remon van Vliet]

Java Progammer Criteria?

a) You don't have to think [...]

Okay. No thinking when programming...

b) You don't have to bother to use auto_pointer (not working with

Never having to bother... yeah.

c) You don't have to decide about programming style. Sun provided

No decisions... right.

d) You don't have to decide about naming of files and classes - they are
the same.

Once again.

e) Logical package directory structure is forced on you.

Likes being "forced." Ugh...

f) You don't have to choose between char *, string, CString ... - String

Once again.

g) you don't have to choose between long int, unsigned int, WORD, DWORD,
size_t .... - close to optimal choice if forced on you.

Ohhh, yes, how horrid to have to actually make an informed decision. I
feel for you.

h) You don't decide do you use internal or external functions

I'm starting to see a pattern.

i) You don't have to decide if you use methods or define new operators.

There IS a *clear* pattern. Quite clear.

Java choice is sometimes more verbose, but usually more clear.

Well apparently it's *not* the Java programmer who is going to be
clear, so something has to be, right? I mean s/he is too busy not
making decisions, right. I get the feeling there would be lots of
left-over rotten food and sticky keyboards that could never be decided
upon either. Hygiene would be something to consider though.

As you can guess, I can continue.
Dropping all these choices first - makes programming easier, you have
less things to bother about,

If you were never meant to be a programmer in the first place I
guess.... Hmm, VB and Java programmer are a lot alike. A river in
Egypt, baby, a river in Egypt....

Wow, given that list I would feel more comfortable paying a monkey to
code my apps. Why pay a human just to follow the banana around when I
can get chimps to do it for less.

"Some drink at the fountain of knowledge... others just gargle."

It's not that i dont appreciate sarcasm, selective copy'n' pasting and
painfully biased opinions. But are you
"C++-programmers-are-vastly-superior-to-you-Java-types" kinda people ever
going to come up with actual practical arguments or are we gonna stick to
the "we have [insert C++ specific feature/design patters here] so Java
sucks" kinda mentality (even though in 90% of the cases quitely ignoring
Java has features that either make said feature/pattern obsolete or have
other equally viable options). Saying just because we dont have to think
about/manually do memory managment (which by itself isnt completely true,
but that aside) Java programmers are somehow less capable is painfully
naive. If you're argueing Java programmers dont have to think about certain
things that the average C++ programmer has to think about then i completely
agree, it's called progress.

 

[Remon van Vliet]

Roedy Green skrev:


This is not quite true. Take old fashioned Pascal as an example. Pascal
has all the adressing modes of C++. Algol has (had) more.

Java has two adressing modes - one for the ints and one for the
objects. And this approach is simple but with drawbacks.

His point was that having more than one addressing mode (from a conceptual
point of view) is not necessary. And if with ints you mean primary types
then yes. It's often argued that types not descending from Object shouldnt
even exist in Java and it's a pretty valid argument. Also the odd mix
implemented for arrays is dodgy design at best.All of the above was meanly
done for performance reasons (and possibly to make code slightly less
verbose?). If there's ever going to be a language based on Java that's
surely the first thing to go in my opinion.

 

[Alex Buell]

I was suprised to see on a VxWorks course that none
programmed in C++.

That's because C is better for this sort of work. How else will you
manage to shoe-horn zillions of features into an embedded device with
only 2MB of flash ROM and 16MB of memory?

 

[Ian Collins]

I was suprised to see on a VxWorks course that none
programmed in C++.

The last major VxWorks project I worked on was C++....

 

[werasm]

That's because C is better for this sort of work. How else will you
manage to shoe-horn zillions of features into an embedded device with
only 2MB of flash ROM and 16MB of memory?

Oh you can - see "Inside the C++ object model" by Lipman. However,
you've enforced my point - the compatibility (with C) is necessary. I
must mention that the course was back in 2000. I have programmed in C++
since for the VxW OS .

W

 

[werasm]

That's because C is better for this sort of work. How else will you
manage to shoe-horn zillions of features into an embedded device with
only 2MB of flash ROM and 16MB of memory?

BTW, most of our hard to find bugs were due to C. sprintf and
strcpy/strncpy and arrays being the culprits. The other irony is that
people programming in C usually have some convoluted form of OO of
their own that is less efficient that what is generated by your C++
compiler. Often they use virtual dispatching mechanisms etc. with
elaborate fpointer matrices etc. I've been lucky enough to maintain
large C projects (iRmx). No thank you - absolute chaos!

W

 

[werasm]

werasm wrote:

Other JVM implementations are written in other languages. Perhaps the most
interesting technically (at several levels) is the IBM Jikes Research JVM which
is written entirely in Java except for a little assembler to allow it to
bootstrap itself.

The platform library is another matter, of course.

Thanks for that. Interesting. Of course, a C++ compiler can also be
implemented in C. I still maintain (from experience) that most of our
problems relate to the C part of C++. I also maintain that the C part
is necessary as many API's still rely heavily on them. Also, many
current C++ libraries rely heavily on those API's.

Regards,

Werner

 

[Chris Uppal]

Oliver Wong wrote:

[me:]

No. I retested just now (quit firefox, went into task manager to make sure
no hidden firefox.exe process was running), and got a similar result
(between 2 and 3 seconds). I do have Eclipse running in the background,
but as I mentioned earlier, I doubt Firefox is sharing the JVM with
Eclipse.

Hmm, interesting.

I imagine that having Eclipse open will have some effect, because the JVM DLL
is already paged-in, and (as I understand it) the data used by the new "class
data sharing" will also have been paged-in.

If you are interested enough to check what happens if you close Eclipse, you
should do something big (start Acrobat or MS Office ;-) to encourage Windows to
flush the cached DLL and CDS data out before trying the applet again.

-- chris

 

[Chris Uppal]

Swing certainly has native portions to interface with the native GUI,
as will generally any library that needs to access some native
third-party library (I/O, thread handling, etc.).

The native stuff which implements the lowest layer of AWT is probably the
single biggest chunk of native code in the library[*]. Principally because
mapping
between the AWT/Swing worldview, and that of (say) Windows, is pretty
complicated. (I have no idea why more of that complicated task isn't done in
Java -- maybe it's just historical, or maybe it's that not /all/ of it can be
done in Java so they felt it was better to keep all the mess in one place.)

I seem to recall that a while back, some maths functions were moved
from native code to Java code, resulting in a speedup of the maths
operations involved. Can't remember any details though.

I think that was the BigInteger/BigDecimal stuff.

-- chris

[*] and probably the buggiest part of the entire library too -- just to stay
on-topic for this thread ;-)

 

[Alex Buell]

Oh you can - see "Inside the C++ object model" by Lipman. However,
you've enforced my point - the compatibility (with C) is necessary. I
must mention that the course was back in 2000. I have programmed in C+
+ since for the VxW OS .

You're probably right. Yesterday, in a fit of utter boredom (I'm
currently unemployed but keeping my skills in use by writing
applications in C++), I used GNU C++ to write a text-based battleship
game. I found it a lot easier to develop.

 

[Remon van Vliet]

Roedy Green skrev:

Have you read the book? Were in there on BIX when Stroustrup dropped
by for a month or two?

I have read the book and numerous articles from Bjarne describing the
evolution of C++.

Stroustrup wrote a book about his trials designing C++ called the
Design and Evolution of C++ with a sprouting oak tree on the cover. He
was heavily constrained by his committee of C users who insisted on
strict upward compatibility. The language was designed and implemented
a bit at a time. He was never permitted to have a reintegration/tidy
up phase.

So tell me - where was that committee insisting on strict backward
compatibility?
What was those trials Bjarne faced?
What tidy up phase was he forbidden to have?

I felt much better about C++ knowing at Stroustrup was on my side in
wanting a cleaner language. It was just he was not forceful enough to
persuade his committee of bosses focused on the current job (which was
not designing a new language) of the need.

When did Bjarne try to persuade his "committee of bosses" to let him
write a cleaner language?
If anyone would care to spend just a few minutes at his website, they
would find your description at best grossly misleading. As I said
before, I see it as a bloody lie.

Just a few quotes from Stroustrups homepage:
(Would he rather have created something like Java?)
No. Java isn't even close. If people insist on comparing C++ and Java -
as they seem to do - I suggest they read The Design and Evolution of
C++ (D&E) to see why C++ is the way it is, and consider both languages
in the light of the design criteria I set for C++. Those criteria will
obviously differ from the criteria of Sun's Java team. [...]Much of the
relative simplicity of Java is - like for most new languages - partly
an illusion and partly a function of its incompleteness.

(About comparing C++ to other languages)
[...]That said, I consider C++ the best choice in programming language
for a wide variety of people and applications.

(Are there features Stroustrup would like to remove from C++?)
Not really. People who ask this kind of question usually think of one
of the major features such as multiple inheritance, exceptions,
templates, or run-time type identification. C++ would be incomplete
without those. I have reviewed their design over the years, and
together with the standards committee I have improved some of their
details, but none could be removed without doing damage.

/Peter
Interesting read, but in fairness that's like asking James Gosling what he
thinks about Java vs. C++ (you'd get an equally biased opinion). Nobody's
refuting C++ is better for some things and has features that are superior to
the way Java deals with the same problem. It's just that it can be turned
around on other language features and be just as valid.

What bothered me is the apparent superiority complex of some C++ fanatics
involved in this thread as well as having most replies focused on
undermining the opinion of someone rather than come up with technical
arguments for either case. Any notion that the ability of a developer is
directly related to the complexity of the language they're familiar with is
a bit naive in my opinion. C++ definately is more complex, definately
requires more knowledge to produce results the same results and definately
gives you more control. The point of discussion is whether or not those
points are advantages or disadvantages (or just features that thrive in
certain situations/applications, and are completely in the way in others).

Oh and by the way, i forgot exactly who did so, but somehow deriving the
quality of the average Java programmer by the quality of the questions asked
in a newsgroup is retarded. A larger part of the people that get into
software development nowadays will go for Java (or any other "new" language
like C#) rather than C++, so it's pretty reasonably to assume more "noob
questions" end up on Java and C# forums compared to the C++ one. An actually
interesting statistic would be to see how many people moved from C++ to Java
and vice versa. That would average out any language fanatics either way. And
whether or not said beginners made a good language choice will probably
always be a point of hot debate, but i suppose they have the employment
market in their favour.

 

[Remon van Vliet]

I myself, and probably many people out here use C++ only because they
naturally come to C++ from C.
In my opinion, C was very good language for his time. It was not safe, but
it was very clear. You always knew exactly what is going on.
C++, on the other side, is current, very bad overcomplicated language. I
myself use it only because it easily allows me to use only small subset of
it's features and still use Microsoft MFC relatively efficiently. I am
sure this ability to use small subset of C++ (which programmer is familiar
with) is what allows C++ to still be generally popular language now.
If you will strongly insist on using only new, 'SAFE' C++ features there
will be no reason at all to use C++, it will quickly become small niche
language to addicted.

Finally...well said.

 

[Remon van Vliet]

Bent C Dalager skrev:

This is also the case with Java. Even the Java compiler is implemented
in Java.

[snip]
So e.g. Swing, JDBC and Vector are all implemented in Java? Without a
single JNI-call in the code? It seems my knowledge of Java needs an
update.

Swing is (99.9%?) pure Java, but it's built on top of AWT which is mapped to
native OS widgets (and thus a bit of a design flaw in my opinion). Actually
Swing was introduced largely to remove inconsistencies of the GUI on
different OS as well as get rid of the (particularly buggy) AWT components.
JDBC just provides an interface. Most JDBC implementations indeed use JNI
interfaces. Vector is obviously completely Java, i suggest you actually look
into Java before commenting here. The general way of things in Java is that
if it *can* be done within Java, it *will* be done within Java. Some things
cant be done in Java and thus require JNI or whatever, and i'll be the first
to agree that that's a weakness, but that's the price you pay for having
other things. Whether or not you're willing to pay that price depends on
personal preferences but even more on what you're actually trying to do.

And that's exactly the point many people i'm trying to make. In the case of
JDBC for example, Java defines an interface for certain functionality. The
fact that the implementation of such an interface involves native code is
not actually that relevant, apart from the fact that you know the people
most capable of implementing it are the ones that generally do it (in other
words, the Oracle JDBC drivers are implemented exclusively by Oracle
engineers etc.). That isnt to say there arent any design flaws in Java
and/or it's APIs, but the general concept i quite agree with. It provides a
huge number of standards (or at least standard ways to do things). Sometimes
those restrictions will be in the way, in which case C++ is a very capable
alternative, but in most other cases it reduces time-to-market, is built on
proven technology (rather than reinvent the wheel), and dare i say it, less
capable Java developers can still produce commercially viable products
because some worries are removed (ofcourse this is more a business
consideration rather than an actual strength of the language, but worth
mentioning nonetheless).

 

[Phlip]

Hmmm, that's Win32 for you. A good c++ implementation would hide that
as far as possible - but you know that! Yes, it compiles with a c++
compiler - so does assembler. Obviously non-standard.

Are we discussing the same sample code? Its leaks and overflow risks all
come from its use of Standard C. (Arrays, if statements, etc.)

 

[werasm]

Are we discussing the same sample code? Its leaks and overflow risks all
come from its use of Standard C. (Arrays, if statements, etc.)

Yes, we are. Typical Win32 style programming. Yes, using standard C.
This kind of code is usually tucked far away, behind a clean inteface
and tested well. The LPWSTR or whatever they may call it, needn't be
used std::wstring would do the job. BTW, how are the ifs exploitable?
The file IO could be scope guarded by either using ofstream, or
wrapping the API call.

Things could have looked like this or similar:

bool CreateURLShortcut(const std::wstring& url, const std::wstring&
shortcutFile)
{
using namespace std;
wofstream of( shortcutFile, ios:ut | ios::trunc );
if( of )
{
return ( of << url );
}
return false;
}
I suppose this body would work too, but little terse for my liking:
....
{
using namespace std;
wofstream of( shortcutFile, ios:ut | ios::trunc );
return (of << url);
}

Please comment on exploitability, as that is not my strength.

 

[Phlip]

Yes, we are. Typical Win32 style programming. Yes, using standard C.
This kind of code is usually tucked far away, behind a clean inteface
and tested well. The LPWSTR or whatever they may call it, needn't be
used std::wstring would do the job. BTW, how are the ifs exploitable?
The file IO could be scope guarded by either using ofstream, or
wrapping the API call.

The ifs are fragile because the file IO could be scope-guarded.

(I don't know if handle exhaustion is exploitable, but it's still icky!!)

Things could have looked like this or similar:

Thanks! I put them both on that web page, as a rejoinder. But I would have
passed the strings by copy. I have heard that some std::basic_string
implementations don't copy-on-write, but I don't care.

Premature optimization is no excuse for fragility!

Please comment on exploitability, as that is not my strength.

And that's the point: Lean C++ code is trivially bulletproof, and trivially
reviewable. Lean C code is trivially exploitable!

 

[Noah Roberts]

Thanks! I put them both on that web page, as a rejoinder. But I would have
passed the strings by copy. I have heard that some std::basic_string
implementations don't copy-on-write, but I don't care.

Then your programs can very well be incredibly slow compared to what
they would be.

Premature optimization is no excuse for fragility!

There's no excuse for premature pessimization either. It is quite
clear that passing around a string by value will cause major slow downs
in code if those strings are not ref counted and copy on write. One of
the most common implementations of the std library use such a string.
Passing in objects as const & is one simple step to remove a common
performance problem.

 

[Noah Roberts]

Excuse me. I meant separate references and pointers with so close
functions. Java has references, but they have also some features of C++
pointers like they can be null.

C++ pointers and references have completely different purposes. The
fact that Java lacks pointers is just another can't.

I can't say Java's, "everything is a reference except when it is not,"
is a move up from having explicit value, reference, and pointer
semantics that operate in a uniform manner.

 

[Phlip]

There's no excuse for premature pessimization either.

If you discover you must optimize, you can convert from foo(string bar) to
foo(string const & bar) in only one logical place; typically 2 physical
places. The change won't cause force other designs to change.

When you have a design decision that's harder to reverse, _then_ you fret
about its performance as you commit it.

(My current boss, though otherwise good at coding, refuses to allow us to
rely on the return value optimization, so maybe I take it out on this
newsgroup