On Java and C++

[Andrew McDonagh]

It's not of being smarter or not....

I am both a C/C++ and JAVA coder :

There is NO C/C++ language.

There is the C Language and the C++ language. There are compilers that
will compile source files from both languages - but there is no C/C++
language.

c is flexible :
this is both a merit and demerit (depending on programmers
capabilities)

Java takes care of this for both lame and stunt performers...

Its simple for those who want to go that way
but for big guys JAVA has much more......

You should not forget that JAVA was the Impetus behind internet ,
this language should be given respect

what are you talking about?

 

[Walter Bright]

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.

This is insightful, and in my experience, correct. C++ has a problem in
that the 'right' way to do things is significantly more work than the
'wrong' way. For example, instead of:

int a[3];

I am supposed to write:

#include <vector>

vector<int> a(10);

If one expects people in general to write better programs, the
programming language should be designed so that the straightforward,
simpler expression is the right one. Doing the wrong thing should
require more work.

This principle is evident in things like power tools and aircraft
design. In the former, you've got to do extra work to remove things like
guards and safety interlocks. In aircraft design, one of the terrible
no-no's is for a mechanic hook up the flight controls backwards. So the
designers go to great lengths to make it very hard for the mechanic to
do so, hopefully hard enough so that at some point the mechanic realizes
he must be doing something wrong. If it's easy to install the flight
controls backwards, sooner or later it will be, with deadly consequences.


-Walter Bright
www.digitalmars.com C, C++, D programming language compilers

 

[Oliver Wong]

If one expects people in general to write better programs, the programming
language should be designed so that the straightforward, simpler
expression is the right one. Doing the wrong thing should require more
work.

This principle is evident in things like power tools and aircraft design.
In the former, you've got to do extra work to remove things like guards
and safety interlocks. In aircraft design, one of the terrible no-no's is
for a mechanic hook up the flight controls backwards. So the designers go
to great lengths to make it very hard for the mechanic to do so, hopefully
hard enough so that at some point the mechanic realizes he must be doing
something wrong.

I go through this experience all the time, e.g. when trying to assemble
furniture. It's incredibly difficult (e.g. the male connector will not fit
into the female connector, even if I try slam my entire body mass,
accelerated by gravity, to force them together), so I wonder if I'm doing
something wrong, but I'm staring at the assembly diagram (all pictures, no
words, supposedly in the interest of i18n), and I can't find any other
reasonable interpretation of the instructions than the one I was following
thus far.

I eventually end up with a working piece of furniture (e.g. if it's a
chair, then yes, you can sit on it; a table, yes, you can place items on
it), but inevitably, there are spare parts, and the box that the furniture
came in is just plain indescript brown cardboard, with no "real life"
picture to compare against to see if I got it right.

- Oliver

 

[Oliver Wong]

There is NO C/C++ language.

There is the C Language and the C++ language. There are compilers that
will compile source files from both languages - but there is no C/C++
language.

Perhaps "C/C++" is C++ "spoken" with a C "accent".

- Oliver

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, Andrew McDonagh
<[email protected]>
wrote

There is NO C/C++ language.

There is the C Language and the C++ language. There are compilers that
will compile source files from both languages - but there is no C/C++
language.

No, but C++ will accept most of Ansi C, and gcc compiles both,
as well as Objective-C.

what are you talking about?

Indeed; I'm not sure C was all that extant when the
Internet was first formulated in the late 1960's, though
it wasn't long after -- never mind C++, Java, and C#.

Of course Java goes well with the Internet, and is
probably responsible for a goodly chunk of modern server
implementation code and the occasional applet. However,
Mosaic and NCSA came first, and FTP, telnet, and rsh
before them.

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, Walter Bright
<[email protected]>
wrote

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.

This is insightful, and in my experience, correct. C++ has a problem in
that the 'right' way to do things is significantly more work than the
'wrong' way. For example, instead of:

int a[3];

I am supposed to write:

#include <vector>

vector<int> a(10);

I'm not entirely sure of this. Ideally, of course, int
a[3]; would allow for constructs such as Java's .length,
although a workaround might be to use

#define Nsize(a) ( sizeof(a)/sizeof(*(a)) )

or some such. But it's a bit of an ugly mess, and party
because of C's "attitude of convenience" regarding arrays
and pointers.

In short, int *b = a; is a perfectly legal assignment in C,
and it's far from clear that it should be, but presumably
nobody wanted to write int * b = &a[0] instead way back
when, or incur extra overhead in passing the length around.

(For its part Java doesn't even have this issue, since it
has neither of C's unary '*' (pointer dereference) nor '&'
(address of) operators.)

In the case of int a[3]; the array size is quite fixed,
unlike the vector, which is variably sized but potentially
incurs an extra page fault thereby. (There might be a way
around that using an allocator but I'd have to look.)

Java has a vaguely similar problem, and in fact a vaguely
similar syntax:

import java.util.Vector;

Vector<Integer> a = new Vector<Integer>();

as of Java 5, anyway.

If one expects people in general to write better programs, the
programming language should be designed so that the straightforward,
simpler expression is the right one. Doing the wrong thing should
require more work.

If one can achieve consensus on the term "wrong" in this context.
Both constructs have issues; the int a[3]; allows for fast access but
nonextensibility; vector<int> a; has slightly slower access but
can dynamically extend the array as necessary (however, be careful
of constructs such as &a[4] in the latter case; the rug might
very well vanish from under you!).

This principle is evident in things like power tools and aircraft
design. In the former, you've got to do extra work to remove things like
guards and safety interlocks. In aircraft design, one of the terrible
no-no's is for a mechanic hook up the flight controls backwards. So the
designers go to great lengths to make it very hard for the mechanic to
do so, hopefully hard enough so that at some point the mechanic realizes
he must be doing something wrong. If it's easy to install the flight
controls backwards, sooner or later it will be, with deadly consequences.

Murphy was an optimist.

 

[Andrew McDonagh]

In comp.lang.java.advocacy, Andrew McDonagh
<[email protected]>
wrote


No, but C++ will accept most of Ansi C, and gcc compiles both,
as well as Objective-C.

Yes I said this about the compilers....

 

[werasm]

Ruby:

- No comment. Do agree on the syntax point from the little I've worked
with it.

Java:

- No comment. One positive aspect is their uniformity (one lib).
Negative aspect is that sometimes one needs bare-bones. They've also
dropped some good features in C++ (No comment on D just yet).

C++ (deep breath):
- where in memory do you want to
accidentally jump today?

- This is not so much of a problem anymore. Actually, it's not a
problem at all. Using vectors instead of arrays. Using combo of shared
and weak pointers. Wrapping strings or using std::string. We have large
c++ apps running like a clock.

- the only smart pointer that could pass
the 97 committee was one so primitive
and broken that its copy constructor
changes the copied-from object!

Yes, a very, very handy feature. Especially for passing buffers from
lower layers to application layers. Passing data from one thread to
another etc. Certainly used often by me. But hey, long since 97, aint
it.

- mutable; because constancy is enforced
at compile time, not runtime, yet it
_could_ exploit hardware support

Because logic and physical constness is 2 different things.

- strings, strings, and more strings. The
ISO Standard string came so late in the
language's history that every serious
library has its own (multiple) string
classes

Agreed. How about writing your own :->. You can!

- what the >F---< does imbue() do???

- void main is neither illegal nor legal!
Some, but not all, compiler-specific
extensions use a __ prefix

Hmmm, I think most of them are working towards confomance.

- of course RAII can be better than
redundant finally blocks. But _all_
these systems are cheap imitations
of the Execute Around Pattern, which
requires block closures, so objects
can clean themselves up, exception-
safely, deterministically, and
_without_ elaborate destructors

I wonder which came first.

- the majority of the glitches and
common bugs when implementing code
in C++ happen because it's designed
to be efficiently compiled by a
simple compiler. A reinvented language
could make better use of modern
compiler technology

Yes, your humbleness ...

- teachers, bosses, and colleagues make
us use the language because it's
popular, even for inappropriate
situations. This newsgroup gets
a dozen questions per month asking
how to do something that a scripting
language can do

Often trivial examples are used to solve more complex problems. Given
the trivial example, readers don't need to focus on the unnecessary.
Obviously they (the trivial examples) can be performed using scripts
too, but they fit into a bigger picture/application, therefore your
point is?

- you can do an "Applet" in C++ trivially,
using ActiveX. And because C++ has no
security model to speak of, anyone
using your applet exposes their browser
to gawd-knows-what-else is out there...

No comment, mainly because I don't write applets.

- how many here have _ever_ written a
program with _absolutely_ no undefined
behavior? How many _know_ they did??

Yes, you have a point. Many libraries do exists that has been ported to
various (umpteen) platforms, though. Tested and working... Testing is
knowing. This is not only due to language imperfection, but due to
human imperfection (you could even make mistakes with perfect languages
- not meeting user requirements). The most imperfect humans of course
are those that believe they are perfect. Do you fall into that
category, your humbleness?

- when folks say C++ is portable, they
mean the _compiler_ ports easily to
other platforms. By marrying your
statements to the metal, a C++
implementation forces you to
consider _endless_ portability issues
at port time

Blah, blah...

- the exception handling model is so
complex it makes me wonder if Bjarne
Stroustrup actually determined how to
write exception-safe programs when
he invented the language

I can only disagree with this one. But what do you suggest? You can
only criticise if you have a better alternative (Philips language,
whoa!). Better start implementing, that others like you can start
critting.

Hah, hah, hah (Feel like I'm feeding a troll).

Werner

 

[Noah Roberts]

In comp.lang.java.advocacy, Walter Bright
<[email protected]>
wrote

On 28 Apr 2006 00:59:19 -0700, "al pacino" <[email protected]>
wrote, quoted or indirectly quoted someone who said :

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.

This is insightful, and in my experience, correct. C++ has a problem in
that the 'right' way to do things is significantly more work than the
'wrong' way. For example, instead of:

int a[3];

I am supposed to write:

#include <vector>

vector<int> a(10);

I'm not entirely sure of this. Ideally, of course, int
a[3]; would allow for constructs such as Java's .length,
although a workaround might be to use

#define Nsize(a) ( sizeof(a)/sizeof(*(a)) )

or some such. But it's a bit of an ugly mess, and party
because of C's "attitude of convenience" regarding arrays
and pointers.

You have arrays when you want and vectors when you want. A std::vector
isn't always warranted. Sure, 99% of the time that is what you want,
but not always.

In short, int *b = a; is a perfectly legal assignment in C,
and it's far from clear that it should be, but presumably
nobody wanted to write int * b = &a[0] instead way back
when, or incur extra overhead in passing the length around.

Either you are passing around a length or you are somehow finding the
end each time. Java can be no different in this area even if the
language might hide that fact from you.

If one expects people in general to write better programs, the
programming language should be designed so that the straightforward,
simpler expression is the right one. Doing the wrong thing should
require more work.

If one can achieve consensus on the term "wrong" in this context.
Both constructs have issues; the int a[3]; allows for fast access but
nonextensibility; vector<int> a; has slightly slower access but
can dynamically extend the array as necessary (however, be careful
of constructs such as &a[4] in the latter case; the rug might
very well vanish from under you!).

You've of course profiled this so lets see the result...

 

[Walter Bright]

I think the fact that nobody uses D means suggests that it has not only
one stupid feature, but a lot of stupid features.

For a stupid language nobody uses, the D programming language is doing
remarkably well, having moved up to number 19 on
http://www.tiobe.com/tpci.htm

<g>

 

[Phlip]

- This is not so much of a problem anymore. Actually, it's not a
problem at all. Using vectors instead of arrays. Using combo of shared
and weak pointers. Wrapping strings or using std::string. We have large
c++ apps running like a clock.

In general, >70% of all software features are not used as first delivered,
and malware is a crushing burden on global productivity. We have a new form
of war on our hands - a new kind of arms race.

Yet when you look at the sources of security breaches, over and over again
you find the things that sloppy C++ programmers revel in. Double deletes,
array overruns from unchecked buffers, runaway recursion, gratuitous
typecasts, etc.

http://c2.com/cgi/wiki?MicrosoftSampleCode

People are learning that technology in their lives that fails the most often
is software. And C++ is leading the charge.

 

[Oliver Wong]

For a stupid language nobody uses, the D programming language is doing
remarkably well, having moved up to number 19 on
http://www.tiobe.com/tpci.htm

(referring to http://www.tiobe.com/tiobe_index/images/tpci_trends.gif as
of May 2nd, 2006): I wonder what happened in 2004 that made Java drop
considerably, and everything else jump up a bit.

- Oliver

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, Noah Roberts
<[email protected]>
wrote

The Ghost In The Machine wrote:
[snippage]

If one can achieve consensus on the term "wrong" in this context.
Both constructs have issues; the int a[3]; allows for fast access but
nonextensibility; vector<int> a; has slightly slower access but
can dynamically extend the array as necessary (however, be careful
of constructs such as &a[4] in the latter case; the rug might
very well vanish from under you!).

You've of course profiled this so lets see the result...

I have not; the considerations are theoretical. However,
the implementation of std::vector<...>:ush_back() on my
system (gcc 3.4.5) includes a call to
_M_insert_aux(end(), __x), which among other things calls
_M_allocate(2 * size()), to allocate a bigger chunk, and
_M_deallocate() on the existing storage.

This makes constructs such as b = &a[4] dangerous if one
holds onto b for too long and also inserts additional
stuff into a. One would hope most reasonable coders wouldn't
do that, of course, but anyone who's seen Jeff Relf's code
(or a facsimile thereof) has to wonder.

It is barely possible that a very smart compiler might
have equivalent code for the sequences:

a[0] = 1;
a[n-1] = 2;

except for a single register load (in the case of std::vector<> the
field value _M_start). However, I'd have to experiment.

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, Andrew McDonagh
<[email protected]>
wrote

Yes I said this about the compilers....

Yes you did. Oops.

 

[peter koch]

Walter Bright skrev:

Roedy Green wrote: [snip]
This is insightful, and in my experience, correct. C++ has a problem in
that the 'right' way to do things is significantly more work than the
'wrong' way. For example, instead of:

int a[3];

I am supposed to write:

#include <vector>

vector<int> a(10);

If one expects people in general to write better programs, the
programming language should be designed so that the straightforward,
simpler expression is the right one. Doing the wrong thing should
require more work.

This principle is evident in things like power tools and aircraft
design. In the former, you've got to do extra work to remove things like
guards and safety interlocks. In aircraft design, one of the terrible
no-no's is for a mechanic hook up the flight controls backwards. So the
designers go to great lengths to make it very hard for the mechanic to
do so, hopefully hard enough so that at some point the mechanic realizes
he must be doing something wrong. If it's easy to install the flight
controls backwards, sooner or later it will be, with deadly consequences.

I do not disagree with you here. C++ is not the perfect language,
inheriting as we all know some of the bad stuff from C - including
arrays.
What you can do is not teach beginners about e.g. pointers, build in
arrays and stuff like that. Just as e.g. Koenig and Moe do in their
introductory text.
Your comparison with the aircraft design is also not quite fair. When
you write software, you hopefully do lots of testing and review before
slipping anything out the door - and this testing can easily be done
without any deadly consequences. In my opinion, these dangerous
facilities in C++ come in handy in some situations (e.g. when you
implement the std::vector class!) and are very easy to avoid. The first
review will easily find them.

/Peter

 

[Luc The Perverse]

(referring to http://www.tiobe.com/tiobe_index/images/tpci_trends.gif
as of May 2nd, 2006): I wonder what happened in 2004 that made Java drop
considerably, and everything else jump up a bit.

It would appear that the rise in Python users (From virtually nothing)
corresponds almost exactly with the drop in Java users. VB also rose,
which probably stole a little java use.

 

[peter koch]

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.

/Peter

 

[peter koch]

Roedy Green skrev:

come on. There are alternate notations that generate the same
assembler code. That is a legacy wart, not a feature.

Are you talking about C++ references and C++ pointers? While they might
be identical under the covers, they have widely different semantic uses
and you can't substitute one for the other.

/Peter

 

[Otis Bricker]

In comp.lang.java.advocacy, Walter Bright
<[email protected]>
wrote

Roedy Green wrote:
On 28 Apr 2006 00:59:19 -0700, "al pacino"
someone who said :

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.

This is insightful, and in my experience, correct. C++ has a
problem in that the 'right' way to do things is significantly more
work than the 'wrong' way. For example, instead of:

int a[3];

I am supposed to write:

#include <vector>

vector<int> a(10);

I'm not entirely sure of this. Ideally, of course, int
a[3]; would allow for constructs such as Java's .length,
although a workaround might be to use

#define Nsize(a) ( sizeof(a)/sizeof(*(a)) )

or some such. But it's a bit of an ugly mess, and party
because of C's "attitude of convenience" regarding arrays
and pointers.

You have arrays when you want and vectors when you want. A
std::vector isn't always warranted. Sure, 99% of the time that is
what you want, but not always.

I doubt it is 99%. Most of the time what I need is a boost::array<int,7>,

In short, int *b = a; is a perfectly legal assignment in C,
and it's far from clear that it should be, but presumably
nobody wanted to write int * b = &a[0] instead way back
when, or incur extra overhead in passing the length around.

Either you are passing around a length or you are somehow finding the
end each time. Java can be no different in this area even if the
language might hide that fact from you.

I would not say quite that. In Java, the array hold the length for you.
It is a property of the object you created. It is more like the tr1:array
than a raw(int a[3]) C array.

If one expects people in general to write better programs, the
programming language should be designed so that the
straightforward, simpler expression is the right one. Doing the
wrong thing should require more work.

If one can achieve consensus on the term "wrong" in this context.
Both constructs have issues; the int a[3]; allows for fast access but
nonextensibility; vector<int> a; has slightly slower access but
can dynamically extend the array as necessary (however, be careful
of constructs such as &a[4] in the latter case; the rug might
very well vanish from under you!).

You've of course profiled this so lets see the result...

It would vary by compiler and settings. But you are free to test this
sort of thing yourself. The main force behind the STL was Alexander
Stepanov and he has done a lot of work on testing the cost of these
Abstraction penalties.

http://www.stepanovpapers.com/

Look at the section on Source Code.

My memory is that accessing the vector via an iterator usually had no
penalty but there was some cost to using opertor[] and more for using
vector.at(). Again, this would be compiler dependent.

OB

 

[peter koch]

Roedy Green skrev:
[snip]

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

Not all processors have 32-bit integers. Also not all processors
floating point unit is IEEE compliant. There are processors out there
where the smallest addressable unit is 32-bits. They still have a
C++-compiler.

/Peter