f



On Java and C++

Java programmers seem to always be whining about how confusing and
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.

0
4/26/2006 10:05:15 PM
comp.lang.c++ 49423 articles. 7 followers. Post Follow

393 Replies
3273 Views

Similar Articles

[PageSpeed] 4

wellstone9912@yahoo.com wrote:

snipped dribble....

oh good a pissing competition!

My Ruby is better than your (Insert your fave, all time language here).

0
news261 (167)
4/26/2006 10:18:37 PM
wellstone9912@yahoo.com wrote:

> 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
0
JULIANALBO (791)
4/26/2006 10:19:04 PM
wellstone9912@yahoo.com wrote:

drivel

          +-------------------+             .:\:\:/:/:.
          |   PLEASE DO NOT   F            :.:\:\:/:/:.:
          |  FEED THE TROLLS  |           :=.' -   - '.=:
          |                   |           '=(\ 9   9 /)='
          |   Thank you,      |              (  (_)  )
          |       Management  |              /`-vvv-'\
          +-------------------+             /         \
                  |  |        @@@          / /|,,,,,|\ \
                  |  |        @@@         /_//  /^\  \\_\
    @x@@x@        |  |         |/         WW(  (   )  )WW
    \||||/        |  |        \|           __\,,\ /,,/__
     \||/         |  |         |      jgs (______Y______)
 /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
 ==============================================================
-- 
Ian Collins.
0
ian-news (10155)
4/26/2006 10:20:29 PM
Ian Collins wrote:
> wellstone9912@yahoo.com wrote:
>
> drivel
>
>           +-------------------+             .:\:\:/:/:.
>           |   PLEASE DO NOT   F            :.:\:\:/:/:.:
>           |  FEED THE TROLLS  |           :=.' -   - '.=:
>           |                   |           '=(\ 9   9 /)='
>           |   Thank you,      |              (  (_)  )
>           |       Management  |              /`-vvv-'\
>           +-------------------+             /         \
>                   |  |        @@@          / /|,,,,,|\ \
>                   |  |        @@@         /_//  /^\  \\_\
>     @x@@x@        |  |         |/         WW(  (   )  )WW
>     \||||/        |  |        \|           __\,,\ /,,/__
>      \||/         |  |         |      jgs (______Y______)
>  /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>  ==============================================================
> --
> Ian Collins.

Wow, posted for only 15 minutes and already 3 replies including a
"don't reply to the trolls" reply.

Nice one ;)

0
roberts.noah (1664)
4/26/2006 10:23:52 PM
["Followup-To:" header set to comp.lang.java.programmer.] On
2006-04-26, wellstone9912@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
0
spam444 (617)
4/26/2006 10:26:23 PM
from 
how to start a flame..
chapter 1

0
4/26/2006 10:41:42 PM
I agree that may be C++ programmers are smarter. Even more, I agree that 
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.

wellstone9912@yahoo.com wrote:
> Java programmers seem to always be whining about how confusing and
> 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.
> 
0
4/26/2006 10:48:25 PM
<wellstone9912@yahoo.com> wrote in message 
news:1146089115.096580.311990@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
*snip*

LOL - welcome troll!

--
LTP

:) 


0
4/26/2006 11:41:48 PM
....
> 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?


0
me4 (19624)
4/27/2006 5:03:09 AM
i am a student,
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.)

0
4/27/2006 5:09:25 AM
Gernot Frisch wrote:
> ...
>> 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?
> 
> 
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.
0
4/27/2006 5:50:32 AM
"al pacino" <siddharthdave84@gmail.com> wrote in message 
news:1146114565.653708.46780@g10g2000cwb.googlegroups.com...
>i am a student,
> 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.)

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

:)



0
4/27/2006 5:56:50 AM
> 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... 


0
me4 (19624)
4/27/2006 7:38:11 AM
> 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.

> 
> 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
0
benhongh (304)
4/27/2006 7:44:14 AM
Monique Y. Mudama wrote:
> ["Followup-To:" header set to comp.lang.java.programmer.] On
> 2006-04-26, wellstone9912@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 aren't because usally nobody forces them to program on C++ and
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.

0
mishagam (1)
4/27/2006 8:06:05 AM
Monique Y. Mudama wrote:
> ["Followup-To:" header set to comp.lang.java.programmer.] On
> 2006-04-26, wellstone9912@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 ;)
0
4/27/2006 8:31:09 AM
Gernot Frisch wrote:
>> 
>> 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... 
> 
I always wondered in such context what word 'powerfull' means?
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?
0
4/27/2006 8:49:45 AM
Mishagam wrote:
> Gernot Frisch wrote:
>>>
>>> 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...
> I always wondered in such context what word 'powerfull' means?
> 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?
I meant in last case C++ program using C++ library looks simpler than 
Java program using Java library.
0
4/27/2006 8:57:51 AM
I think that some people may be missing the point in having multiple
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.....

0
4/27/2006 9:12:00 AM
Gernot Frisch wrote:
> 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
0
walter24 (181)
4/27/2006 9:31:15 AM
In article <4450764e$0$14494$afc38c87@news.optusnet.com.au>,
benben  <benhongh@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 - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/27/2006 10:01:46 AM
"Walter Bright" <walter@digitalmars-nospamm.com> schrieb im 
Newsbeitrag news:XtidnZG8I679Es3ZnZ2dnUVZ_sSdnZ2d@comcast.com...
> Gernot Frisch wrote:
>> 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 .

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.


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










0
me4 (19624)
4/27/2006 1:06:53 PM
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

0
spamjunk (313)
4/27/2006 1:32:17 PM
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.
>
>> 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.


0
remon (167)
4/27/2006 2:13:52 PM
"Bent C Dalager" <bcd@pvv.ntnu.no> wrote in message 
news:e2q4qa$h60$2@orkan.itea.ntnu.no...
> In article <4450764e$0$14494$afc38c87@news.optusnet.com.au>,
> benben  <benhongh@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?


0
remon (167)
4/27/2006 2:15:51 PM
"Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote in message 
news:9236i3x7qk.ln2@loki.cmears.id.au...
> "al pacino" <siddharthdave84@gmail.com> wrote in message 
> news:1146114565.653708.46780@g10g2000cwb.googlegroups.com...
>>i am a student,
>> 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.)
>
> 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
>
> :)
>
>
>

Well said. "Actual programmers" shouldnt spend a large chunk of dev time on 
things like standard data structures, memory managment and well known 
algorithms. 


0
remon (167)
4/27/2006 2:17:45 PM
In comp.lang.java.advocacy, wellstone9912@yahoo.com
<wellstone9912@yahoo.com>
 wrote
on 26 Apr 2006 15:05:15 -0700
<1146089115.096580.311990@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
> 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!"

[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, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
4/27/2006 3:00:04 PM
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?

or try writing web based programs in C++, get ready for a headache...
0
bescott1 (29)
4/27/2006 3:03:52 PM
[removed c.l.j.programmer and comp.lang.c++ as this post seems off topic 
there. If there's a c++.advocacy, feel free to add it to the crosspost list]

<wellstone9912@yahoo.com> wrote in message 
news:1146089115.096580.311990@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
> explanation for this.  Is it possible that Java programmers simply
> aren't smart enough to understand C++?

    Sounds about right. I did a bit of C++ (back in highschool), but I never 
got really far. And I kept getting those core dumps 'cause apparently I 
wasn't doing the memory allocation stuff right. To write C++ programs that 
perform as well as typical Java programs, you have to be pretty smart, and I 
think I'm just not that smart. I'd rather just use Java and increase my 
overall productivity.

[...]
>
> "Oooh I'm confused about the difference between pointers, references,
> and objects!  How confusing!"

    Yeah, been there. What IS the difference between a pointer and a 
reference? And is my understanding correct in that you can have a "local" 
object? Does that thing live on the stack or what?

>
> "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?"

    Heard about this, but never actually encountered operator overloading in 
the field. Not to my knowledge anyway. Oh wait, when you do cout << 
"something", that's an operator overloading, right? See, I never really 
understood what was going on under the hood in C++.

>
> "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!"

    Heard about this too. If you've got a method signature conflicts via 
inheritance, what happens? I've heard there are rules to resolve this, but I 
never actually learned what those rules are.

>
> "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!"

    I've never even heard of "virtual bases". What is that?

>
> 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.

    Right, so the conclusion I come to is that given mediocre programmers, 
you're more likely to get good code written if those programmers write in 
Java than if they write in C++. By definition, most programmers are 
mediocre, or worse. If you're running a software development business, 
having C++ be the standard language in your shop means you either have to 
hire better (and thus more expensive) programmers, or you have to settle for 
buggier programs. So it makes good business sense to have your standard 
language be Java. You save money, and get better programs out the door.

    In the open source world, Java (along with PHP) seems to be very 
popular. I think that may be because with Java or PHP, programming has 
become a lot more accessible to the masses.

    As others have said this is probably a troll, but I don't think there's 
anything to be ashamed of in admitting that there may be people out there in 
the world smarter than you. What the troll is basically saying is that C++ 
requires you to be smarter to use it effectively (i.e. it's a poorly 
designed tool, since it doesn't allow for idiots to use it effectively). 
Note that this is distinct from "Everyone who uses C++ is smarter than those 
who use Java".

    As an analogy, ever been to those Japanese restaurants where the chef 
makes a show of preparing a meal in front of you by, for example, juggling 
the knives while using the knife currently in his hand to cut the shrimp? I 
am not skilled enough in cooking, nor in juggling, that I would attempt to 
juggle knives while cooking. And I'm not ashamed of that. I just cook 
"normally", just like millions of other people do. I'm not ashamed of that 
either. There are some people out there who manage to cook while juggling 
knives just fine. Kudos to them. I'm not one of them, and I'm not interested 
in becoming one of them. I'm satisfied just cooking my food in the way that 
is most convenient for me. My intent is to eat up with a delicious meal to 
feed myself, not to impress the people around me.

    Now someone comes onto the newsgroup and boasts how we're all too 
unskilled to juggle knives while cooking. This doesn't imply that juggling 
knives while cooking is "the best way" to cook. Nor does it imply that 
everyone who *attempts* to juggle knives while cooking will yield a better 
meal than those of us who are cooking "normally".

    - Oliver 

0
Oliver
4/27/2006 3:32:24 PM
They /both/ suck.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! 


0
phlipcpp (2771)
4/27/2006 3:48:03 PM
> 
>> 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.
0
4/27/2006 3:48:54 PM
Oliver Wong wrote:

>>
>> "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?"
> 
>    Heard about this, but never actually encountered operator overloading 
> in the field. Not to my knowledge anyway. Oh wait, when you do cout << 
> "something", that's an operator overloading, right? See, I never really 
> understood what was going on under the hood in C++.

Lucky you.

>> "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!"
> 
>    Heard about this too. If you've got a method signature conflicts via 
> inheritance, what happens? I've heard there are rules to resolve this, 
> but I never actually learned what those rules are.

Again lucky you.
> 
>>
>> "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!"
> 
>    I've never even heard of "virtual bases". What is that?
> 
Again lucky you. And hopefully you even never heard of REALLY confusing 
stuff: Templates, STL, functors - have you heard this word?

And it looks like pretty average people can understand Java collections 
framework.
0
Mishagam
4/27/2006 4:06:56 PM
Ben wrote:
> 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?
>
> or try writing web based programs in C++, get ready for a headache...

I don't know if you are agreeing with me or just misunderstood my
statement.

REH

0
spamjunk (313)
4/27/2006 4:23:35 PM
In comp.lang.java.advocacy, Ben
<bescott1@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.

http://www.jnode.org/

>
> 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<>>.

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
4/27/2006 5:00:10 PM
"Ben" <bescott1@vt.edu> wrote in message 
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 

0
owong (6178)
4/27/2006 5:27:58 PM
On Wed, 26 Apr 2006 22:48:25 GMT, Mishagam <noemail@provider.com>
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.
0
4/27/2006 5:46:02 PM
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.

0
roberts.noah (1664)
4/27/2006 5:54:17 PM
On Thu, 27 Apr 2006 10:43:36 GMT, Mishagam <noemail@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.

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.


-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 5:55:36 PM
On Thu, 27 Apr 2006 15:06:53 +0200, "Gernot Frisch" <Me@Privacy.net>
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.
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 5:59:00 PM
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?

0
roberts.noah (1664)
4/27/2006 5:59:36 PM
On Thu, 27 Apr 2006 15:48:54 GMT, Mishagam <noemail@provider.com>
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
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 6:04:47 PM
Roedy Green wrote:
> On Thu, 27 Apr 2006 15:06:53 +0200, "Gernot Frisch" <Me@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.

0
roberts.noah (1664)
4/27/2006 6:08:42 PM
The Ghost In The Machine wrote:
> [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
0
avakar (36)
4/27/2006 6:09:24 PM
On Wed, 26 Apr 2006 23:56:50 -0600, "Luc The Perverse"
<sll_noSpamlicious_z_XXX_m@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.

-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 6:21:25 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146161322.269395.183190@t31g2000cwb.googlegroups.com...
>
> Roedy Green wrote:
>> On Thu, 27 Apr 2006 15:06:53 +0200, "Gernot Frisch" <Me@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.
>

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.. 


0
remon (167)
4/27/2006 6:25:42 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146160457.471899.144450@v46g2000cwv.googlegroups.com...
>
> 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.

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. 


0
remon (167)
4/27/2006 6:33:17 PM
Noah Roberts wrote:
> Roedy Green wrote:
>> On Thu, 27 Apr 2006 15:06:53 +0200, "Gernot Frisch" <Me@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
0
walter24 (181)
4/27/2006 6:39:10 PM
"Martin Vejn�r" <avakar@volny.cz> wrote in message 
news:e2r19d$vfr$1@ns.felk.cvut.cz...
> The Ghost In The Machine wrote:
>> [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

Have you ever used Java and actually ran into an issue that requires RAII? 


0
remon (167)
4/27/2006 6:40:42 PM
* 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.

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?
0
alfps (7389)
4/27/2006 6:42:21 PM
"Walter Bright" <walter@digitalmars-nospamm.com> wrote in message 
news:DcednXD8q8lXkszZnZ2dnUVZ_vednZ2d@comcast.com...
> Noah Roberts wrote:
>> Roedy Green wrote:
>>> On Thu, 27 Apr 2006 15:06:53 +0200, "Gernot Frisch" <Me@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

What point am i missing if i mention the "finally" block in Java? 


0
remon (167)
4/27/2006 6:44:11 PM
"Alf P. Steinbach" <alfps@start.no> wrote in message 
news:4bchkeF112d1iU1@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? 


0
remon (167)
4/27/2006 6:55:02 PM
Remon van Vliet wrote:
> "Noah Roberts" <roberts.noah@gmail.com> wrote in message
> news:1146161322.269395.183190@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.

0
roberts.noah (1664)
4/27/2006 7:06:16 PM
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.

0
roberts.noah (1664)
4/27/2006 7:17:12 PM
Remon van Vliet skrev:

> "Alf P. Steinbach" <alfps@start.no> wrote in message
> news:4bchkeF112d1iU1@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

0
4/27/2006 7:18:59 PM
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.

0
roberts.noah (1664)
4/27/2006 7:19:47 PM
* Remon van Vliet:
> "Alf P. Steinbach" <alfps@start.no> wrote in message 
> news:4bchkeF112d1iU1@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.

-- 
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?
0
alfps (7389)
4/27/2006 7:25:12 PM
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.

0
roberts.noah (1664)
4/27/2006 7:26:12 PM
Roedy Green skrev:

> On Thu, 27 Apr 2006 10:43:36 GMT, Mishagam <noemail@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

0
4/27/2006 7:31:12 PM
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
> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.

0
4/27/2006 7:45:27 PM
In comp.lang.java.advocacy, Remon van Vliet
<remon@exmachina.nl>
 wrote
on Thu, 27 Apr 2006 20:40:42 +0200
<44511034$0$31643$e4fe514c@news.xs4all.nl>:
>
> "Martin Vejn�r" <avakar@volny.cz> wrote in message 
> news:e2r19d$vfr$1@ns.felk.cvut.cz...
>> The Ghost In The Machine wrote:
>>> [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
>
> Have you ever used Java and actually ran into an issue that requires RAII? 
>

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, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
4/27/2006 8:00:05 PM
In comp.lang.java.advocacy, Noah Roberts
<roberts.noah@gmail.com>
 wrote
on 27 Apr 2006 10:59:36 -0700
<1146160776.819744.6340@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?
>

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.

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
4/27/2006 8:00:05 PM
In comp.lang.java.advocacy, Remon van Vliet
<remon@exmachina.nl>
 wrote
on Thu, 27 Apr 2006 20:44:11 +0200
<44511104$0$31654$e4fe514c@news.xs4all.nl>:
>
> "Walter Bright" <walter@digitalmars-nospamm.com> wrote in message 
> news:DcednXD8q8lXkszZnZ2dnUVZ_vednZ2d@comcast.com...
>> Noah Roberts wrote:
>>> Roedy Green wrote:
>>>> On Thu, 27 Apr 2006 15:06:53 +0200, "Gernot Frisch" <Me@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
>
> What point am i missing if i mention the "finally" block in Java? 
>

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

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
4/27/2006 8:00:06 PM
Remon van Vliet <remon@exmachina.nl> wrote:
> 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
0
cdsmith (3862)
4/27/2006 8:11:05 PM
> Roedy Green wrote:
> > Mixing exception handling and memory management boggles the human
> > mind.

Noah Roberts <roberts.noah@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.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
4/27/2006 8:15:26 PM
Chris Smith wrote:
> > Roedy Green wrote:
> > > Mixing exception handling and memory management boggles the human
> > > mind.
>
> Noah Roberts <roberts.noah@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.

0
roberts.noah (1664)
4/27/2006 8:25:03 PM
Remon van Vliet wrote:
> 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
0
avakar (36)
4/27/2006 8:30:39 PM
Remon van Vliet wrote:
> "Walter Bright" <walter@digitalmars-nospamm.com> wrote in message 
> news:DcednXD8q8lXkszZnZ2dnUVZ_vednZ2d@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
> What point am i missing if i mention the "finally" block in Java? 

'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
www.digitalmars.com C, C++, D programming language compilers

0
walter24 (181)
4/27/2006 8:37:09 PM
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

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
0
walter24 (181)
4/27/2006 8:39:00 PM
In article <4450d21f$0$31654$e4fe514c@news.xs4all.nl>,
Remon van Vliet <remon@exmachina.nl> wrote:
>
>We're all aware Javascript is completely unrelated to Java right?

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 - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/27/2006 8:39:21 PM
In article <e2qmi5$sqg$1@solaris.cc.vt.edu>, Ben  <bescott1@vt.edu> wrote:
>
>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.

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/27/2006 8:42:21 PM
* 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.

-- 
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?
0
alfps (7389)
4/27/2006 8:48:04 PM
Bent C Dalager wrote:
> (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>.

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
0
walter24 (181)
4/27/2006 8:50:08 PM
In article <e2r9gn$137l$1@ns.felk.cvut.cz>,
Martin Vejn�r  <avakar@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.

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/27/2006 8:50:37 PM
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.

0
roberts.noah (1664)
4/27/2006 8:56:24 PM
In article <Uu-dnZmwD9Pgs8zZnZ2dneKdnZydnZ2d@comcast.com>,
Walter Bright  <walter@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 :-)

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/27/2006 8:58:04 PM
Alf P. Steinbach wrote:
> * 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.
0
walter24 (181)
4/27/2006 9:13:20 PM
"peter koch" <peter.koch.larsen@gmail.com> wrote in message 
news:1146165539.399808.297980@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 

0
owong (6178)
4/27/2006 9:30:44 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146160776.819744.6340@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 

0
owong (6178)
4/27/2006 9:34:06 PM
Remon van Vliet wrote:
> 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.
0
news261 (167)
4/27/2006 9:35:35 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146169503.894509.261390@e56g2000cwe.googlegroups.com...
>
> 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.
>
> Lots of silly statements but no backing.  "X is hard."  Meaningless.

    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 

0
owong (6178)
4/27/2006 9:37:37 PM
"peter koch" <peter.koch.larsen@gmail.com> wrote in message 
news:1146167127.505510.92440@i40g2000cwc.googlegroups.com...
>
> 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 

0
owong (6178)
4/27/2006 9:48:47 PM
Phlip wrote:
> 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
0
news261 (167)
4/27/2006 9:48:59 PM
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
>
> --
> #191, ewill3@earthlink.net
> Windows Vista.  Because it's time to refresh your hardware.  Trust us.

0
4/27/2006 9:51:39 PM
Oliver Wong skrev:

> "Noah Roberts" <roberts.noah@gmail.com> wrote in message
> news:1146160776.819744.6340@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.

Which ironically precludes writing the Java library in Java.

/Peter
> 
>     - Oliver

0
4/27/2006 9:57:19 PM
* Remon van Vliet:
> 
> 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.

-- 
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?
0
alfps (7389)
4/27/2006 10:01:48 PM
In article <1146175039.197565.109730@j33g2000cwa.googlegroups.com>,
peter koch <peter.koch.larsen@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.)

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/27/2006 10:04:29 PM
Chris Smith skrev:

> > Roedy Green wrote:
> > > Mixing exception handling and memory management boggles the human
> > > mind.
>
> Noah Roberts <roberts.noah@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
>
> --
> www.designacourse.com
> The Easiest Way To Train Anyone... Anywhere.
>
> Chris Smith - Lead Software Developer/Technical Trainer
> MindIQ Corporation

0
4/27/2006 10:16:11 PM
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?

0
roberts.noah (1664)
4/27/2006 10:24:59 PM
Noah Roberts schrieb:
> 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.


Are you sure that you know what byte code is?


Timo
0
timo.stamm (231)
4/27/2006 10:38:19 PM
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

0
4/27/2006 10:44:15 PM
On Fri, 28 Apr 2006 00:01:48 +0200, "Alf P. Steinbach"
<alfps@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.
0
4/27/2006 10:48:04 PM
On 27 Apr 2006 10:54:17 -0700, "Noah Roberts" <roberts.noah@gmail.com>
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. 
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 11:02:38 PM
Roedy Green skrev:

> On Fri, 28 Apr 2006 00:01:48 +0200, "Alf P. Steinbach"
> <alfps@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

> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.

0
4/27/2006 11:02:53 PM
Bent C Dalager wrote:

> 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.
0
walter24 (181)
4/27/2006 11:07:01 PM
On 27 Apr 2006 10:59:36 -0700, "Noah Roberts" <roberts.noah@gmail.com>
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.
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 11:13:06 PM
Bent C Dalager skrev:

> In article <1146175039.197565.109730@j33g2000cwa.googlegroups.com>,
> peter koch <peter.koch.larsen@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

>
> (No, it's not an important point.)
>
> Cheers
> 	Bent D
> --
> Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
>                                     powered by emacs

0
4/27/2006 11:15:34 PM
Roedy Green wrote:
> On 27 Apr 2006 10:54:17 -0700, "Noah Roberts" <roberts.noah@gmail.com>
> 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.

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

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

0
roberts.noah (1664)
4/27/2006 11:16:20 PM
* Roedy Green:
> On Fri, 28 Apr 2006 00:01:48 +0200, "Alf P. Steinbach"
> <alfps@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.

When a program uintentionally gobbles up memory, never releasing it, and 
never using it again, there is a memory leak.  So, you're not quibbling 
over terminology: you're using terminology to try to define that reality 
away.  Which would be utterly silly were it not that someone might 
believe it, and that someone evidently has believed it.

Your reference states:

   "In fact it is almost impossible to write a program that nullifies
   references to every object the instant it will never be needed again.
   So every program is guilty of minor packratting."

Apart from the lack of connection from premise to conclusion, that's not 
a fact, it's an excuse for sloppiness.  Trying to define the problem 
away by inventing new terminology and redefining old is more of the 
same, an extra, fallback excuse position for incompetence.  "Hey, it's 
not a memory leak, it's /packratting/ [or whatever], and besides 
[fallback excuse position], it's impossible to avoid, so there!"

Let's not discuss at that level, trying to pull the wool over things 
that are technically clear and trivial but perhaps not viewed as 
compatible with one's position.

It is possible to avoid memory leaks, it is possible to have them with 
or without automatic garbage collection, and it is possible to use 
garbage collection in C++, so the assumptions are all incorrect.

-- 
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?
0
alfps (7389)
4/27/2006 11:19:40 PM
On 27 Apr 2006 15:24:59 -0700, "Noah Roberts" <roberts.noah@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>Hey, my CPU will run C++ byte code natively but there are no CPU's that
>run Java source code...guess Java sucks then.

There are machines that run Java bytes codes directly.  But even such
machines have some microcode or other assembler assists to handle the
lowest levels.  see http://mindprod.com/jgloss/picojava.html

There is no equivalent to byte code in C++ that you as programmer see,
though there may be an intermediate triple form internal to the
compiler using during optimisation. In C++ you compile straight to
platform machine code.  In Java you compile to a virtual machine, as
sort of idealized Java CPU  similar to a FORTH stack machine. From
then it can be interpreted, JITed, HotSpotted, statically compiled
etc.  Code is usually distributed in byte code format, often called
class file format or jars. The byte code format is
platform-independent.  The platform independencies are handled by a
platform-specific JVM (a program written usually in C++) and set of
standard class libraries. 

See http://mindprod.com/jgloss/compiler.html
http://mindprod.com/jgloss/jvm.html


-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 11:20:34 PM
In article <1146179734.846857.41850@g10g2000cwb.googlegroups.com>,
peter koch <peter.koch.larsen@gmail.com> wrote:
>
>
>Large parts of the C++ libraries are implemented in C++.

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

>> 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? ;-)

It's just an observation. Since Java always compiles to one specific
instruction set that can be implemented in hardware with relative
ease, it doesn't need to rely on non-Java components at all.

You could still make it perform differently on different platforms but
I am not sure why that is important at all.

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/27/2006 11:21:07 PM
On 27 Apr 2006 12:31:12 -0700, "peter koch"
<peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
someone who said :

>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!

come on. There are alternate notations that generate the same
assembler code.  That is a legacy wart, not a feature.
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 11:22:23 PM
In article <1146178973.117822.223530@v46g2000cwv.googlegroups.com>,
peter koch <peter.koch.larsen@gmail.com> wrote:
>
>
>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.

Swing is rather notorious for this. If you don't remember to call
"dispose()" on your GUI windows when you are done with them, they may
decide to stick around indefinately. This then also prevents the GC
from collecting everything that is referenced within the window, which
can be a lot.

>So Java is not
>just "allocate and forget" even when it comes down to "pure" memory.
>Again the advantage is with C++.

Depends a bit on what you mean by "pure" memory, but that is probably
too academic a debate to get into.

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/27/2006 11:25:22 PM
Roedy Green wrote:
> On 27 Apr 2006 15:24:59 -0700, "Noah Roberts" <roberts.noah@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
> >Hey, my CPU will run C++ byte code natively but there are no CPU's that
> >run Java source code...guess Java sucks then.
>
> There are machines that run Java bytes codes directly.  But even such
> machines have some microcode or other assembler assists to handle the
> lowest levels.  see http://mindprod.com/jgloss/picojava.html
>
> [blah blah blah JVM blah blah]

I know all about that.  Point is that it was asserted that C++ is not
as good as Java because Java binary code will run on some processors
but C++ source code won't.  This is just stupid...almost as stupid as
me having to point this out to you.

I definately hear a vacuum...

0
roberts.noah (1664)
4/27/2006 11:27:49 PM
On Thu, 27 Apr 2006 16:07:01 -0700 Walter Bright
<walter@digitalmars-nospamm.com> waved a wand and this message
magically appeared:

> 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.

OK, are there any stupid features in D? ;o)

-- 
http://www.munted.org.uk

Take a nap, it saves lives.
0
4/27/2006 11:28:00 PM
On Thu, 27 Apr 2006 22:48:59 +0100, Andrew McDonagh <news@andmc.com>
wrote, quoted or indirectly quoted someone who said :

>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

My ex boss, (one of the cleverest guys I have ever run into) has gone
gung ho on Ruby.  I did some work  documenting it.  It has much of the
appeal of Python, not making you ramble on for pages telling the
compiler things it can figure out on its own,  but on the other hand,
it seems a lot harder to figure out what a program is doing without
all the embedded type clues.

I wonder if someday we will have a language that lets you write like
Ruby, but that does all kinds of inferencing to tell you additional
info like types, potential bounds etc. but only when you want to see
it.



-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 11:34:11 PM
On Thu, 27 Apr 2006 20:42:21 +0000 (UTC), bcd@pvv.ntnu.no (Bent C
Dalager) wrote, quoted or indirectly quoted someone who said :

>Java-based CPUs for desktops have been tried I think, but it didn't
>take off.
 they ran too hot.

But there are all kinds of tiny CPUs that run JVM byte code directly
(or more precisely in microcode).

This approach saves a lot of RAM.  You don't need room for a JIT,
machine code, JITED machine code etc. All you have is nice compact
byte code.
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 11:37:07 PM
On 27 Apr 2006 12:45:27 -0700, "peter koch"
<peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
someone who said :

>
>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

Have you read the book?  Were in there on BIX when Stroustrup dropped
by for a month or two?
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/27/2006 11:38:57 PM
peter koch <peter.koch.larsen@gmail.com> wrote:
> > 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,

You seem to have missed the point... whether intentionally or otherwise, 
I don't know.  I am referring to how quickly the language can be 
understood; not how quickly software written in the language can be 
understood.

Nevertheless, since we're now talking about it:

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

// Java

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

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

I don't know where you got the so-called Java code you posted.  Whoever 
gave it to you, don't accept their Java code any longer.  Corrections 
aside from syntax and naming conventions include:

1. A constructor would throw an exception if initialization failed, so 
there is no need to check for that situation.

2. There is no need to catch exceptions within the finally block.  If 
the call to the clean-up method (e.g., dispose) fails, then an exception 
will be thrown, which is what you wanted anyway.  Although some people 
may choose to be picky about which of the two exceptions they wish to 
see in case doSomethingWith also failed, the C++ code doesn't handle 
that any better, so it's rather irrelevant here.

3. Removed the cast to an interface before calling dispose.  Upcasting 
of references is always dispensible in situations like this.  It appears 
to have been added for no other reason than to make the Java code look 
longer and uglier.  Actually, come to think of it, most of the code that 
was posted appears to have been added for that reason.

> Four simple lines of C++ becomes 21 lines of complex and convoluted
> Java-code.

Not sure how you're counting.  Nevertheless, the C++ code is clearly a 
little bit shorter, since the Java code needs to make cleanup explicit.

> So the Java func above is as easy to understand as the C++-one?? Come
> on - you do not really mean that.

No I don't mean that.  See above.

> 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.

How is that relevant?  Or is this just becoming a gripe list about 
languages, which you obviously don't understand to begin with?

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
4/27/2006 11:47:33 PM
Alex Buell wrote:
> On Thu, 27 Apr 2006 16:07:01 -0700 Walter Bright
> <walter@digitalmars-nospamm.com> waved a wand and this message
> magically appeared:
>
> > 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.
> 
> OK, are there any stupid features in D? ;o)

Its name?

0
roberts.noah (1664)
4/28/2006 12:04:12 AM
Noah Roberts wrote:
> 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.

You should just relax and look for pleasure ;) Having to obey these 
rules don't bother me at all. I doubt they bother much other Java 
programmers .

> 
>> 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.
Yes, you can use char[] (or byte[]), but as you said it has no support, 
so nobody uses it (as opposed to String, which is more heavily supported 
than any C/C++ strings version). It is VERY rare Java programmer who 
would spend time deciding which string representation to use. Everybody 
just uses String. And the beauty it - it is really very close to optimal 
choice. (as opposed too, for example, original Pascal 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.
>> 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.
Yes, it COULD easily become jail. The beauty of Java is that all choices 
are made so clever, that they are very close to optimal, and (I am sure 
for me) that advantage of not having to think about alternatives 
overweights possible gains from other choices.
It also makes different pieces of software much more compatible.
0
4/28/2006 12:25:18 AM
Alex Buell wrote:
> On Thu, 27 Apr 2006 16:07:01 -0700 Walter Bright
> <walter@digitalmars-nospamm.com> waved a wand and this message
> magically appeared:
> 
>> 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.
> 
> OK, are there any stupid features in D? ;o)

There was the bit basic type. It sure seemed like a good idea at the 
time <g>.
0
walter24 (181)
4/28/2006 12:26:41 AM
On Thu, 27 Apr 2006 20:09:24 +0200, Martin Vejn�r <avakar@volny.cz>
wrote, quoted or indirectly quoted someone who said :

>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 

The equivalent in Java is called finalizers. This is one of the  most
unsatisfactory parts of Java. One problem is guaranteeing ALL the
finalizers will be run on shutdown. The whole business is a bit flaky
and most people avoid using them.

You find ad hoc solutions, basically making a note to run some code on
exist.

In practice you find everyone using explicit procedural closes rather
than relying on any sort of finalizer.  Part of the reason is when you
do it manually, you free the resource sooner.
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 12:35:42 AM
Mishagam wrote:
> Noah Roberts wrote:
> > Mishagam wrote:

> >> 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.
> Yes, you can use char[] (or byte[]), but as you said it has no support,
> so nobody uses it (as opposed to String, which is more heavily supported
> than any C/C++ strings version). It is VERY rare Java programmer who
> would spend time deciding which string representation to use. Everybody
> just uses String. And the beauty it - it is really very close to optimal
> choice. (as opposed too, for example, original Pascal strings)

Interesting statement.  Just how close, in quantifiable values, to
optimal is it then?  Also, optimal in what way?

> >
> >> 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.
> Yes, it COULD easily become jail. The beauty of Java is that all choices
> are made so clever, that they are very close to optimal, and (I am sure
> for me) that advantage of not having to think about alternatives
> overweights possible gains from other choices.
> It also makes different pieces of software much more compatible.

Cleverness is subjective.  IMHO a lot of choices in Java where rather
dumb.

"Very close to optimal"...that seems like a fluff statement to me but
if you can quantify it I'll place more value in it.

Not having any choices doesn't seem to me to be that great.

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

0
roberts.noah (1664)
4/28/2006 12:38:17 AM
Martin Vejn�r wrote:
>(C# and D both support 
> RAII, but require the programmer to explicitly mark objects that should 
> be destroyed when leaving scope. Why?)

There must be a way to distinguish between an object to be have a longer 
lifetime than the current scope, and one to be destroyed when the 
current scope ends.

C++ has such a distinction by declaring using a '*'. D uses 'auto' to 
make a distinction.

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
0
walter24 (181)
4/28/2006 1:09:58 AM
On Fri, 28 Apr 2006 00:25:18 GMT, Mishagam <noemail@provider.com>
wrote, quoted or indirectly quoted someone who said :

>>  You make Java sound like a jail sentance.
>Yes, it COULD easily become jail. The beauty of Java is that all choices 
>are made so clever, that they are very close to optimal, and (I am sure 
>for me) that advantage of not having to think about alternatives 
>overweights possible gains from other choices.
>It also makes different pieces of software much more compatible.

To assert you independendence in Java, you don't rebel against the
trivial conventions.  Metaphorically speaking, you don't just wear a
nose ring to spite your parents.  You express your creativity at a
higher level.

The advantage is, it is pretty easy for any Java programmer to come
along and make sense of any of your low level code with almost no
effort.  All the low level stuff is done in the most boring idiomatic
standard way. The problem is always trying to figure out how it all
fits together..

This stereotypical coding style  also means you can dig into anybody
else's code with relatively little effort to learn from it or change
it or override it. Java coding is anything but tricky.

-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 1:54:39 AM
On 27 Apr 2006 16:27:49 -0700, "Noah Roberts" <roberts.noah@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>I know all about that.

You seem to have forgotten the difference between email and
newsgroups. These are public posts not done exclusively for your
highness's  entertainment.
..
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 2:11:06 AM
On Thu, 27 Apr 2006 16:07:01 -0700, Walter Bright
<walter@digitalmars-nospamm.com> wrote, quoted or indirectly quoted
someone who said :

>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.

My original peeve in Java was making byte signed.  It should have been
unsigned by default or there should have been an separate unsigned
primitive.

The original I/O library is a dog's breakfast. There is no
orthogonality.  It as though every class were written by a different
programmer confined in solitary.

Conversion methods lack a consistent naming convention.

Casting should have been a postfix operation.

I think we will come to regret type erasure in generics.  It has added
too much craziness and means you lose track of type info on
serialization. You can't even implement ArrayList with its features
without cheating.

For C++ I think I would nail down the names and sizes in bits of each
primitive the way Java does.  I would see what could be done to reduce
the number of addressing modes and operators. I would either define
some additional operators to use in overloading or allow users to
specify the new operators so that you don't have ambiguity.  C++
reuses the same operators for unrelated functions. I have always found
reusing the shift operator for I/O offensive.


-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 2:27:28 AM
Mishagam <noemail@provider.com> wrote:
> Yes, you can use char[] (or byte[]), but as you said it has no support, 
> so nobody uses it (as opposed to String, which is more heavily supported 
> than any C/C++ strings version). It is VERY rare Java programmer who 
> would spend time deciding which string representation to use.

True, true, except not quite.  There are certainly a number of choices 
in Java for representing a character sequence, depending on the 
requirements of the situation.  Sometimes, for example, it's more 
efficient to do string operations directly on a java.nio.CharBuffer for 
performance reasons.  The Swing JPasswordField class has a getPassword 
method that returns a char[] so that the information can be cleared from 
memory immediately after use.  String wouldn't work for that, because 
it's immutable... the information would survive in RAM or swap space 
until the GC reclaims the memory and allocates it to a new object.  
There are also java.lang.StringBuilder and the older 
java.lang.StringBuffer, for working with rapidly mutating strings in a 
way that minimizes copying of information.

Certainly not as bad as the situation in C++, since all of these 
alternatives are rare and (with the exception of the now-outdated 
StringBuffer class) necessitated by the varying requirements of 
different situations.  Nevertheless, it's not quite so clear-cut as it 
sounded from your post.

Of course, String is used 99.5% of the time, and there are easy ways to 
convert back and forth to/from the other options most of the time, and a 
common interface java.lang.CharSequence for all but the char[] 
possibility.

> It also makes different pieces of software much more compatible.

Bingo.  There are a lot of things that would make sense about freedom of 
choice if you only had to deal with your own code.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
4/28/2006 2:56:35 AM
Roedy Green wrote:
> For C++ I think I would nail down the names and sizes in bits of each
> primitive the way Java does.

D does that.

> I would see what could be done to reduce
> the number of addressing modes and operators. I would either define
> some additional operators to use in overloading or allow users to
> specify the new operators so that you don't have ambiguity.  C++
> reuses the same operators for unrelated functions. I have always found
> reusing the shift operator for I/O offensive.

I agree that using operators for unrelated functions is a bad design 
idea. Enshrining iostreams' use of << and >> for non-arithmetic purposes 
in the Standard was a worse idea, as it legitimizes such uses.

Operator overloading should be used only for the purpose of making user 
defined types work like built-in types.

-Walter Bright
www.digitalmars.com C, C++, D programming languages
0
walter24 (181)
4/28/2006 2:59:45 AM
Roedy Green <my_email_is_posted_on_my_website@munged.invalid> wrote:
> On Thu, 27 Apr 2006 20:09:24 +0200, Martin Vejn=E1r <avakar@volny.cz>
> wrote, quoted or indirectly quoted someone who said :
>=20
> >For some reason, you've put the most important statement in parentheses.=
=20
> >RAII is one of the two reasons I stick with C++. I don't know of any=20
> >other language that would support such concept. (C# and D both support=
=20
> >RAII, but require the programmer to explicitly mark objects that should=
=20
>=20
> The equivalent in Java is called finalizers. This is one of the  most
> unsatisfactory parts of Java. One problem is guaranteeing ALL the
> finalizers will be run on shutdown. The whole business is a bit flaky
> and most people avoid using them.

Sorry to jump in, but it's terribly misleading to call finalizers the=20
Java equivalent of RAII, even with all the qualification above.  Without=20
a doubt, try/finally is the Java equivalent of RAII, with all that is=20
implied by the asymmetry of the two.  I'd hate to see someone misled=20
into using a finalizer for this.

So what are finalizers good for?  Causing programs to run out of memory=20
by interfering with the garbage collector.  That, and pretty much=20
nothing else, except for MAYBE the possibility of displaying diagnostic=20
messages telling programmers that they forgot to close a resource, but=20
it would be best to disable that in a production build to avoid the=20
program correctness problems that finalizers imply; some kind of ant=20
magic, perhaps.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
4/28/2006 3:01:26 AM
Roedy Green <my_email_is_posted_on_my_website@munged.invalid> wrote:
> I think we will come to regret type erasure in generics.

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

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
4/28/2006 3:08:49 AM
On Thu, 27 Apr 2006 20:56:35 -0600, Chris Smith <cdsmith@twu.net>
wrote, quoted or indirectly quoted someone who said :

>Bingo.  There are a lot of things that would make sense about freedom of 
>choice if you only had to deal with your own code.

One of the more remarkable things about Java is how easily code from
different sources can be cobbled together.

Everything follows the same commenting conventions for example so you
can create Javadoc (automatically generated documentation) as a
unified whole.

This blending works because, for example a HashMap from Source A will
be the exact same beast as a HashMap from Source B.  The collection
can be passed freely back and forth without special glue.

Even when you use vendor specific implementations like SQL, JCE
(cryptography), JMF (media), JavaMail (email), vendor packages all
hook up using the same API.  Sun has a defined a standard pluggable
API for darn near everything. 

You can plug in a free implementation, or a high performance one, or a
special features one.  You can have different customers with different
service providers all running the exact same object code.

-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 3:42:58 AM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146180469.474449.76480@e56g2000cwe.googlegroups.com...
>> >Hey, my CPU will run C++ byte code natively but there are no CPU's that
>> >run Java source code...guess Java sucks then.
>>
>> There are machines that run Java bytes codes directly.  But even such
>> machines have some microcode or other assembler assists to handle the
>> lowest levels.  see http://mindprod.com/jgloss/picojava.html
>>
>> [blah blah blah JVM blah blah]
>
> I know all about that.  Point is that it was asserted that C++ is not
> as good as Java because Java binary code will run on some processors
> but C++ source code won't.  This is just stupid...almost as stupid as
> me having to point this out to you.
>
> I definately hear a vacuum...
>

If you think you are being witty, vacuum boy, you are falling short.

You can't use 6th grade rhetoric to try to convince a group of people who 
have been using Java for years that suddenly it "sucks" because you say so. 
You can't ignore counter arguments and expect people not to remember that 
one post ago you posted something grossly inaccurate.

You hide behind a thin veil of intelligence - but it only works among the 
ignorant.   Don't argue with experts about things you don't know.  You only 
succeed in making yourself look stupid.  Almost as stupid as me having to 
point this out to you.

--
LTP

:) 


0
4/28/2006 3:43:11 AM
"Roedy Green" <my_email_is_posted_on_my_website@munged.invalid> wrote in 
message news:dej2525dibbq6tkahr41794jimhciea5u4@4ax.com...
> 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.

And then pass it on to their children ;)

--
LTP

:) 


0
4/28/2006 3:49:30 AM
On Thu, 27 Apr 2006 19:59:45 -0700, Walter Bright
<walter@digitalmars-nospamm.com> wrote, quoted or indirectly quoted
someone who said :

>Operator overloading should be used only for the purpose of making user 
>defined types work like built-in types.

If operator overloading comes to Java, I would hope that matrix
overloaded plus would not use + (already confusingly meaning both
addition and concatenation See
http://mindprod.com/jgloss/gotchas.html#CONCATENATION
)

I would hope they would use a high Unicode character that looks like +
but would not easily be confused with it such as \u2a01

see http://mindprod.com/jgloss/unicode.html to view the glyphs.


-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 4:17:30 AM
On Thu, 27 Apr 2006 21:08:49 -0600, Chris Smith <cdsmith@twu.net>
wrote, quoted or indirectly quoted someone who said :

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

You and I have certainly, and a number of others. By "we" I mean the
entire Java community including Sun an  the inventors of generics.
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 4:18:40 AM
if you need power and performance from a language then you can expect
it to be simpler.

java scores in free and special purpose libraries.

0
4/28/2006 4:50:24 AM
if you need power and performance from a language then you can expect
it to be simpler.

java scores in free and special purpose libraries.

0
4/28/2006 4:51:00 AM
> Language design is complicated, with lots of tradeoffs. I don't know any 
> language that doesn't contain at least one stupid feature its designer 
> should have known better about.

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

-- 
Tony Morris
http://tmorris.net/ 


0
not147 (631)
4/28/2006 5:03:29 AM
Roedy Green wrote:
[snip]
> For C++ I think I would nail down the names and sizes in bits of each
> primitive the way Java does.
Why? If a CPU does not have a 32-bit integer or an 8-bit char or a IEEE
floating point you could then not write C++ programs on it. That seems
a severe restriction to me.
If you want to restrict yourself to "fixed-bit" ints, you simply need
to include a small include file (standard in C - if not available with
your compiler you can create one in no time).
>  I would see what could be done to reduce
> the number of addressing modes and operators.
It's time to come out of the bush. What adressing mode is not needed?
Anyone with a reasonable knowledge of C++ knows theyre all necesarry.
>I would either define
> some additional operators to use in overloading or allow users to
> specify the new operators so that you don't have ambiguity.  C++
> reuses the same operators for unrelated functions. I have always found
> reusing the shift operator for I/O offensive.

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

/Peter

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

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

0
4/28/2006 7:59:19 AM
Chris Smith wrote:
> peter koch <peter.koch.larsen@gmail.com> wrote:
>> //  C++
>> func()
>> {
>>    class_with_possible_ressource  cwpr;
>>    dosomethingwith(cwpr);
>> }
> 
> // Java
> 
> void func()
> {
>     ClassWithPossibleResource cwpr = new ClassWithPossibleResource();
> 
>     try
>     {
>         doSomethingWith(cwpr);
>     }
>     finally
>     {
>         cwpr.dispose();
>     }
> }

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

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

....and for this?

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

-- 
Martin
0
avakar (36)
4/28/2006 8:06:46 AM
In article <1146180469.474449.76480@e56g2000cwe.googlegroups.com>,
Noah Roberts <roberts.noah@gmail.com> wrote:
>
>I know all about that.  Point is that it was asserted that C++ is not
>as good as Java because Java binary code will run on some processors
>but C++ source code won't.

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

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/28/2006 8:37:22 AM
On 28 Apr 2006 00:59:08 -0700, "peter koch"
<peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
someone who said :

>> For C++ I think I would nail down the names and sizes in bits of each
>> primitive the way Java does.
>Why? If a CPU does not have a 32-bit integer or an 8-bit char or a IEEE
>floating point you could then not write C++ programs on it. That seems
>a severe restriction to me.


the two are not mutually exclusive.



You could do it by saying for example that int32 is a built-in type
and must have precisely 32 bits.  That does not stop you from having
some other type 
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 11:16:59 AM
On 28 Apr 2006 00:59:08 -0700, "peter koch"
<peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
someone who said :

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

C++ has more addressing modes than other languages except for
assemblers. So obviously they are not "necessary" in some absolute
sense. They are only necessary in the legacy sense.  Java has only one
addressing operator. 
-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 11:21:40 AM
On 28 Apr 2006 00:59:19 -0700, "al pacino" <siddharthdave84@gmail.com>
wrote, quoted or indirectly quoted someone who said :

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

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

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

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

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

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


-- 
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.
0
4/28/2006 11:40:16 AM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146179780.020113.118840@i39g2000cwa.googlegroups.com...
>
> Roedy Green wrote:
>> On 27 Apr 2006 10:54:17 -0700, "Noah Roberts" <roberts.noah@gmail.com>
>> 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.
>
> I don't see how your assertion applies to my quoted statement above.
> If you want to be understood I suggest you make your point more
> clearly.

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

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

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

    - Oliver 

0
owong (6178)
4/28/2006 2:37:29 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146184697.920387.49800@i40g2000cwc.googlegroups.com...
>
> I'm still looking for the can.  You listed all the thing Java *can't*
> do but haven't come with anything it can.  I don't see much advantage
> in *can't*.

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

    - Oliver 

0
owong (6178)
4/28/2006 2:39:55 PM
Oliver Wong wrote:
> See
> http://en.wikipedia.org/wiki/Psychological_projection

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

0
roberts.noah (1664)
4/28/2006 2:53:46 PM
In comp.lang.java.advocacy, peter koch
<peter.koch.larsen@gmail.com>
 wrote
on 27 Apr 2006 14:51:39 -0700
<1146174699.316975.65720@u72g2000cwu.googlegroups.com>:
>
> The Ghost In The Machine skrev:
>
> [snip]
>> "finally" is to RAII as manual transmission is to
>> automatic, from the looks of things.
>
> Not at all. RAII is to finally what a printing machine is to a pen.
> RAII simplifies a nontrivial and tedious task. Or do you always check
> for your objects being of the IDisposable type before deciding if you
> can leave their destruction to the garbage collector or if you will
> have to destroy them manually?
> If not - how will your program cope with classes that change?
> Also - how do you write generic code if you do not know if you will
> have to destroy your objects - except than by using run-time
> information?

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

[.sigsnip]

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
4/28/2006 3:00:04 PM
Martin Vejn=E1r <avakar@volny.cz> wrote:
> Could you please give me equivalent Java code for this...
>=20
> // C++
> func()
> {
>     class_with_possible_ressource  cwpr, cwpr2;
>     dosomethingwith(cwpr, cwpr2);
> }
>=20
> ...and for this?
>=20
> // C++
> func()
> {
>     class_with_possible_ressource  cwprs[1000];
>     dosomethingwith(cwprs);
> }

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

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
4/28/2006 3:09:40 PM
Mishagam wrote:
>>
>> 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.
>>
> Yes, large standard library helps. However Perl, Python, C# have 
> something close.
> I would give additional benefits (for me).
> a) You don't have to think should you include fields of have variables 
> as objects or references or pointers. It is decided for you usually 
> close to optimal way (closest to references).
> b) You don't have to bother to use auto_pointer (not working with 
> collections) or new delete or automatic destructor. It is decided for 
> you to use something like auto_ptr but much better.
> c) You don't have to decide about programming style. Sun provided 
> standard Java style.
> d) You don't have to decide about naming of files and classes - they are 
> the same.
> e) Logical package directory structure is forced on you.
> f) You don't have to choose between char *, string, CString ... - String 
> is better (or same) than either of them and it is only choice.
> g) you don't have to choose between long int, unsigned int, WORD, DWORD, 
> size_t .... - close to optimal choice if forced on you.
> h) You don't decide do you use internal or external functions 
> definitions, or do you use macro. - close to optimal choice if only one 
> possible.
> i) You don't have to decide if you use methods or define new operators. 
> Java choice is sometimes more verbose, but usually more clear.
> ...
> As you can guess, I can continue.
> Dropping all these choices first - makes programming easier, you have 
> less things to bother about, second - makes language smaller and more 
> easy to understand. Of course such approach could lead to very bad 
> language - but Java luckily has good design. And I thing C++ standard 
> committee just made bad design - introducing complexities which doesn't 
> add enough benefits to justify them.
And of course one of main items:
j: In Java you generally don't have to think how to report error - you 
throw Exception. In C++ you have different conventions for different 
systems changing over time. Some programs return NULL or 0 or -1 or 
SIGNALS ..., Microsoft COM programs returned HRESULT, lately C++ started 
using exceptions, but I am sure it is still only one of choices. I don't 
know, but doubt that C++ exceptions are as convenient as in Java. Of 
course this result of Java being designed later when exceptions already 
were well known .
0
4/28/2006 3:13:16 PM
Noah Roberts schrieb:
> Oliver Wong wrote:
>> See
>> http://en.wikipedia.org/wiki/Psychological_projection
> 
> Ahhh yes, the last ditch attack from the weak.

You are the only one who takes this discussion for a battle. Oliver 
didn't attack you, he just tried to help you realizing what is going on.


Timo
0
timo.stamm (231)
4/28/2006 3:22:42 PM
Roedy Green wrote:
> On 27 Apr 2006 10:59:36 -0700, "Noah Roberts" <roberts.noah@gmail.com>
> wrote, quoted or indirectly quoted someone who said :

> The big advantage of the Java approach is it FORCES you to write
> cleaner code.

> 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.

Another totally unrelated ad hominem.  You are obviously a very stupid
person.  I base this on your method of argument, your inability to
argue effectively, your inability to comprehend simple statements, and
your overwhelming supply of idiotic assumptions that have nothing,
whatsoever, to do with the purported evidence.

....there is ample evidence in your own statements to support that you
are in fact an idiot.

Interesting set in this last post of yours though...bring up Java's
nature to force you into doing something the way a set of people
decided where best and then call ME a fundamentalist - you have no
evidence to support that statement except the fact that there was a
famous and important Hebrew that shared my namesake but your own
statements lend some support to the argument that in fact you are very
likely a fundamentalist as well as a facist.

Irony can be a facinating thing.

Yes, this is also a personal attack having nothing to do with the
topic, however, instead of grasping at staws in an attempt to discredit
you based on assumed ansestry and upbringing I am simply pointing out
the fact that you already discredited yourself through your own words
and methods.

You loose, no question about it.  Of course this has no bearing on the
usefulness of the Java language...it only means you are a piss poor
advocate of it and not a particularly intelligent or nice person.

0
roberts.noah (1664)
4/28/2006 3:29:24 PM
"peter koch" <peter.koch.larsen@gmail.com> wrote in message 
news:1146177855.488879.211610@e56g2000cwe.googlegroups.com...

Very interesting post, Koch. I've snipped the parts I've agreed with, and am 
only including some concerns I have about C++ and clarifications on Java.

>
> I do not
> understand why each class MUST have its own file (unless you make that
> class a secondary citizen).

    Actually, only the top level public classes should be in their own 
files. Private classes, or nested classes, can be within any file. I suspect 
the reason why is primarily a pragmatic one: So that the classloader can 
easily locate the file that contains the bytecode for the classes and load 
them.

    It has some nice side effects. When I'm given someone else's code base, 
and I have a qualified class name, I always immediately know the full path 
to the source code file. I don't even have to browse a directory listing or 
anything like that.

>
> 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.

    I'm surprised unicode-stuff would appear as an advantage of C++ over 
Java. I won't dispute this, since I don't know enough about the state of C++ 
libraries, but I was under the impression that the lowest common denominator 
for C++ was ASCII, while the lowest common denominator for Java was the BMP 
(Basic Multilingual Plane) portion of unicode.

    I can't speak for others (e.g. archeologists, etc.), but I've never used 
characters characters outside the BMP. For example, while I am interested in 
writing text in English, French and Japanese, I am not interested in writing 
in cuneiform, cypriot, or byzantinne musical notation. So I've never had a 
problem with text in Java applications.

    However, I have had problems with C++ applications which assumed ASCII. 
WinAmp is one example. It has trouble handling the ID3 tags of my Japanese 
songs. iTunes seems a bit better at this. *SOMETIMES* it properly renders 
the kanji characters, but other times the track name will show up as a bunch 
of question marks.

    So I was under the impression that C++ support for unicode was behind 
Java, not ahead of it. I guess times have changed.

> 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.

    In its defense, I think the fact that the size of Java's primitive 
datatypes remains constant is a "good thing". If an when you want to use a 
64 bit datatype, you'd simply use "long" instead of "int". And I don't think 
there's any technical reason why, in a few years from now, if 128 bit were 
desired, a new datatype couldn't be added to Java to support that, without 
breaking any previous code (except possibly via the addition of a new 
keyword, which could no longer be used as a variable or method name).

    The company I work at, Castor Technologies, makes some money by porting 
C code from 32 bit platforms to 64 bit platforms. The fact that we're making 
money must mean it's too painful for our clients to do the migration 
themselves. I don't know if this C situation applies to C++ as well.

    - Oliver 

0
owong (6178)
4/28/2006 3:45:21 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146236026.546230.184480@e56g2000cwe.googlegroups.com...
>
> Oliver Wong wrote:
>> See
>> http://en.wikipedia.org/wiki/Psychological_projection
>
> Ahhh yes, the last ditch attack from the weak.  I grant you that it
> appears to be a big gun as there is no way to argue against it...any
> such attempt is of course also projecting.  But only the unintelligent
> cannot see it for what it is; I'll count you among them.
>

    Taken in context, you wrote:

<quote>
It is clear you
don't have any good, and valid, arguments for you assertion that Java
is better than C++.
</quote>

and I wrote

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

    Assuming that I am correct in thinking that Roedy did not make the 
assertion you claim he made, what would you call your behaviour, if not 
psychological projection?

    Alternatively, perhaps he DID make that assertion somewhere, and I had 
forgotten about it, or perhaps that particular message never arrived at my 
newsgroup server. If so, I apologize for any offense I may have caused you 
by suggesting that you might have been projecting.

    I don't mind if you think I'm "weak" or "unintelligent". My goal wasn't 
to earn your praise, but rather to point out a possible source of the 
apparent disagrement you're having with Roedy.

    - Oliver 

0
owong (6178)
4/28/2006 3:52:45 PM
Luc The Perverse wrote:

> You can't use 6th grade rhetoric to try to convince a group of people who
> have been using Java for years that suddenly it "sucks" because you say so.

Quote me saying that.

Simple request...

You won't...because you can't...because I never said it.

Come back when you can understand.

0
roberts.noah (1664)
4/28/2006 3:54:21 PM
The Ghost In The Machine wrote:
> In comp.lang.java.advocacy, peter koch

>> Not at all. RAII is to finally what a printing machine is to a pen.
>> RAII simplifies a nontrivial and tedious task. Or do you always check
>> for your objects being of the IDisposable type before deciding if you
>> can leave their destruction to the garbage collector or if you will
>> have to destroy them manually?
>> If not - how will your program cope with classes that change?
>> Also - how do you write generic code if you do not know if you will
>> have to destroy your objects - except than by using run-time
>> information?
> 
> How indeed?  The best Java can do in that department is
> a dispose() method (Swing) -- and that's not supported
> in the language, unlike C++'s virtual destructor.  finalize()
> is overridable but it's never clear exactly when that will
> be called.
I understand that RAII is basically use automatically called 
destructor's to dispose resources? I agree it is useful where it can be 
used.
It works if you work with objects as values, it doesn't work if you work 
with pointers or references. In such cases destructor can easily leave 
dangling pointer. If you work with references you are on your own, or 
have to duplicate something like reference counting or Java GC. I don't 
think you can work without using references in big program.
I think because of this STL mostly works (in examples) with value 
elements, and this creates a lot of problems - you cannot place 
descended class objects were you can place base objects, you have to 
deal with constructors, destructor's, copy constructors called in 
strange places, you waste memory and so on. Also, you have to have 
different generated code for different objects and use templates. And in 
Java one Collections library works OK with any object.
0
4/28/2006 3:57:11 PM
peter koch wrote:

> 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,

You are joking, Right?
0
4/28/2006 3:59:33 PM
Bent C Dalager wrote:
> In article <1146180469.474449.76480@e56g2000cwe.googlegroups.com>,
> Noah Roberts <roberts.noah@gmail.com> wrote:
> >
> >I know all about that.  Point is that it was asserted that C++ is not
> >as good as Java because Java binary code will run on some processors
> >but C++ source code won't.
>
> That is an assertion that may exist inside your head, but you will not
> actually find it in this thread.

Really?  I guess you never said the following then:

"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 :-) "

Now, that statement can only be talking about C++ source code as all
other forms of C++ come in the form of binary codes meant for execution
by a CPU or in the intermediate object form, also composed primarily of
CPU instructions but without enough total information to be a true
executable...sort like pulling a Java .class file out of its package
and trying to run it.

At any rate, no matter how you slice it...the comparison is purposfully
scewed, being a compiled form on one hand and something other than a
complete compilation on the other...it's a red herring, and not a very
good one.

0
roberts.noah (1664)
4/28/2006 4:00:52 PM
"Mishagam" <noemail@provider.com> wrote in message 
news:A_54g.5564$n13.1659@tornado.southeast.rr.com...
> And hopefully you even never heard of REALLY confusing stuff: Templates, 
> STL, functors - have you heard this word?

Templates: That's like Java generics, except more powerful/dangerous right?

STL: Er... Standard something library?

Functors: Heard the term, but don't know what it means. Something about 
function and pointers?

    - Oliver 

0
Oliver
4/28/2006 4:08:32 PM
Mishagam wrote:

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

Where to start...

First, are you really making the statement that Java supports no other
error reporting facility?  That is blatantly false but let's assume for
the moment that is true and ask ourselves if that is actually a good
thing...

Second...I'm not sure of you use of the term "program".  Are you really
claiming that a Java *program* can somehow report exceptions to the OS
or object running it in a way other than what the OS supports - signals
being one common facility?  If this is in fact true it would be an
interesting CAN I am not aware of.  C++ programs never "return NULL"
but do most commonly return an integer...0 meaning all is ok.  AFAIK
Java must do this too as many operating systems depend on the behavior.

Third...COM is not C++, it is a MS specific standard of coding a set of
functionality in ANY language that can be used from ANY language
capable of interacting with COM.  I do believe Java can be counted
among them but of course any such program instantly looses any platform
independance.

Finally, if you don't know then your doubts are meaningless.

0
roberts.noah (1664)
4/28/2006 4:11:23 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146240052.002903.31590@j33g2000cwa.googlegroups.com...
>
> Bent C Dalager wrote:
>> In article <1146180469.474449.76480@e56g2000cwe.googlegroups.com>,
>> Noah Roberts <roberts.noah@gmail.com> wrote:
>> >
>> >I know all about that.  Point is that it was asserted that C++ is not
>> >as good as Java because Java binary code will run on some processors
>> >but C++ source code won't.
>>
>> That is an assertion that may exist inside your head, but you will not
>> actually find it in this thread.
>
> Really?  I guess you never said the following then:
>
> "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 :-) "

    FWIW, on the very next line, Bent wrote "(No, it's not an important 
point.)"

    From the text you've quoted, even if you omit the parenthesis that 
follows, I don't see where Bent implies "C++ is not as good as Java". This 
is an example of what I was referring to when I mentioned psychological 
projection. Bent simply stated the fact that chips exist which process Java 
bytecode natively. From there, you inferred that Bent was making a statement 
about the merits of Java versus C++. I don't think Bent intended for that 
interpretation.

    - Oliver 

0
owong (6178)
4/28/2006 4:28:55 PM
Noah Roberts <roberts.noah@gmail.com> wrote:
> Really?  I guess you never said the following then:
> 
> "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 don't see any "C++ is not as good as Java because" in that paragraph.  
I took it as an indictment of the silliness of bringing up this hardware 
CPU/bytecode stuff in this conversation in the first place.  Maybe I 
misinterpreted something, but I really don't think so.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
4/28/2006 4:37:00 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146240683.016271.158050@j73g2000cwa.googlegroups.com...
>
> Where to start...
>
> First, are you really making the statement that Java supports no other
> error reporting facility?  That is blatantly false but let's assume for
> the moment that is true and ask ourselves if that is actually a good
> thing...

    Of course, it's possible in Java to declare a method as returning an 
int, and then using various codes for reporting status (e.g. 0 means 
everything is OK, -1 means something bad happened, etc.), however if you 
actually write Java code like this, you will probably be ridiculed. It's 
like those conventions people brought up earlier and were complained as 
being "can'ts" or "straightjackets" of Java. You *CAN* return error codes. 
It's just that most Java programmers don't. It's considered bad form.

>
> Second...I'm not sure of you use of the term "program".  Are you really
> claiming that a Java *program* can somehow report exceptions to the OS
> or object running it in a way other than what the OS supports - signals
> being one common facility?  If this is in fact true it would be an
> interesting CAN I am not aware of.  C++ programs never "return NULL"
> but do most commonly return an integer...0 meaning all is ok.  AFAIK
> Java must do this too as many operating systems depend on the behavior.

    If the OS expects specific return values as the primary mechanism for 
exception reporting, I fail to see how Java, C++, or any other language and 
their conventions are relevant. If you had a Java-centric OS, the OS might 
simply expect "nothing" (in the same way that you expect nothing from a void 
method) when everything is working normally, and expect exceptions when 
something bad happens. I believe BlueJ does something like this: 
http://www.bluej.org/

    And for what it's worth, the main method of a Java program is declared 
to return void. I.e.:

public static void main(String args[])

    If you wish to signal an error to the OS, you would usually use the 
"Runtime.exit(int status)" method. See 
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#exit(int)

    - Oliver 

0
owong (6178)
4/28/2006 4:39:12 PM
Oliver Wong wrote:
> "Noah Roberts" <roberts.noah@gmail.com> wrote in message
> news:1146240052.002903.31590@j33g2000cwa.googlegroups.com...
> >
> > Bent C Dalager wrote:
> >> In article <1146180469.474449.76480@e56g2000cwe.googlegroups.com>,
> >> Noah Roberts <roberts.noah@gmail.com> wrote:
> >> >
> >> >I know all about that.  Point is that it was asserted that C++ is not
> >> >as good as Java because Java binary code will run on some processors
> >> >but C++ source code won't.
> >>
> >> That is an assertion that may exist inside your head, but you will not
> >> actually find it in this thread.
> >
> > Really?  I guess you never said the following then:
> >
> > "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 :-) "
>
>     FWIW, on the very next line, Bent wrote "(No, it's not an important
> point.)"

If you are correct in what you point out below then it is not only not
important it is completely meaningless.

>
>     From the text you've quoted, even if you omit the parenthesis that
> follows, I don't see where Bent implies "C++ is not as good as Java". This
> is an example of what I was referring to when I mentioned psychological
> projection. Bent simply stated the fact that chips exist which process Java
> bytecode natively.

And that none exist to process C++ "instructions".

 From there, you inferred that Bent was making a statement
> about the merits of Java versus C++. I don't think Bent intended for that
> interpretation.

Well perhaps he wasn't infering Java was thus better than C++ but he
was certainly stating that this was something Java does that C++
doesn't.  Either way it is a meaningless comparison between compiled
Java vs. an apparently less than compiled form of C++.

0
roberts.noah (1664)
4/28/2006 4:40:06 PM
In comp.lang.java.advocacy, Mishagam
<noemail@provider.com>
 wrote
on Fri, 28 Apr 2006 15:57:11 GMT
<rXq4g.21857$Sa1.2309@tornado.southeast.rr.com>:
> The Ghost In The Machine wrote:
>> In comp.lang.java.advocacy, peter koch
>
>>> Not at all. RAII is to finally what a printing machine is to a pen.
>>> RAII simplifies a nontrivial and tedious task. Or do you always check
>>> for your objects being of the IDisposable type before deciding if you
>>> can leave their destruction to the garbage collector or if you will
>>> have to destroy them manually?
>>> If not - how will your program cope with classes that change?
>>> Also - how do you write generic code if you do not know if you will
>>> have to destroy your objects - except than by using run-time
>>> information?
>> 
>> How indeed?  The best Java can do in that department is
>> a dispose() method (Swing) -- and that's not supported
>> in the language, unlike C++'s virtual destructor.  finalize()
>> is overridable but it's never clear exactly when that will
>> be called.
> I understand that RAII is basically use automatically called 
> destructor's to dispose resources? I agree it is useful where it can be 
> used.

The little I've studied the issue indicates it's more
than that.  Apparently, the general idea is that a resource
can be destructed at any time, and in a human-predictable
fashion.  (This includes during exceptions.)

C++ destructors here are merely a means to an end.

> It works if you work with objects as values, it doesn't work if you work 
> with pointers or references.

Java has neither pointers nor references (although one could consider
any Object a pointer to some sort of data structure, really, and
any Object function parameter is passed by reference, allowing
modification methods and/or field assignments to that parameter).

Personally, I prefer smart pointers in C++, when I
use pointers at all, and tend to use reference counts.
(std::auto_ptr<> is IMO a horrid hack.)  There are a number of
problems with reference counts, though; the main one is the
"floating loop" problem.

> In such cases destructor can easily leave 
> dangling pointer. If you work with references you are on your own, or 
> have to duplicate something like reference counting or Java GC. I don't 
> think you can work without using references in big program.
> I think because of this STL mostly works (in examples) with value 
> elements, and this creates a lot of problems - you cannot place 
> descended class objects were you can place base objects, you have to 
> deal with constructors, destructor's, copy constructors called in 
> strange places, you waste memory and so on. Also, you have to have 
> different generated code for different objects and use templates. And in 
> Java one Collections library works OK with any object.

Depends on the Object and the Collection.  TreeMap, for instance,
cannot work with Objects that aren't Comparables without a
Comparator.

I don't see major problems in this area, though, except that
the List interface requiring implementation of a get by index
is a little weird.

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
4/28/2006 5:00:05 PM
In comp.lang.java.advocacy, Mishagam
<noemail@provider.com>
 wrote
on Fri, 28 Apr 2006 15:59:33 GMT
<FZq4g.21858$Sa1.9467@tornado.southeast.rr.com>:
> peter koch wrote:
>
>> 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,
>
> You are joking, Right?

I think he's serious, but then RAII may or may not be a big issue.  I
for one can't tell at this point.

The typical usage paradigm is opening a file:

[a] normal case.

File f = ...; // optional
FileInputStream fs = new FileInputStream(f);

....

fs.close();

[b] with exception handling.

File f = null;
FileInputStream fs = null;

try
{
    f = ...;
    fs = new FileInputStream(f);
    doSomething(fs);
}
catch(Exception ex)
{
    log.error("Oops", ex);
}
finally
{
    if(fs != null) try { fs.close(); } catch(Exception ex2) {}
}

I've seen prettier but the general idea is clear enough.

In C++:

{
    std::ifstream ifs("pathname");
    doSomething(ifs);
}

is far simpler; if an exception is thrown std::ifstream::~ifstream
is also guaranteed to be called.  However, I have no idea what

{

    std::ifstream ifs1("pathname");
    std::ifstream ifs2(ifs1);
    doSomething(ifs1);
    doSomething(ifs2);
}

or

{

    std::ifstream ifs1("pathname");
    std::ifstream ifs2("path2");

    ifs1 = ifs2;

    doSomething(ifs1);
    doSomething(ifs2);
}

are intended to do; the most logical would be the C++ equivalent
of dup2().  In Java, one runs into object aliasing issues:

FileInputStream fs1 = ...;
FileInputStream fs2 = fs1;

in the foregoing fs1 and fs2 refer to *the same object*.  This is either
a bug or a feature.

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
4/28/2006 6:00:12 PM
In comp.lang.java.advocacy, Oliver Wong
<owong@castortech.com>
 wrote
on Fri, 28 Apr 2006 16:08:32 GMT
<46r4g.181$zn1.135@edtnps90>:
> "Mishagam" <noemail@provider.com> wrote in message 
> news:A_54g.5564$n13.1659@tornado.southeast.rr.com...
>> And hopefully you even never heard of REALLY confusing stuff: Templates, 
>> STL, functors - have you heard this word?
>
> Templates: That's like Java generics, except more powerful/dangerous right?
>
> STL: Er... Standard something library?

Standard Template Library.  Includes, among other things,

std::string
std::map
std::hashmap
std::set
std::hashset

>
> Functors: Heard the term, but don't know what it means. Something about 
> function and pointers?
>
>     - Oliver 
>


-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
The
4/28/2006 6:00:13 PM
Andrew McDonagh wrote:

> go Ruby ..Go Ruby...Go Ruby

Ruby:

 - a cheap imitation of Smalltalk that stretches
     too far, all the way to Perl. (And don't get 
     me started about Perl!)
 - syntax crippled by an early design decision
     to make parens on method calls () optional.
     this has since been adjusted, leaving the 
     language whitespace-sensitive
 - the require('module') command dumps everything
     into your module, even if you don't want it,
     even if it causes a circular dependency
 - if you name your class the same as some other
     class, somewhere, then they become one class!
 - a dynamic and interpreted model that makes 
     compiling and optimizing absolutely impossible
 - permits a super-terse style that everyone
     exploits to show off

Java:

 - write once debug everywhere
 - forgets everything on all its CLASSPATHs at
    the drop of a hat
 - projects must depend on fragile and 
    programmer-hostile tools, like ANT,
    that make easy things hard and hard
    things absurd
 - impersonates the worst of C++ - typecasts
    for simple containers, two different kinds
    of type to store a stupid Integer, multiple
    String classes, and last but least generics!
 - arrays aren't really arrays. But they really
    are. Kinda.
 - static typing, to flatter Pascal with a vain
    impersonation that, instead, forces you to
    break typesafety just to get anything done
 - everything must be inside a class. You can 
    still write object-disoriented crap, but at 
    least it's inside a class!
 - pretends you broke something if your file
    name differs from your class name. Figure
    it out, stoopid!
 - when a smart editor like Eclipse can finish
    every line for you, it makes you wonder 
    what the language is _there_ for!
 - adds keywords, like interface, based on
    someone else's preconceived notion of good
    design. Not keywords like 'virtual', based
    on what the hardware will actually do
 - comes with an advertising campaign capable
    of making inexperienced programmers think
    all this cruft is "lean and elegant".
 - provides whole new categories of bugs, based
    on zombie objects, non-deterministic
    destructors, redundant finally blocks, all
    under the excuse we are saving you from all
    the C++ memory errors that a good standard
    library implementation will save you from
    anyway
 - instead of providing a narrow and reasonable
    implementation of multiple inheritance like
    C++ (or an alternate "mixin" system like 
    Ruby) we instead get endless lectures, 
    endlessly repeated by newbies, about why
    real programmers don't need multiple
    inheritance of implementation
 - at least C++ makes some of the benefits
    of dynamic typing available. Java instead
    enforces such a narrow view of static
    typing that you can't even simulate
    those benefits
 - why the >F---< does Netbeans ask me where
    the _same_ JAR files are, _each_ time I 
    launch it???
 - a marketing campaign that teaches newbies
    that a language is good if only smart
    people can figure out how to use it
 - GUIs require block closures and dynamic 
    typing. But what language does your boss
    tell you to write the GUI in???

C++ (deep breath):
 - where in memory do you want to 
    accidentally jump today?
 - the only smart pointer that could pass
    the 97 committee was one so primitive
    and broken that its copy constructor
    changes the copied-from object!
 - mutable; because constancy is enforced
    at compile time, not runtime, yet it
    _could_ exploit hardware support
 - strings, strings, and more strings. The
    ISO Standard string came so late in the
    language's history that every serious 
    library has its own (multiple) string
    classes
 - what the >F---< does imbue() do???
 - void main is neither illegal nor legal!
    Some, but not all, compiler-specific
    extensions use a __ prefix
 - of course RAII can be better than
    redundant finally blocks. But _all_
    these systems are cheap imitations
    of the Execute Around Pattern, which
    requires block closures, so objects
    can clean themselves up, exception-
    safely, deterministically, and
    _without_ elaborate destructors
 - the majority of the glitches and
    common bugs when implementing code
    in C++ happen because it's designed
    to be efficiently compiled by a 
    simple compiler. A reinvented language
    could make better use of modern
    compiler technology
 - teachers, bosses, and colleagues make
    us use the language because it's 
    popular, even for inappropriate 
    situations. This newsgroup gets
    a dozen questions per month asking
    how to do something that a scripting
    language can do
 - you can do an "Applet" in C++ trivially,
    using ActiveX. And because C++ has no
    security model to speak of, anyone
    using your applet exposes their browser
    to gawd-knows-what-else is out there...
 - how many here have _ever_ written a 
    program with _absolutely_ no undefined
    behavior? How many _know_ they did??
 - when folks say C++ is portable, they
    mean the _compiler_ ports easily to 
    other platforms. By marrying your 
    statements to the metal, a C++
    implementation forces you to 
    consider _endless_ portability issues
    at port time
 - the exception handling model is so
    complex it makes me wonder if Bjarne
    Stroustrup actually determined how to
    write exception-safe programs when
    he invented the language

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
4/28/2006 6:14:07 PM
Phlip wrote:
>  - the majority of the glitches and
>     common bugs when implementing code
>     in C++ happen because it's designed
>     to be efficiently compiled by a 
>     simple compiler.

A C++ compiler is probably the most complex of all language compilers.
0
walter24 (181)
4/28/2006 8:04:53 PM
Walter Bright wrote:

> Phlip wrote:
>>  - the majority of the glitches and
>>     common bugs when implementing code
>>     in C++ happen because it's designed
>>     to be efficiently compiled by a
>>     simple compiler.
> 
> A C++ compiler is probably the most complex of all language compilers.

There's a better way to state that item, because otherwise C++ wouldn't
suck, and we all know that's not the case.

Newbie: Why can't I put template bodies in .cpp files?

Guru: Because the linker doesn't have a compiler in it.

Newbie: Why doesn't the linker have a compiler in it?

And so on...

I grant you the point a C++ compiler is complex, but in a bad way...

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
4/28/2006 8:09:28 PM
Phlip wrote:
[snip]

And the moral is....


We should all be using Objective-C.

0
roberts.noah (1664)
4/28/2006 8:15:53 PM
Noah Roberts wrote:

> We should all be using Objective-C.

Maaster!! You have created ... a monster!!

Yes, Igor! By tr-r-ransplanting Smalltalk's virtual dispatch system into zee
skull of my cadaver of zee C language, zee virtual messages shall move zee
arms and zee legs of structs and ints! Und zey vill doo our biddings!! Vee
vill rool zee wooorld!! Mwha-ha-haha!

Vhat vill you call heem, Maaster??

I vill call him... Id.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
4/28/2006 8:23:23 PM
"Walter Bright" <walter@digitalmars-nospamm.com> wrote in message 
news:-8-dnXEYjff76M_ZRVn-ig@comcast.com...
> Phlip wrote:
>>  - the majority of the glitches and
>>     common bugs when implementing code
>>     in C++ happen because it's designed
>>     to be efficiently compiled by a simple compiler.
>
> A C++ compiler is probably the most complex of all language compilers.

    COBOL is pretty difficult to parse. It isn't an LL(*) language, like C, 
C++ and Java are.

    - Oliver 

0
owong (6178)
4/28/2006 8:39:58 PM
["Followup-To:" header set to comp.lang.java.programmer.] On
2006-04-27, peter koch penned:
>
>
> 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.

Odd.  At my first company we did java apps that ran in Solaris and
Windows with almost no trouble.  The only real trouble we ran into was
when someone hard coded things like "C:".

That was several years ago, when java was much more immature, too.

-- 
monique

Help us help you:
http://www.catb.org/~esr/faqs/smart-questions.html
0
spam444 (617)
4/28/2006 9:25:20 PM
Phlip wrote:
> Walter Bright wrote:
> 
>> Phlip wrote:
>>>  - the majority of the glitches and
>>>     common bugs when implementing code
>>>     in C++ happen because it's designed
>>>     to be efficiently compiled by a
>>>     simple compiler.
>> A C++ compiler is probably the most complex of all language compilers.
> 
> There's a better way to state that item, because otherwise C++ wouldn't
> suck, and we all know that's not the case.
> 
> Newbie: Why can't I put template bodies in .cpp files?
> 
> Guru: Because the linker doesn't have a compiler in it.

You can put template bodies in separate .d files in the D programming 
language, and it works with a standard linker.

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
0
walter24 (181)
4/28/2006 10:20:27 PM
Walter Bright wrote:

> You can put template bodies in separate .d files in the D programming
> language, and it works with a standard linker.
> 
> -Walter Bright
> www.digitalmars.com C, C++, D programming language compilers

I'm not yet qualified to put your D on the Suck list, but rest assured I
will soon work to correct the situation. However...

....Can D treat classes as objects?

That's about the most complex and subtle programming concept that I
understand, so I tend to harp on it too much. ;-)

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
4/28/2006 10:27:09 PM
Phlip wrote:
> Walter Bright wrote:
>
> > You can put template bodies in separate .d files in the D programming
> > language, and it works with a standard linker.
> >
> > -Walter Bright
> > www.digitalmars.com C, C++, D programming language compilers
>
> I'm not yet qualified to put your D on the Suck list, but rest assured I
> will soon work to correct the situation.

Common, just look at its name.  Can't possibly be anything but suck
with a name like "D".

0
roberts.noah (1664)
4/28/2006 10:31:16 PM
In article <MPG.1ebbf29811d33ee598969c@news.astraweb.com>,
Chris Smith  <cdsmith@twu.net> wrote:
>
>I don't see any "C++ is not as good as Java because" in that paragraph.  
>I took it as an indictment of the silliness of bringing up this hardware 
>CPU/bytecode stuff in this conversation in the first place.  Maybe I 
>misinterpreted something, but I really don't think so.

It was a bit of that, and also a bit of a stab at the language zealots
from both sides of the fence: this is the sort of uninteresting trivia
that seems to interest them a lot for some reason.

A bit trollish of me, perhaps, but then this _is_ a troll thread :-)

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
4/28/2006 10:33:14 PM
On 28 Apr 2006 15:31:16 -0700 "Noah Roberts" <roberts.noah@gmail.com>
waved a wand and this message magically appeared:

> > I'm not yet qualified to put your D on the Suck list, but rest
> > assured I will soon work to correct the situation.
> 
> Common, just look at its name.  Can't possibly be anything but suck
> with a name like "D".

That name reminds me of being back at school, getting my prep graded on
a scale between A (good), to F (fail). Getting a D meant you made a very
poor effort... ;o)

-- 
http://www.munted.org.uk

Take a nap, it saves lives.
0
4/28/2006 10:33:43 PM
On Fri, 2006-04-28 at 13:04 -0700, Walter Bright wrote:
> 
> 
> A C++ compiler is probably the most complex of all language compilers.
> 

Not Befunge?

0
jmcgill1 (238)
4/28/2006 10:42:38 PM
Walter Bright wrote:
> Phlip wrote:
> 
>> Walter Bright wrote:
>>
>>> Phlip wrote:
>>>
>>>>  - the majority of the glitches and
>>>>     common bugs when implementing code
>>>>     in C++ happen because it's designed
>>>>     to be efficiently compiled by a
>>>>     simple compiler.
>>>
>>> A C++ compiler is probably the most complex of all language compilers.
>>
>>
>> There's a better way to state that item, because otherwise C++ wouldn't
>> suck, and we all know that's not the case.
>>
>> Newbie: Why can't I put template bodies in .cpp files?
>>
>> Guru: Because the linker doesn't have a compiler in it.
> 
> 
> You can put template bodies in separate .d files in the D programming
> language, and it works with a standard linker.
> 
You can do the same with a number of C++ compilers, whether or not they
support the 'export' keyword.

-- 
Ian Collins.
0
ian-news (10155)
4/28/2006 10:45:41 PM
Noah Roberts wrote:
> Mishagam wrote:
> 
>> And of course one of main items:
>> j: In Java you generally don't have to think how to report error - you
>> throw Exception. In C++ you have different conventions for different
>> systems changing over time. Some programs return NULL or 0 or -1 or
>> SIGNALS ..., Microsoft COM programs returned HRESULT, lately C++ started
>> using exceptions, but I am sure it is still only one of choices. I don't
>> know, but doubt that C++ exceptions are as convenient as in Java. Of
>> course this result of Java being designed later when exceptions already
>> were well known .
> 
> Where to start...
> 
> First, are you really making the statement that Java supports no other
> error reporting facility?  That is blatantly false but let's assume for
> the moment that is true and ask ourselves if that is actually a good
> thing...
You can of course return 0 or null or false or something on error, but 
most programmers and libraries use Exceptions. Exceptions in Java are 
very convenient, there is usually no sense not to use them.
> 
> Second...I'm not sure of you use of the term "program".  

I made and error. I meant procedure, not program.

Are you really
> claiming that a Java *program* can somehow report exceptions to the OS
> or object running it in a way other than what the OS supports - signals
> being one common facility?  If this is in fact true it would be an
> interesting CAN I am not aware of.  C++ programs never "return NULL"
> but do most commonly return an integer...0 meaning all is ok.  AFAIK
> Java must do this too as many operating systems depend on the behavior.
> 

I was writing about how called procedure can inform calling procedure 
about error or some condition, like broken network connection. All I 
wrote about C was also about communicating errors to calling procedure. 
I don't know exactly how JVM informs OS how program ended - (I thing it 
is value in System.exit( code )) this is not what I was talking about 
(and not most central part in programming, if you are not programming 
mainly in Unix shell).
> Third...COM is not C++, it is a MS specific standard of coding a set of
> functionality in ANY language that can be used from ANY language
> capable of interacting with COM.  I do believe Java can be counted
> among them but of course any such program instantly looses any platform
> independance.
I programmed on COM on C/C++, and all COM procedures use HRESULT as 
error code. Other often used COM Language is VB, where error codes 
apparently are somehow hidden - I don't know VB very well. Java cannot 
directly use COM, probably there exist JNI Libraries allowing 
communications Java <-> COM through native calls.
> 
> Finally, if you don't know then your doubts are meaningless.
> 
0
4/29/2006 12:05:34 AM
On Fri, 28 Apr 2006 18:14:07 +0000, Phlip wrote:

> Andrew McDonagh wrote:
> 
>> go Ruby ..Go Ruby...Go Ruby
> 
> Ruby:
> 
> Java:

> C++ (deep breath):

makes me miss Fortran-4 and LSI-11 assembler even more so... :^(

Long live the PDP11 !

cause everybody knows that architectures should be based on octal values,
right?


0
noone6680 (136)
4/29/2006 12:17:07 AM
Noah Roberts wrote:
> Mishagam wrote:
>> Noah Roberts wrote:
>>> Mishagam wrote:
> 
>>>> 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.
>> Yes, you can use char[] (or byte[]), but as you said it has no support,
>> so nobody uses it (as opposed to String, which is more heavily supported
>> than any C/C++ strings version). It is VERY rare Java programmer who
>> would spend time deciding which string representation to use. Everybody
>> just uses String. And the beauty it - it is really very close to optimal
>> choice. (as opposed too, for example, original Pascal strings)
> 
> Interesting statement.  Just how close, in quantifiable values, to
> optimal is it then?  Also, optimal in what way?
For strings main feature is convenience. You can easily define strings, 
you can easily make operations, especially concatenations, with strings. 
You don't bother about allocating pieces of string. You can use strings 
as keys. You can easily convert other type to strings, and simple types 
from strings. Strings should be efficient.
C char * strings are very fast, have decent support and great 
improvement over Pascal strings (not to mention Fortran), especially 
because of sprintf / sscanf functions, but you always have to bother 
where to allocate strings, and C strings are not safe.
STL string and CString are slower than C, but safe. They have some 
support, but Java strings are supported better. You also always have to 
choose which string to use, and different programs and libraries use 
different strings. For example, part of pain of COM programming on 
Windows was very frequent need to convert strings from one format to 
another.
So Java String look better than any C/C++ strings version. This is what 
I call close to optimal.
> 
>>>> 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.
>> Yes, it COULD easily become jail. The beauty of Java is that all choices
>> are made so clever, that they are very close to optimal, and (I am sure
>> for me) that advantage of not having to think about alternatives
>> overweights possible gains from other choices.
>> It also makes different pieces of software much more compatible.
> 
> Cleverness is subjective.  IMHO a lot of choices in Java where rather
> dumb.
> 
> "Very close to optimal"...that seems like a fluff statement to me but
> if you can quantify it I'll place more value in it.
> 
> Not having any choices doesn't seem to me to be that great.
> 
> I'm still looking for the can.  You listed all the thing Java *can't*
> do but haven't come with anything it can.  I don't see much advantage
> in *can't*.
Generally you can do anything on any general purpose computer language. 
I can say you can write safe programs on Java, you can do GC on Java.
There is also very long list of things that is more easy to do on Java 
(almost everything). For example.
Connect to databases.
Use http connections, requests and responses.
Write string to clipboard.
Write servlet  (comparing to use CGI programs or ISAPI module).
and so on.

> 
0
4/29/2006 12:30:21 AM
Ian Collins wrote:

> You can do the same with a number of C++ compilers, whether or not they
> support the 'export' keyword.

Newbie: Why do I have to define classes twice?

Guru: You don't define them twice. You declare them in header
          files, define them in header files, and define their methods
          in implementation files.

Newbie: Why do I have to de...scribe classes three times?

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! 


0
phlipcpp (2771)
4/29/2006 12:40:11 AM
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 :-)
Because C++ is compiled language, and has no defined intemediate 
language, it is very difficult to see what Computer that "support C++ 
instructions natively" should look like. For Java there is defined 
bytecode and so you can make computer to run this bytecode directly.
This doesn't mean that Java is better, but it does mean that speed 
advantage of C++ wouldn't exist (it if still exists with modern JIT JVM) 
on such computers.
0
4/29/2006 12:42:05 AM
Alex Buell wrote:

> That name reminds me of being back at school, getting my prep graded on
> a scale between A (good), to F (fail). Getting a D meant you made a very
> poor effort... ;o)

They already make that joke on their web page.

I tried its source on the train ride home, and d2html.d struck me as one 
huge function, with absurdly deep nested blocks. Couldn't it have been a 
table?

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


0
phlipcpp (2771)
4/29/2006 12:42:07 AM
Mishagam skrev:

> Noah Roberts wrote:
>
[snip]
> > Third...COM is not C++, it is a MS specific standard of coding a set of
> > functionality in ANY language that can be used from ANY language
> > capable of interacting with COM.  I do believe Java can be counted
> > among them but of course any such program instantly looses any platform
> > independance.
> I programmed on COM on C/C++, and all COM procedures use HRESULT as
> error code. Other often used COM Language is VB, where error codes
> apparently are somehow hidden - I don't know VB very well. Java cannot
> directly use COM, probably there exist JNI Libraries allowing
> communications Java <-> COM through native calls.
This is absurd. If you program against a COM interface you use a
HRESULT. This is so in ANY language - even Java. Unless Java does not
support COM programming, of course.
> >
> > Finally, if you don't know then your doubts are meaningless.
> >

/Peter

0
4/29/2006 12:50:37 AM
Alex Buell wrote:
> On Thu, 27 Apr 2006 16:07:01 -0700 Walter Bright
> <walter@digitalmars-nospamm.com> waved a wand and this message
> magically appeared:
> 
>> 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.
> 
> OK, are there any stupid features in D? ;o)
> 
It is not honest to ask about stupid feature of language nobody knows 
much about.
Everybody knows about C++ stupid features, because it had it's period of 
fame when everybody programmed on it. The same for Java.
I think the fact that nobody uses D means suggests that it has not only 
one stupid feature, but a lot of stupid features.
0
4/29/2006 12:51:15 AM
Phlip wrote:
> Ian Collins wrote:
> 
> 
>>You can do the same with a number of C++ compilers, whether or not they
>>support the 'export' keyword.
> 
> 
> Newbie: Why do I have to define classes twice?
> 
> Guru: You don't define them twice. You declare them in header
>           files, define them in header files, and define their methods
>           in implementation files.
> 
> Newbie: Why do I have to de...scribe classes three times?
> 
Because it makes then easier to read?

I've been doing a lot of PHP lately and the biggest problem I have is
not being able to see all of the methods on one page.  So I end up
creating an interface for each class as a documentation tool.

-- 
Ian Collins.
0
ian-news (10155)
4/29/2006 1:16:36 AM
Mishagam skrev:

[snip]
> I understand that RAII is basically use automatically called
> destructor's to dispose resources?
That is correct. When the lifetime of an object, its destructor is
automatically called. I do not need to say that this is regardless of
whether an exception is thrown or not.
> I agree it is useful where it can be
> used.
> It works if you work with objects as values, it doesn't work if you work
> with pointers or references.
This is correct - and it should not work in such cases.
>  In such cases destructor can easily leave
> dangling pointer.
I do not know that statement.
> If you work with references you are on your own, or
> have to duplicate something like reference counting or Java GC.
Replace references with pointers here and I agree.
> I don't
> think you can work without using references in big program.
(I assume again that you mean pointers here.)You surely can. Modern C++
uses almost no raw pointers. Instead it uses objects called smart
pointers and these could well rely on reference counting.
> I think because of this STL mostly works (in examples) with value
> elements, and this creates a lot of problems - you cannot place
> descended class objects were you can place base objects, you have to
> deal with constructors, destructor's, copy constructors called in
> strange places, you waste memory and so on.
STL is value-based and rightly so in my opinion. For places where
value-based objects don't fit (your example with a container that
should hold elements of a type or descendants of that type), you simply
store a smart pointer.
>  Also, you have to have
> different generated code for different objects and use templates.
This is partly true. By having different code generated for each type
you get far better runtime performance so this is a good thing. As an
example, the sort in C++ is three times faster than the C qsort for
double. This is primarily a result of having code inlined.
Still, sometimes code might be shared across different template-types.
E.g. std::vector<int> could share much of its code with
std::vector<unsigned>.
> And in
> Java one Collections library works OK with any object.
If you do not use Java generics you basically end up with runtime type
checks. This is not nice.

/Peter

0
4/29/2006 1:29:25 AM
Oliver Wong wrote:
> "Mishagam" <noemail@provider.com> wrote in message 
> news:A_54g.5564$n13.1659@tornado.southeast.rr.com...
>> And hopefully you even never heard of REALLY confusing stuff: 
>> Templates, STL, functors - have you heard this word?
> 
> Templates: That's like Java generics, except more powerful/dangerous right?
Basically right. They were in C++ much earlier than Java Generics 
arrived, however.
> 
> STL: Er... Standard something library?
Standard Template Library - main standard library for C++.
> 
> Functors: Heard the term, but don't know what it means. Something about 
> function and pointers?
I never used, but read about them. It is really funny part of STL - 
overwriting () operator for packing things like custom compare, if I 
correctly remember. I was really shocked when I have seen them in STL book.
> 
>    - Oliver
0
Mishagam
4/29/2006 1:30:59 AM
peter koch wrote:
> Mishagam skrev:
>> It works if you work with objects as values, it doesn't work if you work
>> with pointers or references.
> This is correct - and it should not work in such cases.
>>  In such cases destructor can easily leave
>> dangling pointer.
> I do not know that statement.
I mean here you pass pointer or C++ reference to your object, this 
pointer is saved somewhere, and then you destruct you object. Then 
pointer in pointing to basically random position. I name such pointer 
dangling. I thought it is standard name for such pointers.

>> If you work with references you are on your own, or
>> have to duplicate something like reference counting or Java GC.
> Replace references with pointers here and I agree.
You can work with C++ pointers or references. Both of them can have 
problem of pointing to no longer existing objects.

>> I don't
>> think you can work without using references in big program.
> (I assume again that you mean pointers here.)You surely can. Modern C++
> uses almost no raw pointers. Instead it uses objects called smart
> pointers and these could well rely on reference counting.
I, unfortunately, not very fluent in C++ smart pointers. I know that COM 
objects used reference counting, and it was major pain in ass. However I 
didn't use smart pointers there - mey be they would alliviate problem?
If you use reference counting you cannot be sure when you object gets 
destructed, you cannot use RAII, you  can get memory leak because 
somebody forgot to delete reference. You are in the same position as in 
Java, except that GC works with cyclic references.
>> I think because of this STL mostly works (in examples) with value
>> elements, and this creates a lot of problems - you cannot place
>> descended class objects were you can place base objects, you have to
>> deal with constructors, destructor's, copy constructors called in
>> strange places, you waste memory and so on.
> STL is value-based and rightly so in my opinion. 
Doesn't moving around full objects instead of just pointers to them feel 
wasteful?
For places where
> value-based objects don't fit (your example with a container that
> should hold elements of a type or descendants of that type), you simply
> store a smart pointer.
I never actively used smart pointers. I looked on Web - there are 
actually a lot of different types of smart pointers in C++ (as usual, 
Java has one close to optimal choice). I suspect it is another hole, not 
"simply store a smart pointer".
>>  Also, you have to have
>> different generated code for different objects and use templates.
> This is partly true. By having different code generated for each type
> you get far better runtime performance so this is a good thing. As an
> example, the sort in C++ is three times faster than the C qsort for
> double. This is primarily a result of having code inlined.
Yes, if in C you call custom function for every comparison of doubles it 
should be slower. I bet if you sort array of structures C++ speed up 
will disappear. Actually in Java they wrote separate sort procedures for 
native types - because there are only about 8 native types it is 
manageable. But all objects are sorted by the same procedure. And they 
don't have to copy objects (with calling copy constructor and 
destructor's) on each operation. I would be tempted to write benchmark 
program, but feel too lazy.
> Still, sometimes code might be shared across different template-types.
> E.g. std::vector<int> could share much of its code with
> std::vector<unsigned>.
>> And in
>> Java one Collections library works OK with any object.
> If you do not use Java generics you basically end up with runtime type
> checks. This is not nice.
Even in Java with generics I am almost sure there is only one compiled 
library for all (Object) types.
> 
> /Peter
> 
0
4/29/2006 4:29:53 AM
peter koch wrote:
> Mishagam skrev:
> 
>> Noah Roberts wrote:
>>
> [snip]
>>> Third...COM is not C++, it is a MS specific standard of coding a set of
>>> functionality in ANY language that can be used from ANY language
>>> capable of interacting with COM.  I do believe Java can be counted
>>> among them but of course any such program instantly looses any platform
>>> independance.
>> I programmed on COM on C/C++, and all COM procedures use HRESULT as
>> error code. Other often used COM Language is VB, where error codes
>> apparently are somehow hidden - I don't know VB very well. Java cannot
>> directly use COM, probably there exist JNI Libraries allowing
>> communications Java <-> COM through native calls.
> This is absurd. If you program against a COM interface you use a
> HRESULT. This is so in ANY language - even Java. Unless Java does not
> support COM programming, of course.
What is absurd? I suspect you don't know what you are talking about. Are 
you sure VB programmers use HRESULT? I cite "You, as the programmer, 
never see the HRESULT; Visual Basic hides its existence to make your 
code more manageable. " from
http://support.microsoft.com/kb/q189134/How To Raise an Error in Visual 
Basic From Your C DLL
Does in mean VB doesn't support COM? Now that is absurd. VB is one of 
main users of COM objects.
Even on C++ Microsoft likes to hide COM objects behind special kind of 
smart pointers that convert HRESULT to exceptions.
Java, on the other side, doesn't support COM, but it is possible to 
write library to communicate between Java and COM (as I wrote).
>>> Finally, if you don't know then your doubts are meaningless.
>>>
> 
> /Peter
> 
0
4/29/2006 4:48:52 AM
Phlip wrote:

>  - impersonates the worst of C++ - typecasts
>     for simple containers, two different kinds
>     of type to store a stupid Integer, multiple
>     String classes, 
What are you talking about?
and last but least generics!
>  - arrays aren't really arrays. But they really
>     are. Kinda.
>  - static typing, to flatter Pascal with a vain
>     impersonation that, instead, forces you to
>     break typesafety just to get anything done.
Types are checked on each casting, but in run-time. You begin whining 
about absence of dynamic typing few lines lower.
>  - adds keywords, like interface, based on
>     someone else's preconceived notion of good
>     design. Not keywords like 'virtual', based
>     on what the hardware will actually do
What 'interface' means is much more clear than what  'virtual' means. 
Nobody is interested much in what hardware actually do.
>  - provides whole new categories of bugs, based
>     on zombie objects, non-deterministic
>     destructors, redundant finally blocks, all
>     under the excuse we are saving you from all
>     the C++ memory errors that a good standard
>     library implementation will save you from
>     anyway
Call me when memory errors will disappear from C++. STL and templates 
are so complex, I bet they actually increase number of errors.

>  - why the >F---< does Netbeans ask me where
>     the _same_ JAR files are, _each_ time I 
>     launch it???
It feels the sucker ;)
>  - a marketing campaign that teaches newbies
>     that a language is good if only smart
>     people can figure out how to use it
>  - GUIs require block closures and dynamic 
>     typing. But what language does your boss
>     tell you to write the GUI in???
> 
0
4/29/2006 5:08:15 AM
Mishagam wrote:
> Noah Roberts wrote:
> > Mishagam wrote:
> >
> >> And of course one of main items:
> >> j: In Java you generally don't have to think how to report error - you
> >> throw Exception. In C++ you have different conventions for different
> >> systems changing over time. Some programs return NULL or 0 or -1 or
> >> SIGNALS ..., Microsoft COM programs returned HRESULT, lately C++ started
> >> using exceptions, but I am sure it is still only one of choices. I don't
> >> know, but doubt that C++ exceptions are as convenient as in Java. Of
> >> course this result of Java being designed later when exceptions already
> >> were well known .
> >
> > Where to start...
> >
> > First, are you really making the statement that Java supports no other
> > error reporting facility?  That is blatantly false but let's assume for
> > the moment that is true and ask ourselves if that is actually a good
> > thing...
> You can of course return 0 or null or false or something on error, but
> most programmers and libraries use Exceptions. Exceptions in Java are
> very convenient, there is usually no sense not to use them.

No different than C++ there then.  The only thing that could apply is
there are people who insist on using the old C ways for everything and
pretend not to use exceptions.  Usually they come up with some make
believe argument about performance but they are usually arguing from
ignorance with small nuggets of fact from something some expert said 20
years ago.

Frankly, unless you do everything with the old C functions and don't
use a single class out of the std lib you ARE using exceptions in
C++...some people just don't get it though.

At any rate, the languages have little difference in this area from
what I can tell.  Slightly different approaches but in effect the same
idea.

0
roberts.noah (1664)
4/29/2006 6:28:49 AM
Mishagam wrote:

> What is absurd? I suspect you don't know what you are talking about. Are
> you sure VB programmers use HRESULT? I cite "You, as the programmer,
> never see the HRESULT; Visual Basic hides its existence to make your
> code more manageable. " from
> http://support.microsoft.com/kb/q189134/How To Raise an Error in Visual
> Basic From Your C DLL
> Does in mean VB doesn't support COM? Now that is absurd. VB is one of
> main users of COM objects.
> Even on C++ Microsoft likes to hide COM objects behind special kind of
> smart pointers that convert HRESULT to exceptions.
> Java, on the other side, doesn't support COM, but it is possible to
> write library to communicate between Java and COM (as I wrote).

Going off on a bit of a tanget here now.  The real point wrt to COM is
that COM is a red herring.  We could discuss the various ways in which
some API's hide the facts of COM from the programmer but what bearing
does it have on the conversation?  None that I can see.

COM is an MS creation meant for use on their systems, with their
languages, and their toolsets.  Any other use is asking for
unpleasantries.  VB and the .NET languages make COM easy because they
are both creations of the same company with the same target platforms;
in these languages a COM object looks like any other object.  I doubt
Java has a very nice COM interface and I know working with it in C++ is
less than ideal.

At any rate, COM is unimportant.  It's use in this argument was
fallacy.  We should move on.

0
roberts.noah (1664)
4/29/2006 6:41:58 AM
Mishagam wrote:

> >> I don't
> >> think you can work without using references in big program.
> > (I assume again that you mean pointers here.)You surely can. Modern C++
> > uses almost no raw pointers. Instead it uses objects called smart
> > pointers and these could well rely on reference counting.
> I, unfortunately, not very fluent in C++ smart pointers. I know that COM
> objects used reference counting, and it was major pain in ass. However I
> didn't use smart pointers there - mey be they would alliviate problem?
> If you use reference counting you cannot be sure when you object gets
> destructed, you cannot use RAII, you  can get memory leak because
> somebody forgot to delete reference. You are in the same position as in
> Java, except that GC works with cyclic references.

That comparison is quite a stretch.  GC is, as far as I know and as far
as Java implements it, totally unaccessable to the programmer.  Can you
force the GC to delete anything?  There may be certain times when you
can expect the GC to do some cleanup but you cannot guarantee it nor
can you control it.  On the other hand, refrence counting using smart
pointers is 100% programmer controlled.  You _can_ force something to
get deleted and you know for certain that the object will get deleted
the instant the last reference to it leaves scope or is destroyed.
This is a totally dependable action that is 100% guaranteed.  With the
GC you can have no references to an object but it hangs out until who
knows when and then gets destroyed sometime after the last reference to
it leaves scope or is destroyed..../sometime/ after.

Does that mean it works if the programmer doesn't work?  No.  But it
means that RAII _can_ be depended on to perform the actions it has been
described so long as the programmer does their job.  Requiring correct
code is not unreasonable and in reality RAII is quite effective at
keeping a lot of bugs out of code so long as it is followed.

> > STL is value-based and rightly so in my opinion.
> Doesn't moving around full objects instead of just pointers to them feel
> wasteful?

As is said, you can store pointers.  They don't have to be smart but
then you do have to be.  If you use smart pointers you can be dumb and
get away with much more.

> For places where
> > value-based objects don't fit (your example with a container that
> > should hold elements of a type or descendants of that type), you simply
> > store a smart pointer.
> I never actively used smart pointers. I looked on Web - there are
> actually a lot of different types of smart pointers in C++ (as usual,
> Java has one close to optimal choice).

Java has no such choice.  Java doesn't need smart pointers as it has no
pointers to begin with.  Nor could it support a construct remotely
resembling a smart pointer.  Half of the benefits of smart pointers are
the fact that they look like any other pointer and can be used anywhere
a normal pointer would be...this requires operator overloading.

A smart pointer is nothing else but an RAII wrapper around a gatherable
resource that must be released.  Most of the time we are speaking of
memory and some dynamically allocated object.  There are several types
because there are several targets.  One pointer does not fit all
situations.  For instance, should it check to be sure the object exists
before dereferencing it?  Does it need some sort of shared process
locking mechanism?  Not everyone wants these things....choice is good
in this case as it allows one to choose the correct mechanism for their
needs.  There is no "most optimal" choice here.

I can't parse the rest of the post.

0
roberts.noah (1664)
4/29/2006 7:03:31 AM
Phlip wrote:

> Ruby: [snipped]
> Java: [snipped]
> C++ (deep breath): [snipped -- reluctantly]

Good rant.  Enjoyable.  Thanks.

I'd pick different points to, um, pick on in all three languages, but -- what
the hell -- it's still just shooting fish in a barrel.

    -- chris



0
chris.uppal (3980)
4/29/2006 7:03:52 AM
Ian Collins wrote:
> Phlip wrote:
>> Ian Collins wrote:
>>
>>
>>> You can do the same with a number of C++ compilers, whether or not they
>>> support the 'export' keyword.
>>
>> Newbie: Why do I have to define classes twice?
>>
>> Guru: You don't define them twice. You declare them in header
>>           files, define them in header files, and define their methods
>>           in implementation files.
>>
>> Newbie: Why do I have to de...scribe classes three times?
>>
> Because it makes then easier to read?
> 
> I've been doing a lot of PHP lately and the biggest problem I have is
> not being able to see all of the methods on one page.  So I end up
> creating an interface for each class as a documentation tool.
> 

This is very easily over come by using a  decent IDE which shows all the 
method signatures - all the time.  eclipse, intellj, etc...

but then again some strange people still think vi is good.....

0
news261 (167)
4/29/2006 7:41:45 AM
"Larry Barowski" <MElarrybar-AT-eng_DOT_auburnANOTHERDOTeduEND> wrote in 
message news:n8CdnefeSthEhs7ZnZ2dnUVZ_vSdnZ2d@comcast.com...
>
> "Noah Roberts" <roberts.noah@gmail.com> wrote in message 
> news:1146255353.271415.47500@y43g2000cwc.googlegroups.com...
>>
>> Phlip wrote:
>> [snip]
>>
>> And the moral is....
>>
>>
>> We should all be using Objective-C.
>>
>
> That's a good one, but it's funnier this way:
>
> And the moral is...
>
>
> We should all be using Visual Basic.

Oh . . .was it a joke before?

I get it now

--
LTP

:) 


0
4/29/2006 8:55:35 AM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146255353.271415.47500@y43g2000cwc.googlegroups.com...
>
> Phlip wrote:
> [snip]
>
> And the moral is....
>
>
> We should all be using Objective-C.
>

That's a good one, but it's funnier this way:

And the moral is...


We should all be using Visual Basic.


0
Larry
4/29/2006 8:59:04 AM
On Sat, 29 Apr 2006 03:59:04 -0500 "Larry Barowski"
<MElarrybar-AT-eng_DOT_auburnANOTHERDOTeduEND> waved a wand and this
message magically appeared:

> We should all be using Visual Basic.

Death to all VB programmers and the buggers that dreamed up the
language!


NB: It's a JOKE!
-- 
http://www.munted.org.uk

Take a nap, it saves lives.
0
4/29/2006 10:13:22 AM
On Sat, 2006-04-29 at 11:13 +0100, Alex Buell wrote:
> 
> 
> NB: It's a JOKE! 

Production work I did in VB2.0 when it was new, is still in production.
I think that code might be nearly old enough to vote.

0
jmcgill1 (238)
4/29/2006 10:24:06 AM
James McGill wrote:
> On Sat, 2006-04-29 at 11:13 +0100, Alex Buell wrote:
>>
>> NB: It's a JOKE! 
> 
> Production work I did in VB2.0 when it was new, is still in production.
> I think that code might be nearly old enough to vote.
> 

and your point is?

longevity of use is no indicator of a 'good' language - its simply that 
the application does what it was supposed to OR the company is unwilling 
to rewrite for some reason if it isn't doing as its supposed to.
0
news261 (167)
4/29/2006 11:07:17 AM
Phlip <phlip2005@gmail.com> writes:

>  - write once debug everywhere

Less of an issue now than back in the horrid days of applets.

>  - forgets everything on all its CLASSPATHs at
>     the drop of a hat

There's no such thing as CLASSPATHs in Java, only ClassLoaders, which
may or may not use something called CLASSPATH. I have luckily not run
into a case where a ClassLoader suddenly forgot all its classes.

>  - impersonates the worst of C++ - typecasts
>     for simple containers, two different kinds
>     of type to store a stupid Integer, multiple
>     String classes, and last but least generics!

Well the latter cancels out the first. Pick your poison I guess.

>  - arrays aren't really arrays. But they really
>     are. Kinda.

They are. But they're not C/C++ "syntactic sugar for pointers".

>  - pretends you broke something if your file
>     name differs from your class name. Figure
>     it out, stoopid!

You can have lots of classes in a source file that differ from the
file name, but none of them can be top-level public ones.

>  - when a smart editor like Eclipse can finish
>     every line for you, it makes you wonder 
>     what the language is _there_ for!

Noone prevents you from using vi to write Java. Well, maybe the Emacs
tribalists do.

>  - adds keywords, like interface, based on
>     someone else's preconceived notion of good
>     design. Not keywords like 'virtual', based
>     on what the hardware will actually do

Language defines what is virtual or not. It's up to the (virtual)
hardware to comply.

>  - instead of providing a narrow and reasonable
>     implementation of multiple inheritance like
>     C++ (or an alternate "mixin" system like 
>     Ruby) we instead get endless lectures, 
>     endlessly repeated by newbies, about why
>     real programmers don't need multiple
>     inheritance of implementation

The syntax for multiple inheritance of implementation in Java is more
convoluted, but doable. (It involves delegate objects, nested member
classes if necessary etc.)

>  - at least C++ makes some of the benefits
>     of dynamic typing available. Java instead
>     enforces such a narrow view of static
>     typing that you can't even simulate
>     those benefits

Is that the "let's pretend this block of memory is something else"
stuff "inherited" from C's union and void*?

>  - GUIs require block closures and dynamic 
>     typing.

Whatever for? I've written GUIs in Java, and the Swing MVC system is
decent enough to use. Where do you need either of those?
0
jadedgamer (368)
4/29/2006 1:36:55 PM
Noah Roberts wrote:
> Mishagam wrote:
> 
>>>> I don't
>>>> think you can work without using references in big program.
>>> (I assume again that you mean pointers here.)You surely can. Modern C++
>>> uses almost no raw pointers. Instead it uses objects called smart
>>> pointers and these could well rely on reference counting.
>> I, unfortunately, not very fluent in C++ smart pointers. I know that COM
>> objects used reference counting, and it was major pain in ass. However I
>> didn't use smart pointers there - mey be they would alliviate problem?
>> If you use reference counting you cannot be sure when you object gets
>> destructed, you cannot use RAII, you  can get memory leak because
>> somebody forgot to delete reference. You are in the same position as in
>> Java, except that GC works with cyclic references.
> 
> That comparison is quite a stretch.  GC is, as far as I know and as far
> as Java implements it, totally unaccessable to the programmer.  Can you
> force the GC to delete anything?  
You can call something like System.gc(). But if you want to be 100% sure 
that something happen you don't rely on gc, you use finally blocks.
There may be certain times when you
> can expect the GC to do some cleanup but you cannot guarantee it nor
> can you control it.  On the other hand, reference counting using smart
> pointers is 100% programmer controlled. 
If you have valuable resources other that memory, with reference 
counting they get called only when all pointers to it in all parts of 
program are explicitly closed. You have no help here from RAII, smart 
pointers or anything.
You have help from C++ only with one reference in one place in program 
(and in RAII object). Then you don't need reference at all you can use 
value object. Otherwise there is no help, it becomes worse than finally 
block.
  You _can_ force something to
> get deleted and you know for certain that the object will get deleted
> the instant the last reference to it leaves scope or is destroyed.
> This is a totally dependable action that is 100% guaranteed.  With the
> GC you can have no references to an object but it hangs out until who
> knows when and then gets destroyed sometime after the last reference to
> it leaves scope or is destroyed..../sometime/ after.
You can close object in finally block and be 100% sure that non-memory 
resources are freed. Then you can be 100% sure that GC will do it's best 
to provide you with memory. You also can be sure (not so in C++) that 
this memory isn't pointing to other active objects. (of course last part 
happen in C++ only if programmer made some error somewhere in program).
> 
> Does that mean it works if the programmer doesn't work?  No.  But it
> means that RAII _can_ be depended on to perform the actions it has been
> described so long as the programmer does their job.  Requiring correct
> code is not unreasonable and in reality RAII is quite effective at
> keeping a lot of bugs out of code so long as it is followed.
> 

>> For places where
>>> value-based objects don't fit (your example with a container that
>>> should hold elements of a type or descendants of that type), you simply
>>> store a smart pointer.
>> I never actively used smart pointers. I looked on Web - there are
>> actually a lot of different types of smart pointers in C++ (as usual,
>> Java has one close to optimal choice).
> 
> Java has no such choice.  Java doesn't need smart pointers as it has no
> pointers to begin with.  Nor could it support a construct remotely
> resembling a smart pointer.  Half of the benefits of smart pointers are
> the fact that they look like any other pointer and can be used anywhere
> a normal pointer would be...this requires operator overloading.
Ok, Java has references, which resemble C++ pointers, but are better. 
Java doesn't need smart pointers because references provide most of 
advantages of smart pointers.
> 
> A smart pointer is nothing else but an RAII wrapper around a gatherable
> resource that must be released.  
If you have several pointers (you insist on pointers, however C++ HAS 
references which are almost the same as pointers from this point of 
view) to the same object/resource, you cannot speak about RAII. Logic of 
releasing resource when going out of block doesn't work.
I can imagine you can hope that if you made all pointers to your object 
smart, and if you didn't pointed to your object from non RAII objects. 
Then you can be sure than when you stop your program (and went out of 
all blocks) you released all objects. If you had only one thread . But 
OS will release all your resources anyway.
If you have only one pointer you can just as well use value object.
Most of the time we are speaking of
> memory and some dynamically allocated object.  There are several types
> because there are several targets.  One pointer does not fit all
> situations.  For instance, should it check to be sure the object exists
> before dereferencing it?  Does it need some sort of shared process
> locking mechanism?  Not everyone wants these things....choice is good
> in this case as it allows one to choose the correct mechanism for their
> needs.  There is no "most optimal" choice here.
> 
> I can't parse the rest of the post.
> 
0
4/29/2006 1:46:53 PM
You made me think you code directly in binary machine instructions. At 
least that's your favorite language.

As for me, I'd dream to program in English, but someone is yet to invent 
an English compiler for me.

Regards,
Ben
0
benhongh (304)
4/29/2006 1:56:58 PM
benben wrote:
> You made me think you code directly in binary machine instructions. At 
> least that's your favorite language.
> 
> As for me, I'd dream to program in English, but someone is yet to invent 
> an English compiler for me.
> 
> Regards,
> Ben

already done - google Domain Specific languages
0
news261 (167)
4/29/2006 2:22:10 PM
On Sat, 29 Apr 2006 12:07:17 +0100 Andrew McDonagh <news@andmc.com>
waved a wand and this message magically appeared:

> > Production work I did in VB2.0 when it was new, is still in
> > production. I think that code might be nearly old enough to vote.
> > 
> 
> and your point is?
> 
> longevity of use is no indicator of a 'good' language - its simply
> that the application does what it was supposed to OR the company is
> unwilling to rewrite for some reason if it isn't doing as its
> supposed to.

And besides, VB 2.0 was released in 1992, so it's just a 14 year old
grumpy and grouchy teenager.

-- 
http://www.munted.org.uk

Take a nap, it saves lives.
0
4/29/2006 2:33:10 PM
Tor Iver Wilhelmsen wrote:

>>  - write once debug everywhere
>
> Less of an issue now than back in the horrid days of applets.

Ooh, I love it when they fight back.

>>  - arrays aren't really arrays. But they really
>>     are. Kinda.
>
> They are. But they're not C/C++ "syntactic sugar for pointers".

There is no language C/C++.

Arrays in C++ convert to pointers very easily, but they are still 
first-class objects. They have a complete type, including a length, and all 
these can be manipulated by ... generics.

>>  - when a smart editor like Eclipse can finish
>>     every line for you, it makes you wonder
>>     what the language is _there_ for!
>
> Noone prevents you from using vi to write Java. Well, maybe the Emacs
> tribalists do.

You missed the point. If an editor can parse your code and predict what you 
are trying to do, then the language could too. The language itself could 
finish these lines, and all I'd have to do is start them.

Read:

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

log4j's src folder has 31,764 lines of code.

log4r's src folder has 2,071 lines of code.

That's not just fewer lines; it's an order of magnitude fewer, for the exact 
same feature set.

Please don't say "that's because Java programmers write more professional 
comments..."

>>  - adds keywords, like interface, based on
>>     someone else's preconceived notion of good
>>     design. Not keywords like 'virtual', based
>>     on what the hardware will actually do
>
> Language defines what is virtual or not. It's up to the (virtual)
> hardware to comply.

Again you missed the point. 'virtual' is a weak, primitive keyword that I 
can use to assemble a class or an interface. I can control how concrete and 
how abstract the class is. Just because I _should_ create interfaces doesn't 
mean the language should _force_ me to.

You cannot legislate morality. (You _can_, however, legislate immorality!)

>>  - at least C++ makes some of the benefits
>>     of dynamic typing available. Java instead
>>     enforces such a narrow view of static
>>     typing that you can't even simulate
>>     those benefits
>
> Is that the "let's pretend this block of memory is something else"
> stuff "inherited" from C's union and void*?

Write an Any or Variant class in Java.

>>  - GUIs require block closures and dynamic
>>     typing.
>
> Whatever for? I've written GUIs in Java, and the Swing MVC system is
> decent enough to use. Where do you need either of those?

You have insufficient experience with block closures.

A GUI should be event-driven. Block closures make those as easy as falling 
off a log. Most of the code you write in a static-typing OO language, for a 
GUI, is excess plumbing to route events to handlers, and then excess 
plumbing to convey state variables into handlers. Block closures simply turn 
that problem inside out. The language does the plumbing, and all you need to 
do is add the custom behaviors.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


0
phlipcpp (2771)
4/29/2006 3:31:29 PM
Alex Buell wrote:

> [A spanking] to all VB programmers and the buggers that dreamed up the
> language!

> Take a nap, it saves lives.

A 6-hour work day to all VB buggers.

As the mental clarity takes effect, they will ask "why am I debugging all 
the time instead of thinking?"

;-)

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! 


0
phlipcpp (2771)
4/29/2006 3:38:05 PM
Andrew McDonagh wrote:
> Ian Collins wrote:
>> Phlip wrote:
>>> Ian Collins wrote:
>>>
>>>
>>>> You can do the same with a number of C++ compilers, whether or not they
>>>> support the 'export' keyword.
>>>
>>> Newbie: Why do I have to define classes twice?
>>>
>>> Guru: You don't define them twice. You declare them in header
>>>           files, define them in header files, and define their methods
>>>           in implementation files.
>>>
>>> Newbie: Why do I have to de...scribe classes three times?
>>>
>> Because it makes then easier to read?
>>
>> I've been doing a lot of PHP lately and the biggest problem I have is
>> not being able to see all of the methods on one page.  So I end up
>> creating an interface for each class as a documentation tool.
>>
> 
> This is very easily over come by using a  decent IDE which shows all the 
> method signatures - all the time.  eclipse, intellj, etc...

And allow folding of areas you currently don't want to look at.
> 
> but then again some strange people still think vi is good.....
> 
0
4/29/2006 5:17:34 PM
"James McGill" <jmcgill@cs.arizona.edu> wrote in message 
news:1146264158.16908.17.camel@localhost.localdomain...
> On Fri, 2006-04-28 at 13:04 -0700, Walter Bright wrote:
>>
>>
>> A C++ compiler is probably the most complex of all language compilers.
>>
>
> Not Befunge?

    It's pretty easy to write a Befunge interpreter. To write a compiler, 
you could simply generate an executable that contains the interpreter as 
code, and the befunge source code as an embedded resource.

    - Oliver 

0
owong (6178)
5/1/2006 4:14:30 PM
*SNIP*

> That comparison is quite a stretch.  GC is, as far as I know and as far
> as Java implements it, totally unaccessable to the programmer.  Can you
> force the GC to delete anything?  There may be certain times when you
> can expect the GC to do some cleanup but you cannot guarantee it nor
> can you control it.  On the other hand, refrence counting using smart
> pointers is 100% programmer controlled.  You _can_ force something to
> get deleted and you know for certain that the object will get deleted
> the instant the last reference to it leaves scope or is destroyed.
> This is a totally dependable action that is 100% guaranteed.  With the
> GC you can have no references to an object but it hangs out until who
> knows when and then gets destroyed sometime after the last reference to
> it leaves scope or is destroyed..../sometime/ after.

Which is a problem because? You dont have to point out continuously that the 
GC doesnt allow exact control over cleaning up discarded objects. We all 
know that and consider that a good thing. What'd be more interesting is to 
finally hear a valid reason why it's actually a problem rather than an 
advantage.

>
> Does that mean it works if the programmer doesn't work?  No.  But it
> means that RAII _can_ be depended on to perform the actions it has been
> described so long as the programmer does their job.  Requiring correct
> code is not unreasonable and in reality RAII is quite effective at
> keeping a lot of bugs out of code so long as it is followed.

Why are you so stuck on wanting control over these kind of things? Are you 
under the impression you do a better job at manually alloc/deallocing memory 
and cleaning up objects than the latest generation Java GC will do? I'm 
getting a bit tired of all these unsupported assumptions. Either come with 
practical examples/facts or just agree to disagree. 


0
remon (167)
5/1/2006 4:16:24 PM
"Remon van Vliet" <remon@exmachina.nl> wrote in message 
news:4456347a$0$31652$e4fe514c@news.xs4all.nl...
[...]
>> There may be certain times when you
>> can expect the GC to do some cleanup but you cannot guarantee it nor
>> can you control it.  On the other hand, refrence counting using smart
>> pointers is 100% programmer controlled.  You _can_ force something to
>> get deleted and you know for certain that the object will get deleted
>> the instant the last reference to it leaves scope or is destroyed.
>> This is a totally dependable action that is 100% guaranteed.  With the
>> GC you can have no references to an object but it hangs out until who
>> knows when and then gets destroyed sometime after the last reference to
>> it leaves scope or is destroyed..../sometime/ after.
>
> Which is a problem because? You dont have to point out continuously that 
> the GC doesnt allow exact control over cleaning up discarded objects. We 
> all know that and consider that a good thing. What'd be more interesting 
> is to finally hear a valid reason why it's actually a problem rather than 
> an advantage.
>
[...]
>
> Why are you so stuck on wanting control over these kind of things? Are you 
> under the impression you do a better job at manually alloc/deallocing 
> memory and cleaning up objects than the latest generation Java GC will do? 
> I'm getting a bit tired of all these unsupported assumptions. Either come 
> with practical examples/facts or just agree to disagree.

    Even if (whoever "you" refers to here) does believe that they are better 
at manually allocating and deallocating memory than a modern GC, there's 
still the issue of whether the average programmer is better as well, or if 
("you") is simply gifted in that respect. If it's the latter, non-garbage 
collected programming languages may be suitable for ("you"), but not 
suitable for anyone else.

    - Oliver 

0
owong (6178)
5/1/2006 4:24:12 PM
"Oliver Wong" <owong@castortech.com> wrote in message 
news:MCq5g.2724$zn1.505@edtnps90...
>
> "Remon van Vliet" <remon@exmachina.nl> wrote in message 
> news:4456347a$0$31652$e4fe514c@news.xs4all.nl...
> [...]
>>> There may be certain times when you
>>> can expect the GC to do some cleanup but you cannot guarantee it nor
>>> can you control it.  On the other hand, refrence counting using smart
>>> pointers is 100% programmer controlled.  You _can_ force something to
>>> get deleted and you know for certain that the object will get deleted
>>> the instant the last reference to it leaves scope or is destroyed.
>>> This is a totally dependable action that is 100% guaranteed.  With the
>>> GC you can have no references to an object but it hangs out until who
>>> knows when and then gets destroyed sometime after the last reference to
>>> it leaves scope or is destroyed..../sometime/ after.
>>
>> Which is a problem because? You dont have to point out continuously that 
>> the GC doesnt allow exact control over cleaning up discarded objects. We 
>> all know that and consider that a good thing. What'd be more interesting 
>> is to finally hear a valid reason why it's actually a problem rather than 
>> an advantage.
>>
> [...]
>>
>> Why are you so stuck on wanting control over these kind of things? Are 
>> you under the impression you do a better job at manually alloc/deallocing 
>> memory and cleaning up objects than the latest generation Java GC will 
>> do? I'm getting a bit tired of all these unsupported assumptions. Either 
>> come with practical examples/facts or just agree to disagree.
>
>    Even if (whoever "you" refers to here) does believe that they are 
> better at manually allocating and deallocating memory than a modern GC, 
> there's still the issue of whether the average programmer is better as 
> well, or if ("you") is simply gifted in that respect. If it's the latter, 
> non-garbage collected programming languages may be suitable for ("you"), 
> but not suitable for anyone else.
>
>    - Oliver

I was referring to Noah. And yes, very true, but even so his point is 
flawed. Recent tests and research (from IBM, amongst others) showed that the 
latest generation of garbage collectors not only meet the performance of 
manual memory managment in the vast majority of cases, it's often 
considerably faster. So even if you've perfected the art of manual memory 
managment the odds are now still against you (and yes i can actually explain 
why that would be rather than just claim it).

It's an argument quite similar to that of people claiming natively compiled 
code will always (or mostly) be faster than Java code running in the VM. It 
was true, but it hasnt been so for quite a while now.

- Remon van Vliet


0
remon (167)
5/1/2006 5:00:34 PM
>> Noone prevents you from using vi to write Java. Well, maybe the Emacs
>> tribalists do.
>
> You missed the point. If an editor can parse your code and predict what 
> you are trying to do, then the language could too. The language itself 
> could finish these lines, and all I'd have to do is start them.

The point wasnt exactly strong to begin with. Surely you're not serious 
here, if you are you're shooting down your own credibility.

>
> Read:
>
> http://c2.com/cgi/wiki?RubyVsJava
>
> log4j's src folder has 31,764 lines of code.
>
> log4r's src folder has 2,071 lines of code.
>
> That's not just fewer lines; it's an order of magnitude fewer, for the 
> exact same feature set.
>
> Please don't say "that's because Java programmers write more professional 
> comments..."

Okay i wont say that, i'll rephrase it a bit since you're proving yourself 
to be misinformed. As per Java convention the Java version has the lowest 
level API reference documentation included in it's source code which 
obviously adds quite a few newlines (an odd measurement of verbosity to 
begin with but hey). It also happened to be properly spaced and indented 
code. Now i took the liberty of browsing through the code of the Ruby 
equivalent you mentioned and it has none of that (as in, hardly any comments 
and horribly formatted code). Since both are more a matter of taste/style i 
dont see it's relevance anyway. I'm pretty sure a similar amount of input 
went into both versions (code + docs).

>> Is that the "let's pretend this block of memory is something else"
>> stuff "inherited" from C's union and void*?
>
> Write an Any or Variant class in Java.

Never had to. Would very rarely want to.

>
>>>  - GUIs require block closures and dynamic
>>>     typing.
>>
>> Whatever for? I've written GUIs in Java, and the Swing MVC system is
>> decent enough to use. Where do you need either of those?
>
> You have insufficient experience with block closures.
>
> A GUI should be event-driven. Block closures make those as easy as falling 
> off a log. Most of the code you write in a static-typing OO language, for 
> a GUI, is excess plumbing to route events to handlers, and then excess 
> plumbing to convey state variables into handlers. Block closures simply 
> turn that problem inside out. The language does the plumbing, and all you 
> need to do is add the custom behaviors.

I can only agree, GUI development is tedious and overly complicated in Java 
nad most available visual editors produce code nobody even wants to look 
at). I must say a few well chosen design patterns make the lack of block 
closure functions (if that's what you were referring to) not quite as 
painful, but still...Java definately loses here. And btw, it can be 
succesfully argued that any need for dynamic typing will negatively affect 
the robustness of your program in the majority of cases. 


0
remon (167)
5/1/2006 5:46:59 PM
"Andrew McDonagh" <news@andmc.com> wrote in message 
news:e2vhd6$net$1@news.freedom2surf.net...
> James McGill wrote:
>> On Sat, 2006-04-29 at 11:13 +0100, Alex Buell wrote:
>>>
>>> NB: It's a JOKE!
>>
>> Production work I did in VB2.0 when it was new, is still in production.
>> I think that code might be nearly old enough to vote.
>>
>
> and your point is?
>
> longevity of use is no indicator of a 'good' language - its simply that 
> the application does what it was supposed to OR the company is unwilling 
> to rewrite for some reason if it isn't doing as its supposed to.

longevity is usually solely related to the people that design the 
application rather than the language it was developed in. That said, i think 
he was simply making a point that writing commercial quality applications 
using VB is tricky at best. I think that point is pretty valid. 


0
remon (167)
5/1/2006 6:00:52 PM
>> http://c2.com/cgi/wiki?RubyVsJava

By the way, if i may add, i dont know who submitted the language comparison 
articles for that wiki but it is littered with information that simply is 
not true. 


0
remon (167)
5/1/2006 6:12:06 PM
Remon van Vliet wrote:

>>> http://c2.com/cgi/wiki?RubyVsJava
> 
> By the way, if i may add, i dont know who submitted the language
> comparison articles for that wiki but it is littered with information that
> simply is not true.

Use the Edit button and fix it.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/1/2006 6:17:10 PM
"Phlip" <phlip2005@gmail.com> wrote in message 
news:Ggs5g.5569$mu2.4566@newssvr24.news.prodigy.net...
> Remon van Vliet wrote:
>
>>>> http://c2.com/cgi/wiki?RubyVsJava
>>
>> By the way, if i may add, i dont know who submitted the language
>> comparison articles for that wiki but it is littered with information 
>> that
>> simply is not true.
>
> Use the Edit button and fix it.
>

Hehe, fair enough, but i dont really care either way, just figured i'd point 
it out for those that use it as a reference. 


0
remon (167)
5/1/2006 6:20:10 PM
Remon van Vliet wrote:
> "Andrew McDonagh" <news@andmc.com> wrote in message 
> news:e2vhd6$net$1@news.freedom2surf.net...
>> James McGill wrote:
>>> On Sat, 2006-04-29 at 11:13 +0100, Alex Buell wrote:
>>>> NB: It's a JOKE!
>>> Production work I did in VB2.0 when it was new, is still in production.
>>> I think that code might be nearly old enough to vote.
>>>
>> and your point is?
>>
>> longevity of use is no indicator of a 'good' language - its simply that 
>> the application does what it was supposed to OR the company is unwilling 
>> to rewrite for some reason if it isn't doing as its supposed to.
> 
> longevity is usually solely related to the people that design the 
> application rather than the language it was developed in. That said, i think 
> he was simply making a point that writing commercial quality applications 
> using VB is tricky at best. I think that point is pretty valid. 
> 
> 
cause it isn't - the company doesn't give a monkeys who wrote the thing 
- just that it works or that the work arounds for any problems work. A 
company doesn't change things lightly, nor just because some developer 
says they can do a better job.

There needs to be a clear business benefit involved in changing - e.g. 
the OS the app is running on is being upgraded and the new app wont work 
on it (as is often the case with WindowsNT -> WindowsXP)
0
news261 (167)
5/1/2006 6:53:55 PM
On Mon, 01 May 2006 18:16:24 +0200, Remon van Vliet wrote:
> Which is a problem because? You dont have to point out continuously that the 
> GC doesnt allow exact control over cleaning up discarded objects. We all 
> know that and consider that a good thing. What'd be more interesting is to 
> finally hear a valid reason why it's actually a problem rather than an 
> advantage.

The issue isn't memory. The issue is other resources which are in short
supply, or which may not get cleaned up automatically by the OS, or which
you need to ensure are cleaned up as quickly as possible - database
connections, perhaps, or shared resources in a windowing system, or
mutexes. In other words, things for which you would use the dispose
pattern in Java.

Don't think of RAII as a way to manage memory (it is used for that, but if
C++ had GC, RAII for memory management would be a lot less important),
think of it as a way of automating the dispose pattern.
0
wrongbad (73)
5/1/2006 6:59:04 PM
"I V" <wrongbad@gmail.com> wrote in message 
news:pan.2006.05.01.18.58.53.973129@gmail.com...
> On Mon, 01 May 2006 18:16:24 +0200, Remon van Vliet wrote:
>> Which is a problem because? You dont have to point out continuously that 
>> the
>> GC doesnt allow exact control over cleaning up discarded objects. We all
>> know that and consider that a good thing. What'd be more interesting is 
>> to
>> finally hear a valid reason why it's actually a problem rather than an
>> advantage.
>
> The issue isn't memory. The issue is other resources which are in short
> supply, or which may not get cleaned up automatically by the OS, or which
> you need to ensure are cleaned up as quickly as possible - database
> connections, perhaps, or shared resources in a windowing system, or
> mutexes. In other words, things for which you would use the dispose
> pattern in Java.
>
> Don't think of RAII as a way to manage memory (it is used for that, but if
> C++ had GC, RAII for memory management would be a lot less important),
> think of it as a way of automating the dispose pattern.

I'll take your word for it, but his argument was that having exact control 
over memory usage is somehow an advantage.

As for resources that are in short supply, i've never actually run into such 
an issue with Java to begin with and i develop high concurrency servers. 
Reusable resources are usually pooled and cleanly released when necessary, 
and i cant really think of any other kind of resource that would cause 
issues. In fact i cant even recall a single case of resource leak in my 
entire Java career, and i dont exactly believe that's due to above average 
skill, it simply comes with Java, or is avoided by using Java. 


0
remon (167)
5/1/2006 7:11:10 PM
"Andrew McDonagh" <news@andmc.com> wrote in message 
news:e35lg7$jb3$1@news.freedom2surf.net...
> Remon van Vliet wrote:
>> "Andrew McDonagh" <news@andmc.com> wrote in message 
>> news:e2vhd6$net$1@news.freedom2surf.net...
>>> James McGill wrote:
>>>> On Sat, 2006-04-29 at 11:13 +0100, Alex Buell wrote:
>>>>> NB: It's a JOKE!
>>>> Production work I did in VB2.0 when it was new, is still in production.
>>>> I think that code might be nearly old enough to vote.
>>>>
>>> and your point is?
>>>
>>> longevity of use is no indicator of a 'good' language - its simply that 
>>> the application does what it was supposed to OR the company is unwilling 
>>> to rewrite for some reason if it isn't doing as its supposed to.
>>
>> longevity is usually solely related to the people that design the 
>> application rather than the language it was developed in. That said, i 
>> think he was simply making a point that writing commercial quality 
>> applications using VB is tricky at best. I think that point is pretty 
>> valid.
> cause it isn't - the company doesn't give a monkeys who wrote the thing - 
> just that it works or that the work arounds for any problems work. A 
> company doesn't change things lightly, nor just because some developer 
> says they can do a better job.
>
> There needs to be a clear business benefit involved in changing - e.g. the 
> OS the app is running on is being upgraded and the new app wont work on it 
> (as is often the case with WindowsNT -> WindowsXP)

I think i may have had a bad choice of words there. I didnt mean the actual 
people are at all relevant when it comes to longevity, but that skilled 
people will come up with a design that helps longevity. A proper design is 
easily extensible and maintainable, and thus adds longevity because the 
changes you mention arent as big an investment compared to designs that 
arent easily extended. A company's willingness to change/extend their 
software depends on so many things it's hard to generalize, but it's fair to 
say that if the payoff of a certain chance is considerably higher than the 
investment than that company is likely to go forward with the change. And 
the investment is considerably lower for applications that are built with 
evolution in mind.

And none of that is related to VB sucking when it comes to all that ;) 


0
remon (167)
5/1/2006 7:21:23 PM
On Mon, 01 May 2006 21:11:10 +0200, Remon van Vliet wrote:
> As for resources that are in short supply, i've never actually run into such 
> an issue with Java to begin with and i develop high concurrency servers. 

Actually, I've never really had a problem with resources being released by
GC systems either, but I don't develop the sort of applications where I
would imagine it being a problem. I'd be interested if anyone knows of any
actual studies which have investigated in precisely what cases
non-deterministic destruction causes real-world problems. Or, indeed,
anecdotal experience from those with a wider range of experience than my
own.

> Reusable resources are usually pooled and cleanly released when
> necessary, and i cant really think of any other kind of resource that

How is the pool notified that a resource is ready to be reused? By a
finalizer, or by explicitly calling a "release" or "dispose" method? In
the later case, RAII would be useful in automating the release and helping
to ensure correctness.

0
wrongbad (73)
5/1/2006 10:12:09 PM
I V <wrongbad@gmail.com> wrote:
> Actually, I've never really had a problem with resources being released by
> GC systems either, but I don't develop the sort of applications where I
> would imagine it being a problem. I'd be interested if anyone knows of any
> actual studies which have investigated in precisely what cases
> non-deterministic destruction causes real-world problems. Or, indeed,
> anecdotal experience from those with a wider range of experience than my
> own.

If you're asking what I think you are, then I have such anecdotal 
evidence.  About a year ago, I fixed a web application that wouldn't 
release a database connection if the user clicked the stop button at a 
certain time.  This generally didn't cause any problems, since the JDBC 
spec requires that finalization will close the connection (a very bad 
choice, by the way, which prevented this bug from be discovered in 
testing).  The app started failing by running out of database 
connections when it was sold and installed for a very large customer who 
had far more users than were previously seen.

That was with database connections being released in a timely manner 
most of the time, and only occasionally being left open in certain 
failure cases.  I'd hate to see what would've happened if database 
connections were never explicitly closed at all!

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
5/2/2006 5:01:13 AM
It's not of being smarter or not....

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

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

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

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

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


.....
........and its programmers are not just smart..they are bigger than
that

Bhaskar

0
ebhakt (1)
5/2/2006 9:50:54 AM
"Chris Smith" <cdsmith@twu.net> wrote in message 
news:MPG.1ec09586176e17199896a2@news.astraweb.com...
>I V <wrongbad@gmail.com> wrote:
>> Actually, I've never really had a problem with resources being released 
>> by
>> GC systems either, but I don't develop the sort of applications where I
>> would imagine it being a problem. I'd be interested if anyone knows of 
>> any
>> actual studies which have investigated in precisely what cases
>> non-deterministic destruction causes real-world problems. Or, indeed,
>> anecdotal experience from those with a wider range of experience than my
>> own.
>
> If you're asking what I think you are, then I have such anecdotal
> evidence.  About a year ago, I fixed a web application that wouldn't
> release a database connection if the user clicked the stop button at a
> certain time.  This generally didn't cause any problems, since the JDBC
> spec requires that finalization will close the connection (a very bad
> choice, by the way, which prevented this bug from be discovered in
> testing).  The app started failing by running out of database
> connections when it was sold and installed for a very large customer who
> had far more users than were previously seen.
>
> That was with database connections being released in a timely manner
> most of the time, and only occasionally being left open in certain
> failure cases.  I'd hate to see what would've happened if database
> connections were never explicitly closed at all!

Hehe, okay, in that is Java weakness rather than bad programming? I'm lead 
developer of high-concurrency servers and i cant begin to count the number 
of times we use JDBC connections and file access. Not once have we ran into 
any such issue. Not dealing with all escape paths is simply bad 
implementation and certainly not a language weakness, Java just makes that 
quite easy at times with the "finally" block.... 


0
remon (167)
5/2/2006 9:51:27 AM
"Remon van Vliet" <remon@exmachina.nl> wrote in
news:44572bc7$0$31638$e4fe514c@news.xs4all.nl: 

> 
> "Chris Smith" <cdsmith@twu.net> wrote in message 
> news:MPG.1ec09586176e17199896a2@news.astraweb.com...
>>I V <wrongbad@gmail.com> wrote:
>>> Actually, I've never really had a problem with resources being
>>> released by
>>> GC systems either, but I don't develop the sort of applications
>>> where I would imagine it being a problem. I'd be interested if
>>> anyone knows of any
>>> actual studies which have investigated in precisely what cases
>>> non-deterministic destruction causes real-world problems. Or,
>>> indeed, anecdotal experience from those with a wider range of
>>> experience than my own.
>>
>> If you're asking what I think you are, then I have such anecdotal
>> evidence.  About a year ago, I fixed a web application that wouldn't
>> release a database connection if the user clicked the stop button at
>> a certain time.  This generally didn't cause any problems, since the
>> JDBC spec requires that finalization will close the connection (a
>> very bad choice, by the way, which prevented this bug from be
>> discovered in testing).  The app started failing by running out of
>> database connections when it was sold and installed for a very large
>> customer who had far more users than were previously seen.
>>
>> That was with database connections being released in a timely manner
>> most of the time, and only occasionally being left open in certain
>> failure cases.  I'd hate to see what would've happened if database
>> connections were never explicitly closed at all!
> 
> Hehe, okay, in that is Java weakness rather than bad programming? I'm
> lead developer of high-concurrency servers and i cant begin to count
> the number of times we use JDBC connections and file access. Not once
> have we ran into any such issue. Not dealing with all escape paths is
> simply bad implementation and certainly not a language weakness, Java
> just makes that quite easy at times with the "finally" block.... 
> 

While what you say IS true, you should handle all escape paths, I do have 
to agree that RAII(or should we focus on the other end, RDIF Resource 
Diallocation is Finalization) often makes it easier to handle all escape 
paths. It is common in C++ to create a class on the stack that 
locks/unlocks/opens a resource during construction and returns it to its 
original state in its destructor. Having done so you can forget about it. 
No need to deal with it at all when the method using it exits. Even 
during exceptions. You know the destructor will have been called once you 
are out and all will be as it was.

When I work with Java I often miss the ease deterministic destructors 
provide. And I also sometimes miss 'finally' and anonymous classes when 
programming in C++.

RAII is a tool. You don't need it but it does make things a lot easier 
when its can be used.

Otis

0
obricker (68)
5/2/2006 11:59:06 AM
ebhakt wrote:
> It's not of being smarter or not....
> 
> I am both a C/C++ and JAVA coder :
> 
> c is flexible  :
>            this is both a merit and demerit (depending on programmers
> capabilities)
> 
> Java takes care of this for both lame and stunt performers...
> 
> Its simple for those who want to go that way
> but for big guys JAVA has much more......
> 
> You should not forget that JAVA was the Impetus behind internet ,
> this language should be given respect

No, the american military and the threat of nuclear war was the impetus 
behind the internet, which started coming into being at the tail of of 
the 60s. Java didn't exist until the 90's.
0
lard (953)
5/2/2006 2:46:46 PM
Remon van Vliet schrieb:
> "Chris Smith" wrote:
>> That was with database connections being released in a timely manner
>> most of the time, and only occasionally being left open in certain
>> failure cases.  I'd hate to see what would've happened if database
>> connections were never explicitly closed at all!
> 
> Hehe, okay, in that is Java weakness rather than bad programming? I'm lead 
> developer of high-concurrency servers and i cant begin to count the number 
> of times we use JDBC connections and file access. Not once have we ran into 
> any such issue. 

The same argument could be used for unmanaged memory allocation. In that 
sense, memory leaks are the result of bad programming, not a weakness of 
the language.


Timo
0
timo.stamm (231)
5/2/2006 2:49:33 PM
ebhakt wrote:
> It's not of being smarter or not....
> 
> I am both a C/C++ and JAVA coder :
> 

There is NO C/C++ language.

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


> c is flexible  :
>            this is both a merit and demerit (depending on programmers
> capabilities)
> 
> Java takes care of this for both lame and stunt performers...
> 
> Its simple for those who want to go that way
> but for big guys JAVA has much more......
> 
> You should not forget that JAVA was the Impetus behind internet ,
> this language should be given respect

what are you talking about?


> 
> 
> ....
> .......and its programmers are not just smart..they are bigger than
> that
> 
> Bhaskar
> 
0
news261 (167)
5/2/2006 6:42:45 PM
Roedy Green wrote:
> On 28 Apr 2006 00:59:19 -0700, "al pacino" <siddharthdave84@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
> 
>> improve your programming skills and what better tool to do that than
>> using c++.
> 
> You might find the work of W. Edwards Deming interesting.  He was the
> man who taught the art of quality control to the Japanese.
> 
> He argues there is no point in exhorting people to be better.  You
> have to change the environment so they naturally and without
> additional effort produce better results.

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

    int a[3];

I am supposed to write:

    #include <vector>

    vector<int> a(10);

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

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


-Walter Bright
www.digitalmars.com C, C++, D programming language compilers
0
walter24 (181)
5/2/2006 6:47:54 PM
"Walter Bright" <walter@digitalmars-nospamm.com> wrote in message 
news:co-dnbuX753ENMrZRVn-jw@comcast.com...
>
> If one expects people in general to write better programs, the programming 
> language should be designed so that the straightforward, simpler 
> expression is the right one. Doing the wrong thing should require more 
> work.
>
> This principle is evident in things like power tools and aircraft design. 
> In the former, you've got to do extra work to remove things like guards 
> and safety interlocks. In aircraft design, one of the terrible no-no's is 
> for a mechanic hook up the flight controls backwards. So the designers go 
> to great lengths to make it very hard for the mechanic to do so, hopefully 
> hard enough so that at some point the mechanic realizes he must be doing 
> something wrong.

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

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

    - Oliver 

0
owong (6178)
5/2/2006 7:04:24 PM
"Andrew McDonagh" <news@andmc.com> wrote in message 
news:e3897a$aen$1@news.freedom2surf.net...
> ebhakt wrote:
>>
>> I am both a C/C++ and JAVA coder :
>>
>
> There is NO C/C++ language.
>
> There is the C Language and the C++ language.  There are compilers that 
> will compile source files from both languages - but there is no C/C++ 
> language.

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

    - Oliver 

0
owong (6178)
5/2/2006 7:05:23 PM
In comp.lang.java.advocacy, Andrew McDonagh
<news@andmc.com>
 wrote
on Tue, 02 May 2006 19:42:45 +0100
<e3897a$aen$1@news.freedom2surf.net>:
> ebhakt wrote:
>> It's not of being smarter or not....
>> 
>> I am both a C/C++ and JAVA coder :
>> 
>
> There is NO C/C++ language.
>
> There is the C Language and the C++ language.  There are compilers that 
> will compile source files from both languages - but there is no C/C++ 
> language.

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

>
>
>> c is flexible  :
>>            this is both a merit and demerit (depending on programmers
>> capabilities)
>> 
>> Java takes care of this for both lame and stunt performers...
>> 
>> Its simple for those who want to go that way
>> but for big guys JAVA has much more......
>> 
>> You should not forget that JAVA was the Impetus behind internet ,
>> this language should be given respect
>
> what are you talking about?

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

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

>
>
>> 
>> 
>> ....
>> .......and its programmers are not just smart..they are bigger than
>> that
>> 
>> Bhaskar
>> 


-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
5/2/2006 8:00:04 PM
In comp.lang.java.advocacy, Walter Bright
<walter@digitalmars-nospamm.com>
 wrote
on Tue, 02 May 2006 11:47:54 -0700
<co-dnbuX753ENMrZRVn-jw@comcast.com>:
> Roedy Green wrote:
>> On 28 Apr 2006 00:59:19 -0700, "al pacino" <siddharthdave84@gmail.com>
>> wrote, quoted or indirectly quoted someone who said :
>> 
>>> improve your programming skills and what better tool to do that than
>>> using c++.
>> 
>> You might find the work of W. Edwards Deming interesting.  He was the
>> man who taught the art of quality control to the Japanese.
>> 
>> He argues there is no point in exhorting people to be better.  You
>> have to change the environment so they naturally and without
>> additional effort produce better results.
>
> This is insightful, and in my experience, correct. C++ has a problem in 
> that the 'right' way to do things is significantly more work than the 
> 'wrong' way. For example, instead of:
>
>     int a[3];
>
> I am supposed to write:
>
>     #include <vector>
>
>     vector<int> a(10);

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

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

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

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

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

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

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

import java.util.Vector;

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

as of Java 5, anyway.

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

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

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

Murphy was an optimist. :-)

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


-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
5/2/2006 8:00:05 PM
The Ghost In The Machine wrote:
> In comp.lang.java.advocacy, Andrew McDonagh
> <news@andmc.com>
>  wrote
> on Tue, 02 May 2006 19:42:45 +0100
> <e3897a$aen$1@news.freedom2surf.net>:
>> ebhakt wrote:
>>> It's not of being smarter or not....
>>>
>>> I am both a C/C++ and JAVA coder :
>>>
>> There is NO C/C++ language.
>>
>> There is the C Language and the C++ language.  There are compilers that 
>> will compile source files from both languages - but there is no C/C++ 
>> language.
> 
> No, but C++ will accept most of Ansi C, and gcc compiles both,
> as well as Objective-C.

Yes I said this about the compilers....
0
news261 (167)
5/2/2006 8:04:49 PM
Phlip wrote:
> Ruby:
- No comment. Do agree on the syntax point from the little I've worked
with it.

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

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

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

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

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

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

Because logic and physical constness is 2 different things.

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

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

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

Admittedly, I've used it <iostreams> less often. Others consider it
very scalable. To extend a good book is required, but very extensible.

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

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

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

I wonder which came first.

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

Yes, your humbleness ...

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

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

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

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

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

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

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

Blah, blah...

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

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

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

Werner

0
w_erasm (159)
5/2/2006 9:14:49 PM
The Ghost In The Machine wrote:
> In comp.lang.java.advocacy, Walter Bright
> <walter@digitalmars-nospamm.com>
>  wrote
> on Tue, 02 May 2006 11:47:54 -0700
> <co-dnbuX753ENMrZRVn-jw@comcast.com>:
> > Roedy Green wrote:
> >> On 28 Apr 2006 00:59:19 -0700, "al pacino" <siddharthdave84@gmail.com>
> >> wrote, quoted or indirectly quoted someone who said :
> >>
> >>> improve your programming skills and what better tool to do that than
> >>> using c++.
> >>
> >> You might find the work of W. Edwards Deming interesting.  He was the
> >> man who taught the art of quality control to the Japanese.
> >>
> >> He argues there is no point in exhorting people to be better.  You
> >> have to change the environment so they naturally and without
> >> additional effort produce better results.
> >
> > This is insightful, and in my experience, correct. C++ has a problem in
> > that the 'right' way to do things is significantly more work than the
> > 'wrong' way. For example, instead of:
> >
> >     int a[3];
> >
> > I am supposed to write:
> >
> >     #include <vector>
> >
> >     vector<int> a(10);
>
> I'm not entirely sure of this.  Ideally, of course, int
> a[3]; would allow for constructs such as Java's .length,
> although a workaround might be to use
>
> #define Nsize(a) ( sizeof(a)/sizeof(*(a)) )
>
> or some such.  But it's a bit of an ugly mess, and party
> because of C's "attitude of convenience" regarding arrays
> and pointers.

You have arrays when you want and vectors when you want.  A std::vector
isn't always warranted.  Sure, 99% of the time that is what you want,
but not always.
>
> In short, int *b = a; is a perfectly legal assignment in C,
> and it's far from clear that it should be, but presumably
> nobody wanted to write int * b = &a[0] instead way back
> when, or incur extra overhead in passing the length around.

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

> >
> > If one expects people in general to write better programs, the
> > programming language should be designed so that the straightforward,
> > simpler expression is the right one. Doing the wrong thing should
> > require more work.
>
> If one can achieve consensus on the term "wrong" in this context.
> Both constructs have issues; the int a[3]; allows for fast access but
> nonextensibility; vector<int> a; has slightly slower access but
> can dynamically extend the array as necessary (however, be careful
> of constructs such as &a[4] in the latter case; the rug might
> very well vanish from under you!).

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

0
roberts.noah (1664)
5/2/2006 9:38:03 PM
Mishagam wrote:
> I think the fact that nobody uses D means suggests that it has not only 
> one stupid feature, but a lot of stupid features.

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

<g>
0
walter24 (181)
5/2/2006 9:38:32 PM
werasm wrote:

>> C++ (deep breath):
>>  - where in memory do you want to
>>     accidentally jump today?
> 
> - This is not so much of a problem anymore. Actually, it's not a
> problem at all. Using vectors instead of arrays. Using combo of shared
> and weak pointers. Wrapping strings or using std::string. We have large
> c++ apps running like a clock.

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

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

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

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

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/2/2006 9:49:07 PM
"Walter Bright" <walter@digitalmars-nospamm.com> wrote in message 
news:ia2dnefGwqvITMrZnZ2dnUVZ_s-dnZ2d@comcast.com...
> Mishagam wrote:
>> I think the fact that nobody uses D means suggests that it has not only 
>> one stupid feature, but a lot of stupid features.
>
> For a stupid language nobody uses, the D programming language is doing 
> remarkably well, having moved up to number 19 on 
> http://www.tiobe.com/tpci.htm

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

    - Oliver 

0
owong (6178)
5/2/2006 10:02:45 PM
In comp.lang.java.advocacy, Noah Roberts
<roberts.noah@gmail.com>
 wrote
on 2 May 2006 14:38:03 -0700
<1146605883.293939.22100@y43g2000cwc.googlegroups.com>:
>
> The Ghost In The Machine wrote:

[snippage]

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

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

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

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

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

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

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
5/2/2006 11:00:04 PM
In comp.lang.java.advocacy, Andrew McDonagh
<news@andmc.com>
 wrote
on Tue, 02 May 2006 21:04:49 +0100
<e38e17$ds5$1@news.freedom2surf.net>:
> The Ghost In The Machine wrote:
>> In comp.lang.java.advocacy, Andrew McDonagh
>> <news@andmc.com>
>>  wrote
>> on Tue, 02 May 2006 19:42:45 +0100
>> <e3897a$aen$1@news.freedom2surf.net>:
>>> ebhakt wrote:
>>>> It's not of being smarter or not....
>>>>
>>>> I am both a C/C++ and JAVA coder :
>>>>
>>> There is NO C/C++ language.
>>>
>>> There is the C Language and the C++ language.  There are compilers that 
>>> will compile source files from both languages - but there is no C/C++ 
>>> language.
>> 
>> No, but C++ will accept most of Ansi C, and gcc compiles both,
>> as well as Objective-C.
>
> Yes I said this about the compilers....

Yes you did.  :-)  Oops.

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
5/2/2006 11:00:06 PM
Walter Bright skrev:

> Roedy Green wrote:
[snip]
> This is insightful, and in my experience, correct. C++ has a problem in
> that the 'right' way to do things is significantly more work than the
> 'wrong' way. For example, instead of:
>
>     int a[3];
>
> I am supposed to write:
>
>     #include <vector>
>
>     vector<int> a(10);
>
> If one expects people in general to write better programs, the
> programming language should be designed so that the straightforward,
> simpler expression is the right one. Doing the wrong thing should
> require more work.
>
> This principle is evident in things like power tools and aircraft
> design. In the former, you've got to do extra work to remove things like
> guards and safety interlocks. In aircraft design, one of the terrible
> no-no's is for a mechanic hook up the flight controls backwards. So the
> designers go to great lengths to make it very hard for the mechanic to
> do so, hopefully hard enough so that at some point the mechanic realizes
> he must be doing something wrong. If it's easy to install the flight
> controls backwards, sooner or later it will be, with deadly consequences.
>

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

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

0
5/2/2006 11:20:54 PM
"Oliver Wong" <owong@castortech.com> wrote in message 
news:9GQ5g.4422$Fg4.335@clgrps12...
>
> "Walter Bright" <walter@digitalmars-nospamm.com> wrote in message 
> news:ia2dnefGwqvITMrZnZ2dnUVZ_s-dnZ2d@comcast.com...
>> Mishagam wrote:
>>> I think the fact that nobody uses D means suggests that it has not only 
>>> one stupid feature, but a lot of stupid features.
>>
>> For a stupid language nobody uses, the D programming language is doing 
>> remarkably well, having moved up to number 19 on 
>> http://www.tiobe.com/tpci.htm
>
>    (referring to http://www.tiobe.com/tiobe_index/images/tpci_trends.gif 
> as of May 2nd, 2006): I wonder what happened in 2004 that made Java drop 
> considerably, and everything else jump up a bit.

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

--
LTP

:) 


0
5/2/2006 11:27:32 PM
Bent C Dalager skrev:

> In article <1146179734.846857.41850@g10g2000cwb.googlegroups.com>,
> peter koch <peter.koch.larsen@gmail.com> wrote:
> >
> >
> >Large parts of the C++ libraries are implemented in C++.
>
> This is also the case with Java. Even the Java compiler is implemented
> in Java.
>
[snip]
So e.g. Swing, JDBC and Vector are all implemented in Java? Without a
single JNI-call in the code? It seems my knowledge of Java needs an
update.

/Peter
>
> Cheers
> 	Bent D
> --
> Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
>                                     powered by emacs

0
5/2/2006 11:29:14 PM
Roedy Green skrev:

> On 27 Apr 2006 12:31:12 -0700, "peter koch"
> <peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
> someone who said :
>
> >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!
>
> come on. There are alternate notations that generate the same
> assembler code.  That is a legacy wart, not a feature.

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

/Peter
> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.

0
5/2/2006 11:34:35 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in
news:1146605883.293939.22100@y43g2000cwc.googlegroups.com: 

> 
> The Ghost In The Machine wrote:
>> In comp.lang.java.advocacy, Walter Bright
>> <walter@digitalmars-nospamm.com>
>>  wrote
>> on Tue, 02 May 2006 11:47:54 -0700
>> <co-dnbuX753ENMrZRVn-jw@comcast.com>:
>> > Roedy Green wrote:
>> >> On 28 Apr 2006 00:59:19 -0700, "al pacino"
>> >> <siddharthdave84@gmail.com> wrote, quoted or indirectly quoted
>> >> someone who said : 
>> >>
>> >>> improve your programming skills and what better tool to do that
>> >>> than using c++.
>> >>
>> >> You might find the work of W. Edwards Deming interesting.  He was
>> >> the man who taught the art of quality control to the Japanese.
>> >>
>> >> He argues there is no point in exhorting people to be better.  You
>> >> have to change the environment so they naturally and without
>> >> additional effort produce better results.
>> >
>> > This is insightful, and in my experience, correct. C++ has a
>> > problem in that the 'right' way to do things is significantly more
>> > work than the 'wrong' way. For example, instead of:
>> >
>> >     int a[3];
>> >
>> > I am supposed to write:
>> >
>> >     #include <vector>
>> >
>> >     vector<int> a(10);
>>
>> I'm not entirely sure of this.  Ideally, of course, int
>> a[3]; would allow for constructs such as Java's .length,
>> although a workaround might be to use
>>
>> #define Nsize(a) ( sizeof(a)/sizeof(*(a)) )
>>
>> or some such.  But it's a bit of an ugly mess, and party
>> because of C's "attitude of convenience" regarding arrays
>> and pointers.
> 
> You have arrays when you want and vectors when you want.  A
> std::vector isn't always warranted.  Sure, 99% of the time that is
> what you want, but not always.

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

>>
>> In short, int *b = a; is a perfectly legal assignment in C,
>> and it's far from clear that it should be, but presumably
>> nobody wanted to write int * b = &a[0] instead way back
>> when, or incur extra overhead in passing the length around.
> 
> Either you are passing around a length or you are somehow finding the
> end each time.  Java can be no different in this area even if the
> language might hide that fact from you.
> 

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

>> >
>> > If one expects people in general to write better programs, the
>> > programming language should be designed so that the
>> > straightforward, simpler expression is the right one. Doing the
>> > wrong thing should require more work.
>>
>> If one can achieve consensus on the term "wrong" in this context.
>> Both constructs have issues; the int a[3]; allows for fast access but
>> nonextensibility; vector<int> a; has slightly slower access but
>> can dynamically extend the array as necessary (however, be careful
>> of constructs such as &a[4] in the latter case; the rug might
>> very well vanish from under you!).
> 
> You've of course profiled this so lets see the result...
> 

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

http://www.stepanovpapers.com/

Look at the section on Source Code.

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

OB
0
obricker (68)
5/2/2006 11:38:30 PM
Roedy Green skrev:
[snip]
>
> >> For C++ I think I would nail down the names and sizes in bits of each
> >> primitive the way Java does.
> >Why? If a CPU does not have a 32-bit integer or an 8-bit char or a IEEE
> >floating point you could then not write C++ programs on it. That seems
> >a severe restriction to me.
>
>
> the two are not mutually exclusive.
>
>
>
> You could do it by saying for example that int32 is a built-in type
> and must have precisely 32 bits.  That does not stop you from having
> some other type

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

/Peter
> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.

0
5/2/2006 11:39:15 PM
Roedy Green skrev:

> On 28 Apr 2006 00:59:08 -0700, "peter koch"
> <peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
> someone who said :
>
> >It's time to come out of the bush. What adressing mode is not needed?
> >Anyone with a reasonable knowledge of C++ knows theyre all necesarry
>
> C++ has more addressing modes than other languages except for
> assemblers. So obviously they are not "necessary" in some absolute
> sense. They are only necessary in the legacy sense.  Java has only one
> addressing operator.

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

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

/Peter

> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.

0
5/2/2006 11:44:08 PM
Java Progammer Criteria?

On Thu, 27 Apr 2006 10:43:36 GMT, Mishagam <noemail@provider.com>
wrote:
>a) You don't have to think [...]

Okay. No thinking when programming...

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

Never having to bother... yeah.

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

No decisions... right.

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

Once again.

>e) Logical package directory structure is forced on you.

Likes being "forced." Ugh...

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

Once again.

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

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

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

I'm starting to see a pattern.

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

There IS a *clear* pattern. Quite clear.

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

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

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

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

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

"Some drink at the fountain of knowledge... others just gargle."
0
JustBoo1 (168)
5/3/2006 12:03:45 AM
Roedy Green skrev:

> On 27 Apr 2006 12:45:27 -0700, "peter koch"
> <peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
> someone who said :
>
> >
> >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
>
> Have you read the book?  Were in there on BIX when Stroustrup dropped
> by for a month or two?

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


First let me reinsert the part you accidently snipped: you wrote:
>  Stroustrup wrote a book about his trials designing C++ called the
> Design and Evolution of C++ with a sprouting oak tree on the cover. He
> was heavily constrained by his committee of C users who insisted on
> strict upward compatibility. The language was designed and implemented
> a bit at a time.  He was never permitted to have a reintegration/tidy
> up phase.
So tell me - where was that committee insisting on strict backward
compatibility?
What was those trials Bjarne faced?
What tidy up phase was he forbidden to have?
> I felt much better about C++ knowing at Stroustrup was on my side in
> wanting a cleaner language. It was just he was not forceful enough to
> persuade his committee of bosses focused on the current job (which was
> not designing a new language) of the need.

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

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

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

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

/Peter
> --
> Canadian Mind Products, Roedy Green.
> http://mindprod.com Java custom programming, consulting and coaching.

0
5/3/2006 12:09:02 AM
peter koch wrote:
> Your comparison with the aircraft design is also not quite fair. When
> you write software, you hopefully do lots of testing and review before
> slipping anything out the door - and this testing can easily be done
> without any deadly consequences. In my opinion, these dangerous
> facilities in C++ come in handy in some situations (e.g. when you
> implement the std::vector class!) and are very easy to avoid. The first
> review will easily find them.

No comparison or analogy is perfect, but such cross-pollination from 
seemingly unrelated fields can be very useful. In a former life, I 
worked on aircraft flight control systems for Boeing. I learned an awful 
lot about practical ways to make things safe and reliable in the 
presence of unreliable, perverse human beings. A lot of those ideas 
*can* be transferred to the practice of computer programming.

Airframe design testing can be done with little to no risk to life and 
limb. There's very little that cannot be simulated on the ground in an 
appropriately designed test rig, or in computers.

Boeing's test pilots are incredibly good. If you're lucky enough to snag 
a ride on a test flight, if they happen to be looking up at the ground, 
the most you'll likely get out of them is a laconic "cool".

http://www.707sim.com/images/texrole.jpg
0
walter24 (181)
5/3/2006 12:10:26 AM
On Tue, 02 May 2006 21:49:07 GMT, Phlip <phlip2005@gmail.com> wrote:

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

Do you have a credible citation for that? The C++ part I mean. Thanks.
0
JustBoo1 (168)
5/3/2006 12:12:55 AM
JustBoo wrote:

>>People are learning that technology in their lives that fails the most 
>>often
>>is software. And C++ is leading the charge.
>
> Do you have a credible citation for that? The C++ part I mean. Thanks.

If I made it up, I could also make up "C is leading the charge", because 
that's the language all these penetratable systems are usually written in. 
Same difference, and yes I agree with Werner that robust and bullet-proof 
C++ is easy to rapidly write...

Click the link I provided; it's a symptom of a major source of these 
defects. And many shops hire people to read the code and review it looking 
for nothing but these obvious problems.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! 


0
phlipcpp (2771)
5/3/2006 12:33:04 AM
peter koch wrote:
> Walter Bright skrev:
> 
>> Roedy Green wrote:
> ...
>> This principle is evident in things like power tools and aircraft
>> design. In the former, you've got to do extra work to remove things like
>> guards and safety interlocks. In aircraft design, one of the terrible
>> no-no's is for a mechanic hook up the flight controls backwards. So the
>> designers go to great lengths to make it very hard for the mechanic to
>> do so, hopefully hard enough so that at some point the mechanic realizes
>> he must be doing something wrong. If it's easy to install the flight
>> controls backwards, sooner or later it will be, with deadly consequences.
>>
> 
> I do not disagree with you here. C++ is not the perfect language,
> inheriting as we all know some of the bad stuff from C - including
> arrays.
> What you can do is not teach beginners about e.g. pointers, build in
> arrays and stuff like that. Just as e.g. Koenig and Moe do in their
> introductory text.
I myself, and probably many people out here use C++ only because they 
naturally come to C++ from C.
In my opinion, C was very good language for his time. It was not safe, 
but it was very clear. You always knew exactly what is going on.
C++, on the other side, is current, very bad overcomplicated language. I 
myself use it only because it easily allows me to use only small subset 
of it's features and still use Microsoft MFC relatively efficiently. I 
am sure this ability to use small subset of C++ (which programmer is 
familiar with) is what allows C++ to still be generally popular language 
now.
If you will strongly insist on using only new, 'SAFE' C++ features there 
will be no reason at all to use C++, it will quickly become small niche 
language to addicted.
0
5/3/2006 1:26:50 AM
peter koch wrote:
> Roedy Green skrev:
> 
>> On 27 Apr 2006 12:31:12 -0700, "peter koch"
>> <peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>> 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!
>> come on. There are alternate notations that generate the same
>> assembler code.  That is a legacy wart, not a feature.
> 
> Are you talking about C++ references and C++ pointers? While they might
> be identical under the covers, they have widely different semantic uses
> and you can't substitute one for the other.
C++ references are not SO different from pointers. Just like Roedy Green 
said - one more addressing mode. I doubt any well designed language 
(like Java) would have (or has) references.
0
5/3/2006 1:45:47 AM
Walter Bright wrote:
> Mishagam wrote:
>> I think the fact that nobody uses D means suggests that it has not 
>> only one stupid feature, but a lot of stupid features.
> 
> For a stupid language nobody uses, the D programming language is doing 
> remarkably well, having moved up to number 19 on 
> http://www.tiobe.com/tpci.htm
> 
One part of being uninformed about language is being uninformed about 
this language status ;)
But still asking "OK, are there any stupid features in D?" in this 
thread is not very clever, because in this thread we talked about C++ 
and Java most people knew about, and because most people here don't know 
D nobody knows D stupid features and so D language could get unfair 
advantage.
This is why I posted my answer (at the top).
0
5/3/2006 1:56:21 AM
Luc The Perverse wrote:
> "Oliver Wong" <owong@castortech.com> wrote in message 
> news:9GQ5g.4422$Fg4.335@clgrps12...
>> "Walter Bright" <walter@digitalmars-nospamm.com> wrote in message 
>> news:ia2dnefGwqvITMrZnZ2dnUVZ_s-dnZ2d@comcast.com...
>>> Mishagam wrote:
>>>> I think the fact that nobody uses D means suggests that it has not only 
>>>> one stupid feature, but a lot of stupid features.
>>> For a stupid language nobody uses, the D programming language is doing 
>>> remarkably well, having moved up to number 19 on 
>>> http://www.tiobe.com/tpci.htm
>>    (referring to http://www.tiobe.com/tiobe_index/images/tpci_trends.gif 
>> as of May 2nd, 2006): I wonder what happened in 2004 that made Java drop 
>> considerably, and everything else jump up a bit.
> 
> It would appear that the rise in Python users (From virtually nothing) 
> corresponds almost exactly with the drop in Java users.   VB also rose, 
> which probably stole a little java use.
>
There are many strange features in this chart. Why C always so much 
higher than C++? Why VB started growing now when it is losing MS support 
and there isn't any reason to use VB?
What is measured here anyway?
0
5/3/2006 1:58:59 AM
"Mishagam" <noemail@provider.com> wrote in message 
news:D7U5g.14596$P65.10219@southeast.rr.com...
> Luc The Perverse wrote:
>> "Oliver Wong" <owong@castortech.com> wrote in message 
>> news:9GQ5g.4422$Fg4.335@clgrps12...
>>> "Walter Bright" <walter@digitalmars-nospamm.com> wrote in message 
>>> news:ia2dnefGwqvITMrZnZ2dnUVZ_s-dnZ2d@comcast.com...
>>>> Mishagam wrote:
>>>>> I think the fact that nobody uses D means suggests that it has not 
>>>>> only one stupid feature, but a lot of stupid features.
>>>> For a stupid language nobody uses, the D programming language is doing 
>>>> remarkably well, having moved up to number 19 on 
>>>> http://www.tiobe.com/tpci.htm
>>>    (referring to http://www.tiobe.com/tiobe_index/images/tpci_trends.gif 
>>> as of May 2nd, 2006): I wonder what happened in 2004 that made Java drop 
>>> considerably, and everything else jump up a bit.
>>
>> It would appear that the rise in Python users (From virtually nothing) 
>> corresponds almost exactly with the drop in Java users.   VB also rose, 
>> which probably stole a little java use.
>>
> There are many strange features in this chart. Why C always so much higher 
> than C++? Why VB started growing now when it is losing MS support and 
> there isn't any reason to use VB?
> What is measured here anyway?

It would be funny if it were something dumb - like number of applications 
being run by what they are written in

--
LTP

:) 


0
5/3/2006 2:56:37 AM
Mishagam wrote:

> C++ references are not SO different from pointers. Just like Roedy Green
> said - one more addressing mode. I doubt any well designed language
> (like Java) would have (or has) references.

Java has references.

0
roberts.noah (1664)
5/3/2006 5:52:53 AM
Noah Roberts wrote:
> Mishagam wrote:
> 
>> C++ references are not SO different from pointers. Just like Roedy Green
>> said - one more addressing mode. I doubt any well designed language
>> (like Java) would have (or has) references.
> 
> Java has references.
> 
Excuse me. I meant separate references and pointers with so close 
functions. Java has references, but they have also some features of C++ 
pointers like they can be null.
0
5/3/2006 6:45:09 AM
Phlip wrote:
> werasm wrote:
>
> >> C++ (deep breath):
> >>  - where in memory do you want to
> >>     accidentally jump today?
> >
> > - This is not so much of a problem anymore. Actually, it's not a
> > problem at all. Using vectors instead of arrays. Using combo of shared
> > and weak pointers. Wrapping strings or using std::string. We have large
> > c++ apps running like a clock.
>
> In general, >70% of all software features are not used as first delivered,
> and malware is a crushing burden on global productivity. We have a new form
> of war on our hands - a new kind of arms race.
>
> Yet when you look at the sources of security breaches, over and over again
> you find the things that sloppy C++ programmers revel in. Double deletes,
> array overruns from unchecked buffers, runaway recursion, gratuitous
> typecasts, etc.

Yes, its time that we get a good book on exactly how software can be
exploited (what to look out for). Maybe they are around. I haven't seen
one in the Bjarne Stroustrup series though, which is what I have come
to like to read.

As far as the things you've mentioned are concerned, they are quite
rare, and with a little of experience easy to spot. Simply look for
sprintf, strncpy, memcpy, memset - replace arrays with vectors, using
at() for indexing. Prohibit c-style casting (actually, prohibit C, or
tuck it away where no one can see it, testing the tucked away part well
- most legacy API's are C - hence the unfortunate need for
compatibility). I was suprised to see on a VxWorks course that none
programmed in C++. There is a lot of embedded code running out there
and still being developed every day. Most of the projects I work on
interface with the hardware very closely. Runaway recursion, hmmm -
sometimes recursion can reduce code and make it much simpler (Tower of
Hanoi, quicksort etc). Is recursion only applicable to C++ as
programming language, if so, one more reason to use it :-).

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

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

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

No, not C++ - the humans using it (BTW, maybe its the Win32 API with
hundreds of ways to do things and no organised documentation indicating
more correct ways). As far as stability is concerned, IMHO the standard
is pretty clear on when you should test your code before trusting it,
aside from many authoritative books written on the subject.

The biggest thing the Java guys (SUN) did was to give humans less
freedom - this cut out >50% of their problems. Leave the hard work to a
couple of guys that know how to develop software (BTW, in which
language was their VM written). Programming in sub-standard teams
before I could appreciate the value in this. This does not mean I
personally enjoy programming in C++ far more than other languages (I
have not tried D, BTW - I appreciate that they maintain templates with
similar flexibility that C++). As far as ruby is concerned, I've tried
it briefly, and it's a bit too loose for my liking. Maybe I should try
it more before commenting.

Kind regards,

W

0
w_erasm (159)
5/3/2006 8:02:01 AM
Mishagam schrieb:
> What is measured here anyway?

| The ratings are calculated by counting hits of the most popular search
| engines.

TIOBE Programming Community Index Definition
http://www.tiobe.com/index.htm?tiobe_index (you have to click the first 
link on the page yourself, stupid website doesn't allow direct links)


Timo
0
timo.stamm (231)
5/3/2006 8:12:16 AM
Oliver Wong wrote:

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

From the TIOBE faq:

Q: What happened to Java in April 2004? Did you change your methodology?
A: No, we did not change our methodology at that time. Google changed its
methodology. They performed a general sweep action to get rid of all kinds of
web sites that had been pushed up. As a consequence, there was a huge drop for
languages such as Java and C++. In order to minimize such fluctuations in the
future, we added two more search engines (MSN and Yahoo) a few months after
this incident.

    -- chris


0
chris.uppal (3980)
5/3/2006 8:16:56 AM
Phlip wrote:

> > > People are learning that technology in their lives that fails the most
> > > often
> > > is software. And C++ is leading the charge.
> >
> > Do you have a credible citation for that? The C++ part I mean. Thanks.
>
> If I made it up, I could also make up "C is leading the charge", because
> that's the language all these penetratable systems are usually written in.

I think that PHP is making a credible attempt for top-dog status here.

As is Java if the posts in this (c.l.j.p) newsgroup are anything to go by -- 
huge numbers of posters appear to see nothing even faintly questionable in
assembling SQL queries by concatenating user-supplied strings...

    -- chris


0
chris.uppal (3980)
5/3/2006 8:21:36 AM
werasm wrote:

> The biggest thing the Java guys (SUN) did was to give humans less
> freedom - this cut out >50% of their problems. Leave the hard work to a
> couple of guys that know how to develop software (BTW, in which
> language was their VM written).

The current series of JVMs from Sun are written mostly in reasonable quality C
sprinkled with a little C++ dust to help structure it.  I.e. it needs a C++
compiler, but a C-only programmer could follow most of it without difficulty.
IIRC there is also some assembler in there.

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

The platform library is another matter, of course.

    -- chris


0
chris.uppal (3980)
5/3/2006 8:33:42 AM
In article <1146612554.265541.96570@j33g2000cwa.googlegroups.com>,
peter koch <peter.koch.larsen@gmail.com> wrote:
>
>So e.g. Swing, JDBC and Vector are all implemented in Java? Without a
>single JNI-call in the code? It seems my knowledge of Java needs an
>update.

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

There is no reason for Vector (or its replacement, ArrayList) to have
native code and so they don't, and I don't expect JDBC has any but I
haven't actually looked.

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

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
5/3/2006 8:46:41 AM
In article <knrf52hksash9la4inn5r4h3igigv4b85s@4ax.com>,
JustBoo  <JustBoo@BooWho.com> wrote:
>
> (...)
>
>Wow, given that list I would feel more comfortable paying a monkey to
>code my apps. Why pay a human just to follow the banana around when I
>can get chimps to do it for less.

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

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

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
5/3/2006 8:50:10 AM
"JustBoo" <JustBoo@BooWho.com> wrote in message 
news:knrf52hksash9la4inn5r4h3igigv4b85s@4ax.com...
>
> Java Progammer Criteria?
>
> On Thu, 27 Apr 2006 10:43:36 GMT, Mishagam <noemail@provider.com>
> wrote:
>>a) You don't have to think [...]
>
> Okay. No thinking when programming...
>
>>b) You don't have to bother to use auto_pointer (not working with
>
> Never having to bother... yeah.
>
>>c) You don't have to decide about programming style. Sun provided
>
> No decisions... right.
>
>>d) You don't have to decide about naming of files and classes - they are
>>the same.
>
> Once again.
>
>>e) Logical package directory structure is forced on you.
>
> Likes being "forced." Ugh...
>
>>f) You don't have to choose between char *, string, CString ... - String
>
> Once again.
>
>>g) you don't have to choose between long int, unsigned int, WORD, DWORD,
>>size_t .... - close to optimal choice if forced on you.
>
> Ohhh, yes, how horrid to have to actually make an informed decision. I
> feel for you.
>
>>h) You don't decide do you use internal or external functions
>
> I'm starting to see a pattern.
>
>>i) You don't have to decide if you use methods or define new operators.
>
> There IS a *clear* pattern. Quite clear.
>
>>Java choice is sometimes more verbose, but usually more clear.
>
> Well apparently it's *not* the Java programmer who is going to be
> clear, so something has to be, right? I mean s/he is too busy not
> making decisions, right. I get the feeling there would be lots of
> left-over rotten food and sticky keyboards that could never be decided
> upon either. Hygiene would be something to consider though.
>
>>As you can guess, I can continue.
>>Dropping all these choices first - makes programming easier, you have
>>less things to bother about,
>
> If you were never meant to be a programmer in the first place I
> guess.... Hmm, VB and Java programmer are a lot alike. A river in
> Egypt, baby, a river in Egypt....
>
> Wow, given that list I would feel more comfortable paying a monkey to
> code my apps. Why pay a human just to follow the banana around when I
> can get chimps to do it for less.
>
> "Some drink at the fountain of knowledge... others just gargle."

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


0
remon (167)
5/3/2006 9:06:10 AM
"peter koch" <peter.koch.larsen@gmail.com> wrote in message 
news:1146613448.279888.38230@i40g2000cwc.googlegroups.com...
>
> Roedy Green skrev:
>
>> On 28 Apr 2006 00:59:08 -0700, "peter koch"
>> <peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
>> someone who said :
>>
>> >It's time to come out of the bush. What adressing mode is not needed?
>> >Anyone with a reasonable knowledge of C++ knows theyre all necesarry
>>
>> C++ has more addressing modes than other languages except for
>> assemblers. So obviously they are not "necessary" in some absolute
>> sense. They are only necessary in the legacy sense.  Java has only one
>> addressing operator.
>
> This is not quite true. Take old fashioned Pascal as an example. Pascal
> has all the adressing modes of C++. Algol has (had) more.
>
> Java has two adressing modes - one for the ints and one for the
> objects. And this approach is simple but with drawbacks.
>

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


0
remon (167)
5/3/2006 9:13:08 AM
On 3 May 2006 01:02:01 -0700 "werasm" <w_erasm@telkomsa.net> waved a
wand and this message magically appeared:

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

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

-- 
http://www.munted.org.uk

Take a nap, it saves lives.
0
5/3/2006 9:13:51 AM
werasm wrote:
> I was suprised to see on a VxWorks course that none
> programmed in C++.

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

-- 
Ian Collins.
0
ian-news (10155)
5/3/2006 9:23:20 AM
Alex Buell wrote:
> On 3 May 2006 01:02:01 -0700 "werasm" <w_erasm@telkomsa.net> waved a
> wand and this message magically appeared:
>
> > I was suprised to see on a VxWorks course that none
> > programmed in C++.
>
> That's because C is better for this sort of work. How else will you
> manage to shoe-horn zillions of features into an embedded device with
> only 2MB of flash ROM and 16MB of memory?

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

W

0
w_erasm (159)
5/3/2006 9:43:51 AM
Alex Buell wrote:
> On 3 May 2006 01:02:01 -0700 "werasm" <w_erasm@telkomsa.net> waved a
> wand and this message magically appeared:
>
> > I was suprised to see on a VxWorks course that none
> > programmed in C++.
>
> That's because C is better for this sort of work. How else will you
> manage to shoe-horn zillions of features into an embedded device with
> only 2MB of flash ROM and 16MB of memory?

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

W

> 
> -- 
> http://www.munted.org.uk
> 
> Take a nap, it saves lives.

0
w_erasm (159)
5/3/2006 9:50:58 AM
Chris Uppal wrote:
> werasm wrote:

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

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

Regards,

Werner

0
w_erasm (159)
5/3/2006 9:55:51 AM
Bent C Dalager wrote:

> > So e.g. Swing, JDBC and Vector are all implemented in Java? Without a
> > single JNI-call in the code? It seems my knowledge of Java needs an
> > update.
>
> Swing certainly has native portions to interface with the native GUI,
> as will generally any library that needs to access some native
> third-party library (I/O, thread handling, etc.).

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


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

I think that was the BigInteger/BigDecimal stuff.

    -- chris

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


0
chris.uppal (3980)
5/3/2006 10:07:01 AM
On 3 May 2006 02:43:51 -0700 "werasm" <w_erasm@telkomsa.net> waved a
wand and this message magically appeared:

> > That's because C is better for this sort of work. How else will you
> > manage to shoe-horn zillions of features into an embedded device
> > with only 2MB of flash ROM and 16MB of memory?
> 
> Oh you can - see "Inside the C++ object model" by Lipman. However,
> you've enforced my point - the compatibility (with C) is necessary. I
> must mention that the course was back in 2000. I have programmed in C+
> + since for the VxW OS :-).

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

-- 
http://www.munted.org.uk

Take a nap, it saves lives.
0
5/3/2006 10:08:29 AM
"peter koch" <peter.koch.larsen@gmail.com> wrote in message 
news:1146614942.693181.156270@i40g2000cwc.googlegroups.com...
>
> Roedy Green skrev:
>
>> On 27 Apr 2006 12:45:27 -0700, "peter koch"
>> <peter.koch.larsen@gmail.com> wrote, quoted or indirectly quoted
>> someone who said :
>>
>> >
>> >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
>>
>> Have you read the book?  Were in there on BIX when Stroustrup dropped
>> by for a month or two?
>
> I have read the book and numerous articles from Bjarne describing the
> evolution of C++.
>
>
> First let me reinsert the part you accidently snipped: you wrote:
>>  Stroustrup wrote a book about his trials designing C++ called the
>> Design and Evolution of C++ with a sprouting oak tree on the cover. He
>> was heavily constrained by his committee of C users who insisted on
>> strict upward compatibility. The language was designed and implemented
>> a bit at a time.  He was never permitted to have a reintegration/tidy
>> up phase.
> So tell me - where was that committee insisting on strict backward
> compatibility?
> What was those trials Bjarne faced?
> What tidy up phase was he forbidden to have?
>> I felt much better about C++ knowing at Stroustrup was on my side in
>> wanting a cleaner language. It was just he was not forceful enough to
>> persuade his committee of bosses focused on the current job (which was
>> not designing a new language) of the need.
>
> When did Bjarne try to persuade his "committee of bosses" to let him
> write a cleaner language?
> If anyone would care to spend just a few minutes at his website, they
> would find your description at best grossly misleading. As I said
> before, I see it as a bloody lie.
>
> Just a few quotes from Stroustrups homepage:
> (Would he rather have created something like Java?)
> No. Java isn't even close. If people insist on comparing C++ and Java -
> as they seem to do - I suggest they read The Design and Evolution of
> C++ (D&E) to see why C++ is the way it is, and consider both languages
> in the light of the design criteria I set for C++. Those criteria will
> obviously differ from the criteria of Sun's Java team. [...]Much of the
> relative simplicity of Java is - like for most new languages - partly
> an illusion and partly a function of its incompleteness.
>
> (About comparing C++ to other languages)
> [...]That said, I consider C++ the best choice in programming language
> for a wide variety of people and applications.
>
> (Are there features Stroustrup  would like to remove from C++?)
> Not really. People who ask this kind of question usually think of one
> of the major features such as multiple inheritance, exceptions,
> templates, or run-time type identification. C++ would be incomplete
> without those. I have reviewed their design over the years, and
> together with the standards committee I have improved some of their
> details, but none could be removed without doing damage.
>
> /Peter
>> --
>> Canadian Mind Products, Roedy Green.
>> http://mindprod.com Java custom programming, consulting and coaching.
>

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

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

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


0
remon (167)
5/3/2006 10:40:19 AM
"Mishagam" <noemail@provider.com> wrote in message 
news:uFT5g.25011$Sa1.13248@tornado.southeast.rr.com...
> peter koch wrote:
>> Walter Bright skrev:
>>
>>> Roedy Green wrote:
>> ...
>>> This principle is evident in things like power tools and aircraft
>>> design. In the former, you've got to do extra work to remove things like
>>> guards and safety interlocks. In aircraft design, one of the terrible
>>> no-no's is for a mechanic hook up the flight controls backwards. So the
>>> designers go to great lengths to make it very hard for the mechanic to
>>> do so, hopefully hard enough so that at some point the mechanic realizes
>>> he must be doing something wrong. If it's easy to install the flight
>>> controls backwards, sooner or later it will be, with deadly 
>>> consequences.
>>>
>>
>> I do not disagree with you here. C++ is not the perfect language,
>> inheriting as we all know some of the bad stuff from C - including
>> arrays.
>> What you can do is not teach beginners about e.g. pointers, build in
>> arrays and stuff like that. Just as e.g. Koenig and Moe do in their
>> introductory text.
> I myself, and probably many people out here use C++ only because they 
> naturally come to C++ from C.
> In my opinion, C was very good language for his time. It was not safe, but 
> it was very clear. You always knew exactly what is going on.
> C++, on the other side, is current, very bad overcomplicated language. I 
> myself use it only because it easily allows me to use only small subset of 
> it's features and still use Microsoft MFC relatively efficiently. I am 
> sure this ability to use small subset of C++ (which programmer is familiar 
> with) is what allows C++ to still be generally popular language now.
> If you will strongly insist on using only new, 'SAFE' C++ features there 
> will be no reason at all to use C++, it will quickly become small niche 
> language to addicted.

Finally...well said. 


0
remon (167)
5/3/2006 10:51:10 AM
"peter koch" <peter.koch.larsen@gmail.com> wrote in message 
news:1146612554.265541.96570@j33g2000cwa.googlegroups.com...
>
> Bent C Dalager skrev:
>
>> In article <1146179734.846857.41850@g10g2000cwb.googlegroups.com>,
>> peter koch <peter.koch.larsen@gmail.com> wrote:
>> >
>> >
>> >Large parts of the C++ libraries are implemented in C++.
>>
>> This is also the case with Java. Even the Java compiler is implemented
>> in Java.
>>
> [snip]
> So e.g. Swing, JDBC and Vector are all implemented in Java? Without a
> single JNI-call in the code? It seems my knowledge of Java needs an
> update.

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

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


0
remon (167)
5/3/2006 11:03:46 AM
werasm wrote:

>> http://c2.com/cgi/wiki?MicrosoftSampleCode
>
> Hmmm, that's Win32 for you. A good c++ implementation would hide that
> as far as possible - but you know that! Yes, it compiles with a c++
> compiler - so does assembler. Obviously non-standard.

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

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


0
phlipcpp (2771)
5/3/2006 1:52:49 PM
Phlip wrote:
> werasm wrote:
>
> >> http://c2.com/cgi/wiki?MicrosoftSampleCode
> >
> > Hmmm, that's Win32 for you. A good c++ implementation would hide that
> > as far as possible - but you know that! Yes, it compiles with a c++
> > compiler - so does assembler. Obviously non-standard.
>
> Are we discussing the same sample code? Its leaks and overflow risks all
> come from its use of Standard C. (Arrays, if statements, etc.)

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

Things could have looked like this or similar:

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

Please comment on exploitability, as that is not my strength.
> 
> -- 
>   Phlip
>   http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

0
w_erasm (159)
5/3/2006 4:16:13 PM
werasm wrote:

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

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

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

> Things could have looked like this or similar:

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

Premature optimization is no excuse for fragility!

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

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

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/3/2006 4:34:48 PM
Phlip wrote:

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

Then your programs can very well be incredibly slow compared to what
they would be.
>
> Premature optimization is no excuse for fragility!

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

0
roberts.noah (1664)
5/3/2006 4:46:35 PM
Mishagam wrote:
> Noah Roberts wrote:
> > Mishagam wrote:
> >
> >> C++ references are not SO different from pointers. Just like Roedy Green
> >> said - one more addressing mode. I doubt any well designed language
> >> (like Java) would have (or has) references.
> >
> > Java has references.
> >
> Excuse me. I meant separate references and pointers with so close
> functions. Java has references, but they have also some features of C++
> pointers like they can be null.

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

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

0
roberts.noah (1664)
5/3/2006 4:51:31 PM
Noah Roberts wrote:

> There's no excuse for premature pessimization either.

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

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

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

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/3/2006 4:58:56 PM
Phlip wrote:
> Noah Roberts wrote:
>
> > There's no excuse for premature pessimization either.
>
> If you discover you must optimize, you can convert from foo(string bar) to
> foo(string const & bar) in only one logical place; typically 2 physical
> places. The change won't cause force other designs to change.
>
> When you have a design decision that's harder to reverse, _then_ you fret
> about its performance as you commit it.
>
> (My current boss, though otherwise good at coding, refuses to allow us to
> rely on the return value optimization, so maybe I take it out on this
> newsgroup;)

Return value optimization is not always available and that IS a hard to
reverse design decision.

Besides, that won't help you with inputs.

0
roberts.noah (1664)
5/3/2006 5:09:02 PM
Noah Roberts wrote:

> Return value optimization is not always available and that IS a hard to
> reverse design decision.

I didn't say it wasn't.

> Besides, that won't help you with inputs.

I didn't say it did.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/3/2006 5:11:07 PM
Just for fun,

Phlip <phlip2005@gmail.com> wrote:
> Java:
> 
>  - write once debug everywhere

I find this to be not at all true.  In fact, most of what I do for a 
living these days is write code (and manage a development team that 
writes code) in Java on Windows, and deploy the code on Linux.  In the 
last five years of doing so, I have seen exactly ONE bug that was 
operating system specific... and it failed on Windows but not Linux, 
rather than the other way around.  It had to do with another programmer 
misinterpreting String.replaceAll and not realizing that the parameters 
were regular expressions, and passing the platform-specific file 
separator as a parameter.  Of course, on Windows that was a backslash 
and resulted in an error trying to parse the regular expression.

That's it.  No other bugs in five years.  Of course other bugs are 
possible.  There are even areas I'd describe as pitfalls: character 
encodings, Runtime.exec, and the like.  However, I haven't run into them 
in practice.  I have enough confidence that I feel pretty good releasing 
code tested on Windows directly onto a production system running Linux.

(I imagine there are also issues with the Macintosh and GUI apps, since 
I see questions about it.  I wouldn't really know.)

>  - forgets everything on all its CLASSPATHs at
>     the drop of a hat

I don't understand what you mean by this.  As far as I can tell, it's a 
completely senseless statement.  If you're talking about a CLASSPATH 
environment variable, then this is an operating system issue, not at all 
related to Java.  If you're talking about the classpath (in more general 
terms, not the environment variable) used by the system class loader, 
then it doesn't change, ever.  Perhaps you managed to confuse yourself 
at some point with a custom class loader?

>  - projects must depend on fragile and 
>     programmer-hostile tools, like ANT,
>     that make easy things hard and hard
>     things absurd

I also dislike ant.  That's why I've never used it -- except for a brief 
period of experimentation with XDoclet, which seems to depend on it.  So 
far as I can tell, I don't suffer any great disadvantages from not using 
ant.

>  - impersonates the worst of C++
>     multiple String classes

Are you referring to my earlier post where I listed different ways of 
representing character sequences?  The point of that post was that 
different functionality requirements require different types for the 
same basic concept, regardless of language...  The only dispensable 
representation from my list in Java is StringBuffer, and it will go away 
over time.

>     and last but least generics!

I have my complaints about generics in Java.  Their existence, though, 
is not one of those complaints.

>  - arrays aren't really arrays. But they really
>     are. Kinda.

Eh?  Arrays are arrays.  Perhaps you're too married to some language-
specific concept of what an array is.

>  - pretends you broke something if your file
>     name differs from your class name. Figure
>     it out, stoopid!

Exactly what important information did you expect to express by naming 
your source file something different?  A decent development environment 
might have mitigated the headache you would have caused by doing so... 
but it's no justification.

(Technically, this is not a requirement of the Java language.  It is 
only suggested by the Java Language Specification, and is enforced by 
choice in all major Java compilers.  The JLS doesn't mention source 
files at all in any normative statement.)

>  - when a smart editor like Eclipse can finish
>     every line for you, it makes you wonder 
>     what the language is _there_ for!

This is perhaps a useful thing for some to wonder, but only so that they 
can get around to knowing the answer.  The answer is that we're talking 
about two different sets of things:

(1) What can be reasonably guessed, with the assurance that the 
programmer will see the guess and correct it if it's wrong?

(2) What is so certain to be the programmers meaning that it can be done 
without guessing?

Clearly, there are things that fit into set (1) without also fitting 
into set (2).  Those things should be implemented with IDE auto-complete 
features, and not with the language itself.  Whether the boundaries are 
drawn correctly is another issue, and there are undoubtedly places where 
the boundaries could be drawn better... but criticizing the need for 
auto-complete entirely doesn't look reasonable.

>  - adds keywords, like interface, based on
>     someone else's preconceived notion of good
>     design. Not keywords like 'virtual', based
>     on what the hardware will actually do

So you don't like the lack of multiple inheritance.  That's fine.  
However, the existence of interfaces as a language feature is perfectly 
sensible in a language without multiple inheritance.  This is not a 
separate gripe.

>  - provides whole new categories of bugs, based
>     on zombie objects, non-deterministic
>     destructors, redundant finally blocks, all
>     under the excuse we are saving you from all
>     the C++ memory errors that a good standard
>     library implementation will save you from
>     anyway

It's not true that, in practice, good libraries have saved C++ 
programmers from memory management bugs.  Results indicate that long-
running applications in C++ tend to benefit when the new operator is 
overloaded with a simple conservative garbage collected implementation, 
and delete with a no-op.  This is because the accidental memory leaks 
from the dumb conservative collector and from these "zombie" objects are 
substantially less than the memory leaks from typical memory allocation 
bugs.  Clearly something is wrong.  If you wish to embark upon a massive 
education campaign to teach C++ programmers how to avoid these bugs, 
that would perhaps be a noble undertaking.  In the interim, though, it 
would be counterproductive to interfere with efforts to avoid memory 
management bugs that do occur in real-life applications.  Modern Java 
implementations have non-conservative collectors that are even better.

>  - GUIs require block closures and dynamic 
>     typing. But what language does your boss
>     tell you to write the GUI in???

Anonymous inner classes actually tend to solve this problem very easily.  
Yes, they are more wordy.  If you don't like wordy languages, then you 
shouldn't use Java.  (And shouldn't take jobs where Java is used, or 
should just deal with it when the language is decided on; your choice!)  
The only significant lost feature is the ability to modify the values of 
local variables.  That feature would be nice just for consistency, but 
it is probably more dangerous than it's worth in practice.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
5/3/2006 5:31:11 PM
Chris Smith wrote:

> I find this to be not at all true.  In fact, most of what I do for a
> living these days is write code (and manage a development team that
> writes code) in Java on Windows, and deploy the code on Linux.

Me too. I could have kicked off the list with a less cheap shot. For
example:

"Java : the elegant simplicity of C++ and the blazing speed of Smalltalk."
--Jan Steinman

>>  - adds keywords, like interface, based on
>>     someone else's preconceived notion of good
>>     design. Not keywords like 'virtual', based
>>     on what the hardware will actually do
> 
> So you don't like the lack of multiple inheritance.  That's fine.
> However, the existence of interfaces as a language feature is perfectly
> sensible in a language without multiple inheritance.  This is not a
> separate gripe.

Ooh, I was gonna snip it all, but you finally got thru to me.

I didn't mention MI!!!

When I was a tiny kid, my mom read me a children's book about a rabbit
scolding another rabbit (or something like that) for sneaking into a
garden. The one rabbit complains, "but I didn't sneak in!" "Because you
stopped in time!!" "But I wasn't _gonna_ sneak in!!" etc.

I apologise for just being about to mention MI and stopping in time.
(Noah!;)

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/3/2006 5:40:03 PM
Phlip wrote:

> I apologise for just being about to mention MI and stopping in time.
> (Noah!;)

?

0
roberts.noah (1664)
5/3/2006 6:10:31 PM
Noah Roberts wrote:
> Mishagam wrote:
>> Noah Roberts wrote:
>>> Mishagam wrote:
>>>
>>>> C++ references are not SO different from pointers. Just like Roedy Green
>>>> said - one more addressing mode. I doubt any well designed language
>>>> (like Java) would have (or has) references.
>>> Java has references.
>>>
>> Excuse me. I meant separate references and pointers with so close
>> functions. Java has references, but they have also some features of C++
>> pointers like they can be null.
> 
> C++ pointers and references have completely different purposes.  The
> fact that Java lacks pointers is just another can't.
> 
> I can't say Java's, "everything is a reference except when it is not,"
> is a move up from having explicit value, reference, and pointer
> semantics that operate in a uniform manner.
> 

Java has a thing called 'references'.  Its more like a C Pointer than a 
C++ reference, as in it can be nulled.  The major difference is that no 
pointer arithmetic can be done with it.

Java references are passed by value. The objects that they point to does 
actually move.

Granted a better name than 'reference' or 'pointer' would have helped - 
though I cant think of one.


0
news261 (167)
5/3/2006 6:21:53 PM
Noah Roberts wrote:
> Mishagam wrote:
>> Noah Roberts wrote:
>>> Mishagam wrote:
>>>
>>>> C++ references are not SO different from pointers. Just like Roedy Green
>>>> said - one more addressing mode. I doubt any well designed language
>>>> (like Java) would have (or has) references.
....
> C++ pointers and references have completely different purposes.  

'purpose' is what language designers imagined references would be used 
for. Functionaly, as I understand, difference between references and 
pointers is little syntax sugar [ -> replaced with . ] + what values 
they can hold - references cannot hold null or objects allocated by new. 
But you CAN have reference to destructed object out of scope (or field 
in deleted object allocated on heap). Also references syntax resembles 
value objects enough that is is difficult to distinguish what you are 
using now. It is one more way where C++ loses C clarity.
What I meant is difference with pointer is too small to justify 
existence of references for well designed language. I think that 
designers of C++ just hated C pointers too much to think rationally.

By the way, I have little problem. I Wiki about C++ reference types I read:
"Once a reference is created, it cannot be later made to reference 
another object; we say it cannot be reseated. This is often done with 
pointers."
But in my VS 2003 C++ compiler you can easily put new value to 
reference, like code sample below. Do you know who is correct here?

int main() {
     int aa = 25;
     int & ra = aa;
     int bb = 323;
     ra = bb;
     printf("ra= %d\n", ra);
     int *ii = new int;
     *ii = 999;
     ra = *ii;
     printf("ra= %d\n", ra);
     ii = NULL;
     ra = *ii;
......
THis code compiled and run OK on VS 2003
0
5/3/2006 8:14:11 PM
Mishagam wrote:
> Noah Roberts wrote:
> > Mishagam wrote:
> >> Noah Roberts wrote:
> >>> Mishagam wrote:
> >>>
> >>>> C++ references are not SO different from pointers. Just like Roedy Green
> >>>> said - one more addressing mode. I doubt any well designed language
> >>>> (like Java) would have (or has) references.
> ...
> > C++ pointers and references have completely different purposes.
>
> 'purpose' is what language designers imagined references would be used
> for. Functionaly, as I understand, difference between references and
> pointers is little syntax sugar [ -> replaced with . ] + what values
> they can hold - references cannot hold null or objects allocated by new.
> But you CAN have reference to destructed object out of scope (or field
> in deleted object allocated on heap). Also references syntax resembles
> value objects enough that is is difficult to distinguish what you are
> using now. It is one more way where C++ loses C clarity.
> What I meant is difference with pointer is too small to justify
> existence of references for well designed language. I think that
> designers of C++ just hated C pointers too much to think rationally.

You say that references are little more than syntatic sugar and then
directly quote at least one way in which they are drastically different
below.  I guess logic isn't something you are good at.
>
> By the way, I have little problem. I Wiki about C++ reference types I read:
> "Once a reference is created, it cannot be later made to reference
> another object; we say it cannot be reseated. This is often done with
> pointers."
> But in my VS 2003 C++ compiler you can easily put new value to
> reference, like code sample below. Do you know who is correct here?
>
> int main() {
>      int aa = 25;
>      int & ra = aa;
>      int bb = 323;
>      ra = bb;
>      printf("ra= %d\n", ra);
>      int *ii = new int;
>      *ii = 999;
>      ra = *ii;
>      printf("ra= %d\n", ra);
>      ii = NULL;
>      ra = *ii;
> .....
> THis code compiled and run OK on VS 2003

You obviously don't understand what a reference is.  Print out aa and
you will have your answer.  Print out bb after your second change and
it may become more clear.

0
roberts.noah (1664)
5/3/2006 8:25:14 PM
[followups set to non-Java groups]

Mishagam wrote:

>> C++ pointers and references have completely different purposes.
> 
> 'purpose' is what language designers imagined references would be used
> for. Functionaly, as I understand, difference between references and
> pointers is little syntax sugar [ -> replaced with . ]

Nope. A reference is an alias for an object. Unlike a pointer, you cannot
take the address of the refering thing (the thing that's probably secretly
a pointer). It's secret because the compiler can optimize it away, and go
to the real object if possible.

> + what values 
> they can hold - references cannot hold null or objects allocated by new.

They can hold heap objects; they just shouldn't.

  int & i = *new int;
  delete &i;

That's valid but high risk.

> But you CAN have reference to destructed object out of scope (or field
> in deleted object allocated on heap).

Yep. Even thinking about i after my delete line is illegal.

> Also references syntax resembles 
> value objects enough that is is difficult to distinguish what you are
> using now. It is one more way where C++ loses C clarity.

There's a difference between clarity and exposed plumbing...

> What I meant is difference with pointer is too small to justify
> existence of references for well designed language. I think that
> designers of C++ just hated C pointers too much to think rationally.

If they burdened C++ with your misunderstandings of references, then your
point might be valid. References are good because they are the _weakest_
kind of alias or handle we have. Use them in preference to pointers.

> By the way, I have little problem. I Wiki about C++ reference types I
> read: "Once a reference is created, it cannot be later made to reference
> another object; we say it cannot be reseated. This is often done with
> pointers."
> But in my VS 2003 C++ compiler you can easily put new value to
> reference, like code sample below. Do you know who is correct here?
> 
> int main() {
>      int aa = 25;
>      int & ra = aa;
>      int bb = 323;
>      ra = bb;

That copys the value of bb into aa, which ra still refers to.

>      printf("ra= %d\n", ra);
>      int *ii = new int;
>      *ii = 999;
>      ra = *ii;

Right. Now that copies the 999 to the aa, which ra still refers to.

>      printf("ra= %d\n", ra);
>      ii = NULL;

I hope you didn't think that 'delete's ii. It just leaks the memory.

>      ra = *ii;

And that's undefined behavior.

So the well-defined parts of your sample program do indeed demonstrate how
references are aliases for their target objects. You may want to debug your
program, or even look at its opcodes, to see what's going on. The compiler
might optimize ra away, and the statement ra = bb might produce the same
opcodes as aa = bb.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/3/2006 8:30:28 PM
"Andrew McDonagh" <news@andmc.com> wrote in message 
news:e3asc8$gj7$1@news.freedom2surf.net...
>
> Java has a thing called 'references'.  Its more like a C Pointer than a 
> C++ reference, as in it can be nulled.  The major difference is that no 
> pointer arithmetic can be done with it.
>
> Java references are passed by value. The objects that they point to does 
> actually move.

    I'm assuming you mean "does NOT actually move".

    - Oliver 

0
owong (6178)
5/3/2006 9:05:21 PM
"Chris Smith" <cdsmith@twu.net> wrote in message 
news:MPG.1ec296c6e065ed2e9896a7@news.astraweb.com...
>>  - when a smart editor like Eclipse can finish
>>     every line for you, it makes you wonder
>>     what the language is _there_ for!
>
> This is perhaps a useful thing for some to wonder, but only so that they
> can get around to knowing the answer.  The answer is that we're talking
> about two different sets of things:
>
> (1) What can be reasonably guessed, with the assurance that the
> programmer will see the guess and correct it if it's wrong?
>
> (2) What is so certain to be the programmers meaning that it can be done
> without guessing?
>
> Clearly, there are things that fit into set (1) without also fitting
> into set (2).  Those things should be implemented with IDE auto-complete
> features, and not with the language itself.  Whether the boundaries are
> drawn correctly is another issue, and there are undoubtedly places where
> the boundaries could be drawn better... but criticizing the need for
> auto-complete entirely doesn't look reasonable.

    Also, when some types in:

public class Foo i

    the Eclipse Editor, and just about anyone else who is familiar with 
Java, could probably safely assume that the programmer is about to type in 
"mplements" to yield:

public class Foo implements

    does that mean that the designers of Java should have used the string 
"i" instead of "implements" as the keyword? It depends on whether one values 
clarity or terseness.

    - Oliver 

0
owong (6178)
5/3/2006 9:16:31 PM
"Mishagam" <noemail@provider.com> wrote in message 
news:na86g.15594$P65.5917@southeast.rr.com...
> int main() {
>     int aa = 25;
>     int & ra = aa;
>     int bb = 323;
>     ra = bb;
>     printf("ra= %d\n", ra);
>     int *ii = new int;
>     *ii = 999;
>     ra = *ii;
>     printf("ra= %d\n", ra);
>     ii = NULL;
>     ra = *ii;
> .....
> THis code compiled and run OK on VS 2003

Wow.   Noah your point is well taken.   I have just been convinced that Java 
is a superior programming language for not allowing this kind of BS.

--
LTP

:) 


0
5/3/2006 9:21:23 PM
"Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote in message 
news:44587b75$0$656$bed64819@news.gradwell.net...
> Oliver Wong wrote:
>
>>     (referring to http://www.tiobe.com/tiobe_index/images/tpci_trends.gif
>> as of May 2nd, 2006): I wonder what happened in 2004 that made Java drop
>> considerably, and everything else jump up a bit.
>
> From the TIOBE faq:
>
> Q: What happened to Java in April 2004? Did you change your methodology?
> A: No, we did not change our methodology at that time. Google changed its
> methodology. They performed a general sweep action to get rid of all kinds 
> of
> web sites that had been pushed up. As a consequence, there was a huge drop 
> for
> languages such as Java and C++. In order to minimize such fluctuations in 
> the
> future, we added two more search engines (MSN and Yahoo) a few months 
> after
> this incident.

It's a flawed method of rating to begin with.    I do not believe we can 
directly infer that web page occurrences some how indicate usage.   It may 
provide some kind of vague correlation - I suppose.

--
LTP

:) 


0
5/3/2006 9:24:25 PM
Luc The Perverse wrote:

>>     int aa = 25;
>>     int & ra = aa;
>>     int bb = 323;
>>     ra = bb;
>>     printf("ra= %d\n", ra);
>>     int *ii = new int;
>>     *ii = 999;
>>     ra = *ii;
>>     printf("ra= %d\n", ra);
>>     ii = NULL;
>>     ra = *ii;

> Wow.   Noah your point is well taken.   I have just been convinced that
> Java is a superior programming language for not allowing this kind of BS.

Noah's point - between the cheap shots - was that C++ does _not_ allow that
kind of BS.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/3/2006 9:32:32 PM
Luc The Perverse wrote:
> "Mishagam" <noemail@provider.com> wrote in message
> news:na86g.15594$P65.5917@southeast.rr.com...
> > int main() {
> >     int aa = 25;
> >     int & ra = aa;
> >     int bb = 323;
> >     ra = bb;
> >     printf("ra= %d\n", ra);
> >     int *ii = new int;
> >     *ii = 999;
> >     ra = *ii;
> >     printf("ra= %d\n", ra);
> >     ii = NULL;
> >     ra = *ii;
> > .....
> > THis code compiled and run OK on VS 2003
>
> Wow.   Noah your point is well taken.

Can't figure out who you're quoting??

   I have just been convinced that Java
> is a superior programming language for not allowing this kind of BS.

Java doesn't allow this huh?  Hmm...guess that will be news for some.
Can't exactly function as a language I guess...

0
roberts.noah (1664)
5/3/2006 9:33:47 PM
Luc The Perverse schrieb:
> It's a flawed method of rating to begin with.    I do not believe we can 
> directly infer that web page occurrences some how indicate usage.   It may 
> provide some kind of vague correlation - I suppose.

I think a simple chart of sourceforge projects by programming languages 
would be much more meaningful. It wouldn't be representational because 
it's far from complete, but at least you know what you are measuring.


Timo
0
timo.stamm (231)
5/3/2006 9:58:30 PM
In comp.lang.java.advocacy, Noah Roberts
<roberts.noah@gmail.com>
 wrote
on 3 May 2006 09:51:31 -0700
<1146675091.350372.260640@e56g2000cwe.googlegroups.com>:
>
> Mishagam wrote:
>> Noah Roberts wrote:
>> > Mishagam wrote:
>> >
>> >> C++ references are not SO different from pointers. Just like Roedy Green
>> >> said - one more addressing mode. I doubt any well designed language
>> >> (like Java) would have (or has) references.
>> >
>> > Java has references.
>> >
>> Excuse me. I meant separate references and pointers with so close
>> functions. Java has references, but they have also some features of C++
>> pointers like they can be null.
>
> C++ pointers and references have completely different purposes.  The
> fact that Java lacks pointers is just another can't.

Pointers are a means to an end (well, so is everything else in
a computer language, really).  Exactly what is it that Java can't
do in this space?

(Especially since java.nio.channels.FileChannel.map() is Java's
answer to C/C++'s mmap() method.)

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

It would help if "uniform" = "consistent with type declaration".

int a[5];
int * b = a;

just isn't quite kosher to those schooled in Pascal, convenient as it
might be otherwise; it should be:

int a[5];
int * b = &a[0];

(I don't remember the actual Pascal offhand.  It's been too long,
and in any event standard Pascal didn't have an addr() method.)

I'm also not all that sure of the usefulness of such things as

const char * p = "A rainy day in Georgia";
const char * q = p + 15; // q="Georgia"

unless q is an index variable stepping through p's string,
usually in a for or while loop:

for(q = p; *q; q++) { ... }

And of course there are the problems with such things as punning:

char * p = "Another rainy day in Georgia";

void routine(const char * p, char * q)
{
    for(;*p;p++, q++) *q = (*p) + 1;
}

routine(p,p);

which could confuse maintainers of routine() -- especially
if routine() for some reason frees its arguments without
checking them first.

For its part Java has its own problems with arrays:

  int[] s = new int[]{1,2,3};
  int[][] a = new int[][]{
    s,
    new int[]{1,2,3},
    s,
    new int[]{4,5},
    new int[]{6},
    null,
    new int[]{7,8,9,10,11}
  }

can quite easily trip up naive coding in programs; also,
the int/Integer dichtotomy is a bit of a wart, though not
nearly as bad a lesion as it could have been had Integer
been implemented with a setIntvalue() method.

I like the syntax, though. :-)

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
5/3/2006 10:00:42 PM
Timo Stamm wrote:
> Luc The Perverse schrieb:
>> It's a flawed method of rating to begin with.    I do not believe we 
>> can directly infer that web page occurrences some how indicate 
>> usage.   It may provide some kind of vague correlation - I suppose.
> 
> I think a simple chart of sourceforge projects by programming languages 
> would be much more meaningful. It wouldn't be representational because 
> it's far from complete, but at least you know what you are measuring.

SourceForge is very non random selection, not very representative of all 
language usages.
0
5/3/2006 10:35:59 PM
Oliver Wong schrieb:
> "Chris Smith" <cdsmith@twu.net> wrote in message 
> news:MPG.1ec296c6e065ed2e9896a7@news.astraweb.com...
>>>  - when a smart editor like Eclipse can finish
>>>     every line for you, it makes you wonder
>>>     what the language is _there_ for!
>> [...]
> 
>    Also, when some types in:
> 
> public class Foo i
> 
>    the Eclipse Editor, and just about anyone else who is familiar with 
> Java, could probably safely assume that the programmer is about to type 
> in "mplements" to yield:
> 
> public class Foo implements 
> 
>    does that mean that the designers of Java should have used the string 
> "i" instead of "implements" as the keyword? It depends on whether one 
> values clarity or terseness.

No. But maybe it could have looked like this:

   class Foo : List

"public" is made default, ":" replaces "implements" (extends could be 
replaced by "<").


A better example for superfluous verbosity:

   ArrayList<Entry<String, Integer, Object>> l = new
   ArrayList<Entry<String, Integer, Object>>();

Wouldn't it be nice to have local type inference here?

   def l = new ArrayList<Entry<String, Integer, Object>>();


Getters and Setters are another good example. Sure, the IDE can generate 
them. But C#s properties are a lot more elegant. You can start with 
simple public members and introduce getters and setters later without 
any need to change the clients of the class.


Anonymous classes are also quickly generated by the IDE, but true 
closures with a short syntax would certainly make the code more 
expressive and readable.


I don't say that these changes should be made. Java sacrifices 
flexibility and expressiveness for readability, and that's fine in many 
situations. But I think Phlip raised a valid point, even if it was 
comically exaggerated.


Timo
0
timo.stamm (231)
5/3/2006 10:39:32 PM
Mishagam schrieb:
> Timo Stamm wrote:
>> Luc The Perverse schrieb:
>>> It's a flawed method of rating to begin with.    I do not believe we 
>>> can directly infer that web page occurrences some how indicate 
>>> usage.   It may provide some kind of vague correlation - I suppose.
>>
>> I think a simple chart of sourceforge projects by programming 
>> languages would be much more meaningful. It wouldn't be 
>> representational because it's far from complete, but at least you know 
>> what you are measuring.
> 
> SourceForge is very non random selection, not very representative of all 
> language usages.

I know my english isn't perfect, but did you even read what you replied to?


Timo
0
timo.stamm (231)
5/3/2006 10:49:19 PM
Timo Stamm wrote:
> Mishagam schrieb:
>> Timo Stamm wrote:
>>> Luc The Perverse schrieb:
>>>> It's a flawed method of rating to begin with.    I do not believe we 
>>>> can directly infer that web page occurrences some how indicate 
>>>> usage.   It may provide some kind of vague correlation - I suppose.
>>>
>>> I think a simple chart of sourceforge projects by programming 
>>> languages would be much more meaningful. It wouldn't be 
>>> representational because it's far from complete, but at least you 
>>> know what you are measuring.
>>
>> SourceForge is very non random selection, not very representative of 
>> all language usages.
> 
> I know my english isn't perfect, but did you even read what you replied to?
>
I meant that not only SourceForge doesn't represent all programmers, it 
also represents very non random subset of programmers [and this 
selection is very potentially dependent from language used], so any 
conclusions about SourceForge projects has very little relation to 
language use in general world.
Much better (through less "complete") would be to select 1000 
programmers in random and ask them.
0
5/3/2006 11:00:52 PM
Timo Stamm wrote:

> Getters and Setters are another good example. Sure, the IDE can generate
> them. But C#s properties are a lot more elegant.

A good design that doesn't need them at all is slightly more elegant
there. ;-)

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/3/2006 11:10:35 PM
Phlip schrieb:
> Timo Stamm wrote:
> 
>> Getters and Setters are another good example. Sure, the IDE can generate
>> them. But C#s properties are a lot more elegant.
> 
> A good design that doesn't need them at all is slightly more elegant
> there. ;-)

That's the point.

The following link explains it better than I did
http://cephas.net/blog/2004/02/16/c_public_properties_vs_java_getx_and_setx.html


Timo
0
timo.stamm (231)
5/4/2006 12:00:50 AM
Followups set to non-Java groups.

Timo Stamm wrote:

>>> Getters and Setters are another good example. Sure, the IDE can generate
>>> them. But C#s properties are a lot more elegant.
>>
>> A good design that doesn't need them at all is slightly more elegant
>> there. ;-)
>
> That's the point.

No it isn't.

> The following link explains it better than I did
> http://cephas.net/blog/2004/02/16/c_public_properties_vs_java_getx_and_setx.html

The more elegant design follows "the hollywood principle". That means "tell 
don't ask". (Specifically it means "don't call us we'll call you", but with 
slightly greater odds of getting called!)

In the more elegant design, clients tell classes what to do. Clients don't 
Get variables (regardless of whatever syntactic sugar is available), then 
change data, then call Set variables to push the data back in. Clients 
should send messages to servant classes, and these should perform whatever 
secret manipulations are required to obey these commands.

Put another way, classes should obey both the physical and logical meaning 
of the rule "no public data". Yes, a Get method is slightly more 
encapsulated that raw public data. But it's still not fully encapsulated.

The blog you cite quotes Martin Fowler, who assumes we know this before 
discussing the C# property system.

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! 


0
phlipcpp (2771)
5/4/2006 2:10:17 AM
In comp.lang.java.advocacy, Mishagam
<noemail@provider.com>
 wrote
on Wed, 03 May 2006 20:14:11 GMT
<na86g.15594$P65.5917@southeast.rr.com>:
> Noah Roberts wrote:
>> Mishagam wrote:
>>> Noah Roberts wrote:
>>>> Mishagam wrote:
>>>>
>>>>> C++ references are not SO different from pointers. Just like Roedy Green
>>>>> said - one more addressing mode. I doubt any well designed language
>>>>> (like Java) would have (or has) references.
> ...
>> C++ pointers and references have completely different purposes.  
>
> 'purpose' is what language designers imagined references would be used 
> for. Functionaly, as I understand, difference between references and 
> pointers is little syntax sugar [ -> replaced with . ] + what values 
> they can hold - references cannot hold null or objects allocated by new. 
> But you CAN have reference to destructed object out of scope (or field 
> in deleted object allocated on heap). Also references syntax resembles 
> value objects enough that is is difficult to distinguish what you are 
> using now. It is one more way where C++ loses C clarity.
> What I meant is difference with pointer is too small to justify 
> existence of references for well designed language. I think that 
> designers of C++ just hated C pointers too much to think rationally.
>
> By the way, I have little problem. I Wiki about C++ reference types I read:
> "Once a reference is created, it cannot be later made to reference 
> another object; we say it cannot be reseated. This is often done with 
> pointers."
> But in my VS 2003 C++ compiler you can easily put new value to 
> reference, like code sample below. Do you know who is correct here?

You can certainly store through the reference.  See below for a
line-by-line description of what this program is actually doing.

(assuming #include <cstdio> at the top, for completeness)

>
> int main() {

OK, no runtime arguments expected during invocation.

>      int aa = 25;

OK, declaration and initialization of auto variable aa.

>      int & ra = aa;

OK, declaration of reference ra, an alias for aa.  Scope is
routine main().  (It is possible to declare a static reference
to a static variable.  It is also possible to declare a
local reference to a static variable.  It is not possible to
declare a static reference to a local variable, since the local
variable is out of scope.)

>      int bb = 323;

OK, declaration and initialization of auto variable bb.

>      ra = bb;

OK, assignment of bb to aa (via ra).  aa now contains 323.

>      printf("ra= %d\n", ra);

OK, "ra= 323\n" is output.

>      int *ii = new int;

OK, allocation of a dynamic int.

>      *ii = 999;

OK, *ii is now initialized to the value 999.

>      ra = *ii;

OK, aa now contains 999.

>      printf("ra= %d\n", ra);

OK, "ra= 999\n" is output.

>      ii = NULL;

OK, ii now contains the pointer NULL.

>      ra = *ii;

NULL pointer dereference, should cause a failure.
Never mind what *ii is trying to assign to; the system
will dutifully load ii into a register, which will then
contain 0.  It will then dereference that register,
causing an exception.

> .....
> THis code compiled and run OK on VS 2003

Then VS2003's generated code may have a problem.
It segfaults on my machine, as expected.

If you really want I can dump the generated code here as
well, to show you what's going on.  There's not much in
the way of GCC-generated comments, so I'll put my own in.
This is on an x86/32 machine running Linux; the syntax is a
little different from Intel's standard (e.g., Intel would
write "movl $25, -4(%ebp)" as "MOV LONG PTR -4(EPB),#25"
or some such; the reasons for the flip are historical).

        .section        .rodata
..LC0:
        .string "ra= %d\n"
        .text
        .align 2
..globl main
        .type   main, @function
main:
..LFB3:
        pushl   %ebp                 ; standard frame
..LCFI0:
        movl    %esp, %ebp           ; ... adjustment code
..LCFI1:
        subl    $24, %esp            ; apparently this is scratch area
                                     ; for subroutine calls
..LCFI2:
        andl    $-16, %esp           ; stack alignment
        movl    $0, %eax             ; clear %EAX
        subl    %eax, %esp           ; No-operation, but why??
        movl    $25, -4(%ebp)        ; store 25 into aa
        leal    -4(%ebp), %eax       ; get aa's location into %EAX
        movl    %eax, -8(%ebp)       ; and store it into ra, which makes
                                     ; it a de facto pointer which is
                                     ; never moved, as far as the code
                                     ; generation is concerned -- looks
                                     ; fairly straightforward from a
                                     ; backend's standpoint, but may be
                                     ; slightly misleading here
        movl    $323, -12(%ebp)      ; initialize bb
        movl    -8(%ebp), %edx       ; get ra's location into %EDX
                                     ; this looks a little weird but
                                     ; remember that ra is supposed to
                                     ; be a reference; however, the
                                     ; compiler is treating it as a sort
                                     ; of const pointer
        movl    -12(%ebp), %eax      ; get bb's value (323) into %EAX
        movl    %eax, (%edx)         ; store 323 into aa, which is what
                                     ; ra is (always) referring to
        movl    -8(%ebp), %eax       ; get ra's location
        movl    (%eax), %eax         ; ... then its value
        movl    %eax, 4(%esp)        ; construct ...
        movl    $.LC0, (%esp)        ; ... parameter list for printf()
        call    printf               ; ... and call it.
        movl    $4, (%esp)           ; construct parameter list
        call    _Znwj                ; ... and call global 'operator new'
        movl    %eax, -16(%ebp)      ; stuff the pointer into ii
        movl    -16(%ebp), %eax      ; now get ii back out again (!)
        movl    $999, (%eax)         ; and shove 999 into it
        movl    -8(%ebp), %edx       ; get ra's location (still aa)
                                     ; into %EDX
        movl    -16(%ebp), %eax      ; get ii's *value* into %EAX
        movl    (%eax), %eax         ; dereference ii
        movl    %eax, (%edx)         ; ... and store it into aa
        movl    -8(%ebp), %eax       ; now get ra's location again
        movl    (%eax), %eax         ; ... and fetch its value
        movl    %eax, 4(%esp)        ; construct ...
        movl    $.LC0, (%esp)        ; ... parameter list for printf()
        call    printf               ; and call it.
        movl    $0, -16(%ebp)        ; zap ii
        movl    -8(%ebp), %edx       ; get ra's location yet again
        movl    -16(%ebp), %eax      ; get ii's value again
        movl    (%eax), %eax         ; ***CRASH***
        movl    %eax, (%edx)         ; store ii's deferenced value
        movl    $0, %eax             ; compiler-inserted 'return 0'
        leave                        ; bye...
        ret

Obviously, the compiler's doing some interesting (and rather dumb)
things in code generation.  The comments are mine, of course, and
hopefully illustrative of its "thinking" process.  (For those
schooled in compiler theory, I for one find it interesting that
it's not pushing things onto the stack, but using offsets.)

If I turn on the optimizer (-O) the program gets far shorter,
and probably faster (for what it's worth here).

..globl main
        .type   main, @function
main:
..LFB14:
        pushl   %ebp                 ; standard frame ...
..LCFI0:
        movl    %esp, %ebp           ; ... adjustment code
..LCFI1:
        subl    $8, %esp             ; space for parameters
..LCFI2:
        andl    $-16, %esp           ; align/space for aa,bb, and ii,
                                     ; presumably
        movl    $323, 4(%esp)        ; aa=323 store directly
                                     ; into printf()'s parameter list;
                                     ; the compiler has correctly
                                     ; concluded that the '25' value is
                                     ; never used, and also doesn't
                                     ; bother with an explicit store
        movl    $.LC0, (%esp)        ; setup for printf()
        call    printf               ; and call
        movl    $4, (%esp)           ; we do need 4 bytes
        call    _Znwj                ; ... from 'operator new'
        movl    $999, (%eax)         ; initialize *ii = 999
        movl    $999, 4(%esp)        ; and also store it directly into
                                     ; printf()'s parameter list again
                                     ; since we've really done very
                                     ; little here
        movl    $.LC0, (%esp)        ; setup again
        call    printf               ; and call
        movl    $0, %eax             ; store 0 into ii, presumably
        movl    %ebp, %esp           ; ... hey, wait, you're supposed
        popl    %ebp                 ; ... to CRASH HERE!
        ret

It would appear that gcc's optimizer has eliminated a
store into *ii at the very end, and "saved" the program.
This is actually an optimizer bug.  I suspect VC++ is doing
something similar.

I do not advocate depending on this bug, of course.

Your program would probably be more illustrative if you
were to replace your printf("ra= %d\n", ra) calls with
printf("ra= %d aa= %d bb= %d\n", ra, aa, ab) calls.

I'll have to see if 3.4.6 has the same problem.  The code is from 3.3.6.

(Note that crackers do this sort of thing on an ongoing basis, looking
for exploitable loopholes in assembly code.  No, I'm not a cracker, but
I do know several dialects of assembler, including this one.)

Now....after *all* that, I can throw another problem out at you.
Suppose one has the code

#include <cstdio>
int main() {
    int a[2];
    int b[2];
    int & ra0 = &a[0];
    int & ra1 = &a[1];
    a[0] = 1;
    a[1] = 2;
    b[0] = 3;
    b[1] = 4;

    ra0 = b[0];
    ra1 = b[1];

    printf("%d %d %d %d\n", a[0], a[1], b[0], b[1]);

    return 0;
}

The output is

3 4 3 4

and it should be very clear as to why.

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
5/4/2006 3:00:35 AM
"Phlip" <phlipcpp@yahoo.com> wrote in
news:dod6g.27314$NS6.20989@newssvr30.news.prodigy.com: 

> Followups set to non-Java groups.
> 
> Timo Stamm wrote:
> 
>>>> Getters and Setters are another good example. Sure, the IDE can
>>>> generate them. But C#s properties are a lot more elegant.
>>>
>>> A good design that doesn't need them at all is slightly more elegant
>>> there. ;-)
>>
>> That's the point.
> 
> No it isn't.
> 
>> The following link explains it better than I did
>> http://cephas.net/blog/2004/02/16/c_public_properties_vs_java_getx_and
>> _setx.html 
> 
> The more elegant design follows "the hollywood principle". That means
> "tell don't ask". (Specifically it means "don't call us we'll call
> you", but with slightly greater odds of getting called!)
> 
> In the more elegant design, clients tell classes what to do. Clients
> don't Get variables (regardless of whatever syntactic sugar is
> available), then change data, then call Set variables to push the data
> back in. Clients should send messages to servant classes, and these
> should perform whatever secret manipulations are required to obey
> these commands. 
> 
> Put another way, classes should obey both the physical and logical
> meaning of the rule "no public data". Yes, a Get method is slightly
> more encapsulated that raw public data. But it's still not fully
> encapsulated. 
> 
> The blog you cite quotes Martin Fowler, who assumes we know this
> before discussing the C# property system.
> 

You are correct that the data should be private. 

But I like the IDEA of C# Properties generating functions. I feel it 
encourages the use of them to provide non-variable results. For example, 
a Square might have a property Area, (get only) that returns the area of 
the square. Or a Color Object might have multiple Properties, RGB or CMYK 
for example, that translate to different representations. Internally, it 
may use some other definition but that state can only be changed by using 
the properties you exposed.

Otis

0
obricker (68)
5/4/2006 3:05:20 AM
The Ghost In The Machine wrote:

>>      ii = NULL;
>>      ra = *ii;

>> THis code compiled and run OK on VS 2003
>
> Then VS2003's generated code may have a problem.
> It segfaults on my machine, as expected.

I can recall an MS situation where *NULL contained a 0ul in each address 
space. That's because so many NULLs were causing problems that MS decided to 
make *NULL bizarrely temporarily useful. (char*)0 would appear to be "", for 
example.

I could be wrong; all this is both undefined behavior and off-topic, etc...

>        movl    -8(%ebp), %edx       ; get ra's location (still aa)
>                                     ; into %EDX

props!

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!! 


0
phlipcpp (2771)
5/4/2006 3:24:34 AM
Phlip wrote:

> In the more elegant design, clients tell classes what to do. Clients don't
> Get variables (regardless of whatever syntactic sugar is available), then
> change data, then call Set variables to push the data back in. Clients
> should send messages to servant classes, and these should perform whatever
> secret manipulations are required to obey these commands.

Agreed.

Still, an argument could be made that if a program has design errors, then they
should /look/ like design errors too.

So the correct design for the language is for it to provide "properties"
instead of requiring get/set() pairs.  And the correct design for any program
written /in/ that language is for it not to use properties at all.

;-)

    -- chris




0
chris.uppal (3980)
5/4/2006 10:10:06 AM
Phlip schrieb:
> Followups set to non-Java groups.
> 
> Timo Stamm wrote:
> 
>>>> Getters and Setters are another good example. Sure, the IDE can generate
>>>> them. But C#s properties are a lot more elegant.
>>> A good design that doesn't need them at all is slightly more elegant
>>> there. ;-)
>> That's the point.
> 
> No it isn't.

Then I misunderstood your point.

I thought that "them" referred to accessor methods. Now I realize that 
you referred to public members in general.


>> The following link explains it better than I did
>> http://cephas.net/blog/2004/02/16/c_public_properties_vs_java_getx_and_setx.html
> 
> The more elegant design follows "the hollywood principle". That means "tell 
> don't ask". (Specifically it means "don't call us we'll call you", but with 
> slightly greater odds of getting called!)
> 
> In the more elegant design, clients tell classes what to do. Clients don't 
> Get variables (regardless of whatever syntactic sugar is available), then 
> change data, then call Set variables to push the data back in. Clients 
> should send messages to servant classes, and these should perform whatever 
> secret manipulations are required to obey these commands.
> 
> Put another way, classes should obey both the physical and logical meaning 
> of the rule "no public data". Yes, a Get method is slightly more 
> encapsulated that raw public data. But it's still not fully encapsulated.

All agreed. But I don't think that full encapsulation is appropriate in 
all cases, even in a clean object oriented design.

I think the following article of Martin Fowler has a balanced view on 
the topic:

http://www.martinfowler.com/bliki/GetterEradicator.html


Timo


> The blog you cite quotes Martin Fowler, who assumes we know this before 
> discussing the C# property system.
0
timo.stamm (231)
5/4/2006 12:17:54 PM
In comp.lang.java.advocacy, Phlip
<phlipcpp@yahoo.com>
 wrote
on Thu, 04 May 2006 03:24:34 GMT
<Ste6g.826$zR3.33@newssvr33.news.prodigy.com>:
> The Ghost In The Machine wrote:
>
>>>      ii = NULL;
>>>      ra = *ii;
>
>>> THis code compiled and run OK on VS 2003
>>
>> Then VS2003's generated code may have a problem.
>> It segfaults on my machine, as expected.
>
> I can recall an MS situation where *NULL contained a 0ul in each address 
> space. That's because so many NULLs were causing problems that MS decided to 
> make *NULL bizarrely temporarily useful. (char*)0 would appear to be "", for 
> example.
>
> I could be wrong; all this is both undefined behavior and off-topic, etc...
>
>>        movl    -8(%ebp), %edx       ; get ra's location (still aa)
>>                                     ; into %EDX
>
> props!
>

I'll admit, I for one would love to see an -S option in Java.  Best I
can do is to use BCEL afterwards. :-)  Or maybe gcj.

ObOffTopic: It appears gcc has a similar problem.  I'll have to see if a
"dead" pointer store is mistakenly optimized away in a non-main()
routine; that could lead to some subtle C++ bugs.

Microsoft may be having a hangover from its DOS days, when 0000:0000
was a valid address of sorts. :-)

-- 
#191, ewill3@earthlink.net
Windows Vista.  Because it's time to refresh your hardware.  Trust us.
0
ewill5 (11075)
5/4/2006 2:00:08 PM
The Ghost In The Machine wrote:
> In comp.lang.java.advocacy, Noah Roberts
> <roberts.noah@gmail.com>
>  wrote
> on 3 May 2006 09:51:31 -0700
> <1146675091.350372.260640@e56g2000cwe.googlegroups.com>:
> >
> > Mishagam wrote:
> >> Noah Roberts wrote:
> >> > Mishagam wrote:
> >> >
> >> >> C++ references are not SO different from pointers. Just like Roedy Green
> >> >> said - one more addressing mode. I doubt any well designed language
> >> >> (like Java) would have (or has) references.
> >> >
> >> > Java has references.
> >> >
> >> Excuse me. I meant separate references and pointers with so close
> >> functions. Java has references, but they have also some features of C++
> >> pointers like they can be null.
> >
> > C++ pointers and references have completely different purposes.  The
> > fact that Java lacks pointers is just another can't.
>
> Pointers are a means to an end (well, so is everything else in
> a computer language, really).  Exactly what is it that Java can't
> do in this space?

None that matter to Java.

> >
> > I can't say Java's, "everything is a reference except when it is not,"
> > is a move up from having explicit value, reference, and pointer
> > semantics that operate in a uniform manner.
> >
>
> It would help if "uniform" = "consistent with type declaration".
>
> int a[5];
> int * b = a;
>
> just isn't quite kosher to those schooled in Pascal, convenient as it
> might be otherwise; it should be:
>
> int a[5];
> int * b = &a[0];

You can use this syntax if you wish and believe it makes more sense.
Nothing stopping you there.  You can even establish a coding standard
to say the former is not allowed.  Nothing stopping you there.  Since
C++ doesn't make pointless artificial restrictions just to enforce a
policy that is really a developer side issue you can also do the former
if it makes sense to you, and it does to most C++ programmers (who
cares about programmers in another language...code in the language you
are using).
>
> (I don't remember the actual Pascal offhand.  It's been too long,
> and in any event standard Pascal didn't have an addr() method.)

Hmmm...I don't see Pascal used for a lot of stuff.
>
> I'm also not all that sure of the usefulness of such things as
>
> const char * p = "A rainy day in Georgia";
> const char * q = p + 15; // q="Georgia"
>
> unless q is an index variable stepping through p's string,
> usually in a for or while loop:
>
> for(q = p; *q; q++) { ... }

Umm...yeah, that is one use....why did you say you weren't sure of its
usefulness??!!
>
> And of course there are the problems with such things as punning:
>
> char * p = "Another rainy day in Georgia";
>
> void routine(const char * p, char * q)
> {
>     for(;*p;p++, q++) *q = (*p) + 1;
> }

Well that function is bad for numerous reasons, not the least of which
is its use of char* instead of string.  There are numerous ambiguities
that need be established that can only be so by looking at that code.
For one, who owns q?

Also, even a java programmer should see that it blows up.  If you are
familiar with pointers enough to even know what that does you can see
that it doesn't work.
>
> routine(p,p);
>
> which could confuse maintainers of routine() -- especially
> if routine() for some reason frees its arguments without
> checking them first.

Yes, who owns q?

That routine is just poorly designed and even poorly implemented.  Yes,
you can write bad code in any language and C++ is certainly no
exception to that.
>
> For its part Java has its own problems with arrays:
>
>   int[] s = new int[]{1,2,3};

Ick, and you say C++ has ugly syntax.

int s[] = {1, 2, 3};

0
roberts.noah (1664)
5/4/2006 2:57:24 PM
"Timo Stamm" <timo.stamm@arcor.de> wrote in message 
news:44593125$0$4504$9b4e6d93@newsread2.arcor-online.net...
> Oliver Wong schrieb:
>>
>>    does that mean that the designers of Java should have used the string 
>> "i" instead of "implements" as the keyword? It depends on whether one 
>> values clarity or terseness.
>
> No. But maybe it could have looked like this:
>
>   class Foo : List
>
> "public" is made default, ":" replaces "implements" (extends could be 
> replaced by "<").

    Not sure "<" is the best choice, as it might be mistaken for a generic 
type argument, but otherwise the idea is sound.

>
>
> A better example for superfluous verbosity:
>
>   ArrayList<Entry<String, Integer, Object>> l = new
>   ArrayList<Entry<String, Integer, Object>>();
>
> Wouldn't it be nice to have local type inference here?
>
>   def l = new ArrayList<Entry<String, Integer, Object>>();

    I had forgotten about this feature in C++, and I can see the utility of 
it. These two syntactic-sugar changes sound harmless enough that I think you 
could (relatively) easily write a compiler that compiles from this new 
language back to "plain" Java, and from there run the standard java compiler 
to get the class files (or gcj for executables or whatever).

>
> Getters and Setters are another good example. Sure, the IDE can generate 
> them. But C#s properties are a lot more elegant. You can start with simple 
> public members and introduce getters and setters later without any need to 
> change the clients of the class.

The language could forbid public fields altogether, and have

<code>
public int foo;
</code>

be syntactic sugar for

<code>
private int foo;

public int foo {
  get { return foo; }
  set { foo = value; }
}
</code>

assuming the language had some sort of mechanism for disabiguating between 
the public property and the private field.

    - Oliver 

0
owong (6178)
5/4/2006 3:00:41 PM
Timo Stamm wrote:

> No. But maybe it could have looked like this:
>
>    class Foo : List
>
> "public" is made default, ":" replaces "implements" (extends could be
> replaced by "<").

Don't know if you meant to imply that C++ works that way but it
doesn't.  "public" is not the default inheritance mode, private is.
>
>
> A better example for superfluous verbosity:
>
>    ArrayList<Entry<String, Integer, Object>> l = new
>    ArrayList<Entry<String, Integer, Object>>();
>
> Wouldn't it be nice to have local type inference here?
>
>    def l = new ArrayList<Entry<String, Integer, Object>>();

You mean like this?:

typedef ArrayList<Entry<String, Integer, Object> > AL;

AL l1;
AL l2;

VERY commonly done.
>
>
> Getters and Setters are another good example. Sure, the IDE can generate
> them. But C#s properties are a lot more elegant. You can start with
> simple public members and introduce getters and setters later without
> any need to change the clients of the class.

Getters and Setters are just poor design indicating that perhapse a
class is not the best data type to represent your data or that your
classes are lazy.

0
roberts.noah (1664)
5/4/2006 3:07:17 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146754644.830793.114060@j73g2000cwa.googlegroups.com...
>>
>> char * p = "Another rainy day in Georgia";
>>
>> void routine(const char * p, char * q)
>> {
>>     for(;*p;p++, q++) *q = (*p) + 1;
>> }
>
> Well that function is bad for numerous reasons, not the least of which
> is its use of char* instead of string.  There are numerous ambiguities
> that need be established that can only be so by looking at that code.
> For one, who owns q?
>
> Also, even a java programmer should see that it blows up.  If you are
> familiar with pointers enough to even know what that does you can see
> that it doesn't work.

    I think to grok the above code, you have to know certain things that you 
might never learn if you programmed only in Java, such as the idea that char 
strings are terminated by 0.

    - Oliver 

0
owong (6178)
5/4/2006 3:10:58 PM
Oliver Wong wrote:
> "Noah Roberts" <roberts.noah@gmail.com> wrote in message
> news:1146754644.830793.114060@j73g2000cwa.googlegroups.com...
> >>
> >> char * p = "Another rainy day in Georgia";
> >>
> >> void routine(const char * p, char * q)
> >> {
> >>     for(;*p;p++, q++) *q = (*p) + 1;
> >> }
> >
> > Well that function is bad for numerous reasons, not the least of which
> > is its use of char* instead of string.  There are numerous ambiguities
> > that need be established that can only be so by looking at that code.
> > For one, who owns q?
> >
> > Also, even a java programmer should see that it blows up.  If you are
> > familiar with pointers enough to even know what that does you can see
> > that it doesn't work.
>
>     I think to grok the above code, you have to know certain things that you
> might never learn if you programmed only in Java, such as the idea that char
> strings are terminated by 0.

If you don't understand that you never would have written it.

You might not understand the following if you programmed only in
QBasic:

class X implements Y {}

0
roberts.noah (1664)
5/4/2006 3:55:26 PM
In article <1146754644.830793.114060@j73g2000cwa.googlegroups.com>,
Noah Roberts <roberts.noah@gmail.com> wrote:
>
>The Ghost In The Machine wrote:
>>
>> For its part Java has its own problems with arrays:
>>
>>   int[] s = new int[]{1,2,3};
>
>Ick, and you say C++ has ugly syntax.
>
>int s[] = {1, 2, 3};

This exact line will also work as expected in Java.

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
5/4/2006 3:59:38 PM
Noah Roberts wrote:

>> Wouldn't it be nice to have local type inference here?
>>
>>def l = new ArrayList<Entry<String, Integer, Object>>();
> 
> You mean like this?:
> 
> typedef ArrayList<Entry<String, Integer, Object> > AL;
> 
> AL l1;
> AL l2;
> 
> VERY commonly done.

By the programmer instead of the compiler.

Computers exist to automate rote tasks.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
0
phlip2005 (2215)
5/4/2006 4:06:09 PM
In article <mjk2521e3uu9fqn2nh5cs02t6qo96nilma@4ax.com>, 
my_email_is_posted_on_my_website@munged.invalid says...

[ ... ]

> I wonder if someday we will have a language that lets you write like
> Ruby, but that does all kinds of inferencing to tell you additional
> info like types, potential bounds etc. but only when you want to see
> it.

Yes. It'll be called APL.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin (2241)
5/5/2006 2:33:12 AM
In article <1146755237.231059.87100
@g10g2000cwb.googlegroups.com>, roberts.noah@gmail.com 
says...

[ ... ]

> Don't know if you meant to imply that C++ works that way but it
> doesn't.  "public" is not the default inheritance mode, private is.

In C++, private inheritance is the default for classes, 
but public inheritance is the default for structs.  Lots 
of people routinely write:

class X : public Y { 
public:
// ...
};

which is equivalent to:

struct X : Y { 
// ...
};

> > Getters and Setters are another good example. Sure, the IDE can generate
> > them. But C#s properties are a lot more elegant. You can start with
> > simple public members and introduce getters and setters later without
> > any need to change the clients of the class.
> 
> Getters and Setters are just poor design indicating that perhapse a
> class is not the best data type to represent your data or that your
> classes are lazy.

Or that your variables aren't really of the correct type 
to start with. From what I've seen, the majority of 
getters and setters don't really do anything, and are 
exactly equivalent to public data with a really ugly 
syntax.

Of the (small) minority that really do something, most do 
nothing more than enforce the variable being within a 
fixed range (e.g. an integer restricted to the range 
0..1024). Some languages (e.g. Ada) provide that 
capability directly, and exposing the data publicly works 
just fine, because the compiler enforces the constraint 
without explicit help beyond the definition of the 
variable's range.

Other languages (e.g. C++) have the flexibility to allow 
the programmer to do the job by defining the correct type 
for the variable in question, and enforcing its 
constraints explicitly (but still centralizing the 
enforcement). For the simple range constraint, for 
example, you can write a small template like:

template <class T, T lower, T upper, class less=std::less
<T> >
class bounded {
    T val;

    static bool check(T const &value) {
        return less()(value, lower) || 
            less()(upper, value);
    }

public:
    bounded() : val(lower) { }

    bounded(T const &v) {
        if (check(v))
            throw std::domain_error("out of range");
        val = v;
    }

    bounded(bounded const &init) : val(init.v) {}

    bounded &operator=(T const &v) {
        if (check(v))
            throw std::domain_error("Out of Range");
        val = v;
        return *this;
    }

    operator T() const { return val; }

    friend std::istream &
        operator>>(std::istream &is, bounded &b) 
    {
        T temp;
        is >> temp;

        if (check(temp))
            is.setstate(std::ios::failbit);
        b.val = temp;
        return is;
    }
};

With this, we can make a data member public, keep (even 
tighter) encapsulation, and still get nice syntax that's 
easy to read and use. At least as it stands right now, I 
don't see a way to do this in Java, but Java is close 
enough now that I can imagine enough being added at some 
point to support it...

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin (2241)
5/5/2006 2:33:21 AM
In article <1mu9i3-8v8.ln1@sirius.tg00suus7038.net>, 
ewill@sirius.tg00suus7038.net says...

[ ... ]

> However, I have no idea what
> 
> {
> 
>     std::ifstream ifs1("pathname");
>     std::ifstream ifs2(ifs1);
>     doSomething(ifs1);
>     doSomething(ifs2);
> }
> 
> or
> 
> {
> 
>     std::ifstream ifs1("pathname");
>     std::ifstream ifs2("path2");
> 
>     ifs1 = ifs2;
> 
>     doSomething(ifs1);
>     doSomething(ifs2);
> }

What they do is produce compiler errors -- nothing more 
and nothing less. streams cannot be either copied or 
assigned. Many years ago (pre-standard) there were 
versions of C++ iostreams that included an 
iostream_withassign, but that's ancient history.

You can make two iostreams refer to the same external 
file if you wish, but the code isn't anything like the 
above, and it leaves little room for question for what it 
would mean. The most obvious is simply:

std::ifstream ifs1("pathname");
std::ifstream ifs2("pathname");

At least if memory serves, you can also tell two 
iostreams to use the same stream buffer. In the iostreams 
model, the iostream itself deals primarily with 
formatting. The stream buffer is what deals with things 
like the storage of the data.

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin (2241)
5/5/2006 4:53:46 AM
Most of the messages in this thread appear to be written by people who
only know one programming language. Have you not discovered that most
programming languages have their strengths as well as their weaknesses?
I occasionally do some maintenance in F77 and every time I am surprised
at some of the number crunching power that has been built into this
version of Fortran. I am currently writing software to control
equipment in real time and, even though I llike Java a lot, it is not
the appropriate language because of the rapid respnses required to
control equipment. Consequently C++ is more useful. You haggle about
things that are not worth haggling about. Kind regards, Willem Ferguson.

0
5/5/2006 7:29:49 AM
In article <MPG.1ec46511c629611f98978d@news.sunsite.dk>,
Jerry Coffin  <jcoffin@taeus.com> wrote:
>
>Or that your variables aren't really of the correct type 
>to start with. From what I've seen, the majority of 
>getters and setters don't really do anything, and are 
>exactly equivalent to public data with a really ugly 
>syntax.

The primary advantage to encapsulating otherwise public data into
accessors that don't actually add anything is that access to this data
can later be easily changed to do something interesting.

It is a poor man's encapsulation, but it's still better than just
having public data fields.

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
5/5/2006 8:44:45 AM
> Most of the messages in this thread appear to be written by people who
> only know one programming language.

in chronological order:

C64 BASIC
ARM BASIC
ARM Assembler
Motorola Assembler
Pascal
C
Modula 2
Opal (ugly)
VisualBasic
Java.

Andrey

-- 
http://uio.imagero.com Unified I/O for Java
http://reader.imagero.com Java image reader
http://jgui.imagero.com Java GUI components and utilities


0
spam06916 (329)
5/5/2006 10:17:54 AM
Bent C Dalager wrote:
> In article <MPG.1ec46511c629611f98978d@news.sunsite.dk>,
> Jerry Coffin  <jcoffin@taeus.com> wrote:
> >
>
> The primary advantage to encapsulating otherwise public data into
> accessors that don't actually add anything is that access to this data
> can later be easily changed to do something interesting.

Yes,

One can change the value (if later computation is required) without
changing the interface. Resolution requirements change come to mind.
All said, how about the client specifying what he want.
template <class T>
struct IfToData //Or model from MVC
{
  virtual const T& get( boost::void_<T> ) = 0;
};

....now the one getting specifies what he wants - his data now could
become:
boost::weak_ptr<IfToData<int> > myDataModel_;

This also makes him independent of the client from whom he receives
data...

Regards,

W


>
> It is a poor man's encapsulation, but it's still better than just
> having public data fields.
>
> Cheers
> 	Bent D
> --
> Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
>                                     powered by emacs

0
w_erasm (159)
5/5/2006 10:25:01 AM
In article <e3f39t$jm9$1@orkan.itea.ntnu.no>, 
bcd@pvv.ntnu.no says...
> In article <MPG.1ec46511c629611f98978d@news.sunsite.dk>,
> Jerry Coffin  <jcoffin@taeus.com> wrote:
> >
> >Or that your variables aren't really of the correct type 
> >to start with. From what I've seen, the majority of 
> >getters and setters don't really do anything, and are 
> >exactly equivalent to public data with a really ugly 
> >syntax.
> 
> The primary advantage to encapsulating otherwise public data into
> accessors that don't actually add anything is that access to this data
> can later be easily changed to do something interesting.

If you'd read what I posted (the code in particular) 
you'd realize that the same is possible when you DO use 
public variables.
 
> It is a poor man's encapsulation, but it's still better than just
> having public data fields.

No, it's really not. 

-- 
    Later,
    Jerry.

The universe is a figment of its own imagination.
0
jcoffin (2241)
5/5/2006 1:55:50 PM
"Bent C Dalager" <bcd@pvv.ntnu.no> wrote in message 
news:e3f39t$jm9$1@orkan.itea.ntnu.no...
> In article <MPG.1ec46511c629611f98978d@news.sunsite.dk>,
> Jerry Coffin  <jcoffin@taeus.com> wrote:
>>
>>Or that your variables aren't really of the correct type
>>to start with. From what I've seen, the majority of
>>getters and setters don't really do anything, and are
>>exactly equivalent to public data with a really ugly
>>syntax.
>
> The primary advantage to encapsulating otherwise public data into
> accessors that don't actually add anything is that access to this data
> can later be easily changed to do something interesting.
>
> It is a poor man's encapsulation, but it's still better than just
> having public data fields.

    The code I'm working with has two classes that do almost the same thing, 
because the code was built by merging two other programs together.

<Java>
class NodeToken {
  public int beginColumn, endColumn;
}

class Token {
  public int startColumn, endColumn;
}
</Java>

I'm trying to merge these two classes together. If they had used accessor 
methods, I could have a methods setStartColumn(int) and setBeginColumn(int) 
affect the same private field, so that the changes would be seen by either 
interfaces. Unfortunately, they didn't use accessor methods, and instead 
used public fields, so now I've got to start by adding the accessor methods 
to each seperate classes, mark the fields as deprecated, check for all 
access to those fields, change those to invoke the accessor methods, then 
merge the class, then simplify the API.

    - Oliver 

0
owong (6178)
5/5/2006 2:37:47 PM
Oliver Wong wrote:
> "Bent C Dalager" <bcd@pvv.ntnu.no> wrote in message
> news:e3f39t$jm9$1@orkan.itea.ntnu.no...
> > In article <MPG.1ec46511c629611f98978d@news.sunsite.dk>,
> > Jerry Coffin  <jcoffin@taeus.com> wrote:
> >>
> >>Or that your variables aren't really of the correct type
> >>to start with. From what I've seen, the majority of
> >>getters and setters don't really do anything, and are
> >>exactly equivalent to public data with a really ugly
> >>syntax.
> >
> > The primary advantage to encapsulating otherwise public data into
> > accessors that don't actually add anything is that access to this data
> > can later be easily changed to do something interesting.
> >
> > It is a poor man's encapsulation, but it's still better than just
> > having public data fields.
>
>     The code I'm working with has two classes that do almost the same thing,
> because the code was built by merging two other programs together.
>
> <Java>
> class NodeToken {
>   public int beginColumn, endColumn;
> }
>
> class Token {
>   public int startColumn, endColumn;
> }
> </Java>
>
> I'm trying to merge these two classes together. If they had used accessor
> methods, I could have a methods setStartColumn(int) and setBeginColumn(int)
> affect the same private field, so that the changes would be seen by either
> interfaces. Unfortunately, they didn't use accessor methods, and instead
> used public fields, so now I've got to start by adding the accessor methods
> to each seperate classes, mark the fields as deprecated, check for all
> access to those fields, change those to invoke the accessor methods, then
> merge the class, then simplify the API.

Interestingly one thing the Java camp never brought up was the tools
they have available to them to make them more productive.  Among those
tools are much more sofisticated refactoring tools.  The only one I
have been able to find for C++ has been Ref+ and though it does a lot
it is still missing a lot of refactors you get with just about every
version of Java or .Net refactor tool out there.  I'm going to blame
this on parsing.

Encapsulate Member is a very common refactor and comes in most tools,
including Ref+, and makes the above process completely automatic.  Pop
up a wizard, set a couple of values, and let it go do its thing.  They
usually work quite well and I suspect the Java version to be even more
accurate.  You use this refactor when you find a public variable that
needs to be encapsulated in a getter and/or setter so that you can
alter behavior or when you need to change the variable to some other
form and you use it even internally to your class.

0
roberts.noah (1664)
5/5/2006 2:56:53 PM
Accessor methods also let you implement pre- and post-conditions
allowing you to formalize DesignByContract.

0
maaxiim (25)
5/5/2006 3:01:33 PM
In article <MPG.1ec50714f92c396a98978f@news.sunsite.dk>,
Jerry Coffin  <jcoffin@taeus.com> wrote:
>
>If you'd read what I posted (the code in particular) 
>you'd realize that the same is possible when you DO use 
>public variables.

My comment was largely based on language neutrality. I would rephrase
it to only cover languages that do not have other means of
accomplishing the same effect.

Data encapsulation is the goal. Trivial getX/setX accessors are a
means to reach that goal, and quite defensible in languages that
provide no other (better) means of getting there.

I need to add that in the context of the original suggestion (that
being able to directly access another object's state is wrong in
itself), your operator-based approach would be equally wrong, only
with a nicer syntax. It remains a poor man's approach to
encapsulation: Any algorithms that need to alter an object's state
should be internal to that object itself, not external to it.

According to this philosophy, you would never write
employee.wage *= 1.1;
You would write
employee.raiseWagePercent(10);

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
5/5/2006 3:14:01 PM
In article <1146841012.974804.301890@e56g2000cwe.googlegroups.com>,
Noah Roberts <roberts.noah@gmail.com> wrote:
>
>Interestingly one thing the Java camp never brought up was the tools
>they have available to them to make them more productive.  Among those
>tools are much more sofisticated refactoring tools.  The only one I
>have been able to find for C++ has been Ref+ and though it does a lot
>it is still missing a lot of refactors you get with just about every
>version of Java or .Net refactor tool out there.  I'm going to blame
>this on parsing.

xref-tech.com has XRefactory. I have only used it on C and Java but I
understand they now support C++.

It's quite expensive for hobby users though, and I blame _that_ on
parsing :-)

Cheers
	Bent D
-- 
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
                                    powered by emacs
0
bcd (665)
5/5/2006 3:16:47 PM
Walter Bright <walter@digitalmars-nospamm.com> wrote:
> Mishagam wrote:
> > I think the fact that nobody uses D means suggests that it has not only 
> > one stupid feature, but a lot of stupid features.
> 
> For a stupid language nobody uses, the D programming language is doing 
> remarkably well, having moved up to number 19 on 
> http://www.tiobe.com/tpci.htm

That means it's a language people mention on web pages, not that it's a 
language people use.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
5/5/2006 3:32:47 PM
Oliver Wong <owong@castortech.com> wrote:
> > For a stupid language nobody uses, the D programming language is doing 
> > remarkably well, having moved up to number 19 on 
> > http://www.tiobe.com/tpci.htm
> 
>     (referring to http://www.tiobe.com/tiobe_index/images/tpci_trends.gif as 
> of May 2nd, 2006): I wonder what happened in 2004 that made Java drop 
> considerably, and everything else jump up a bit.

If you read the FAQ, they point out that it was a change in the way 
Google indexed web pages.  I won't speculate (though, clearly, I'm okay 
with implying) about what it means when the single biggest point made by 
this index turns out to just be an artifact of their methodology.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
5/5/2006 3:35:47 PM
peter koch <peter.koch.larsen@gmail.com> wrote:
> So e.g. Swing, JDBC and Vector are all implemented in Java? Without a
> single JNI-call in the code? It seems my knowledge of Java needs an
> update.

Considered in turn:

Swing: The major part of Swing is written in Java.  There are some small 
pieces (the only one that comes to mind is the FileSystemView class) 
that are not.  Of course, Swing depends on AWT, which is implemented 
partly in other languages.

JDBC: The JDBC API is completely written in Java.  It would have been 
silly to use native code for something that is basically just a bunch of 
glue.  Whether JDBC drivers are written entirely in Java depends on the 
driver.  About 90% of them are, but a few are not.  Oracle, for example, 
provides both a pure Java driver and a driver that uses JNI, but I don't 
know of anyone using the latter.  The only driver that I've contributed 
to and thus worked with closely was PostgreSQL, and that's certainly 
100% Java.

Vector: Yes, it's all in Java.  Again, it would be silly to implement 
this in native code.  The result would perform poorly and be harder to 
maintain.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
5/5/2006 3:43:28 PM
"Noah Roberts" <roberts.noah@gmail.com> wrote in message 
news:1146841012.974804.301890@e56g2000cwe.googlegroups.com...
>
> Oliver Wong wrote:
>> "Bent C Dalager" <bcd@pvv.ntnu.no> wrote in message
>> news:e3f39t$jm9$1@orkan.itea.ntnu.no...
>> > In article <MPG.1ec46511c629611f98978d@news.sunsite.dk>,
>> > Jerry Coffin  <jcoffin@taeus.com> wrote:
>> >>
>> >>Or that your variables aren't really of the correct type
>> >>to start with. From what I've seen, the majority of
>> >>getters and setters don't really do anything, and are
>> >>exactly equivalent to public data with a really ugly
>> >>syntax.
>> >
>> > The primary advantage to encapsulating otherwise public data into
>> > accessors that don't actually add anything is that access to this data
>> > can later be easily changed to do something interesting.
>> >
>> > It is a poor man's encapsulation, but it's still better than just
>> > having public data fields.
>>
>>     The code I'm working with has two classes that do almost the same 
>> thing,
>> because the code was built by merging two other programs together.
>>
>> <Java>
>> class NodeToken {
>>   public int beginColumn, endColumn;
>> }
>>
>> class Token {
>>   public int startColumn, endColumn;
>> }
>> </Java>
>>
>> I'm trying to merge these two classes together. If they had used accessor
>> methods, I could have a methods setStartColumn(int) and 
>> setBeginColumn(int)
>> affect the same private field, so that the changes would be seen by 
>> either
>> interfaces. Unfortunately, they didn't use accessor methods, and instead
>> used public fields, so now I've got to start by adding the accessor 
>> methods
>> to each seperate classes, mark the fields as deprecated, check for all
>> access to those fields, change those to invoke the accessor methods, then
>> merge the class, then simplify the API.
>
> Interestingly one thing the Java camp never brought up was the tools
> they have available to them to make them more productive.  Among those
> tools are much more sofisticated refactoring tools.  The only one I
> have been able to find for C++ has been Ref+ and though it does a lot
> it is still missing a lot of refactors you get with just about every
&g