On Java and C++
wellst...@yahoo.com
overly complex C++ appears to them. I would like to introduce an
explanation for this. Is it possible that Java programmers simply
aren't smart enough to understand C++?
This is not merely a whimsical hypothesis. Given my experience with
Java programmers --- the code they write and the conversations they
have --- Occam's Razor points to this explanation. For example,
"Oooh I'm confused about the difference between pointers, references,
and objects! How confusing!"
"Oooh operator overloading confuses me! The expression x + y is so
confusing, who knows what's happening with that? If x and y are
complex numbers, what the hell could x + y mean?"
"Oooh multiple inheritance is so confusing! Though I am both a father
and a programmer, I still find it so confusing how the same object can
be two different things! How confusing!"
"Oooh and virtual bases are so bizarre! I am a student --- myself
'the father' is the same student as myself 'the programmer' --- but
nonetheless the idea of virtual bases is absolutely confounding and
confusing to me!"
Again, Occam's Razor is a valuable tool here. In deciding among
competing hypotheses, choose the simplest one. To impartial observers
of indoctrinated Java programmers, the explanation is simple indeed.
Julián Albo
> Again, Occam's Razor is a valuable tool here. In deciding among
> competing hypotheses, choose the simplest one.
The simplest is: you are a troll.
--
Salu2
Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php
Andrew McDonagh
snipped dribble....
oh good a pissing competition!
My Ruby is better than your (Insert your fave, all time language here).
Ian Collins
drivel
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT F :.:\:\:/:/:.:
| FEED THE TROLLS | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | jgs (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==============================================================
--
Ian Collins.
Noah Roberts
Wow, posted for only 15 minutes and already 3 replies including a
"don't reply to the trolls" reply.
Nice one ;)
Monique Y. Mudama
2006-04-26, wellst...@yahoo.com penned:
> Java programmers seem to always be whining about how confusing and
> overly complex C++ appears to them.
No, they aren't.
Therefore the rest of your troll is moot.
--
monique
Help us help you:
http://www.catb.org/~esr/faqs/smart-questions.html
Dimitri Ognibene
from
how to start a flame..
chapter 1
Mishagam
person that fully understands C++ (or Common Lisp, or PL/I) should be
very clever and more clever than average (not neccessary Java) programmer.
But this doesn't help C++ to be very bad and getting steadily worse
language.
Because computer language is tool. Because people don't study language
for the sake of it, they study them to write programs. More difficult
and complex language is, more time is wasted studying it, and less
people will understand what they are actually writing when they use this
language. I bet <1% of C++ programmers fully understand C++ language. I
am sure statistics is radically different for Java - which is MUCH
simpler and more easy to understand. I myself programmed about 10 years
on C++ and 5 years on Java, so I was able to compare them.
And I am sorry for people who achieved full understanding of C++ virtual
inheritance, STL, Templates, Functors, and so on. They uselessly wasted
huge efforts.
And writing programs on complex, poorly understood language doesn't help
to write reliable and efficient programs.
In this sense C was much better language (through clever use of
preprocessor could provide ugly programs). And I understand why C is
still so popular in Linux.
Luc The Perverse
news:1146089115.0...@y43g2000cwc.googlegroups.com...
> Java programmers seem to always be whining about how confusing and
> overly complex C++ appears to them. I would like to introduce an
LOL - welcome troll!
--
LTP
:)
Gernot Frisch
> In this sense C was much better language (through clever use of
> preprocessor could provide ugly programs). And I understand why C is
> still so popular in Linux.
Now, you are begging for a fight?
al pacino
and i have seen many of my friends 'switch' over to java cos they shy
away from learning much involved language c++
and also they seem to like things like easy GUI interfacing than actual
programming (like practising data structures ..b trees et al.)
Luc The Perverse
news:1146114565....@g10g2000cwb.googlegroups.com...
Learning C++ is marginally more difficult than learning Java.
I used to be a die hard C++ advocate - but the added complexity doesn't
really add a great deal of usability; but it is great for obscuring the
meaning of the code.
Java is simpler, cleaner - but programming is programming. Java is
designed to be able to more easily make integrated GUI apps. This might,
in turn, make the code of two programmers with otherwise equal talent, one
in C++ and one in Java, differ and their end results differ. In C++ you
have to reinvent the wheel all the time. Except, it's not like you're
rediscovering, just annoyingly doing the same thing repetitively to take up
more time. In Java you implement one of the provided algorithms, and you
are good to go, with an exponentially smaller possibility that the
underlying algorithm code is in some way flawed. (With as many Java users
as are out there, a bug should pop up pretty quick.) GUIs are easier, in
general, so the java programmer can use that time to make their GUI better.
Web examples (sample code) tend to work, unlike C++ where if you download
something, there is only a miniscule chance that it will compile after 20-30
minutes of fiddling.
Blah - I'm just blabbering. My point is that coding in Java saves times,
and lessens bugs. It will make the end result better. All the bad things
I thought of Java are pretty much gone.
The reason I am replying is you just seem to have contempt. "Actual
Programming" problems will arise, they will just be less mundane.
I think you might be confusing Java with VB.
Trust me though - you can practice algorithms and data structures in Java -
I do so at least 3 times a week on topcoder.
--
LTP
:)
Mishagam
I (esthetically) liked C very much when I have first seen it, and still
think it is (and especially was (I mean in context of 70-80s when it was
created)) very good language.
However I now prefer to program on Java. I think best quality of Java is
how beautifully it removes most unnecessary choices, leaving one very
decent way to do things.
I now (esthetically) hate C++, however still program on it (using very
few 'modern' features, but using classes) sometimes.
So I stay by my opinion that C is (was) good language, and C++ is bad
language.
Gernot Frisch
> How should I respond to this? May be I am new to this newsgroup.
> I (esthetically) liked C very much when I have first seen it, and
> still think it is (and especially was (I mean in context of 70-80s
> when it was created)) very good language.
> However I now prefer to program on Java. I think best quality of
> Java is how beautifully it removes most unnecessary choices, leaving
> one very decent way to do things.
> I now (esthetically) hate C++, however still program on it (using
> very few 'modern' features, but using classes) sometimes.
> So I stay by my opinion that C is (was) good language, and C++ is
> bad language.
The so called "ugly" features is what makes C++ so powerfull. Operator
overloading is essentiall for RAD-classes. Aynway...
benben
I hate feeding trolls but it is just unfair for C++...
I learned Javascript before C++. My impression is even though C++ is
noticeably more complex, it is not more difficult to learn than Javascript.
>
> I used to be a die hard C++ advocate - but the added complexity doesn't
> really add a great deal of usability; but it is great for obscuring the
> meaning of the code.
A screw driver can help you fix your car; yet it can also do damage to
your car depending on how you use it. C++ is no different. It is just a
tool after all, and you CAN definitely obscure the code with C++. It
takes experience and skill to write good quality code in just about any
language.
The added complexity to C++ is a result of meeting the need of a wide
range of audiences. The language is like a big toolbox, and it is just
unfair to blame the toolbox for offering much more than what you need
for your task.
>
> Java is simpler, cleaner - but programming is programming. Java is
> designed to be able to more easily make integrated GUI apps. This might,
> in turn, make the code of two programmers with otherwise equal talent, one
> in C++ and one in Java, differ and their end results differ. In C++ you
> have to reinvent the wheel all the time. Except, it's not like you're
> rediscovering, just annoyingly doing the same thing repetitively to take up
> more time. In Java you implement one of the provided algorithms, and you
> are good to go, with an exponentially smaller possibility that the
> underlying algorithm code is in some way flawed. (With as many Java users
> as are out there, a bug should pop up pretty quick.) GUIs are easier, in
> general, so the java programmer can use that time to make their GUI better.
> Web examples (sample code) tend to work, unlike C++ where if you download
> something, there is only a miniscule chance that it will compile after 20-30
> minutes of fiddling.
It is again an unfair comparison. The ease building GUI apps with Java
has nothing much to do with the simplistic design of the Java language.
It is Java's "standard" class libraries that allows you to program Java
from a higher level than system calls.
You can program C++ GUI at the same level. First thing to do is to find
a library that supports you. These good libraries are unfortunately not
part of the C++ standard and it is a shame that a lot of people are
under the impression that C++ is incapable of, or poorly supports, tasks
that requires non-standard C++ libraries.
Part of Java's popularity comes from politics rather than technicality.
But I am not in the mood of discussing politics.
>
> Blah - I'm just blabbering. My point is that coding in Java saves times,
> and lessens bugs. It will make the end result better. All the bad things
> I thought of Java are pretty much gone.
Meanwhile Java is getting larger and larger.
Regards,
Ben
mishagam
> ["Followup-To:" header set to comp.lang.java.programmer.] On
> 2006-04-26, wellst...@yahoo.com penned:
> > Java programmers seem to always be whining about how confusing and
> > overly complex C++ appears to them.
>
> No, they aren't.
they have no reason to whine. It is C++ programmers who should whine
about this. But it appears now, when C++ became finally complex enough
to be unacessible to mere mortals, that C++ programmers are feeling
themself members of club open to introduced only . Now they look
somewhat like Linux hackers looking down on programmers using other,
less esotheric languages.
Mishagam
>>
>> I think best quality of
>> Java is how beautifully it removes most unnecessary choices, leaving
>> one very decent way to do things.
>> I now (esthetically) hate C++, however still program on it (using
>> very few 'modern' features, but using classes) sometimes.
>> So I stay by my opinion that C is (was) good language, and C++ is
>> bad language.
>
> The so called "ugly" features is what makes C++ so powerfull. Operator
> overloading is essentiall for RAD-classes. Aynway...
>
Does it mean that you can write program that cannot be written on Java?
or Does it mean that you can write shorter C++ program doing the same as
equivalent Java program? Then may be you should like Perl even more?
Or does it man that you can write library, such that equivalent C++
program will LOOK simpler than Java program?
Mishagam
Java program using Java library.
Mishagam
> ["Followup-To:" header set to comp.lang.java.programmer.] On
> 2006-04-26, wellst...@yahoo.com penned:
>> Java programmers seem to always be whining about how confusing and
>> overly complex C++ appears to them.
>
> No, they aren't.
Java programmers have no reason to whine because usually nobody forces
than to use C++. It is C++ programmers who could whine.
But, when C++ finally become too complex to be understood by mere
mortals, C++ programmers become feeling themselves members of club with
secrets comprehensible only to introduced. They become proud to use C++
and look down on programmers using less esoteric languages like Java.
And so they don't whine either, and C++ language quietly and slowly
moves toward oblivion ;)
chris.m...@googlemail.com
programming languages.
Why do you think that the world has more than one language? Why don't
we all use English instead of all having different languages, it would
make life so much easier. Well, in fact, it wouldn't.
In my honest opinion, once you know how to program at a decent level,
you should be able to use any language with just a small amount of
effort, if you want to master that language then fine, but be prepared
to put the work in. At the same time, the amount of programs or
applications that require a team of programmers to know every in-depth
detail of their language is slim.
C++ has advantages over Java, it also has its fair share of
disadvantages. I don't buy into the fact that Java is easier to learn.
I have been a learning C++ for about 3 years and as part of my uni
course, have now been asked to program some Java. I find Java as a
language nice to work with but have the same number of problems I would
have expected from learning a new language. Yes, its a slimmed down
version, yes it may be easier to do certain things but if we made all
programming languages insanely difficult only a small number of people
would ever get the joy the rest of us get from programming.
Just my thoughts.....
Walter Bright
> The so called "ugly" features is what makes C++ so powerfull.
I don't agree with the fatalistic idea that a feature must be ugly in
order to be powerful. The warts in C++ are not due to its power, but to
its desire to integrate new features in while retaining source
compatibility with 30 years of past decisions, good and bad.
If you're willing to give up legacy compatibility, it's possible to
design a language with similar and even greater power, but in a much
simpler and straightforward package. Such is the D programming language,
www.digitalmars.com/d/
For an example of how an "ugly" power feature like templates can be made
easier (and even more powerful), see
www.digitalmars.com/d/templates-revisited.html .
-Walter Bright
Digital Mars
Bent C Dalager
benben <benh...@yahoo.com.au> wrote:
>> Learning C++ is marginally more difficult than learning Java.
>
>I hate feeding trolls but it is just unfair for C++...
>
>I learned Javascript before C++. My impression is even though C++ is
>noticeably more complex, it is not more difficult to learn than Javascript.
That may say more about Javascript than it does about C++ though :-)
(Personally, I found ECMAScript pretty straight forward up until I
reached the chapter of the spec titled "automatic semicolon
insertion". It went downhill from there <g>)
Cheers
Bent D
--
Bent Dalager - b...@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Gernot Frisch
"Walter Bright" <wal...@digitalmars-nospamm.com> schrieb im
Newsbeitrag news:XtidnZG8I679Es3Z...@comcast.com...
OK. True, the D language has cleaned up old C inheritances C++ suffers
from. However, I doubt anyone would switch to D unless you provide a
large class library for almost everything. That's the only true
benefit of Java, the large std library.
I hope to see D grow and be _the_ (C++)++ one day, though.
Mishagam
> OK. True, the D language has cleaned up old C inheritances C++ suffers
> from. However, I doubt anyone would switch to D unless you provide a
> large class library for almost everything. That's the only true
> benefit of Java, the large std library.
>
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.
Gernot Frisch
> 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).
What about pointer to a pointer? A pointer is a pointer, a reference
is a reference, a variable is a variable. Period.
> 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.
I like new/delete. Makes me feel I'm in charge. Just my .02$
> c) You don't have to decide about programming style. Sun provided
> standard Java style.
Juck!
> d) You don't have to decide about naming of files and classes - they
> are the same.
no, they _have to be_ the same. Otherwise the compiler pukes.
> e) Logical package directory structure is forced on you.
What about freedom of choice?
> 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.
Yeah, and a lot slower in some cases. User std::string where you need
dynamic strings, use char[] where you need static strings. You don't
have to - but you _can_!
> g) you don't have to choose between long int, unsigned int, WORD,
> DWORD, size_t .... - close to optimal choice if forced on you.
Just a question of style. I use the built-in tpyes for everything.
> 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.
That's a real feature of java and D! Include files totally suck!
Internal functions are a great benefit as well. Though I'd not want to
loose the preprocessor.
> 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.
?? I don't understand that. You can't define operators in Java, can
you? Defining operators is one of the most important things for OOP
IMHO.
> And I thing C++ standard committee just made bad design -
> introducing complexities which doesn't add enough benefits to
> justify them.
Well, if you knew C++ as good as Java, you wouldn't say so I guess.
Anyway - I don't give a **** about what others use to write stuff, so
this is all just blahblah about nothing. There's no point making one
language better than the other. You will pick what suits you best or
what your boss indoctrinates on you.
REH
Luc The Perverse wrote:
> Java is simpler, cleaner - but programming is programming.
Yeah, and that's why I write real-time systems in Perl. Languages are
tools. Use the right one for the right job. No language has yet
filled the "one-size-fits-all" catagory.
REH
Remon van Vliet
bs in a single post i can take without replying...
<snip>
>> 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.
>
> I like new/delete. Makes me feel I'm in charge. Just my .02$
So, your entire reasoning behind preferring manual memory managment over
garbage collection is that "you feel in charge"? You should give assembly
language a go. Meanwhile, in the real world most recent garbage collectors
outperform manual memory managment in the vast majority of applications, and
as a bonus you get the complete lack of memory leaks and such.
>
>> c) You don't have to decide about programming style. Sun provided
>> standard Java style.
>
> Juck!
I'll grant you that it's a matter of taste, but no self respecting developer
will consider standards a bad thing. If you do, draw your conclusions.
>
>> d) You don't have to decide about naming of files and classes - they are
>> the same.
>
> no, they _have to be_ the same. Otherwise the compiler pukes.
And the ability to stick tons of classes in a single file with a non-related
name would be a good thing because....? Again, standards -> good
>
>> e) Logical package directory structure is forced on you.
>
> What about freedom of choice?
>
Can you think of a single instance where having an illogical directory
structure is preferred over a logical one?
>> 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.
>
> Yeah, and a lot slower in some cases. User std::string where you need
> dynamic strings, use char[] where you need static strings. You don't have
> to - but you _can_!
When was the last time you benchmarked Java strings vs. C++?
>
>> g) you don't have to choose between long int, unsigned int, WORD, DWORD,
>> size_t .... - close to optimal choice if forced on you.
>
> Just a question of style. I use the built-in tpyes for everything.
It's freedom that doesnt add anything but confusion and hurts readability.
>> 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.
>
> ?? I don't understand that. You can't define operators in Java, can you?
> Defining operators is one of the most important things for OOP IMHO.
He's not claiming you can, he simply says the exact same functionality can
be achieved albeit more verbose (i.e. .add rather than +). There are
certainly instances where operator overloading provides more readable code,
but at the same time it can also be the cause of rather unpredictable code.
On this point my stance is that if used with care operator overloading is a
pretty neat thing.
>
>> And I thing C++ standard committee just made bad design - introducing
>> complexities which doesn't add enough benefits to justify them.
>
> Well, if you knew C++ as good as Java, you wouldn't say so I guess.
> Anyway - I don't give a **** about what others use to write stuff, so this
> is all just blahblah about nothing. There's no point making one language
> better than the other. You will pick what suits you best or what your boss
> indoctrinates on you.
Ofcourse there's a point in making languages "better" or at least different
than others. Sometimes a language is simply outdated, sometimes it's just
not a viable option for certain applications (people generally dont write
web-based application in C++ for example, just as you wont find many
commercial games or OSs written in Java). As for bosses, people usually get
a job based on their language skills and preferences, not the other way
around.
Anyway. there's room for both, but most of your arguments in the post above
are flawed or outdated in my opinion, as i feel you're considering rather
obvious weaknesses of C++ to be benefits. And to the OP, anyone claiming C++
programmers are somehow better than Java programmers is a tool. 90% of
skills related to being a "good developer" is completely unrelated to the
language you're using.
Remon van Vliet
"Bent C Dalager" <b...@pvv.ntnu.no> wrote in message
news:e2q4qa$h60$2...@orkan.itea.ntnu.no...
> In article <4450764e$0$14494$afc3...@news.optusnet.com.au>,
> benben <benh...@yahoo.com.au> wrote:
>>> Learning C++ is marginally more difficult than learning Java.
>>
>>I hate feeding trolls but it is just unfair for C++...
>>
>>I learned Javascript before C++. My impression is even though C++ is
>>noticeably more complex, it is not more difficult to learn than
>>Javascript.
>
> That may say more about Javascript than it does about C++ though :-)
We're all aware Javascript is completely unrelated to Java right?
Remon van Vliet
"Luc The Perverse" <sll_noSpamli...@cc.usu.edu> wrote in message
news:9236i3x...@loki.cmears.id.au...
Well said. "Actual programmers" shouldnt spend a large chunk of dev time on
things like standard data structures, memory managment and well known
algorithms.
The Ghost In The Machine
<wellst...@yahoo.com>
wrote
on 26 Apr 2006 15:05:15 -0700
<1146089115.0...@y43g2000cwc.googlegroups.com>:
> Java programmers seem to always be whining about how confusing and
> aren't smart enough to understand C++?
>
> This is not merely a whimsical hypothesis. Given my experience with
> Java programmers --- the code they write and the conversations they
> have --- Occam's Razor points to this explanation. For example,
>
> "Oooh I'm confused about the difference between pointers, references,
> and objects! How confusing!"
[rest snipped]
First rule of software: know thy tools. This includes
the computer, the compiler, and the environment.
Both Java and C++ aim for a niche: the specification of
instructions to a modern computer. There are, of course,
many differences.
[1] Java hides pointers. This can be a good or a bad
thing; it's good in that Java has the option of playing
garbage collect (built in). It's a bad thing when Java
developers forget and leave an object to moulder in
a global collection map and then wonder why there's a
"memory leak".
[2] Java does not have operator overloading. C++ does.
In C++, this can be a convenience but it also can lead to
some hairy expressions.
[3] Java does not have a C preprocessor. C++ does. And
one thought operator overloading was bad. The Obfuscated
C process is testimony to some of the abuses of a useful
construct; fortunately those are for humorous purposes.
[4] C++ doesn't have packaging. Java does. While there
are some quirks in the implementation of packaging in Java,
it's a very nice way to organize one's code.
[5] Java doesn't have explicit deletes. The garbage
collection is expected to take care of things. (There are
some exceptions; a FileOutputStream for example will be
left open indefinitely, even if the reference is lost.)
There's a fair number of others but these will do for a start.
In any event, many programmers, myself included, migrated
from C++ to Java. To call us stupid invites ridicule, if
not worse.
As for operator overloading -- I'll admit, I occasionally
miss it. Matrix operations in particular would benefit
somewhat from a shortening of the notation; one could write
P = M * N instead of P = M.multiplyBy(N). But operator
overloading does complicate the language, requiring the
compiler to sort out whether an operator is overloaded or
not (and operator precedence issues). In Java it would
be especially bad as the operator may require a run-time
lookup.
If one assumes that an operator can be declared by the pseudo-code
(which looks suspiciously like C++, of course :-) )
String operator+ (String x, String y)
{
StringBuffer z = new StringBuffer();
z.append(x);
z.append(y);
return z.toString();
}
Integer operator+ (Integer x, Integer y)
{
return new Integer(x.intValue() + y.intValue());
}
and then have a code sequence
Object a;
Object b;
Object c = a + b;
what operator should be executed, and when should this be determined?
C++ doesn't have this problem, as all routines are determined at
compile time except for virtual methods.
It is possible Java could implement a C++-like solution (and complain
in the above case as I've not defined operator+(Object,Object)) but
someone will probably be unhappy with whatever solution is finally
implemented.
One can also compare Java to C#. I lack expertise in C# beyond what
I've seen in the press but know that C# has the interesting property of
converting an assignment:
a.b = c.d;
into a sequence of function calls:
a.setB(c.getD());
by a declaration within the classes somehow.
This can get arbitrarily tricky. I'm not sure if I like this property
or not. As I understand it, interactions with [] further complicate
things.
Java avoids all this; except for an issue that one can have variable
lengths in each array row in an Object[][] variable (which is easy
to resolve with some care), one can be sure that
a.b = c.d;
means
a.b = c.d;
:-)
--
#191, ewi...@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.
Ben
I've programmed both in JAVA and C++
Try writing a OS in JAVA...wait is that even possible?
or try writing web based programs in C++, get ready for a headache...
Mishagam
>> c) You don't have to decide about programming style. Sun provided
>> standard Java style.
>
> Juck!
You don't like Sun Style? I find it not worse than any other, and it has
advantage that most Java programmers use it. In C, for example, Linux
core uses one style, and Gnu uses other, incompatible style, and
Microsoft, of course, uses third.
>
>> d) You don't have to decide about naming of files and classes - they
>> are the same.
>
> no, they _have to be_ the same. Otherwise the compiler pukes.
Of course everything I wrote here (style is exception) is enforced by
compiler. That's what compiler is for.
>
>> e) Logical package directory structure is forced on you.
>
> What about freedom of choice?
My main idea in my post was that freedom of choice is often Bad. Anyway,
I don't insist on this as a law, only as my personal preference. May be
you value freedom of choice in programming more. Then C++ obviously has
advantages for 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.
>
> Yeah, and a lot slower in some cases. User std::string where you need
> dynamic strings, use char[] where you need static strings. You don't
> have to - but you _can_!
I benchmarked strings long time ago. My impression - C strings are much
faster, STL/CStrings have about the same speed (I don't remember
exactly) as Java strings. But C strings created their own (apparently
very big) category of security breaches. Bottom line - you don't lose
much, if anything, by sticking to Java strings.
>
>> g) you don't have to choose between long int, unsigned int, WORD,
>> DWORD, size_t .... - close to optimal choice if forced on you.
>
> Just a question of style. I use the built-in tpyes for everything.
And I am a little bit sick of casting size_t to int. Or remembering what
to use: long long or _int64.
>
> Well, if you knew C++ as good as Java, you wouldn't say so I guess.
>
I suspect it is not my fault that I better know Java than C++. I spend
10 years programming mostly on C++ and only 5 years mostly on Java. It
is just more easy to learn Java.
Phlip
--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!
REH
I don't know if you are agreeing with me or just misunderstood my
statement.
REH
The Ghost In The Machine
<besc...@vt.edu>
wrote
on Thu, 27 Apr 2006 11:03:52 -0400
<e2qmi5$sqg$1...@solaris.cc.vt.edu>:
> REH wrote:
>> Luc The Perverse wrote:
>>
>>>Java is simpler, cleaner - but programming is programming.
>>
>>
>> Yeah, and that's why I write real-time systems in Perl. Languages are
>> tools. Use the right one for the right job. No language has yet
>> filled the "one-size-fits-all" catagory.
>>
>> REH
>>
>
> I've programmed both in JAVA and C++
>
> Try writing a OS in JAVA...wait is that even possible?
It's been done, although AFAIK it didn't fare all that well in the
marketplace.
http://en.wikipedia.org/wiki/JavaOS
A freeware variant is also active. This one looks rather interesting,
although the compatibility list is a little skimpy...but then, that's
why freeware is such fun; someone will write those drivers (and one
might port them from equivalent Linux drivers) if they need them.
>
> or try writing web based programs in C++, get ready for a headache...
Not as bad as one might think if one avoids pointers and
sticks to the Standard Template Library. However, Java
may very well be more efficient under those conditions,
as it copies pointers instead of entire structures.
There is one thing missing from Java, the equivalent
of std::multiset<> and std::multimap<>. However, the latter
can be replaced by std::map<..., std::list<>>, and I don't
know of any really good uses for the former offhand that
wouldn't be better served by a std::multimap<> or a
std::map<...,std::list<>>.
Oliver Wong
news:e2qmi5$sqg$1...@solaris.cc.vt.edu...
>
> Try writing a OS in JAVA...wait is that even possible?
http://en.wikipedia.org/wiki/JavaOS
- Oliver
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>I agree that may be C++ programmers are smarter.
There are two meaning for smarter.
There is a the sort of guy who can keep his home books doing all the
arithmetic in his head.
There is the sort of guy who uses an adding machine with a tape for
verification.
The first has more raw skill. The second gets the job done more
accurately with less effort, and gets to go fishing sooner.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Noah Roberts
Mishagam wrote:
> 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.
Three things I _really_ hate about Java.
> 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.
Actually, you are in err. Java also has char[] and there is nothing
stopping someone from using it or designing a new String. Therefor
Java suffers from the same "problem" as C++ here except there are no
Java functions and tools to work with char[]...you have to write them
from scratch.
> 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.
Yes, but all the benefits you are listing are things you *can't* do and
the things forced upon you. Where are the list of things you *can* do?
You make Java sound like a jail sentance.
I don't think one is better than the other but common, these are just
bad arguments.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>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).
This is a huge benefit. There are so many addressing modes in C++ that
really don't buy you much other than confusion.
The other huge benefit is platform independence. Java has everything
removed that would temp you to write platform dependent code.
Granted I tend to use a very vanilla style of coding, but platform
specific problems just don't happen to me.
Even writing something as UI-free as a compiler takes a huge amount of
platform-adjusting application code. In Java, that his already
handled by standard libraries.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>
>I like new/delete. Makes me feel I'm in charge. Just my .02$
The problem is a bit like "feeling in charge" at a 747 control panel.
You know you are not up to the job for any serious app.
I used to use Numega to track leaks in a C/C++ team's code. It was
not a matter of fixing them, but getting them down to a dull roar.
Mixing exception handling and memory management boggles the human
mind.
Noah Roberts
Roedy Green wrote:
> The other huge benefit is platform independence. Java has everything
> removed that would temp you to write platform dependent code.
Well, that is one area where Java *can't* be used then isn't it.
Another can't. Where is the can?
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>>> c) You don't have to decide about programming style. Sun provided
>>> standard Java style.
>>
>> Juck!
>
>You don't like Sun Style? I find it not worse than any other, and it has
>advantage that most Java programmers use it. In C, for example, Linux
>core uses one style, and Gnu uses other, incompatible style, and
>Microsoft, of course, uses third.
1. A Java shop can adopt Sun style which every new programmer knows
since they have seen it ad nauseam in the Sun classes.
2. Or a shop can adopt its own more rigid super set of Sun rules.
3. Or a shop can adopt its own style.
4. Or a shop can adopt chaos and start blood feuds between programmers
to poison the coffee of the programmers who reformat "their" code and
deal with repository false deltas.
How is a C++ shop better off having only choices 3 and 4?
see http://mindprod.com/jgloss/codingconventions.html
Noah Roberts
Roedy Green wrote:
> On Thu, 27 Apr 2006 15:06:53 +0200, "Gernot Frisch" <M...@Privacy.net>
> wrote, quoted or indirectly quoted someone who said :
> Mixing exception handling and memory management boggles the human
> mind.
Only one incapable of learning very simple techniques to make it a
non-issue.
http://www.hackcraft.net/raii/
Note that this won't work in Java. You can't use this technique to
clean up resources like handles and other resources that are not memory
related as you can't depend on the deallocation of any object in your
code; GC picks it up when it wants to.
There are also the three exception guarantees, which are applicable in
ANY language, that also make exception handling in C++ less risky.
If you aren't capable of avoiding a memory leak in an exceptional
situation then you can't handle any other kind of leak and believe
me...the problem exists in ANY language that has exceptions as there
are numerous resources that you gather and have to release that are not
memory related and so you can't use GC as a crutch for that.
So, if your mind is boggled by memory and exception handling then you
better stick to simple problems.
Martin Vejnár
> [5] Java doesn't have explicit deletes. The garbage
> collection is expected to take care of things. (There are
> some exceptions; a FileOutputStream for example will be
> left open indefinitely, even if the reference is lost.)
For some reason, you've put the most important statement in parentheses.
RAII is one of the two reasons I stick with C++. I don't know of any
other language that would support such concept. (C# and D both support
RAII, but require the programmer to explicitly mark objects that should
be destroyed when leaving scope. Why?) How do you do RAII in Java?
--
Martin
Roedy Green
<sll_noSpamli...@cc.usu.edu> wrote, quoted or indirectly
quoted someone who said :
>
>Learning C++ is marginally more difficult than learning Java.
>
>I used to be a die hard C++ advocate - but the added complexity doesn't
>really add a great deal of usability; but it is great for obscuring the
>meaning of the code.
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.
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.
I think of computer languages as like species of dinosaur. Each new
species can build on the last and do one new "trick". It would be
silly to expect one early dinosaur to be the ultimate. Because others
built on the shoulders of its design does not detract from the
"pioneering" work of the earlier species.
People like to pretend their current favourite is the end point in
language evolution. Getting too attached just slows evolution. We
have a long way to go.
We will have to give up more and more fine control, and let more and
more programming be handled by the augmented equivalent of CSS style
sheets. We will have to get used to the idea of specifying the
desired results and letting computers figure out the best algorithms.
The big change will be the effect of the SCID on language design. A
program will become a set of structured data describing how you want a
computer to behave. It won't just be a text stream. It will consist of
binary data, dialogs, images, internationalisation, cross references,
declarations, rules of thumb, style sheets, spreadsheets, PET tables,
examples, online/offline documentation, algorithms that can be
displayed in dozens of different ways, even flow charts.
Remon van Vliet
"Noah Roberts" <robert...@gmail.com> wrote in message
news:1146161322.2...@t31g2000cwb.googlegroups.com...
It's quite tricky to be really condecending and really wrong at the same
time but hey, somehow you managed. Rather than question the intelligence and
expertise of someone who offered perfectly valid points you may want to
consider either actually having a look at Java instead of browing Java
newsgroups ready to jump in on the first sigh of a troll. I'd be more than
interested in even a single practical example of these resource/exception
issues of Java you speak of that are so much easier in C++...just one..
Remon van Vliet
You do think one is better than the other, it's just a flawed way of
reasoning. Also, all arguments you mentioned in your posts range from
somewhat doubtful to factually inaccurate. You're just bashing, which is a
waste of time for people that bother reading this. Move along.
Walter Bright
> Roedy Green wrote:
>> On Thu, 27 Apr 2006 15:06:53 +0200, "Gernot Frisch" <M...@Privacy.net>
>> wrote, quoted or indirectly quoted someone who said :
>
>> Mixing exception handling and memory management boggles the human
>> mind.
>
> Only one incapable of learning very simple techniques to make it a
> non-issue.
>
> http://www.hackcraft.net/raii/
There's another way to do it - scope guard. Here's an article on it:
http://www.digitalmars.com/d/exception-safe.html
-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
Remon van Vliet
"Martin Vejnár" <ava...@volny.cz> wrote in message
news:e2r19d$vfr$1...@ns.felk.cvut.cz...
Have you ever used Java and actually ran into an issue that requires RAII?
Alf P. Steinbach
> I'd be more than
> interested in even a single practical example of these resource/exception
> issues of Java you speak of that are so much easier in C++...just one..
All external resources.
They're not "so much easier" to handle in C++. In fact they're /very
difficult/ to handle correctly in C++. However, C++ offers facilities
that make it practically possible to prevent such problems from arising.
People who come from e.g. Java or C tend to not see those issues as
problems, because in those languages there's just no hope of dealing
preventively with fundamental resource leak issues, so the pragmatic
approach of "if it becomes a real problem, let's deal with that concrete
real problem" is applied instead of designing in any guarantee from the
start. Pick up any C or Java code dealing with external resources of
any kind, and more often than not, there's a potential resource leak
staring the C++ programmer in the eye. However, the C++ programmer
would be wrong to chastise the C or Java programmer for that, because
most probably the resource leaks will be consequences of the intentional
pragmatic approach to dealing with the languages' shortcomings: those
potential leaks won't, in general, be actual problematic leaks.
Add to that that C++ is so infernally huge and complex, like COBOL or
PL/1, that it's seldom used correctly by the average programmer.
And in sum that means that the C or Java code may actually have less
relevant resource leaks than the equivalent average programmer's C++
code. Only for the critical support code written by an expert or
experts does C++ shine. Because there the potential can be realized.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Remon van Vliet
"Walter Bright" <wal...@digitalmars-nospamm.com> wrote in message
news:DcednXD8q8lXkszZ...@comcast.com...
What point am i missing if i mention the "finally" block in Java?
Remon van Vliet
"Alf P. Steinbach" <al...@start.no> wrote in message
news:4bchkeF...@individual.net...
>* Remon van Vliet -> Noah Roberts
> > I'd be more than
>> interested in even a single practical example of these resource/exception
>> issues of Java you speak of that are so much easier in C++...just one..
>
> All external resources.
I think this is factually untrue. So, a practical example please?
>
> They're not "so much easier" to handle in C++. In fact they're /very
> difficult/ to handle correctly in C++. However, C++ offers facilities
> that make it practically possible to prevent such problems from arising.
>
> People who come from e.g. Java or C tend to not see those issues as
> problems, because in those languages there's just no hope of dealing
> preventively with fundamental resource leak issues, so the pragmatic
> approach of "if it becomes a real problem, let's deal with that concrete
> real problem" is applied instead of designing in any guarantee from the
> start. Pick up any C or Java code dealing with external resources of any
> kind, and more often than not, there's a potential resource leak staring
> the C++ programmer in the eye.
Perhaps said C++ programmer just isnt overly familiar with Java. It seems to
be the red line through these kind of threads.
>However, the C++ programmer would be wrong to chastise the C or Java
>programmer for that, because most probably the resource leaks will be
>consequences of the intentional pragmatic approach to dealing with the
>languages' shortcomings: those potential leaks won't, in general, be actual
>problematic leaks.
>
> Add to that that C++ is so infernally huge and complex, like COBOL or
> PL/1, that it's seldom used correctly by the average programmer.
Once again this sounds like a C++ developer with a superiority complex.
"Average programmers" here and there. Fact remains i still need to hear of a
external resource leak problem that's consistently easier to deal with in
C++ compared to Java.
>
> And in sum that means that the C or Java code may actually have less
> relevant resource leaks than the equivalent average programmer's C++ code.
> Only for the critical support code written by an expert or experts does
> C++ shine. Because there the potential can be realized.
"Critical support code"? like?
Noah Roberts
Remon van Vliet wrote:
> "Noah Roberts" <robert...@gmail.com> wrote in message
> news:1146161322.2...@t31g2000cwb.googlegroups.com...
> > There are also the three exception guarantees, which are applicable in
> > ANY language, that also make exception handling in C++ less risky.
> >
> > If you aren't capable of avoiding a memory leak in an exceptional
> > situation then you can't handle any other kind of leak and believe
> > me...the problem exists in ANY language that has exceptions as there
> > are numerous resources that you gather and have to release that are not
> > memory related and so you can't use GC as a crutch for that.
>
> It's quite tricky to be really condecending and really wrong at the same
> time but hey, somehow you managed. Rather than question the intelligence and
> expertise of someone who offered perfectly valid points you may want to
> consider either actually having a look at Java instead of browing Java
> newsgroups ready to jump in on the first sigh of a troll. I'd be more than
> interested in even a single practical example of these resource/exception
> issues of Java you speak of that are so much easier in C++...just one..
Well since you can't read and/or comprehend what you are reading I
think it would be a waste of time and effort to offer any proof of
anything to you...besides being unwilling to prove something I didn't
bring up.
Why do I question your ability to comprehend the written word? Because
I _never_ said anything was easier in C++ than Java or the other way
around. The one thing I did say that could even REMOTELY be considered
such was to say that RAII won't work and I already gave the reason why
- you can't depend on the timing of deallocation in Java and you have 0
control over it.
I am more capable in C++ but that is because I rarely use Java. On the
other hand, I am fully capable of coding in Java and have done so many
times.
Noah Roberts
Remon van Vliet wrote:
> What point am i missing if i mention the "finally" block in Java?
That nobody said it was impossible to release resources correctly in
exceptional situations in Java.
What was said is that memory management and exceptions are "mind
boggling" issues and I made the point that you better be able to handle
such things because the problem comes up in any language that has
exceptions as there are other resources besides memory that need
correct handling in exceptional situations. I also gave two examples
of how C++ programmers deal with the problem from the ground up.
Also, you could read that article above which shows some shortcommings
of both RAII and finally. However, the "scope guard" appears to be a D
language particular construct so is rather moot in this discussion. It
is just another way to do the same thing...better or not, I pretend to
know.
peter koch
Remon van Vliet skrev:
> "Alf P. Steinbach" <al...@start.no> wrote in message
> news:4bchkeF...@individual.net...
> >* Remon van Vliet -> Noah Roberts
> > > I'd be more than
> >> interested in even a single practical example of these resource/exception
> >> issues of Java you speak of that are so much easier in C++...just one..
> >
> > All external resources.
>
> I think this is factually untrue. So, a practical example please?
>
Just one simple example, then: files. The lack of cleaning up of
resources in Java is so common that the Java library calls the
garbagecollector whenever opening a file fails. Often this solves the
problem since the likely reason is that the program leaks this
resource.
You might argue that there's a solution to that problem, but the
"solution" is a hack and it works less than well on a system that is
truly multiuser.
[snip]
> >
> > People who come from e.g. Java or C tend to not see those issues as
> > problems, because in those languages there's just no hope of dealing
> > preventively with fundamental resource leak issues, so the pragmatic
> > approach of "if it becomes a real problem, let's deal with that concrete
> > real problem" is applied instead of designing in any guarantee from the
> > start. Pick up any C or Java code dealing with external resources of any
> > kind, and more often than not, there's a potential resource leak staring
> > the C++ programmer in the eye.
>
> Perhaps said C++ programmer just isnt overly familiar with Java. It seems to
> be the red line through these kind of threads.
Look at any reasonably sized Java program and look at the try ...
finally constructs. Likely each of these is a place where resources are
to be released. This is evidence that this handling of leaks is a
manual process which makes the program more fragile. Also it causes the
programs to be difficult to maintain. What happens - as an example - to
a
> >However, the C++ programmer would be wrong to chastise the C or Java
> >programmer for that, because most probably the resource leaks will be
> >consequences of the intentional pragmatic approach to dealing with the
> >languages' shortcomings: those potential leaks won't, in general, be actual
> >problematic leaks.
> >
> > Add to that that C++ is so infernally huge and complex, like COBOL or
> > PL/1, that it's seldom used correctly by the average programmer.
>
> Once again this sounds like a C++ developer with a superiority complex.
> "Average programmers" here and there. Fact remains i still need to hear of a
> external resource leak problem that's consistently easier to deal with in
> C++ compared to Java.
I do not understand you. So long as you encapsulate all resources in a
class, there is no chance of leaks anymore. This is not the case for
Java.
> > And in sum that means that the C or Java code may actually have less
> > relevant resource leaks than the equivalent average programmer's C++ code.
> > Only for the critical support code written by an expert or experts does
> > C++ shine. Because there the potential can be realized.
>
> "Critical support code"? like?
I believe most large system out there in the real world relies on C or
C++. Examples are numerous, but I could mention banking,
telecommunication and database management systems. I doubt you will
find any large product of this type in Java. There will be lots of Java
in the "supporting" infrastructure of course - most likely my
homebanking solution is Java. But all the "real" and "heavy" stuff is
most likely C/C++.
/Peter
Noah Roberts
Remon van Vliet wrote:
> You do think one is better than the other,
You need to have your mind reading ability rechecked. It isn't working
anymore. IMHO you shouldn't have grown to depend on it anyway.
Your logical reasoning circuitry could use some work too...
Just some helpful hints.
Alf P. Steinbach
> "Alf P. Steinbach" <al...@start.no> wrote in message
> news:4bchkeF...@individual.net...
>> * Remon van Vliet -> Noah Roberts
>>> I'd be more than
>>> interested in even a single practical example of these resource/exception
>>> issues of Java you speak of that are so much easier in C++...just one..
>> All external resources.
>
> I think this is factually untrue. So, a practical example please?
Perhaps the most infamous was the earliest versions of the Swing library
in Java.
> isnt overly familiar with Java
> superiority complex.
> Fact remains i still need
Keep to the technical, not the emotional, please, even in a trolling thread.
> "Critical support code"? like?
That's an ungood question, from the perspective of topicality. What's
critical generally depends on the context (e.g. project, organization),
and describing such a context fully, so that a troller can't take issue
with it, isn't possible in a Usenet posting. However, the C++ standard
library is one example of support code that's critical in any context.
Noah Roberts
peter koch wrote:
> I believe most large system out there in the real world relies on C or
> C++. Examples are numerous, but I could mention banking,
> telecommunication and database management systems. I doubt you will
> find any large product of this type in Java. There will be lots of Java
> in the "supporting" infrastructure of course - most likely my
> homebanking solution is Java. But all the "real" and "heavy" stuff is
> most likely C/C++.
Oh I think there are plenty of large projects using Java even if I
can't think of one off the top of my head. Besides, any fact that lots
of large stuff uses C or C++ can be written of as a legacy issue
anyway. Millions and millions of lines of code don't get turned over
to a different language just because it's better (assuming for the
moment that Java is 'better') even if there has been over 10 years to
do so. It just doesn't happen and anyone insisting that it should is
going to be out of work really fast.
peter koch
Roedy Green skrev:
> On Thu, 27 Apr 2006 10:43:36 GMT, Mishagam <noe...@provider.com>
> wrote, quoted or indirectly quoted someone who said :
>
> >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).
>
> This is a huge benefit. There are so many addressing modes in C++ that
> really don't buy you much other than confusion.
This is ridiculous - like claiming you only know to drive a car with
automatic shifts because manual shifts are all to difficult. I do not
know what gear to use!
>
> The other huge benefit is platform independence. Java has everything
> removed that would temp you to write platform dependent code.
The problem here is that Java is not as portable as C/C++. Also, there
are lots of platforms out there where Java simply can't run.
>
> Granted I tend to use a very vanilla style of coding, but platform
> specific problems just don't happen to me.
>
> Even writing something as UI-free as a compiler takes a huge amount of
> platform-adjusting application code. In Java, that his already
> handled by standard libraries.
Well... the company I work for also programs (partially) in Java and it
has had lots of portability problems. The Java library (e.g. for
locking of files or creating new processes) simply does not work the
same way when moving between Solaris, Windows and AIX.
> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.
/Peter
peter koch
Roedy Green skrev:
[snip]
> 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.
>
> 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.
That is simply false - and most probably a bloody lie. About on par
with the other posts I've seen from you. Others might want to have a
look at
http://public.research.att.com/~bs/bs_faq.html
>
> I think of computer languages as like species of dinosaur. Each new
> species can build on the last and do one new "trick". It would be
> silly to expect one early dinosaur to be the ultimate. Because others
> built on the shoulders of its design does not detract from the
> "pioneering" work of the earlier species.
But Java was never meant to be a step forward in the evolutionary
chain. It was meant to be simpler and with less capability than C++,
and for that it sacrificed some safety features present in C++ (such as
e.g. const and ability to pass by value) while removing others (such as
pointer manipulators).
>
> People like to pretend their current favourite is the end point in
> language evolution. Getting too attached just slows evolution. We
> have a long way to go.
>
> We will have to give up more and more fine control, and let more and
> more programming be handled by the augmented equivalent of CSS style
> sheets. We will have to get used to the idea of specifying the
> desired results and letting computers figure out the best algorithms.
We are a long way from that. But if you focus simply on
high-performance, easy-to-use products C++ has come a long way
delivering this.
[snip]
/Peter
The Ghost In The Machine
<re...@exmachina.nl>
wrote
on Thu, 27 Apr 2006 20:40:42 +0200
<44511034$0$31643$e4fe...@news.xs4all.nl>:
http://www.hackcraft.net/raii/
"Resource Acquisition Is Initialisation"
...
[begin excerpt]
Which Languages are Appropriate for RAII
Or rather, which languages is RAII appropriate for. As will soon be
explained RAII depends on the way that constructors and, in
particular, destructors, get called and the predictability of this
happening.
RAII can be used with:
* Languages which can have user-defined types allocated on the
stack (automatic objects in C/C++ terminology) and cleaned up
during normal stack cleanup (whether because of a function
returning, or an exception being thrown). E.g. C++.
* Languages which have reference-counted garbage collection
and hence predictable cleanup of an object for which there
is only one reference. E.g. VB6
RAII cannot generally be used with languages that clean up
objects using an unpredictable garbage collection, such as
Java (however see the Postscript on .NET). If a language
guarantees cleanup of all objects before an application
shuts down then it may be applicable to some problems.
[end excerpt]
I am not certain whether an Object variable going out of scope
in Java is subject to automatic cleanup or not, and if it is,
under what circumstances. Obviously it cannot be cleaned up
if the Object is placed into a Map or Collection. Otherwise,
I don't know.
In Java one can use a try{}catch{}finally{} pattern to
emulate RAII, but it has to be explicitly programmed.
One can also attempt overload of the finalize() method,
but the problem is that one has no idea exactly when
that will be called -- if at all. Some patterns (Swing)
implement a dispose() method as well, which Java does *not*
support directly.
--
#191, ewi...@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.
The Ghost In The Machine
<robert...@gmail.com>
wrote
on 27 Apr 2006 10:59:36 -0700
<1146160776....@u72g2000cwu.googlegroups.com>:
JNI allows for Java to call down to native code. It tends
to be slow and little-used.
That removes the "can't", but replaces it with a "won't".
Other solutions are also possible, such as named pipes,
sockets, and pseudoterminals.
The Ghost In The Machine
<44511104$0$31654$e4fe...@news.xs4all.nl>:
"finally" is to RAII as manual transmission is to
automatic, from the looks of things.
Chris Smith
> Have you ever used Java and actually ran into an issue that requires
> RAII?
Of course no one has. There are no issues that require RAII. That's
irrelevant to the question of whether it is useful. Certainly,
try/finally gets cumbersome sometimes.
--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Chris Smith
> > Mixing exception handling and memory management boggles the human
> > mind.
Noah Roberts <robert...@gmail.com> wrote:
> Only one incapable of learning very simple techniques to make it a
> non-issue.
>
> http://www.hackcraft.net/raii/
There are two questions being considered simultaneously here. One is
what is required to produce useful software in a language. The other
matter is what is required to understand that language. I side with the
position that a language that's hard to understand has a weakness in
this even if it remains possible to write software using that language.
Exception handling and memory management IS tricky in C++. So is the
relationship between function overloading, implicit type conversions,
and templates.
RAII is a different matter. It's a nice feature to have; but it doesn't
make the language any easier to understand.
Noah Roberts
Chris Smith wrote:
> > Roedy Green wrote:
> > > Mixing exception handling and memory management boggles the human
> > > mind.
>
> Noah Roberts <robert...@gmail.com> wrote:
> > Only one incapable of learning very simple techniques to make it a
> > non-issue.
> >
> > http://www.hackcraft.net/raii/
>
> There are two questions being considered simultaneously here. One is
> what is required to produce useful software in a language. The other
> matter is what is required to understand that language. I side with the
> position that a language that's hard to understand has a weakness in
> this even if it remains possible to write software using that language.
> Exception handling and memory management IS tricky in C++. So is the
> relationship between function overloading, implicit type conversions,
> and templates.
Lots of silly statements but no backing. "X is hard." Meaningless.
>
> RAII is a different matter. It's a nice feature to have; but it doesn't
> make the language any easier to understand.
Actually, RAII is at the HEART of this matter as it is a commonly used
technique to deal with the issue put forth. It is a very simple
concept and it works not only for memory management but also any other
resource that needs to be aquired and released.
Walter Bright
> "Walter Bright" <wal...@digitalmars-nospamm.com> wrote in message
> news:DcednXD8q8lXkszZ...@comcast.com...
>> Noah Roberts wrote:
>>> Only one incapable of learning very simple techniques to make it a
>>> non-issue.
>>>
>>> http://www.hackcraft.net/raii/
>> There's another way to do it - scope guard. Here's an article on it:
>> http://www.digitalmars.com/d/exception-safe.html
'finally' works fine for one level of undo. It doesn't work so well (and
neither does RAII) if there are multiple operations that must all
succeed or none have happened. For example, if a transaction consists of
transactions A, B, and C, and A and B succeed but C fails, one must
unwind B and C. The article goes into more depth with this including
examples.
Walter Bright
> Also, you could read that article above which shows some shortcommings
> of both RAII and finally. However, the "scope guard" appears to be a D
> language particular construct so is rather moot in this discussion.
There's a link at the end of the article with Andrei Alexandrescu's
technique for doing a limited form of scope guard in C++.
Bent C Dalager
Well, "completely unrelated" may be going a bit too far (it's more
like the wayward half brother that comes around to borrow money from
you every now and then, who you don't like to talk about in polite
company) but it is definately a different language.
Cheers
Bent D
--
Bent Dalager - b...@pvv.org - http://www.pvv.org/~bcd
powered by emacs
Martin Vejnár
> Have you ever used Java
No
> and actually ran into an issue that requires RAII?
Require is a strong word. You can always do without RAII. You just have
a greater chance of losing precious time trying to figure out where
exactly have you forgotten to release that mutex...
Garbage collector may be good when it comes to releasing memory, but
memory is not the only resource you use. How about files, network
streams, database connections, synchronization primitives, etc?
A reply from "The Ghost In The Machine" has mentioned try..finally.
Whenever you use that construct to safely dispose of a resource, you're
better off using RAII.
Btw, I'm not really sure, but is the finally block executed, when you do
'return' from inside the try block?
--
Martin
Bent C Dalager
>
>I've programmed both in JAVA and C++
>
>Try writing a OS in JAVA...wait is that even possible?
This is easily possible (and reasonably common) on smart card chips,
many of which support Java bytecode natively.
Java-based CPUs for desktops have been tried I think, but it didn't
take off.
Alf P. Steinbach
> Noah Roberts wrote:
>> Also, you could read that article above which shows some shortcommings
>> of both RAII and finally. However, the "scope guard" appears to be a D
>> language particular construct so is rather moot in this discussion.
>
> There's a link at the end of the article with Andrei Alexandrescu's
> technique for doing a limited form of scope guard in C++.
>
> http://www.digitalmars.com/d/exception-safe.html
I think you should get the attributions right (sorry, how could I put
this in a more gentle way?): ScopeGuard was Petri Marginean's invention,
and he co-authored the CUJ article with Andrei.
Walter Bright
> (Personally, I found ECMAScript pretty straight forward up until I
> reached the chapter of the spec titled "automatic semicolon
> insertion". It went downhill from there <g>)
Automatic semicolon insertion is one of those ideas that perennially
keeps popping back up. The trouble is, it sounds good, and it is only
after experience with it that one eventually realizes what a bad idea it
is. And then a newbie comes along, and goes through the same process
again <g>.
Bent C Dalager
Martin Vejnár <ava...@volny.cz> wrote:
>
>Garbage collector may be good when it comes to releasing memory, but
>memory is not the only resource you use. How about files, network
>streams, database connections, synchronization primitives, etc?
One classic leak is putting things into event listening lists in Swing
and forgetting to remove them at the appropriate time.
>A reply from "The Ghost In The Machine" has mentioned try..finally.
>Whenever you use that construct to safely dispose of a resource, you're
>better off using RAII.
>
>Btw, I'm not really sure, but is the finally block executed, when you do
>'return' from inside the try block?
The finally block will _always_ be entered before the method returns.
Whether the "finally" runs to completion depends on whether an
unhandled exception gets thrown in the finally-block itself. If that
happens, then the remainder of the finally block is skipped.
Noah Roberts
Walter Bright wrote:
> Noah Roberts wrote:
> > Also, you could read that article above which shows some shortcommings
> > of both RAII and finally. However, the "scope guard" appears to be a D
> > language particular construct so is rather moot in this discussion.
>
> There's a link at the end of the article with Andrei Alexandrescu's
> technique for doing a limited form of scope guard in C++.
Well, that is on my list of things to read now; I am always up for
learning new techniques...whether I use them or not is a different
matter.
At any rate, exception safety is not a C++ only problem. Any language
that uses exceptions has exception safety issues and so far I haven't
seen one that did any better than another in this regard.
Bent C Dalager
Walter Bright <wal...@digitalmars-nospamm.com> wrote:
>
>Automatic semicolon insertion is one of those ideas that perennially
>keeps popping back up.
I do admit to many times having run a C, C++ or Java compiler, had it
stop with a "semicolon expected" type error and cursing inwardly at it
thinking "well why don't you just _insert_ a bloody semicolon you
stupid compiler pos since you obviously realise that one is missing
right there".
In my world, however, there is a long way to go from just projecting
my own shortcomings onto the compiler and to actually implementing
complicated heuristics for trying to guess when the programmer did or
did not want a semicolon in the source code :-)
> The trouble is, it sounds good, and it is only
>after experience with it that one eventually realizes what a bad idea it
>is. And then a newbie comes along, and goes through the same process
>again <g>.
Yes, but, I used to think that this was a self-solving problem.
Newbies don't write programming languages, after all, and by the time
they have the skill required to do so, one would have thought they
were long past the "let the language just guess what I mean" stage
. . .
Obviously not though :-)
Walter Bright
> * Walter Bright:
>> Noah Roberts wrote:
>>> Also, you could read that article above which shows some shortcommings
>>> of both RAII and finally. However, the "scope guard" appears to be a D
>>> language particular construct so is rather moot in this discussion.
>>
>> There's a link at the end of the article with Andrei Alexandrescu's
>> technique for doing a limited form of scope guard in C++.
>>
>> http://www.digitalmars.com/d/exception-safe.html
>
> I think you should get the attributions right (sorry, how could I put
> this in a more gentle way?): ScopeGuard was Petri Marginean's invention,
> and he co-authored the CUJ article with Andrei.
You're right. I apologize for the error.
Oliver Wong
"peter koch" <peter.ko...@gmail.com> wrote in message
news:1146165539.3...@e56g2000cwe.googlegroups.com...
>
> I believe most large system out there in the real world relies on C or
> C++. Examples are numerous, but I could mention banking,
> telecommunication and database management systems. I doubt you will
> find any large product of this type in Java. There will be lots of Java
> in the "supporting" infrastructure of course - most likely my
> homebanking solution is Java. But all the "real" and "heavy" stuff is
> most likely C/C++.
You're wrong. I don't know about telecommunication and DBMS, but for
banking, insurance and other "large systems" in the "real world", it's
mostly COBOL, and the businesses are looking to migrate their code to Java
or .NET. The reason I know this is that I work for a porting and migration
company (Castor Technologies) and we often get contracts from banks,
insurance companies, educational institues and the governments asking to
migrate their COBOL stuff to the above two platforms.
For what it's worth, usually for educational institutes they want to
switch to .NET, and everyone else wants to switch to Java.
- Oliver
Oliver Wong
"Noah Roberts" <robert...@gmail.com> wrote in message
news:1146160776....@u72g2000cwu.googlegroups.com...
>
> Roedy Green wrote:
>
>> The other huge benefit is platform independence. Java has everything
>> removed that would temp you to write platform dependent code.
>
> Well, that is one area where Java *can't* be used then isn't it.
>
> Another can't. Where is the can?
>
I think it's a bit silly to complain that you *can't* write platform
dependent code in Java.
If you goal is to intentionally write platform dependent code, maybe
Java isn't for you.
- Oliver
Andrew McDonagh
> I normally dont get involved with pissing contests, but there's only so much
> bs in a single post i can take without replying...
>
> <snip>
>
>>> 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.
>> I like new/delete. Makes me feel I'm in charge. Just my .02$
>
> So, your entire reasoning behind preferring manual memory managment over
> garbage collection is that "you feel in charge"? You should give assembly
> language a go. Meanwhile, in the real world most recent garbage collectors
> outperform manual memory managment in the vast majority of applications, and
> as a bonus you get the complete lack of memory leaks and such.
>
>>> c) You don't have to decide about programming style. Sun provided
>>> standard Java style.
>> Juck!
>
> I'll grant you that it's a matter of taste, but no self respecting developer
> will consider standards a bad thing. If you do, draw your conclusions.
>
>>> d) You don't have to decide about naming of files and classes - they are
>>> the same.
>> no, they _have to be_ the same. Otherwise the compiler pukes.
>
> And the ability to stick tons of classes in a single file with a non-related
> name would be a good thing because....? Again, standards -> good
>
>>> e) Logical package directory structure is forced on you.
>> What about freedom of choice?
>>
>
> Can you think of a single instance where having an illogical directory
> structure is preferred over a logical one?
>
>>> 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.
>> Yeah, and a lot slower in some cases. User std::string where you need
>> dynamic strings, use char[] where you need static strings. You don't have
>> to - but you _can_!
>
> When was the last time you benchmarked Java strings vs. C++?
>
>>> g) you don't have to choose between long int, unsigned int, WORD, DWORD,
>>> size_t .... - close to optimal choice if forced on you.
>> Just a question of style. I use the built-in tpyes for everything.
>
> It's freedom that doesnt add anything but confusion and hurts readability.
>
>>> 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.
>> ?? I don't understand that. You can't define operators in Java, can you?
>> Defining operators is one of the most important things for OOP IMHO.
> He's not claiming you can, he simply says the exact same functionality can
> be achieved albeit more verbose (i.e. .add rather than +). There are
> certainly instances where operator overloading provides more readable code,
> but at the same time it can also be the cause of rather unpredictable code.
> On this point my stance is that if used with care operator overloading is a
> pretty neat thing.
Unfortunately I once saw one of the senior developers/team leaders
actually overload the comma operator.
That cause no end of problems.
Its a powerful tool granted, so is an electric screw driver - but most
times a simpler approach is better.
Oliver Wong
>
> Chris Smith wrote:
>
>> I side with the
>> position that a language that's hard to understand has a weakness in
>> this even if it remains possible to write software using that language.
>
So how about instead of characterizing a language as being universally
hard or universally bad, we just accept that some people find it difficult
to program in C++, and so C++ is not the language for them? Similarly, maybe
some people find it difficult to program in Java, and so Java is not the
language for those people.
Can't we all just get along? ;)
- Oliver
Oliver Wong
>
> Roedy Green skrev:
>
>> 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.
>
> That is simply false - and most probably a bloody lie. About on par
> with the other posts I've seen from you. Others might want to have a
> look at
>
> http://public.research.att.com/~bs/bs_faq.html
From your link:
<quote>
Most of the features I dislike from a language-design perspective are part
of the C subset of C++ and couldn't be removed without doing harm to
programmers working under real-world conditions.
[...]
By now, C++ has features that allows a programmer to refrain from using the
most troublesome C features. For example, standard library containers such
as vector, list, map, and string can be used to avoid most tricky low-level
pointer manipulation.
[...]
Within C++, there is a much smaller and cleaner language struggling to get
out.
</quote>
>
>>
>> I think of computer languages as like species of dinosaur. Each new
>> species can build on the last and do one new "trick". It would be
>> silly to expect one early dinosaur to be the ultimate. Because others
>> built on the shoulders of its design does not detract from the
>> "pioneering" work of the earlier species.
>
> But Java was never meant to be a step forward in the evolutionary
> chain. It was meant to be simpler and with less capability than C++,
> and for that it sacrificed some safety features present in C++ (such as
> e.g. const and ability to pass by value) while removing others (such as
> pointer manipulators).
I think what Java was "meant to be" would best be defined by the people
who actually participated in its creation. I strongly doubt that one of the
design goals was "Let's make a language with less capability than C++",
depending on your definition of capability.
And for what it's worth, I'll mention now that in Java, you *ALWAYS*
pass by value. I hope you'll just take my word for it and/or google the
newsgroup archives for prior discussions on this, rather than have this
claim erupt into another branch of a flame war.
- Oliver
Andrew McDonagh
> They /both/ suck.
>
go Ruby ..Go Ruby...Go Ruby
“I always knew one day Smalltalk would replace Java. I just didn’t know
it would be called Ruby." -- Kent Beck
peter koch
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?
/Peter
peter koch
Oliver Wong skrev:
Which ironically precludes writing the Java library in Java.
/Peter
>
> - Oliver
Alf P. Steinbach
>
> Meanwhile, in the real world most recent garbage collectors
> outperform manual memory managment in the vast majority of applications, and
> as a bonus you get the complete lack of memory leaks and such.
All three of those assertions are incorrect.
(1) the explicit assertion of guaranteed performance is incorrect, (2)
the explicit assertion of no memory leaks is incorrect, and (3) the
implicit assertion of no automatic garbage collection in C++, as if it
was a non-C++ only technique, is incorrect.
Such incorrect, emotionally based beliefs help create bad software.
I think perhaps the easiest for you to see the incorrectness of, is (2),
the belief that no memory leaks occur. A simple way to create a memory
leak in Java is to install an object in some global list of objects to
be called back on (event handling), then forget to remove it.
In short, what you wrote is rubbish, and dangerous rubbish.
Bent C Dalager
peter koch <peter.ko...@gmail.com> wrote:
>
>Oliver Wong skrev:
>
>>
>> If you goal is to intentionally write platform dependent code, maybe
>> Java isn't for you.
>
>Which ironically precludes writing the Java library in Java.
Not any more so than for any other non-assembly language.
At some point, C++ also needs to fall back to assembly code to
implement its basic functions - even if that means bootstrapping a
compiler chain up from a simple assembly-based C compiler.
Interestingly, of course, while there are no CPUs that support C++
instructions natively (that I know of anyway), there are those that
support Java bytecode natively. The conclusion being that while it is
possible to have a pure Java system, it is not possible to have a pure
C++ system :-)
(No, it's not an important point.)
peter koch
Chris Smith skrev:
> > Roedy Green wrote:
> > > Mixing exception handling and memory management boggles the human
> > > mind.
>
> Noah Roberts <robert...@gmail.com> wrote:
> > Only one incapable of learning very simple techniques to make it a
> > non-issue.
> >
> > http://www.hackcraft.net/raii/
>
> There are two questions being considered simultaneously here. One is
> what is required to produce useful software in a language. The other
> matter is what is required to understand that language. I side with the
> position that a language that's hard to understand has a weakness in
> this even if it remains possible to write software using that language.
I agree here. Readability matters a lot. And here C++ is a clear
winner, due to its more advanced features such as templates, operator
overloading and RAII,
> Exception handling and memory management IS tricky in C++.
I must disagree. Exception handling is far easier in C++, due primarily
to RAII. Consider:
// C++
func()
{
class_with_possible_ressource cwpr;
dosomethingwith(cwpr);
}
// Java
func()
{
class_with_possible_ressource cwpr = new
class_with_possible_ressource ;
if (cwpr->did_initialise_properly())
{
try
{
dosomethingwith(cwpr);
}
finally
{
try
{
idisp = (IDisposable)cwpr;
idisp->Dispose();
}
catch (...)
{
}
}
}
}
Four simple lines of C++ becomes 21 lines of complex and convoluted
Java-code.
If you know that the class contains a ressource you save four lines -
and if you know that the class does not contain a ressource (and you
dare betting your program that it newer will) you go down to seven
lines - almost the double of C++.
[snip]
> RAII is a different matter. It's a nice feature to have; but it doesn't
> make the language any easier to understand.
So the Java func above is as easy to understand as the C++-one?? Come
on - you do not really mean that. Also you have a huge problem writing
generic code in Java .... those ugly and presumably costly runtime
checks have to be made all the time.
/Peter
Noah Roberts
Bent C Dalager wrote:
> Interestingly, of course, while there are no CPUs that support C++
> instructions natively (that I know of anyway), there are those that
> support Java bytecode natively. The conclusion being that while it is
> possible to have a pure Java system, it is not possible to have a pure
> C++ system :-)
Yeah, and that is a valid comparison...
Hey, my CPU will run C++ byte code natively but there are no CPU's that
run Java source code...guess Java sucks then.
Do I hear a vacuum?
Timo Stamm
Are you sure that you know what byte code is?
Timo
peter koch
Remon van Vliet skrev:
> I normally dont get involved with pissing contests, but there's only so much
> bs in a single post i can take without replying...
>
> <snip>
>
> >> 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.
> >
> > I like new/delete. Makes me feel I'm in charge. Just my .02$
>
> So, your entire reasoning behind preferring manual memory managment over
> garbage collection is that "you feel in charge"?
The problem is not as simple as that. The fact is that garbage
collection is useful for one resource only: memory. All other resources
must be handled explicitly in Java. Depending on your application, this
might be a small or a large problem, but the fact is that RAII in C++
gives you a way to cope with all resources in a uniform way.
> You should give assembly
> language a go. Meanwhile, in the real world most recent garbage collectors
> outperform manual memory managment in the vast majority of applications, and
> as a bonus you get the complete lack of memory leaks and such.
What do you mean with "and such"? I believe C++ is in the best position
to guarantee the whole thing. Java gives you protection wrt
memory-leaks and C++ gives you protection regardless of the resource.
Also, most C++ programs can use garbage collection if they want to - if
only they do not hide their pointers. This is old knowledge, so I
assume that you are aware of this?
Last but not least, the advantage of garbage collection over manual
memory management is not so evident as you seem to imply. If you look
at the newest, better performing collectors you should also compare
this to the newest and smartest allocators. Also remember that C++
gives you choices - e.g. to use a specialised allocator or to simply
use stackbased variables.
>
> >
> >> c) You don't have to decide about programming style. Sun provided
> >> standard Java style.
> >
> > Juck!
>
> I'll grant you that it's a matter of taste, but no self respecting developer
> will consider standards a bad thing. If you do, draw your conclusions.
Well - there are plenty of standards around. You should use the
standard that fits your purpose, thats what they are there for. Javas
straight-jacket is not an advantage in my eyes. E.g. I do not
understand why each class MUST have its own file (unless you make that
class a secondary citizen).
>
> >
> >> d) You don't have to decide about naming of files and classes - they are
> >> the same.
> >
> > no, they _have to be_ the same. Otherwise the compiler pukes.
>
> And the ability to stick tons of classes in a single file with a non-related
> name would be a good thing because....? Again, standards -> good
Bad programming is far more than that. I do not see any correlation
here.
>
> >
> >> e) Logical package directory structure is forced on you.
> >
> > What about freedom of choice?
> >
>
> Can you think of a single instance where having an illogical directory
> structure is preferred over a logical one?
>
> >> 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.
> >
> > Yeah, and a lot slower in some cases. User std::string where you need
> > dynamic strings, use char[] where you need static strings. You don't have
> > to - but you _can_!
>
> When was the last time you benchmarked Java strings vs. C++?
There are three kinds of lies. Lies, statistics and benchmarks.... or
so I've heard. The nice thing about C++ strings is that the number of
characters in a string is a O(1) operation. In Java, you would have to
check the number of surrogates making it a O(n) operation. Also C++
strings are more powerful than Java strings. All in all I believe I'd
prefer using C++ strings, switching to some specialised class in the
unlikely case string-handling did turn up to take a significand part of
my programs execution time.
>
> >
> >> g) you don't have to choose between long int, unsigned int, WORD, DWORD,
> >> size_t .... - close to optimal choice if forced on you.
> >
> > Just a question of style. I use the built-in tpyes for everything.
>
> It's freedom that doesnt add anything but confusion and hurts readability.
Javas type system is not freedom but rather a jail. It has prevented
porting of Java to several platforms, it gives cumbersome Unicode
support and it forces Java to stick with inefficient 32-bit integers in
a world that is soon turning to 64 bits.
>
> >> 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.
> >
> > ?? I don't understand that. You can't define operators in Java, can you?
> > Defining operators is one of the most important things for OOP IMHO.
> He's not claiming you can, he simply says the exact same functionality can
> be achieved albeit more verbose (i.e. .add rather than +). There are
> certainly instances where operator overloading provides more readable code,
> but at the same time it can also be the cause of rather unpredictable code.
> On this point my stance is that if used with care operator overloading is a
> pretty neat thing.
> >
> >> And I thing C++ standard committee just made bad design - introducing
> >> complexities which doesn't add enough benefits to justify them.
> >
> > Well, if you knew C++ as good as Java, you wouldn't say so I guess.
> > Anyway - I don't give a **** about what others use to write stuff, so this
> > is all just blahblah about nothing. There's no point making one language
> > better than the other. You will pick what suits you best or what your boss
> > indoctrinates on you.
>
> Ofcourse there's a point in making languages "better" or at least different
> than others. Sometimes a language is simply outdated, sometimes it's just
> not a viable option for certain applications (people generally dont write
> web-based application in C++ for example, just as you wont find many
> commercial games or OSs written in Java). As for bosses, people usually get
> a job based on their language skills and preferences, not the other way
> around.
I fully agree here.
>
> Anyway. there's room for both, but most of your arguments in the post above
> are flawed or outdated in my opinion, as i feel you're considering rather
> obvious weaknesses of C++ to be benefits. And to the OP, anyone claiming C++
> programmers are somehow better than Java programmers is a tool. 90% of
> skills related to being a "good developer" is completely unrelated to the
> language you're using.
And here too. Sort of at least! ;-)
/Peter
Roedy Green
<al...@start.no> wrote, quoted or indirectly quoted someone who said :
>I think perhaps the easiest for you to see the incorrectness of, is (2),
>the belief that no memory leaks occur. A simple way to create a memory
>leak in Java is to install an object in some global list of objects to
>be called back on (event handling), then forget to remove it.
see http://mindprod.com/jgloss/packratting.html
I think you are quibbling over terminology. A leak would be an object
nothing pointed to continuing to tie up ram. Packratting is holding
on to objects you will never need again. Unless you ran a program
twice and studied the history, there is no way you could have the ESP
to determine that even in theory.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
> So how about instead of characterizing a language as being universally
>hard or universally bad, we just accept that some people find it difficult
>to program in C++, and so C++ is not the language for them? Similarly, maybe
>some people find it difficult to program in Java, and so Java is not the
>language for those people.
I would be happy with that if people making the comments had working
knowledge of both before pontificating. It seem the people with the
strongest opinions have experience in primarily one language. We are
hearing the breast beatings similar to those about the best hockey or
basketball team, rather than a dispassionate comparison of features.
It further seems these fights could be turned into contests where
teams use their favoured language. The idea is to do the work in the
fewest man hours and have the fastest least resource hungry result.
You would also have a maintainability challenge, X hours to change the
program to do something different. You could get some hard data to
compare.
Roedy Green
<peter.ko...@gmail.com> wrote, quoted or indirectly quoted
someone who said :
>I agree here. Readability matters a lot. And here C++ is a clear
>winner, due to its more advanced features such as templates, operator
>overloading and RAII,
Seems to me so much low level stuff in C++ (e.g. addressing trivia)
clutters readability. Operator overloading can make code more
readable, but if misused is one of the most powerful obfuscators ever
devised. I have not used the latest IDE's but I find it so much
harder in C++ to find the definition of somthing, especially when
smothered in macros.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Yes, but all the benefits you are listing are things you *can't* do and
>the things forced upon you. Where are the list of things you *can* do?
> You make Java sound like a jail sentance.
Team coding and coding on your own are quite different experiences. I
presume you work mostly on your own. The conventions are very useful
to prevent bloodshed between team members. They are just accepted and
you get on with something more important to fight about.
peter koch
Roedy Green skrev:
> On Fri, 28 Apr 2006 00:01:48 +0200, "Alf P. Steinbach"
> <al...@start.no> wrote, quoted or indirectly quoted someone who said :
>
> >I think perhaps the easiest for you to see the incorrectness of, is (2),
> >the belief that no memory leaks occur. A simple way to create a memory
> >leak in Java is to install an object in some global list of objects to
> >be called back on (event handling), then forget to remove it.
>
> see http://mindprod.com/jgloss/packratting.html
>
> I think you are quibbling over terminology. A leak would be an object
> nothing pointed to continuing to tie up ram. Packratting is holding
> on to objects you will never need again. Unless you ran a program
> twice and studied the history, there is no way you could have the ESP
> to determine that even in theory.
This is playing wordgames. I don't care if it is what is in Java-speak
called a memory leak or pack-ratting. The fact is that you have to do
some "resource management" stuff to avoid memory usage increasing ad
infinitum. And this is not theoretical. If I remember correctly this
behaviour was found in a released official Java-library. So Java is not
just "allocate and forget" even when it comes down to "pure" memory.
Again the advantage is with C++.
/Peter
Walter Bright
> Yes, but, I used to think that this was a self-solving problem.
> Newbies don't write programming languages, after all, and by the time
> they have the skill required to do so, one would have thought they
> were long past the "let the language just guess what I mean" stage
> . . .
>
> Obviously not though :-)
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.
peter koch
Roedy Green skrev:
> On 27 Apr 2006 15:16:11 -0700, "peter koch"
> <peter.ko...@gmail.com> wrote, quoted or indirectly quoted
> someone who said :
>
> >I agree here. Readability matters a lot. And here C++ is a clear
> >winner, due to its more advanced features such as templates, operator
> >overloading and RAII,
>
> Seems to me so much low level stuff in C++ (e.g. addressing trivia)
> clutters readability.
I can't follow you here. If you have to do low-level stuff in C++ this
gives you low-level code, of course. What is it in Java that makes it
less low-level in a similar problem than Java? Do you adress stuff such
as using operator-> instead of operator.(dot)? If you refer to raw
pointer manipulations, their usage normally indicates an incompetent
programmer (or that you look at the implementation of std::vector ;-)
/Peter
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Well, that is one area where Java *can't* be used then isn't it.
>
>Another can't. Where is the can?
You CAN write platform independent Java code "in your sleep". You
can't do that in C++. At best you need to resort to the macro
preprocessor, and even then your code works on just the handful of
platforms you explicitly code and test for. In Java, it just comes
out in the wash as a side effect of writing code for one platform.
The big advantage of the Java approach is it FORCES you to write
cleaner code. There simply is no unconscious reliance on platform
quirkiness the way you have with C/C++ code. You use JNI for platform
specific code (Using C/C++) just for what you need, no more. This
makes the code base much more maintainable and generic.
Your name Noah, suggests you might be the son of fundamentalist
parents. Fundamentalists are people who are utterly convinced their
faith is the one true faith, and guarantee they never change their
opinion by scrupulously avoiding studying any others.
peter koch
Bent C Dalager skrev:
> In article <1146175039.1...@j33g2000cwa.googlegroups.com>,
> peter koch <peter.ko...@gmail.com> wrote:
> >
> >Oliver Wong skrev:
> >
> >>
> >> If you goal is to intentionally write platform dependent code, maybe
> >> Java isn't for you.
> >
> >Which ironically precludes writing the Java library in Java.
>
> Not any more so than for any other non-assembly language.
Large parts of the C++ libraries are implemented in C++. All exceptions
I know of (Microsofts C++ compiler) are low-level functions such as
strcpy and memcpy where it was a question of efficiency rather than
possibility.
>
> At some point, C++ also needs to fall back to assembly code to
> implement its basic functions - even if that means bootstrapping a
> compiler chain up from a simple assembly-based C compiler.
Of course - but this has no relation to my statement.
>
> Interestingly, of course, while there are no CPUs that support C++
> instructions natively (that I know of anyway), there are those that
> support Java bytecode natively. The conclusion being that while it is
> possible to have a pure Java system, it is not possible to have a pure
> C++ system :-)
I do not understand that one - are you trying to put a joke on me - or
do you propose that Java should run only on processors supporting
byte-code? ;-)
/Peter