I have a question just for the hell of it... If you had to choose
between Java and C++, which would you choose? Why and why not?

Flaran wrote:
> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?

It depends.

Each language has strengths and weaknesses.
My choice would depend upon my needs at the time.

Why would I have to choose only between two languages?

Jim Rogers

It was just a question for my amusement! :-)

I actually plan on learning both in time.

Flaran wrote:
> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?

Unless there are realtime requirements I would choose Java which is 
safer and will let me finish the program in less time compared to C++ 
which is a real mess.


August

Flaran <flaran@gmail.com> wrote:
> It was just a question for my amusement! :-)

So, your idea of amusement is to intentionally start flame wars?

-Vesa Karvonen

Flaran wrote On 10/17/05 13:39,:
> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?
> 

Which would you rather drive, a dump truck or a fire engine ?

Neither. Java is slow, and C++ is way overcomplex and unsafe.

If I *had* to choose, then I would go work somewhere else.

"Flaran" <flaran@gmail.com> wrote in message news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?
> 
C++ - for applications, Java - for web stuff.

UF

Scott Moore wrote:
> Flaran wrote On 10/17/05 13:39,:
> 
>>I have a question just for the hell of it... If you had to choose
>>between Java and C++, which would you choose? Why and why not?
> 
> Which would you rather drive, a dump truck or a fire engine ?
> 
> Neither. Java is slow, and C++ is way overcomplex and unsafe.
> 
> If I *had* to choose, then I would go work somewhere else.

Agreed. I'd go with Oberon (http://www.modulaware.com/mdlt49.htm).


August

Flaran wrote:

> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?

The choice is between static type polymorphism and static type polymorphism. 
Big choice.

I would chose C++ because it's older, and its tools tend to be faster and 
less crufty. It's easier to get simple in C++ than in Java. For example, the 
best way to do the Abstract Template Pattern is with private virtual methods 
to specialize a generic template. However, Java's architects have decreed 
that "all virtual methods shall be public, because that's good Object 
Oriented Programming". Put another way, they prevented me from using a 
simple and obvious feature not because of any real technical reason, but 
because of their prejudices regarding my OO design.

However, the real choice is between static type polymorphism and dynamic 
type polymorphism. Languages like Python, Ruby, Smalltalk, and even Perl 
allow you to write arbitrarily complex OO models _without_ declaring the 
type of everything. For high-level code, that boosts development speed at 
the cost of a little execution speed.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!! 

Phlip wrote:

> I would chose C++ because it's older, and its tools tend to be faster and
> less crufty. It's easier to get simple in C++ than in Java. For example,
> the best way to do the Abstract Template Pattern is with private virtual
> methods to specialize a generic template. However, Java's architects have
> decreed that "all virtual methods shall be public, because that's good
> Object Oriented Programming".

Erm, I'm not sure what you meant to say, but what you've said is false.
Java virtual (ie non-final non-static) methods need not be public; they
can happily be protected, for example.

Did you mean that /interface/ methods must be public?

[A pet hate: you can't supply template method definitions in an interface.
 Bah.]

-- 
Chris "electric hedgehog" Dollin
Il Principe - Byzantium - Hansa - Antike - King's Progress
Farfalia - Mu - Havoc - Tigris & Euphrates [kartenspiel]

Chris Dollin wrote:

> Phlip wrote:
>
>> I would chose C++ because it's older, and its tools tend to be faster and
>> less crufty. It's easier to get simple in C++ than in Java. For example,
>> the best way to do the Abstract Template Pattern is with private virtual
>> methods to specialize a generic template. However, Java's architects have
>> decreed that "all virtual methods shall be public, because that's good
>> Object Oriented Programming".
>
> Erm, I'm not sure what you meant to say, but what you've said is false.
> Java virtual (ie non-final non-static) methods need not be public; they
> can happily be protected, for example.
>
> Did you mean that /interface/ methods must be public?

No, just that that's as far as I have learned so far. ;-)

But don't get me started on why is interface a property of a class instead 
of a method??

> [A pet hate: you can't supply template method definitions in an interface.
> Bah.]

Maybe they hope to avoid www.boost.org ;-)

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!!

Flaran wrote:

> I have a question just for the hell of it... If you 
> had to choose between Java and C++, which would you 
> choose? Why and why not?

It will depend a lot on what it is you want to develop.

Without some sort of high level design you are really 
in no position to starting choosing a development tools. 

Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, WordStar, Emacs) Text Editor
"The C/C++, Java, HTML, FTP, Python, PHP, Perl folding editor"
http://www.zeusedit.com

Scott Moore wrote:

> Neither. Java is slow, 

I can agree with you on this.

> and C++ is way overcomplex 

I could also let you have this one.

> and unsafe.

But definitely not this one. 

In what way is C++ any less safe than the next langauge? 

If a applicaiton is written in a safe language and that 
language throws an exception that is not handled, the 
result is effectively a program crash. 

For example the Ariane space craft was written in the 
safest language of them all, ADA. But this did not stop
it form literally crashing :)

Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, WordStar, Emacs) Text Editor
"The C/C++, Java, HTML, FTP, Python, PHP, Perl folding editor"
http://www.zeusedit.com

Phlip wrote:

> Chris Dollin wrote:
> 
>> Phlip wrote:
>>
>>> I would chose C++ because it's older, and its tools tend to be faster
>>> and less crufty. It's easier to get simple in C++ than in Java. For
>>> example, the best way to do the Abstract Template Pattern is with
>>> private virtual methods to specialize a generic template. However,
>>> Java's architects have decreed that "all virtual methods shall be
>>> public, because that's good Object Oriented Programming".
>>
>> Erm, I'm not sure what you meant to say, but what you've said is false.
>> Java virtual (ie non-final non-static) methods need not be public; they
>> can happily be protected, for example.
>>
>> Did you mean that /interface/ methods must be public?
> 
> No, just that that's as far as I have learned so far. ;-)

Oh. Well, be of good cheer; virtual methods need not be public.
 
> But don't get me started on why is interface a property of a class instead
> of a method??

Because [Java] interfaces are class-shaped, not method-shaped.

Because methods are not first-class objects in Java.

Because you can say intersting things about a class, given interfaces,
but you can't say interesting things about methods, given the same
machinery but cut down to methods. 

>> [A pet hate: you can't supply template method definitions in an
>> [interface.
>> Bah.]
> 
> Maybe they hope to avoid www.boost.org ;-)

Maybe. In which case, the proverb about the nose and the face applies.

-- 
Chris "electric hedgehog" Dollin
Il Principe - Byzantium - Hansa - Antike - King's Progress
Farfalia - Mu - Havoc - Tigris & Euphrates [kartenspiel]

Jussi Jumppanen wrote:

> Scott Moore wrote:
> 
>> Neither. Java is slow,
> 
> I can agree with you on this.
> 
>> and C++ is way overcomplex
> 
> I could also let you have this one.
> 
>> and unsafe.
> 
> But definitely not this one.
> 
> In what way is C++ any less safe than the next langauge?

int example()
    {
    int values[2] = {17, 42};
    values[-124] += 1;
    return values[77];
    }

int main() { return example(); }

-- 
Chris "electric hedgehog" Dollin
Il Principe - Byzantium - Hansa - Antike - King's Progress
Farfalia - Mu - Havoc - Tigris & Euphrates [kartenspiel]

On Tue, 18 Oct 2005 15:02:22 +0100, Chris Dollin <kers@hpl.hp.com>
wrote:

>Jussi Jumppanen wrote:
>
>> Scott Moore wrote:
>> 
>>> Neither. Java is slow,
>> 
>> I can agree with you on this.
>> 
>>> and C++ is way overcomplex
>> 
>> I could also let you have this one.
>> 
>>> and unsafe.
>> 
>> But definitely not this one.
>> 
>> In what way is C++ any less safe than the next langauge?
>
>int example()
>    {
>    int values[2] = {17, 42};
>    values[-124] += 1;
>    return values[77];
>    }
>
>int main() { return example(); }

That proves that you are an unsafe programmer, but says nothing about
the language ;-)
-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

"Flaran" <flaran@gmail.com> wrote in message
news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?

That's kind of like asking a Supreme Court nominee how
he might rule on a case he hasn't seen yet :-)

Without knowing the task, you can't really say which you'd
choose, assuming there is a choice.

Of the languages I can use easily, I do have some rules of
thumb:

Speed, compactness* and/or Windows api interface: C++ (written leanly)
Moderate speed, rich functionality, portable apps: Java
Serious text processing, portable: Perl
Portable file/text utilities: Bourne shell

And a handful of others as required (such as Python,
InstallShield's InstallScript, etc.).

* Languages such as Java and Perl make for compact apps, but
require considerable overhead, esp. with Java, unless the
interpreter/library system is already installed and of the
correct revision. That's not always the case. (One product
I wrote an install for is only a couple of megabytes in size,
but if the install were written in Java it would leave up to
a 40 MB footprint on the target machine.)

-Wm

Jussi Jumppanen wrote:
> Scott Moore wrote:
> 
> 
>>Neither. Java is slow, 
> 
> 
> I can agree with you on this.
> 
> 
>>and C++ is way overcomplex 
> 
> 
> I could also let you have this one.
> 
> 
>>and unsafe.
> 
> 
> But definitely not this one. 
> 
> In what way is C++ any less safe than the next langauge? 
> 
> If a applicaiton is written in a safe language and that 
> language throws an exception that is not handled, the 
> result is effectively a program crash. 

Yes, but opposed to C/C++ programs it crashes in a predictable way. In 
C/C++ buffer overflows and pointer errors causes undefined behavior 
which can make the error extremely hard to locate. An error in the 
program can go undetected for years; sometimes the program works and 
sometimes not. To me it feels very unsatisfactory to know that if my 
code contains these kinds of errors they might go undetected.


August

Alan Balmer wrote:
> On Tue, 18 Oct 2005 15:02:22 +0100, Chris Dollin <kers@hpl.hp.com>
> wrote:
>
> >Jussi Jumppanen wrote:
> >
> >> Scott Moore wrote:
> >>
> >>> Neither. Java is slow,
> >>
> >> I can agree with you on this.
> >>
> >>> and C++ is way overcomplex
> >>
> >> I could also let you have this one.
> >>
> >>> and unsafe.
> >>
> >> But definitely not this one.
> >>
> >> In what way is C++ any less safe than the next langauge?
> >
> >int example()
> >    {
> >    int values[2] = {17, 42};
> >    values[-124] += 1;
> >    return values[77];
> >    }
> >
> >int main() { return example(); }
>
> That proves that you are an unsafe programmer, but says nothing about
> the language ;-)

It's a poor example since the mistakes above are obvious.  Some C
compilers may report them at compile time.

There are other situations where it's much more difficult to see the
problem.

Alan Balmer wrote On 10/18/05 08:24,:
> On Tue, 18 Oct 2005 15:02:22 +0100, Chris Dollin <kers@hpl.hp.com>
> wrote:
> 
> 
>>Jussi Jumppanen wrote:
>>
>>
>>>Scott Moore wrote:
>>>
>>>
>>>>Neither. Java is slow,
>>>
>>>I can agree with you on this.
>>>
>>>
>>>>and C++ is way overcomplex
>>>
>>>I could also let you have this one.
>>>
>>>
>>>>and unsafe.
>>>
>>>But definitely not this one.
>>>
>>>In what way is C++ any less safe than the next langauge?
>>
>>int example()
>>   {
>>   int values[2] = {17, 42};
>>   values[-124] += 1;
>>   return values[77];
>>   }
>>
>>int main() { return example(); }
> 
> 
> That proves that you are an unsafe programmer, but says nothing about
> the language ;-)

We'll be out to take the bumpers, doors and airbags off your car.
Also, you will only have two speeds, 0 and 100 miles an hour.

It should only be a problem if you are an unsafe driver.

Jussi Jumppanen wrote On 10/18/05 06:42,:
> Scott Moore wrote:
> 
> 
>>Neither. Java is slow, 
> 
> 
> I can agree with you on this.
> 
> 
>>and C++ is way overcomplex 
> 
> 
> I could also let you have this one.
> 
> 
>>and unsafe.
> 
> 
> But definitely not this one. 
> 
> In what way is C++ any less safe than the next langauge? 
> 
> If a applicaiton is written in a safe language and that 
> language throws an exception that is not handled, the 
> result is effectively a program crash. 

This is your choice ? If you can't have it all, then you want
nothing ?

On Tue, 18 Oct 2005 11:21:17 -0700, Scott Moore
<samiamsansspam@Sun.COM> wrote:

>Alan Balmer wrote On 10/18/05 08:24,:
>> On Tue, 18 Oct 2005 15:02:22 +0100, Chris Dollin <kers@hpl.hp.com>
>> wrote:
>> 
>> 
>>>Jussi Jumppanen wrote:
>>>
>>>
>>>>Scott Moore wrote:
>>>>
>>>>
>>>>>Neither. Java is slow,
>>>>
>>>>I can agree with you on this.
>>>>
>>>>
>>>>>and C++ is way overcomplex
>>>>
>>>>I could also let you have this one.
>>>>
>>>>
>>>>>and unsafe.
>>>>
>>>>But definitely not this one.
>>>>
>>>>In what way is C++ any less safe than the next langauge?
>>>
>>>int example()
>>>   {
>>>   int values[2] = {17, 42};
>>>   values[-124] += 1;
>>>   return values[77];
>>>   }
>>>
>>>int main() { return example(); }
>> 
>> 
>> That proves that you are an unsafe programmer, but says nothing about
>> the language ;-)
>
>We'll be out to take the bumpers, doors and airbags off your car.
>Also, you will only have two speeds, 0 and 100 miles an hour.
>
>It should only be a problem if you are an unsafe driver.

If we're inventing random analogies, I'll let you jump out of a plane
at 10,000 feet without a parachute. No problem unless you can't fly.

C++ doesn't force anyone to write unsafe code, and silly analogies
don't change that.

Bad code can be written in any language, and silly analogies don't
change that either.
-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

I've learned a bit from this... And that is that people like to be
hostile... Maybe we can just end this totally?

In article <1129581584.744842.215830@g44g2000cwa.googlegroups.com>,
Flaran <flaran@gmail.com> wrote:
>I have a question just for the hell of it... If you had to choose
>between Java and C++, which would you choose? Why and why not?

C++, because:

* It's an ANSI/ISO standard

* It has a better selection of tools

* It can provide many more choices of run-time enviornments: 
  (managed/unmanaged, libraries/no-libraries, OS/no-OS)

* It's easier to do Java-like things (GC, interfaces, etc.) in C++ than it 
  is to do C++ like things (hardware access, precise control over
  memory, RAII, templates) in Java.

* The standard JVM is written in C++, so given C++, I can get Java. ;-)

-Mike

-- 
hqyhttp://www.mschaef.com

Flaran said:

> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose?

Death.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Alan Balmer wrote:
> C++ doesn't force anyone to write unsafe code, 

but it encourages you to do it.

> Bad code can be written in any language,

and the grass is green.


August

Richard Heathfield wrote:
> Flaran said:
>
> > I have a question just for the hell of it... If you had to choose
> > between Java and C++, which would you choose?
>
> Death.
>

Heh, both of them at times make you want to bang your head on the
table... I swear after going to C++ I thought, "Why can't they just use
print? WTH is this cout crap!?"

"Flaran" <flaran@gmail.com> wrote in message
news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?
>
If  I am entertained by lots of unpredictable surprises, the need to watch out
for errors from strange pointer behavior and all the other little gotchas a
programming language can offer, I would choose C++.

If I want to be boxed into a language that offers me a set way of doing
things, limited flexibility, and lots of other restrictions, I would choose
Java.

If I want a language that offers me all the power of C++, the stability
of Java, the neavyweight extensibility of real object-oriented
programming along with a lightweight extensbility capability, a sound
model for concurrency, and type safety, I would choose Ada.  An
equally good alternative, some would say better, is Eiffel.  For
that matter, Eiffel is vastly better than either C++ or Java is one
is serious about creating dependable software.

Why would anyone restrict their choices to two languages where
one represents some of the worst language design features, and
the other offers so little.   There are lots of good languages available
that offer better choices.   Consider Python.  Consider Ruby.
Consider Eiffel.  Neither C++ nor Java offer the best one can
find in programming languages.

Richard Riehle

"Jussi Jumppanen" <jussij@zeusedit.com> wrote in message
news:4354FBB0.5114@zeusedit.com...
>>
> For example the Ariane space craft was written in the
> safest language of them all, ADA. But this did not stop
> it form literally crashing :)
>
Certainly one can write stupid software in any language.  However,
Ada is much safer than C++.   The error, in Ariane V reused perfectly
good software from Ariane IV.  On Ariane IV the software performed
exactly as it should have.  The engineers failed to take into consideration
that the performance characteristics of Ariane V were different.  They
went ahead and reused software they had not verified for the new
rocket design.  Now that was a stupid mistake in requirements engineering,
not in language choice.

Consider that your doctor, before prescribing a perfectly good medicine
fails to evaluate you for allergies for that medicine.   You die.  Was it
the fault of the otherwise benign medicine of the the fault of the physician
who didn't do his job right?   Penicillin saves lives.  It also kills people
who are allergic to it.

On the other hand, C++ is so full of gotchas, so error-prone that one could
not classify it as safe.   A program that compiles, in C++, might go execute
after deployment for a long time before a surprising error manifests itself.
In Ada there is a strong model of error checking, early in the development
process, and the compiler is an aid in this process.

Ariane V did not crash because of Ada, but in spite of it.  If it had been
programmed in C++, under the same stupid engineering model, it would
have crashed.   On the other hand, I can easily envison it crashing on
some other occasion because of C++, not in spite of it.

The more time I spend with C++, the more amazed I am that anyone
would use it for any kind of software where dependability is important.

Richard Riehle

"Alan Balmer" <albalmer@att.net> wrote in message
news:4qgal1pfc024fset0k61vv0tkp8nr9hrbl@4ax.com...
>
> C++ doesn't force anyone to write unsafe code, and silly analogies
> don't change that.
>
True. C++ does not force anyone to write unsafe code.  It does, however,
make it so much easier to do so.   If you are a practicing C++ programmer,
you realize how easy it is to make errors that are never detected by the
compiler.  We are talking here about errors that would be detected early
by a more robust language.  I don't need examples or analogies to
prove that point, unless you are not as experienced with C++ as I
thought you were.

Richard Riehle

"Richard Heathfield" <invalid@invalid.invalid> wrote in message
news:dj3o0n$98v$1@nwrdmz02.dmz.ncs.ea.ibs-infra.bt.com...
> Flaran said:
>
> > I have a question just for the hell of it... If you had to choose
> > between Java and C++, which would you choose?
>
> Death.
>
This reminds me of an Eighteenth Century philosopher who inadvertantly
insulted one of the best swordsmen of his time.  He was asked to "choose"
his weapon.  The philosopher, knowing that his dueling skills were no match
for the swordsman replied, "Poison.  We each drink a cup of poison and the
one who dies first is the loser."

Richard Riehle

On 17 Oct 2005 13:39:44 -0700, "Flaran" <flaran@gmail.com> wrote:

>I have a question just for the hell of it... If you had to choose
>between Java and C++, which would you choose? Why and why not?

Anyoun posting a question like this should be condemned to program in
BASIC without GOSUBs. For all eternity.

Rob Thorpe wrote:

> Alan Balmer wrote:
>> On Tue, 18 Oct 2005 15:02:22 +0100, Chris Dollin <kers@hpl.hp.com>
>> wrote:
>>
>> >Jussi Jumppanen wrote:
>> >
>> >> Scott Moore wrote:
>> >>
>> >>> Neither. Java is slow,
>> >>
>> >> I can agree with you on this.
>> >>
>> >>> and C++ is way overcomplex
>> >>
>> >> I could also let you have this one.
>> >>
>> >>> and unsafe.
>> >>
>> >> But definitely not this one.
>> >>
>> >> In what way is C++ any less safe than the next langauge?
>> >
>> >int example()
>> >    {
>> >    int values[2] = {17, 42};
>> >    values[-124] += 1;
>> >    return values[77];
>> >    }
>> >
>> >int main() { return example(); }
>>
>> That proves that you are an unsafe programmer, but says nothing about
>> the language ;-)
> 
> It's a poor example since the mistakes above are obvious.

It's a /good/ example, for that very reason. I hope any programmer
worth their salt will be able to generalise from the literal constants.

> Some C compilers may report them at compile time.

Some C++ compilers, too ... but there's no /obligation/ to do so,
and no /obligation/ not to generate code regardless.

> There are other situations where it's much more difficult to see the
> problem.

Oh, yes. 

-- 
Chris "electric hedgehog" Dollin
Il Principe - Byzantium - Hansa - Antike - King's Progress
Farfalia - Mu - Havoc - Tigris & Euphrates [kartenspiel]

On Tue, 18 Oct 2005 22:35:14 GMT, August Karlstrom wrote:
> Alan Balmer wrote:
>> C++ doesn't force anyone to write unsafe code, 
>
> but it encourages you to do it.

No it does not. The recommended c++ way of using arrays is called
std::vector. That class contains the at method which checks bounds while
accessing the element.

-- 
I'm not a racist. I hate everyone equally!

In article <yNl5f.17428$6e1.2854@newssvr14.news.prodigy.com>,
 <adaworks@sbcglobal.net> wrote:
>
>"Alan Balmer" <albalmer@att.net> wrote in message
>news:4qgal1pfc024fset0k61vv0tkp8nr9hrbl@4ax.com...
>>
>> C++ doesn't force anyone to write unsafe code, and silly analogies
>> don't change that.
>>
>True. C++ does not force anyone to write unsafe code.  It does, however,
>make it so much easier to do so.  

That's part of the beauty of the language, IMO. Maybe it'd be nice if the 
'unsafe' features were a little more removed from the core of the 
language, but C++ provides a nice (IMO) balance between powerful, 
high-level, 'safe' abstractions _and_ low-level, 'unsafe' capabilities 
that Java does not.

-Mike
-- 
hqyhttp://www.mschaef.com

Zara wrote:

>>I have a question just for the hell of it... If you had to choose
>>between Java and C++, which would you choose? Why and why not?
>
> Anyoun posting a question like this should be condemned to program in
> BASIC without GOSUBs. For all eternity.

Why? The rest of us have the responsibility to discuss the question 
politely, and I think we did a good job.

(I would reserve that punishment for those who cross-post between a C++ and 
Java newsgroup;)

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!! 

<adaworks@sbcglobal.net> wrote in message
news:yNl5f.17428$6e1.2854@newssvr14.news.prodigy.com...
>
> "Alan Balmer" <albalmer@att.net> wrote in message
> news:4qgal1pfc024fset0k61vv0tkp8nr9hrbl@4ax.com...
> >
> > C++ doesn't force anyone to write unsafe code, and silly analogies
> > don't change that.
> >
> True. C++ does not force anyone to write unsafe code.  It does, however,
> make it so much easier to do so.   If you are a practicing C++ programmer,
> you realize how easy it is to make errors that are never detected by the
> compiler.

"much easier"? Which language are you comparing C++ to now? C, Java, or
something else?

I find C++ compilers much more helpful than C compilers when it comes to
finding bugs. I migrated from C to C++ four years ago, and it is my
experience that the compiler catches many *more* errors that previously used
to be found at runtime. Many of these errors are silly, like type errors and
uninitialized variables, but I no longer have to track down hard-to-find
runtime bugs on that account, because the compiler finds them for me.

Of course, that may not be due to the change C -> C++, but could be instead
a general improvement in the number of warnings/errors that the compiler
checks for.

However, the possibility of using std::map to express associations between
two related concepts makes it easier and quicker to get a program working
than it used to when I only had C. Having to hand-code such relations in C
invariably leads to bugs at run-time.

> We are talking here about errors that would be detected early
> by a more robust language.

Could you be more specific, please. What errors, what language?

Would you say Java is more robust than C++?

Any language that does not explicitly support the concept of pointers and
(especially) pointer arithmetic would be (much) more robust than C/C++.

-Michael.

P.S. Why are we having this discussion? C++ is a powerful language, and with
all power-tools, some caution is required.

<adaworks@sbcglobal.net> wrote in message
news:Xzl5f.17426$6e1.5614@newssvr14.news.prodigy.com...

> Why would anyone restrict their choices to two languages where
> one represents some of the worst language design features, and
> the other offers so little.   There are lots of good languages available
> that offer better choices.   Consider Python.  Consider Ruby.
> Consider Eiffel.  Neither C++ nor Java offer the best one can
> find in programming languages.

I don't know anything about Ada, so please help me fill in a few blanks. Ada
has been around for much longer than C++, right? But it is practically only
used within DOD and NASA, or at least used to be, right?

Would you say Ada is well-suited for OS development (incl. interrupt
drivers), i.e. hardware near and performance critical stuff?

Does Ada have support for pointers and pointer arithmetic?

Does Ada have static type checking (like C++) or dynamic type checking (like
Python)?

I'm not trying to make a point, I'm only trying to educate myself a bit.
It's rather embarrasing that I know so little about Ada.

-Michael.

Michael J�rgensen wrote:
> Any language that does not explicitly support the concept of pointers and
> (especially) pointer arithmetic would be (much) more robust than C/C++.

One approach, taken by Oberon, is to isolate the low level code in 
special modules. From http://www.modulaware.com/mdlt49.htm:

"For system-level programming, Oberon offers the pseudo module SYSTEM, 
which provides implementation and machine dependent operations. Modules 
which import SYSTEM are inherently unportable and unsafe but easily 
identified by the word SYSTEM in their import list. C++ allows the usage 
of system level operations without specially marking such programs. When 
porting programs from one machine to another, this might lead to 
unpleasant surprises and long debugging sessions."


August

adaworks@sbcglobal.net wrote On 10/18/05 23:19,:
> "Flaran" <flaran@gmail.com> wrote in message
> news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> 
>>I have a question just for the hell of it... If you had to choose
>>between Java and C++, which would you choose? Why and why not?
>>
> 
> If  I am entertained by lots of unpredictable surprises, the need to watch out
> for errors from strange pointer behavior and all the other little gotchas a
> programming language can offer, I would choose C++.
> 
> If I want to be boxed into a language that offers me a set way of doing
> things, limited flexibility, and lots of other restrictions, I would choose
> Java.
> 
> If I want a language that offers me all the power of C++, the stability
> of Java, the neavyweight extensibility of real object-oriented
> programming along with a lightweight extensbility capability, a sound
> model for concurrency, and type safety, I would choose Ada.  An
> equally good alternative, some would say better, is Eiffel.  For
> that matter, Eiffel is vastly better than either C++ or Java is one
> is serious about creating dependable software.
> 
> Why would anyone restrict their choices to two languages where
> one represents some of the worst language design features, and
> the other offers so little.   There are lots of good languages available
> that offer better choices.   Consider Python.  Consider Ruby.
> Consider Eiffel.  Neither C++ nor Java offer the best one can
> find in programming languages.
> 
> Richard Riehle
> 

Typically the only criteria for language selection is "used by the greatest
number of people" (or the more nebulous "popular").

However, if you choose your food by the same criteria, you would be eating
at Mcdonalds all the time.

Some of us eat steak, some of us are more discerning in our programming
language choice.

Michael J=F8rgensen wrote On 10/19/05 09:12,:
> <adaworks@sbcglobal.net> wrote in message
> news:Xzl5f.17426$6e1.5614@newssvr14.news.prodigy.com...
>=20
>=20
>>Why would anyone restrict their choices to two languages where
>>one represents some of the worst language design features, and
>>the other offers so little.   There are lots of good languages availabl=
e
>>that offer better choices.   Consider Python.  Consider Ruby.
>>Consider Eiffel.  Neither C++ nor Java offer the best one can
>>find in programming languages.
>=20
>=20
> I don't know anything about Ada, so please help me fill in a few blanks=
=2E Ada
> has been around for much longer than C++, right? But it is practically =
only
> used within DOD and NASA, or at least used to be, right?

I don't think that popularity has much to do with the functionality of th=
e
language. The only valid "proof" that popularity equals productivity is
that more programmers will be found who are knoledgable with language X
than N, but that proof presumes that programmers cannot learn new languag=
es,
which I believe is untrue of good programmers.

>=20
> Would you say Ada is well-suited for OS development (incl. interrupt
> drivers), i.e. hardware near and performance critical stuff?

Yes, ADA implementations have done some amazing things.

>=20
> Does Ada have support for pointers and pointer arithmetic?

Pointers, yes. When you are asking "pointer artithmetic" you are asking
"does it resemble C". Pointer arithmetic is needed in C because pointers
and arrays are united in C, which is in fact the reason that array access=
es
cannot be made secure in C. Other languages like Ada, Pascal, Fortran,
Cobol and others didn't artifically unite arrays and pointers, and so
don't have that problem.

>=20
> Does Ada have static type checking (like C++) or dynamic type checking =
(like
> Python)?

Static. Dynamic typing is nifty, but, alas, slow.

>=20
> I'm not trying to make a point, I'm only trying to educate myself a bit=
=2E
> It's rather embarrasing that I know so little about Ada.
>=20
> -Michael.
>=20
>=20

Sure.

August Karlstrom wrote On 10/19/05 10:27,:
> Michael J=F8rgensen wrote:
>=20
>>Any language that does not explicitly support the concept of pointers a=
nd
>>(especially) pointer arithmetic would be (much) more robust than C/C++.=

>=20
>=20
> One approach, taken by Oberon, is to isolate the low level code in=20
> special modules. From http://www.modulaware.com/mdlt49.htm:
>=20
> "For system-level programming, Oberon offers the pseudo module SYSTEM, =

> which provides implementation and machine dependent operations. Modules=
=20
> which import SYSTEM are inherently unportable and unsafe but easily=20
> identified by the word SYSTEM in their import list. C++ allows the usag=
e=20
> of system level operations without specially marking such programs. Whe=
n=20
> porting programs from one machine to another, this might lead to=20
> unpleasant surprises and long debugging sessions."
>=20
>=20
> August

The C language also has that concept. You can identify programs that are
inherently unsafe by their being compiled with the command "cc".

"Michael J�rgensen" <ccc59035@vip.cybercity.dk> writes:

> I don't know anything about Ada, so please help me fill in a few blanks. Ada
> has been around for much longer than C++, right? But it is practically only
> used within DOD and NASA, or at least used to be, right?

No, not really.  It's definitely a "niche" language, compared to C or
C++, but there are a number of other application areas outside DOD and
NASA.

To learn about Ada, look at:

    www.adapower.org

For the GNU Ada compiler, check out:

    www.adacore.com

SofCheck (www.sofcheck.com) sells Ada compilers, and there are several
other Ada compiler vendors.

> Would you say Ada is well-suited for OS development (incl. interrupt
> drivers), i.e. hardware near and performance critical stuff?

Yes.

> Does Ada have support for pointers and pointer arithmetic?

Pointers, yes.  Pointer arithmetic, yes, but it's rarely needed
and requires jumping through some hoops.

> Does Ada have static type checking (like C++) or dynamic type checking (like
> Python)?

Static.  Somewhat like C++, but there are many things that the
programmer can express in the Ada type system that are impossible
or infeasible to express in the C++ type system.

> I'm not trying to make a point, I'm only trying to educate myself a bit.
> It's rather embarrasing that I know so little about Ada.

The more programming languages you learn, the better!  Even if you don't
use them directly, you get ideas.

- Bob

Flaran wrote:
> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose?

Probably Java.

> Why and why not? 

Garbage collection would improve program stability. Java is slower but
stability is always more important than performance.

Other than that they're pretty similar. In particular, they both lack many
important features:

1. Closures.
2. Run-time code generation.
3. Parametric polymorphism.
4. Type inference.
5. Modules.
6. Functors.
7. Type classes.
8. Higher-order functions.
9. Currying.
10. Variant types.
11. Polymorphic variants.
12. Pattern matching.
13. Laziness.
14. Tuples.
....

You can implement some of these features but it is not easy enough for them
to be useful.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

"Michael J�rgensen" <ccc59035@vip.cybercity.dk> wrote in message
news:43566db0$0$38699$edfadb0f@dread12.news.tele.dk...
>
> <adaworks@sbcglobal.net> wrote in message
> > >
> > True. C++ does not force anyone to write unsafe code.  It does, however,
> > make it so much easier to do so.   If you are a practicing C++ programmer,
> > you realize how easy it is to make errors that are never detected by the
> > compiler.
>
> "much easier"? Which language are you comparing C++ to now? C, Java, or
> something else?
>
I suppose I am comparing it to Ada (every bit as powerful as C++ but
without the danger), or even Eiffel.

> I find C++ compilers much more helpful than C compilers when it comes to
> finding bugs.
>
Well, yes.  C is a universal assembler with a few pathologies left over
from its original targeted platform.
>
>
> > We are talking here about errors that would be detected early
> > by a more robust language.
>
> Could you be more specific, please. What errors, what language?
>
Again, Ada, Eiffel.  Even Oberon.

> Would you say Java is more robust than C++?
>
No.  Java, as currently constituted, is a bit limiting.
>
>Why are we having this discussion? C++ is a powerful language, and with
> all power-tools, some caution is required.
>
You say this as if it is a necessary fact-of-programming life.  It isn't.  We
ought
to be looking for tools that give us the power we need but do so with an
increased amount of reliability.   C++ is not that kind of tool.

Richard Riehle

adaworks@sbcglobal.net wrote:
> I suppose I am comparing it to Ada (every bit as powerful as C++ but
> without the danger), or even Eiffel.

Cyclic data structures?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Rene Moehring wrote:
> On Tue, 18 Oct 2005 22:35:14 GMT, August Karlstrom wrote:
>> Alan Balmer wrote:
>>> C++ doesn't force anyone to write unsafe code,
>>
>> but it encourages you to do it.
> 
> No it does not.

Yes, it does.

> The recommended c++ way of using arrays is called 
> std::vector. That class contains the at method which checks bounds while
> accessing the element.

The more concise way is a[i] rather than a.at(i). The more concise way is
unsafe.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Alan Balmer wrote:
> Bad code can be written in any language, and silly analogies don't
> change that either.

Unsafe code cannot be written in a safe language.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jussi Jumppanen wrote:
> In what way is C++ any less safe than the next langauge?

Non-determinism.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

In article <4356f0e1$0$6521$ed2619ec@ptn-nntp-reader01.plus.net>,
Jon Harrop  <usenet@jdh30.plus.com> wrote:
>Alan Balmer wrote:
>> Bad code can be written in any language, and silly analogies don't
>> change that either.
>
>Unsafe code cannot be written in a safe language.

Sure it can. Just look at the Arianne V example elsewhere in the thread.  
That code was clearly unsafe, for any useful definition of safety, and the 
language had nothing to do with it. My hunch is that phrases like 'Unsafe 
code cannot be written in a safe language.' are ultimately harmful, as 
they might encourage people to drop their guard.

-Mike
-- 
http://www.mschaef.com

Jon Harrop wrote:

> Alan Balmer wrote:

>> Bad code can be written in any language, and silly analogies don't
>> change that either.
>
> Unsafe code cannot be written in a safe language.

Famous last words.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!!

Vesa Karvonen coughed up:
> Flaran <flaran@gmail.com> wrote:
>> It was just a question for my amusement! :-)
>
> So, your idea of amusement is to intentionally start flame wars?
>
> -Vesa Karvonen

It's only a flame war if people reply to it.........................oops

-- 
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides

August Karlstrom coughed up:
> Flaran wrote:
>> I have a question just for the hell of it... If you had to choose
>> between Java and C++, which would you choose? Why and why not?
>
> Unless there are realtime requirements I would choose Java which is
> safer and will let me finish the program in less time compared to C++
> which is a real mess.

This also depends upon the OP's understanding of OO.  If he has no 
experience with OO fundamentals, then he had better /not/ start with C++.

Not gonna get into /why/....it's just been /done/ too many times.  :-P


-- 
"It's easier to be terrified by an enemy you admire."
-Thufir Hawat, Mentat and Master of Assassins to House Atreides

MSCHAEF.COM wrote:
> In article <4356f0e1$0$6521$ed2619ec@ptn-nntp-reader01.plus.net>,
> Jon Harrop  <usenet@jdh30.plus.com> wrote:
>>Alan Balmer wrote:
>>> Bad code can be written in any language, and silly analogies don't
>>> change that either.
>>
>>Unsafe code cannot be written in a safe language.
> 
> Sure it can. Just look at the Arianne V example elsewhere in the thread.
> That code was clearly unsafe, for any useful definition of safety, and the
> language had nothing to do with it. My hunch is that phrases like 'Unsafe
> code cannot be written in a safe language.' are ultimately harmful, as
> they might encourage people to drop their guard.

Safe != Correct

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

On Mon, 17 Oct 2005 13:39:44 -0700, Flaran wrote:

> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?
Using good design methods is more important than using the best
language. Learn ideas and play with them in many different languages,
e.g. make a point to learn a new language each year.

And starting flame wars "just for the hell of it" will put you
into many a killfile pretty quickly.

-- Alex

Jon Harrop wrote:

> Rene Moehring wrote:
>> On Tue, 18 Oct 2005 22:35:14 GMT, August Karlstrom wrote:
>>> Alan Balmer wrote:
>>>> C++ doesn't force anyone to write unsafe code,
>>>
>>> but it encourages you to do it.
>> 
>> No it does not.
> 
> Yes, it does.
> 
>> The recommended c++ way of using arrays is called
>> std::vector. That class contains the at method which checks bounds while
>> accessing the element.
> 
> The more concise way is a[i] rather than a.at(i). The more concise way is
> unsafe.

That is a quality of implementation issue: there are (even free) STL
implementations out there that provide drop in replacements for std::vector
like debug::vector where operator[] is range checked.


Best

Kai-Uwe Bux

"Jon Harrop" <usenet@jdh30.plus.com> wrote in message
news:4356d2f4$0$6521$ed2619ec@ptn-nntp-reader01.plus.net...
> Flaran wrote:
> > I have a question just for the hell of it... If you had to choose
> > between Java and C++, which would you choose?

[snip]

> Other than that they're pretty similar. In particular, they both lack many
> important features:

[snip]

> 13. Laziness.

I thought that what as attribute of the programmer, not the language :-)

-Michael.

"Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com>
wrote in message news:3AE5f.8506$Lb1.2817@trndny03...

> This also depends upon the OP's understanding of OO.  If he has no
> experience with OO fundamentals, then he had better /not/ start with C++.
>
> Not gonna get into /why/....it's just been /done/ too many times.  :-P

Which language would you then suggest for someone wanting to learn OO?

-Michael.

Kai-Uwe Bux wrote:
> Jon Harrop wrote:
>> Rene Moehring wrote:
>>> On Tue, 18 Oct 2005 22:35:14 GMT, August Karlstrom wrote:
>>>> Alan Balmer wrote:
>>>>> C++ doesn't force anyone to write unsafe code,
>>>>
>>>> but it encourages you to do it.
>>> 
>>> No it does not.
>> 
>> Yes, it does.
>> 
>>> The recommended c++ way of using arrays is called
>>> std::vector. That class contains the at method which checks bounds while
>>> accessing the element.
>> 
>> The more concise way is a[i] rather than a.at(i). The more concise way is
>> unsafe.
> 
> That is a quality of implementation issue: there are (even free) STL
> implementations out there that provide drop in replacements for
> std::vector like debug::vector where operator[] is range checked.

Sure, I could go out of my way to interpret my C++ in a VM but that doesn't
change the fact that, by default, C++ is unsafe and encourages programmers
to be unsafe.

More generally, given that the STL requires certain complexities, you
probably can't have a safe STL compliant implementation (e.g. to check that
set iterators are valid at every use).

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Michael J�rgensen wrote:
> "Thomas G. Marshall"
> <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in message
> news:3AE5f.8506$Lb1.2817@trndny03...
> 
>> This also depends upon the OP's understanding of OO.  If he has no
>> experience with OO fundamentals, then he had better /not/ start with C++.
>>
>> Not gonna get into /why/....it's just been /done/ too many times.  :-P
> 
> Which language would you then suggest for someone wanting to learn OO?

OCaml has an interesting form of OO quite unlike C++ and Java's. Also, OCaml
provides alternatives so you aren't forced to use OO when it is
inappropriate.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop wrote:

> Kai-Uwe Bux wrote:
>> Jon Harrop wrote:
>>> Rene Moehring wrote:
[snip]
>>> The more concise way is a[i] rather than a.at(i). The more concise way
>>> is unsafe.
>> 
>> That is a quality of implementation issue: there are (even free) STL
>> implementations out there that provide drop in replacements for
>> std::vector like debug::vector where operator[] is range checked.
> 
> Sure, I could go out of my way to interpret my C++ in a VM but that
> doesn't change the fact that, by default, C++ is unsafe and encourages
> programmers to be unsafe.

"encourages" no. I find it very easy to stay away from stuff that
potentially breaks my code. It is just a matter of acquiring some habits.
Of course, whether that comes easy to you depends on how you learned C++
(and methinks, not coming from C also helps).

But I agree that C++ makes it about as easy to something silly as to do
something right. Unfortunately, to some people the silly way looks always
more natural. One reason is probably, that safe constructs in C++ tend to
be more verbose (std::vector<T> as opposed to T[] or boost::shared_ptr<T>
as opposed to T*). Coming from MODULA 2, I consider verbosity a plus (makes
code easier to read, for me). Those who despise verbosity are in deep
waters with C++.


> More generally, given that the STL requires certain complexities, you
> probably can't have a safe STL compliant implementation (e.g. to check
> that set iterators are valid at every use).

As far as I can tell, range/validity checking can always be done in constant
time. No violation of the standard is required. Specifically for
set-iterators: You keep a reference count for every node in the balanced
tree counting iterators pointing there. Removing an element of the set will
not delete the node, it will just remove it from the tree and mark it as
invalid (add some boolean field for that, or change the sign of the
ref-count). The node self-destructs when the ref-count reaches 0, i.e.,
when all invalidated iterators have been destroyed or redirected.
Referencing a node via an iterator just checks the validity field. All
operations of creating, changing, destroying nodes and iterators have a
constant time and space overhead compared to the unchecked counter parts.


Best

Kai-Uwe Bux

On Thu, 20 Oct 2005 07:59:29 +0200
"Michael J_rgensen" <ccc59035@vip.cybercity.dk> wrote:

> 
> "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com>
> wrote in message news:3AE5f.8506$Lb1.2817@trndny03...
> 
> > This also depends upon the OP's understanding of OO.  If he has no
> > experience with OO fundamentals, then he had better /not/ start with C++.
> >
> > Not gonna get into /why/....it's just been /done/ too many times.  :-P
> 
> Which language would you then suggest for someone wanting to learn OO?

	As many as possible - certainly Smalltalk, Perl, C++, Java,
Python and any others you can get round to. Don't spend too much time
on any of them. If you have time look at the Xlib and Xtk sources to see
how you can do OO without an OO language.

-- 
C:>WIN                                      |   Directable Mirror Arrays
The computer obeys and wins.                | A better way to focus the sun
You lose and Bill collects.                 |    licences available see
                                            |    http://www.sohara.org/

August Karlstrom wrote:

> Yes, but opposed to C/C++ programs it crashes in a predictable 
> way. 

I really don't see a lot of difference between the "bad" 
C/C++ crash when compared to the "good" unhandled 
exception.

All you really have done is replaced the c/c++:

 "Your program has generated a general protect fault." 

message box with the all new:

  "Unhandled exception trapped." 

message box.

In both cases the program is left in an unknown state.

> In C/C++ buffer overflows and pointer errors causes undefined 
> behavior which can make the error extremely hard to locate. 

I agree that can happen in c/c++, but there are also lots
of tools and coding techniques that also make this less 
likely to happen.

> To me it feels very unsatisfactory to know that if my code 
> contains these kinds of errors they might go undetected.

The Zeus editor is written in 100% c++, and I sleep easy at 
night knowing it does not contains these kinds of errors.

Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, WordStar, Emacs) Text Editor
"The C/C++, Java, HTML, FTP, Python, PHP, Perl folding editor"
http://www.zeusedit.com

August Karlstrom wrote:

> but it encourages you to do it.

C++ encourages coders to write bad code in the exactly 
the same way a gun encourages it handler to accidently 
shoot himself in the foot.

Now it could be argued that for the health and well 
being of certain individuals, they some not be allowed 
to handle guns.

In the same way certain coders should never be allowed 
to program in c++ ;)

Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, WordStar, Emacs) Text Editor
"The C/C++, Java, HTML, FTP, Python, PHP, Perl folding editor"
http://www.zeusedit.com

Jussi Jumppanen wrote:
>
>> but it encourages you to do it.
>
> C++ encourages coders to write bad code in the exactly
> the same way a gun encourages it handler to accidently
> shoot himself in the foot.

Right. You leave the safety on, always point at the ground or the sky, don't 
load until use, keep it clean, keep it locked up when not in use, etc.

Oh, you meant "exactly" the same way _inexperienced_ users sometimes hurt 
themselves.

> Now it could be argued that for the health and well
> being of certain individuals, they some not be allowed
> to handle guns.
>
> In the same way certain coders should never be allowed
> to program in c++ ;)

Uh, the odds of shooting your pair programmer are lower...

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!! 

In article <4357174a$0$15078$ed2619ec@ptn-nntp-reader02.plus.net>,
Jon Harrop  <usenet@jdh30.plus.com> wrote:
>MSCHAEF.COM wrote:
>> In article <4356f0e1$0$6521$ed2619ec@ptn-nntp-reader01.plus.net>,
>> Jon Harrop  <usenet@jdh30.plus.com> wrote:
>>>Alan Balmer wrote:
>>>> Bad code can be written in any language, and silly analogies don't
>>>> change that either.
>>>
>>>Unsafe code cannot be written in a safe language.
>> 
>> Sure it can. Just look at the Arianne V example elsewhere in the thread.
>> That code was clearly unsafe, for any useful definition of safety, and the
>> language had nothing to do with it. My hunch is that phrases like 'Unsafe
>> code cannot be written in a safe language.' are ultimately harmful, as
>> they might encourage people to drop their guard.
>
>Safe != Correct

There's that useless definition of safe I was alluding to. I can't think 
of many uses for safe, incorrect code.

-Mike
-- 
http://www.mschaef.com

On Thu, 20 Oct 2005 05:00:25 +0100, Jon Harrop <usenet@jdh30.plus.com>
wrote:

>MSCHAEF.COM wrote:
>> In article <4356f0e1$0$6521$ed2619ec@ptn-nntp-reader01.plus.net>,
>> Jon Harrop  <usenet@jdh30.plus.com> wrote:
>>>Alan Balmer wrote:
>>>> Bad code can be written in any language, and silly analogies don't
>>>> change that either.
>>>
>>>Unsafe code cannot be written in a safe language.
>> 
>> Sure it can. Just look at the Arianne V example elsewhere in the thread.
>> That code was clearly unsafe, for any useful definition of safety, and the
>> language had nothing to do with it. My hunch is that phrases like 'Unsafe
>> code cannot be written in a safe language.' are ultimately harmful, as
>> they might encourage people to drop their guard.
>
>Safe != Correct

!Correct == !Safe
-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Alan Balmer wrote:
> > Safe != Correct
> 
> !Correct == !Safe

No. For example:

  let factorial n = 0

is incorrect but safe.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

adaworks@sbcglobal.net wrote On 10/19/05 18:08,:

> 
> Well, yes.  C is a universal assembler with a few pathologies left over
> from its original targeted platform.

C is what happened when Algol and Fortran got drunk and spent the weekend
together.

MSCHAEF.COM wrote:
> > Safe != Correct
>
> There's that useless definition of safe I was alluding to. I can't think
> of many uses for safe, incorrect code.

This is precisely the point. Given a choice between:

1. Unsafe code that reads data off the end of an array, getting
non-deterministic values, continuing to analyse them and silently producing
incorrect results.

2. Safe code that raises an out of bounds exception.

The latter is preferable because you are told when such an error occurs in
your code. This gives you more faith that your answers are correct.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jussi Jumppanen wrote:
> August Karlstrom wrote:
> 
>> Yes, but opposed to C/C++ programs it crashes in a predictable
>> way.
> 
> I really don't see a lot of difference between the "bad"
> C/C++ crash when compared to the "good" unhandled
> exception.
> 
> All you really have done is replaced the c/c++:
> 
>  "Your program has generated a general protect fault."
> 
> message box with the all new:
> 
>   "Unhandled exception trapped."
> 
> message box.

The critical difference is that you _hope_ a segfault will occur in the
former case because, if it does not, your program can go on silently
producing erroneous results. That is far worse than a segfault.

This is such an important problem that people have gone to great lengths to
create tools like valgrind and electric fence to detect these cases.

> In both cases the program is left in an unknown state.

No. Exceptions leave the program in a well-defined state and exceptions are,
by definition, easier to recover from.

>> In C/C++ buffer overflows and pointer errors causes undefined
>> behavior which can make the error extremely hard to locate.
> 
> I agree that can happen in c/c++, but there are also lots
> of tools and coding techniques that also make this less
> likely to happen.

Or you can use a language that will guarantee that it is impossible and
(better still) will pick up many such errors at compile time using "static
checking".

>> To me it feels very unsatisfactory to know that if my code
>> contains these kinds of errors they might go undetected.
> 
> The Zeus editor is written in 100% c++, and I sleep easy at
> night knowing it does not contains these kinds of errors.

Have you run valgrind on it?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Kai-Uwe Bux wrote:
> Jon Harrop wrote:
>> Sure, I could go out of my way to interpret my C++ in a VM but that
>> doesn't change the fact that, by default, C++ is unsafe and encourages
>> programmers to be unsafe.
> 
> "encourages" no. I find it very easy to stay away from stuff that
> potentially breaks my code. It is just a matter of acquiring some habits.

Yes, it is easy but it requires effort and self-discipline. That is exactly
what I mean when I agreed that C++ encourages unsafe programming.

> But I agree that C++ makes it about as easy to something silly as to do
> something right. Unfortunately, to some people the silly way looks always
> more natural. One reason is probably, that safe constructs in C++ tend to
> be more verbose (std::vector<T> as opposed to T[] or boost::shared_ptr<T>
> as opposed to T*).

Exactly.

> As far as I can tell, range/validity checking can always be done in
> constant time. No violation of the standard is required. Specifically for
> set-iterators: You keep a reference count for every node in the balanced
> tree counting iterators pointing there. Removing an element of the set
> will not delete the node, it will just remove it from the tree and mark it
> as invalid (add some boolean field for that, or change the sign of the
> ref-count). The node self-destructs when the ref-count reaches 0, i.e.,
> when all invalidated iterators have been destroyed or redirected.
> Referencing a node via an iterator just checks the validity field. All
> operations of creating, changing, destroying nodes and iterators have a
> constant time and space overhead compared to the unchecked counter parts.

What happens when you pass a node from one set into a function that is
acting upon a different set? Surely every node must know which set it
belongs to and every set must maintain a set of its nodes in order to check
validity. Splicing will now require you to touch every spliced node.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

On Thu, 20 Oct 2005 19:41:32 +0100, Jon Harrop <usenet@jdh30.plus.com>
wrote:

>Alan Balmer wrote:
>> > Safe != Correct
>> 
>> !Correct == !Safe
>
>No. For example:
>
>  let factorial n = 0
>
>is incorrect but safe.

Not if the process control program depends on having the correct
value, and the reactor blows up.
-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Alan Balmer <albalmer@att.net> writes:

> On Thu, 20 Oct 2005 05:00:25 +0100, Jon Harrop <usenet@jdh30.plus.com>
> wrote:
> 
> >MSCHAEF.COM wrote:
> >> In article <4356f0e1$0$6521$ed2619ec@ptn-nntp-reader01.plus.net>,
> >> Jon Harrop  <usenet@jdh30.plus.com> wrote:
> >>>Alan Balmer wrote:
> >>>> Bad code can be written in any language, and silly analogies don't
> >>>> change that either.
> >>>
> >>>Unsafe code cannot be written in a safe language.
> >> 
> >> Sure it can. Just look at the Arianne V example elsewhere in the thread.
> >> That code was clearly unsafe, for any useful definition of safety, and the
> >> language had nothing to do with it. My hunch is that phrases like 'Unsafe
> >> code cannot be written in a safe language.' are ultimately harmful, as
> >> they might encourage people to drop their guard.
> >
> >Safe != Correct
> 
> !Correct == !Safe

The word "safe" is being used with more than one meaning.
The usual meaning when discussing programming (and after all
this is comp.programming) means there is no possibility of
segfaults, illegal memory accesses, or other kinds of
undefined behaviors.  This meaning is how Jon Harrop used
the word safe.

Apparently Alan Balmer intends the word safe be read more in
it's "regular" sense, of not being dangerous.  However, even
using this meaning, the equation '!Correct == !Safe' isn't
right.  Code to run a nuclear reactor that prevents the
reactor from ever being turned on, or being run in any way,
is (presumably) not correct, but it is still safe.

Unless "safe" is defined as being synonomous with "correct",
I think the equation '!Correct == !Safe' won't always be
right.

Jon Harrop wrote:
> Michael J�rgensen wrote:
> 
>>"Thomas G. Marshall"
>><tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in message
>>news:3AE5f.8506$Lb1.2817@trndny03...
>>
>>
>>>This also depends upon the OP's understanding of OO.  If he has no
>>>experience with OO fundamentals, then he had better /not/ start with C++.
>>>
>>>Not gonna get into /why/....it's just been /done/ too many times.  :-P
>>
>>Which language would you then suggest for someone wanting to learn OO?
> 
> 
> OCaml has an interesting form of OO quite unlike C++ and Java's. Also, OCaml
> provides alternatives so you aren't forced to use OO when it is
> inappropriate.

I'm sure that functional languages like ML and Hakell are superior to 
procedural languages when it comes to really advanced projects (e.g. in 
artificial intelligence). Generally, even though I have a degree in 
mathematics and have studied functional languages at university, I find 
that I have to think twice as hard both when reading and writing code in 
a functional language compared to a procedural (OOP) language. 
Procedural programming just feels more natural to me. Maybe it's just a 
question of practicing.


August

Jon Harrop wrote:

> Kai-Uwe Bux wrote:
>> Jon Harrop wrote:
>>> Sure, I could go out of my way to interpret my C++ in a VM but that
>>> doesn't change the fact that, by default, C++ is unsafe and encourages
>>> programmers to be unsafe.
>> 
>> "encourages" no. I find it very easy to stay away from stuff that
>> potentially breaks my code. It is just a matter of acquiring some habits.
> 
> Yes, it is easy but it requires effort and self-discipline. That is
> exactly what I mean when I agreed that C++ encourages unsafe programming.

I guess, we are not that far apart. However, you make it sound like it is a
permanent struggle; whereas to me it seems that the effort and
self-discipline become second nature rather quickly. 

[agreement snipped]

>> As far as I can tell, range/validity checking can always be done in
>> constant time. No violation of the standard is required. Specifically for
>> set-iterators: You keep a reference count for every node in the balanced
>> tree counting iterators pointing there. Removing an element of the set
>> will not delete the node, it will just remove it from the tree and mark
>> it as invalid (add some boolean field for that, or change the sign of the
>> ref-count). The node self-destructs when the ref-count reaches 0, i.e.,
>> when all invalidated iterators have been destroyed or redirected.
>> Referencing a node via an iterator just checks the validity field. All
>> operations of creating, changing, destroying nodes and iterators have a
>> constant time and space overhead compared to the unchecked counter parts.
> 
> What happens when you pass a node from one set into a function that is
> acting upon a different set?  Surely every node must know which set it 
> belongs to and every set must maintain a set of its nodes in order to
> check validity. Splicing will now require you to touch every spliced node.

I do not understand what you mean. I think that all operations offered by
std::set can be implemented with constant time overhead so that iterators
can be made validity/range checking. Which method do you think is bad.

And, most important, what do you mean by splicing?  


Probably, I should provide a little more detail on how I would implement
checking support in std::set. Unfortunately, I am too tired now. But I
shall come back to this issue.


Best

Kai-Uwe Bux

Kai-Uwe Bux wrote:
> Jon Harrop wrote:
>> Yes, it is easy but it requires effort and self-discipline. That is
>> exactly what I mean when I agreed that C++ encourages unsafe programming.
> 
> I guess, we are not that far apart. However, you make it sound like it is
> a permanent struggle; whereas to me it seems that the effort and
> self-discipline become second nature rather quickly.

I found it so intractable to write correct C++ code that I was forced to
change languages. In particular, I found it prohibitively difficult to find
bugs introduced by fundamental changes to the code.

When I was ported a major project from C++ to OCaml I tried to make a
fundamental change to both (I was new to OCaml and didn't feel confident
enough at the time). After 1 month's work on the C++ it was still not
working. I never got it working. When I went back to the OCaml, the
compiler led me through all of the new bugs. I fixed them all in 1 day and
the program worked perfectly. Then I was sold on OCaml...

>> What happens when you pass a node from one set into a function that is
>> acting upon a different set?  Surely every node must know which set it
>> belongs to and every set must maintain a set of its nodes in order to
>> check validity. Splicing will now require you to touch every spliced
>> node.
> 
> I do not understand what you mean. I think that all operations offered by
> std::set can be implemented with constant time overhead so that iterators
> can be made validity/range checking. Which method do you think is bad.
> 
> And, most important, what do you mean by splicing?

Removing a subsequence from one STL container and inserting into another is
called splicing and is implemented by the STL. You can do this in O(1) with
some STL data structures but, with your approach, I think you will need to
deal with every spliced element and that makes it necessarily O(n).

> Probably, I should provide a little more detail on how I would implement
> checking support in std::set. Unfortunately, I am too tired now. But I
> shall come back to this issue.

I haven't given it enough thought either but I'd be surprised if it can be
done.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

August Karlstrom wrote:
> I'm sure that functional languages like ML and Hakell are superior to
> procedural languages when it comes to really advanced projects (e.g. in
> artificial intelligence). Generally, even though I have a degree in
> mathematics and have studied functional languages at university, I find
> that I have to think twice as hard both when reading and writing code in
> a functional language compared to a procedural (OOP) language.
> Procedural programming just feels more natural to me. Maybe it's just a
> question of practicing.

You probably program in a functional style a lot without realising it. Every
time you use "+" instead of "+=" you're using a functional style. The
natural implementation of a ray tracer in C++ is almost purely functional:

  http://www.ffconsultancy.com/free/ray_tracer/comparison.html

If you want to write code to handle balanced binary trees then it is much
easier in a functional style (OCaml's implementation is 1/10th the length
of the one in the STL).

Some useful operations are asymptotically much faster when written in a
functional style. For example, set union:

  http://groups.google.com/group/comp.lang.functional/msg/cdae678b2d6e7ae6

In mathematics, recurrence relations are the most natural form for a wide
variety of definitions. These are most simply represented by recursive
functions written in a functional style, rather than loops. Look at the
discrete wavelet transform:

  http://www.ffconsultancy.com/products/ocaml_for_scientists/complete

Functional style is not always preferable to imperative style though. GUI
code is often best written in imperative style (as a state machine that is
poked about by the user). Impure functional languages like ML allow you to
mix functional and imperative style easily. I have yet to put enough effort
into any pure functional languages to say with any certainty if they can
compete.

Look at some of the examples that I've put on the SML and OCaml wikipedia
pages and consider how they would look in C++:

  http://en.wikipedia.org/wiki/Ocaml
  http://en.wikipedia.org/wiki/SML_programming_language

I first became interested in functional programming when I excitedly
explained to a friend how judicious use of "const" in my C++ code helped me
to reduce bugs. He pointed out that such use of immutable data structures
is functional programming, and pointed me at OCaml.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

"Flaran" <flaran@gmail.com> wrote in message
news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?

I'd choose the D programming language, which is as powerful as C++ but much
easier to program in. It compiles to native code, not a VM.

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

"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
news:dj7tr1$n9v$1@murdoch.acc.Virginia.EDU...
> But I agree that C++ makes it about as easy to something silly as to do
> something right. Unfortunately, to some people the silly way looks always
> more natural. One reason is probably, that safe constructs in C++ tend to
> be more verbose (std::vector<T> as opposed to T[] or boost::shared_ptr<T>
> as opposed to T*). Coming from MODULA 2, I consider verbosity a plus
(makes
> code easier to read, for me). Those who despise verbosity are in deep
> waters with C++.

This is a serious problem with C++. To write code in the modern C++ fashion
requires far more typing (and far more complex typing) than the built-in
shortcuts. It should be the other way around - the right way to do things
should be the short way, and the convoluted way should be the deprecated
way.

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

"Michael J�rgensen" <ccc59035@vip.cybercity.dk> wrote in message
news:43566db0$0$38699$edfadb0f@dread12.news.tele.dk...
> I find C++ compilers much more helpful than C compilers when it comes to
> finding bugs. I migrated from C to C++ four years ago, and it is my
> experience that the compiler catches many *more* errors that previously
used
> to be found at runtime. Many of these errors are silly, like type errors
and
> uninitialized variables, but I no longer have to track down hard-to-find
> runtime bugs on that account, because the compiler finds them for me.
>
> Of course, that may not be due to the change C -> C++, but could be
instead
> a general improvement in the number of warnings/errors that the compiler
> checks for.

Using uninitialized variables is perfectly legal in C++, and is the cause of
endless problems. This is why many C++ compilers have, as an extension,
optional additional checking to look for uninitialized variables (and many
other things).

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

"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
news:dj7tr1$n9v$1@murdoch.acc.Virginia.EDU...
> Jon Harrop wrote:
operator[] is range checked.
> >
> > Sure, I could go out of my way to interpret my C++ in a VM but that
> > doesn't change the fact that, by default, C++ is unsafe and encourages
> > programmers to be unsafe.
>
> "encourages" no. I find it very easy to stay away from stuff that
> potentially breaks my code.

Actually, with C++ it is often difficult to know about stuff that is
going to break your code.  The language is designed with so
many workarounds that one needs to be exceptionally careful
when using it for anything serious.

Certainly those programmers who know the entire language, the
implications of every construct, and the pitfalls and traps that
are inherent in the current version of C++ -- those programmers
will do just fine.   However, the vast majority of programmers
using C++ are not at that skill level and they are all too easily
seduced into using features that can leap out and bite one in
the nether regions of the anatomy.

Richard Riehle

"Jussi Jumppanen" <jussij@zeusedit.com> wrote in message
news:43579BD3.891@zeusedit.com...
>
> C++ encourages coders to write bad code in the exactly
> the same way a gun encourages it handler to accidently
> shoot himself in the foot.
>
.... and many of us who are forced to use this horrid little language
sometimes feel the urge to deliberately point the loaded gun at our
own heads.

Let's face it, from Dr. Stroustrups original vision, this language has
evolved into a very messy collection of features overlaid by a set
of workarounds, overlaid by obscurely designed libraries.  The
longer it lives, the messier it gets.  The emperor, it seems, really
does not have any clothes.

Richard Riehle

"Scott Moore" <samiamsansspam@Sun.COM> wrote in message
news:dj8oh5$qla$1@news1nwk.SFbay.Sun.COM...
> adaworks@sbcglobal.net wrote On 10/19/05 18:08,:
>
> >
> > Well, yes.  C is a universal assembler with a few pathologies left over
> > from its original targeted platform.
>
> C is what happened when Algol and Fortran got drunk and spent the weekend
> together.
>
In defense of C, the language was well-designed for its time and for its
targeted environment.  It has proven remarkably robust, having been
ported to a lot of different platforms.  It has nothing in it, however,
that cannot be done as easily and more safely with other languages.
And it does contain features that, in our more modern age, are
unnecessary and potentially defect-inducing.

Too many programmers are enchanted with the idea of a language that
is easy to write and not concerned enough with a language that is easy
to read.   Source code that reduces the time to understanding is more
important in our time than source code that is easy to develop.  This
lesson seems difficult to promote.   As long as programmers are more
interested in languages where writeability is more important than
readability, C and C++ will continue to have a following.   That is
probably forever since we seem never to learn our lessons.

Richard Riehle

"Jon Harrop" <usenet@jdh30.plus.com> wrote in message
news:4356f0e1$0$6521$ed2619ec@ptn-nntp-reader01.plus.net...
> Alan Balmer wrote:
> > Bad code can be written in any language, and silly analogies don't
> > change that either.
>
> Unsafe code cannot be written in a safe language.
>
I have a lot of years of experience with Ada, probably the safest
language one can find.   During those years, I have seen people do
truly stupid things in an attempt to thwart the default safe constructs
of the language.

The Ada compiler checks everything at compile time.   There is, however,
a feature of the language that lets the programmer/designer override
the defaults.  These are the "unchecked" features of the language.  Some
developers are forbidden by the standards of their organization to
never use unchecked constructs.  Further, Ada makes it so inconvenient
to use unchecked anything that most developers are discouraged from
doing so.

The code produced by an Ada compiler tends to be pretty reliable until
someone decides to use unchecked conversion, unchecked storage
deallocation, or one of the other unchecked features.

Those of who have found it necessary to use unchecked features realize the
need for building additional safety into our code.  However, there is always
some idiot who doesn't get the message.  So was the case for Ariane V.
An unchecked feature was used and no one wrote backup code to ensure
that it would not fail.  Unchecked means that the built-in assertions no longer
apply.

So, one can write unsafe code in a language that emphasizes safety.  To be
fair, though, when one superimposes SPARK on Ada code, safety is likely
to be uncompromised.

The default of C and C++, for many constructs, is unsafe.  The default for
every construct in Ada is safe.  I can make C or C++ safer.  I can certainly
make Ada less safe, but it takes some deliberate effort to do so.

Richard Riehle

"Phlip" <phlipcpp@yahoo.com> wrote in message
news:lsD5f.859$Y61.745@newssvr33.news.prodigy.com...
> Jon Harrop wrote:
>
> > Alan Balmer wrote:
>
> >> Bad code can be written in any language, and silly analogies don't
> >> change that either.
> >
> > Unsafe code cannot be written in a safe language.
>
> Famous last words.
>
A rare instance where Philp and I are in complete agreement!

Richard Riehle

Jon Harrop wrote:

> Kai-Uwe Bux wrote:
>> Jon Harrop wrote:
>>> Yes, it is easy but it requires effort and self-discipline. That is
>>> exactly what I mean when I agreed that C++ encourages unsafe
>>> programming.
>> 
>> I guess, we are not that far apart. However, you make it sound like it is
>> a permanent struggle; whereas to me it seems that the effort and
>> self-discipline become second nature rather quickly.
> 
> I found it so intractable to write correct C++ code that I was forced to
> change languages. In particular, I found it prohibitively difficult to
> find bugs introduced by fundamental changes to the code.
> 
> When I was ported a major project from C++ to OCaml I tried to make a
> fundamental change to both (I was new to OCaml and didn't feel confident
> enough at the time). After 1 month's work on the C++ it was still not
> working. I never got it working. When I went back to the OCaml, the
> compiler led me through all of the new bugs. I fixed them all in 1 day and
> the program worked perfectly. Then I was sold on OCaml...

Hm, maybe I should have a look at OCaml.


>>> What happens when you pass a node from one set into a function that is
>>> acting upon a different set?  Surely every node must know which set it
>>> belongs to and every set must maintain a set of its nodes in order to
>>> check validity. Splicing will now require you to touch every spliced
>>> node.
>> 
>> I do not understand what you mean. I think that all operations offered by
>> std::set can be implemented with constant time overhead so that iterators
>> can be made validity/range checking. Which method do you think is bad.
>> 
>> And, most important, what do you mean by splicing?
> 
> Removing a subsequence from one STL container and inserting into another
> is called splicing and is implemented by the STL. You can do this in O(1)
> with some STL data structures but, with your approach, I think you will
> need to deal with every spliced element and that makes it necessarily
> O(n).
> 
>> Probably, I should provide a little more detail on how I would implement
>> checking support in std::set. Unfortunately, I am too tired now. But I
>> shall come back to this issue.
> 
> I haven't given it enough thought either but I'd be surprised if it can be
> done.

I had a look. This splicing thing applies to std::list. The idea is that you
can move over a bunch of element from one list to another just by
redirecting some pointers.

You are right that, for splicing, iterators do not just need to keep track
of the element they are referencing but also the container. However, I
think the container does not need to keep track of all iterators:

  void splice(iterator position, list<T,Allocator>& x);

  Requires: &x != this.
  Invalidates all iterators and references to the list x.
  Complexity: Constant time.

Here is an idea of how you can mark all iterators as invalid by only one
operation: have all iterators point to a refcounted object that says: you
belong to the list blah. The list blah itself would also have a pointer to
that object. When blah is passed as the x argument in splice, it would tell
the object: I clear. The object would change its state now flagging that
all pointers became invalid. On the same token, the list blah woudl create
a new object and all iterators provided by blah to any of its elements in
the future would be registered with the new flagging object.



  void splice(iterator position, list<T,Allocator>& x, iterator i);


  The result is unchanged if position == i or position == ++i. Invalidates 
  only the iterators and references to the spliced element.
  Requires: i is a valid dereferenceable iterator of x.
  Complexity: Constant time.

This moves over but one element from x. That can be done in constant time.


  void splice( iterator position, list<T,Allocator>& x, 
               iterator first, iterator last);

  Effects: Inserts elements in the range [first, last) before position and 
  removes the elements from x.
  Requires: [first, last) is a valid range in x. The result is undefined if     
  position is an iterator in the range [first, last). Invalidates only the 
  iterators and references to the spliced elements.
  Throws: Nothing
  Complexity: Constant time if &x == this; otherwise, linear time.

Here, it seems that we can meet the complexity requirement, because it
allows for linear time in the trick case.



Best

Kai-Uwe Bux

ps.: I think, it would be an interesting exercise to actually implement a
range/validity checking list.

In article <4357e863$0$49776$ed2e19e4@ptn-nntp-reader04.plus.net>, 
usenet@jdh30.plus.com says...
> Jussi Jumppanen wrote:

> > All you really have done is replaced the c/c++:
> > 
> >  "Your program has generated a general protect fault."
> > 
> > message box with the all new:
> > 
> >   "Unhandled exception trapped."
> > 
> > message box.
> 
> The critical difference is that you _hope_ a segfault will occur in the
> former case because, if it does not, your program can go on silently
> producing erroneous results. That is far worse than a segfault.

Actually, it completely depends on circumstances.  If the program is a 
typical game, or a space vehicle that can't be reprogrammed, the first 
case is infinitely better - a chance of reasonable success vs. 
guaranteed complete mission failure.

Imagine if people became paralysed and froze up every time they made an 
error in logic!

- Gerry Quinn

Walter Bright wrote:

> Using uninitialized variables is perfectly legal in C++,

Strictly speaking, it's "undefined behavior", meaning the compiler is not 
required to catch the problem, and the code is not required to not crash.

> and is the cause of
> endless problems. This is why many C++ compilers have, as an extension,
> optional additional checking to look for uninitialized variables (and many
> other things).

And either I can fool them, or they can impose a potential performance 
penalty.

(Go with the latter, and only optimize by profiling.)

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!! 

In article <43582849$0$49803$ed2e19e4@ptn-nntp-reader04.plus.net>,
Jon Harrop  <usenet@jdh30.plus.com> wrote:
   ...
>When I went back to the OCaml, the
>compiler led me through all of the new bugs. I fixed them all in 1 day and
>the program worked perfectly.

It's stuff like this that gets me antsy about the distinction between 
safe and correct, elsethread. For all its ability to prove things about 
your program's semantics, the compiler doesn't know what the end result 
should be. That still up to the develoment/analysis team to do the 
engineering/testing/specification legwork.

To me, that somewhat diminishes the value of the 'safe' language. If I'm 
going to have to prove the program correct to a higher standard of 
correctness anyway, then all language safety is is a tool for 
accomplishing that possibly more quickly. As such, if a less safe language 
offers other compelling benefits, it's worth considering using.

Even then, calling C++ less safe seems a little unfair.  Oberon was 
presented as a safe language that offers a SYSTEM module to escape to 
unsafe system features.  In a sense, C++ is the opposite: an unsafe 
language that allows safety to be brought in as desired. That doesn't make 
the question 'do you want safety?', but rather 'do you want to assume 
safety by default?'. There are lots of scenarious when you might not, but 
still want the ability to write new code safely.

In the case of Java (modulo JNI, etc.) maybe the question should be 'do 
you want to only have safety?'.

-Mike

-- 
http://www.mschaef.com

Gerry Quinn wrote:
> In article <4357e863$0$49776$ed2e19e4@ptn-nntp-reader04.plus.net>,
> usenet@jdh30.plus.com says...
> > Jussi Jumppanen wrote:
>
> > > All you really have done is replaced the c/c++:
> > >
> > >  "Your program has generated a general protect fault."
> > >
> > > message box with the all new:
> > >
> > >   "Unhandled exception trapped."
> > >
> > > message box.
> >
> > The critical difference is that you _hope_ a segfault will occur in the
> > former case because, if it does not, your program can go on silently
> > producing erroneous results. That is far worse than a segfault.
>
> Actually, it completely depends on circumstances.  If the program is a
> typical game, or a space vehicle that can't be reprogrammed, the first
> case is infinitely better - a chance of reasonable success vs.
> guaranteed complete mission failure.

I agree.  Also, sometimes it's useful to ignore an overrun error
somewhere in order to be able to debug further and find other problems.

IMO the ideal situation is to have the choice of gauranteed error for
out-of-bounds access as a compiler switch.

(As Jon said above, it is certainly true that overrun errors often do
not gaurantee any reproducible crashes.  I've found many bugs that
behave like this.)

"MSCHAEF.COM" <mschaef@fnord.io.com> wrote in message
news:qKednft2QfGtasXeRVn-vg@io.com...
> In article <43582849$0$49803$ed2e19e4@ptn-nntp-reader04.plus.net>,
>
>  For all its ability to prove things about
> your program's semantics, the compiler doesn't know what the end result
> should be. That still up to the develoment/analysis team to do the
> engineering/testing/specification legwork.
>
There are different levels of safety.   Several standards groups have
laid out examples of those levels.   Also, one can look to DO-178B
for some suggestions.

Some languages are designed so normal constructs are safe by default.
C++ is not one of them.  Neither is C.   Neither is Java.   The design
goals for those languages are different and, though safety was a concern,
it was not the dominant concern.   It takes excellent design skills and
careful programming to ensure that unsafe features are avoided when
developing safety-critical software.  It can be difficult to make an unsafe
language safer.   And "safer" is the issue for such languages, not absolutely
safe.

For a language such as Ada, where safe is the default, one may sometimes
need to relax that default.   There are several ways to do this at varying
levels of safety.  The language specification makes it clear when a construct
is considered unsafe.  Modula-3 has also made some good progress in
this area.

Finally, it is certainly possible to write stupid, unsafe code in any language.
The
Ada compiler will make safety the default, will protect yourself from shooting
youself in the foot, up to a point.  If you pick the wrong algorithm for your
application, use > when you meant < (although we have ways to prevent
that as well), or do something else that is completely stupid, there is a limit
to how much a compiler can protect you.

The example of firearms was given in a different post.  Imagine a pistol
with no safety switch.   Imagine a pistol where, dropping it might drive
the firing-pin into the center of the unfired cartridge.   Many modern
firearms are designed to be safer than their predecessors.   People still
do stupid things with them and get hurt or killed.

Richard Riehle

On 20 Oct 2005 13:26:15 -0700, Tim Rentsch <txr@alumnus.caltech.edu>
wrote:

>Apparently Alan Balmer intends the word safe be read more in
>it's "regular" sense, of not being dangerous.  However, even
>using this meaning, the equation '!Correct == !Safe' isn't
>right.  Code to run a nuclear reactor that prevents the
>reactor from ever being turned on, or being run in any way,
>is (presumably) not correct, but it is still safe.

No, it isn't. It causes the programmer to be fired.
-- 
Al Balmer
Balmer Consulting
removebalmerconsultingthis@att.net

Alan Balmer wrote:
> On 20 Oct 2005 13:26:15 -0700, Tim Rentsch <txr@alumnus.caltech.edu>
> wrote:
>
> >Apparently Alan Balmer intends the word safe be read more in
> >it's "regular" sense, of not being dangerous.  However, even
> >using this meaning, the equation '!Correct == !Safe' isn't
> >right.  Code to run a nuclear reactor that prevents the
> >reactor from ever being turned on, or being run in any way,
> >is (presumably) not correct, but it is still safe.
>
> No, it isn't. It causes the programmer to be fired.

Looking at it that way their is no reason to use the word "safe" at
all, we may as well use the word "correct" always.

I'm more happy with the normal definition Tim and Jon have used.

adaworks@sbcglobal.net wrote:
> "Scott Moore" <samiamsansspam@Sun.COM> wrote in message
> news:dj8oh5$qla$1@news1nwk.SFbay.Sun.COM...
> 
>>adaworks@sbcglobal.net wrote On 10/19/05 18:08,:
>>
>>
>>>Well, yes.  C is a universal assembler with a few pathologies left over
>>>from its original targeted platform.
>>
>>C is what happened when Algol and Fortran got drunk and spent the weekend
>>together.
>>
> 
> In defense of C, the language was well-designed for its time and for its
> targeted environment.  It has proven remarkably robust, having been
> ported to a lot of different platforms.  It has nothing in it, however,
> that cannot be done as easily and more safely with other languages.

Performance (and, stretching a point, portability)

> And it does contain features that, in our more modern age, are
> unnecessary and potentially defect-inducing.
> 
> Too many programmers are enchanted with the idea of a language that
> is easy to write and not concerned enough with a language that is easy
> to read.

It is a myth that C is easier/harder to comprehend than any other 
language. Comprehensibility (for even moderate sized programs) is a 
function of the amount and kind of abstraction added. Too much 
abstraction can be just as bad as too little. Also, if the writer picked 
the "wrong" kind of abstraction (i.e. what the reader didn't expect) 
even a well abstracted program can be difficult to understand.

>   Source code that reduces the time to understanding is more
> important in our time than source code that is easy to develop.

Depends on your domain. Does not hold true, in general, for things like 
embedded programs.

>  This
> lesson seems difficult to promote.   As long as programmers are more
> interested in languages where writeability is more important than
> readability, C and C++ will continue to have a following.   That is
> probably forever since we seem never to learn our lessons.
> 
> Richard Riehle
> 
> 

"CTips" <ctips@bestweb.net> wrote in message
news:11lmtg0ib41a0b0@corp.supernews.com...
> adaworks@sbcglobal.net wrote:
> > "Scott Moore" <samiamsansspam@Sun.COM> wrote in message
> > news:dj8oh5$qla$1@news1nwk.SFbay.Sun.COM...
> >
> >
> > In defense of C, the language was well-designed for its time and for its
> > targeted environment.  It has proven remarkably robust, having been
> > ported to a lot of different platforms.  It has nothing in it, however,
> > that cannot be done as easily and more safely with other languages.
>
> Performance (and, stretching a point, portability)
>
C is not inherently better suited to performance than any other
language.  An optimizing Ada compiler can produce code with
equal perfomance.  Portability is an inherent characteristic of
Ada.
>
>
> It is a myth that C is easier/harder to comprehend than any other
> language. Comprehensibility (for even moderate sized programs) is a
> function of the amount and kind of abstraction added. Too much
> abstraction can be just as bad as too little. Also, if the writer picked
> the "wrong" kind of abstraction (i.e. what the reader didn't expect)
> even a well abstracted program can be difficult to understand.
>
This can be a function of scale.  When one considers readability of
a large-scale program, C does not scale up well.  For smaller
programs, C can be perfectly fine when used by someone who
is careful.  For large teams of programmers, developing embedded
applications, Ada continues to be the best alternative
>
> >   Source code that reduces the time to understanding is more
> > important in our time than source code that is easy to develop.
>
> Depends on your domain. Does not hold true, in general, for things like
> embedded programs.
>
Ada has been highly successful for embedded systems.   The software
for many commercial aircraft systems,  space systems, and other
domains is all embedded.  Ada drives quite a few of these.   Ariane IV
and Ariane V, both use Ada.   Although the first flight of Ariane V
did fail, it is now behaving quite well using Ada.

When it comes to embedded systems that require a portable, efficient
concurrent environment, Ada is certainly more appropriate than
most alternatives.   While C can be used for such applications, it does
not approach the maintainability, readability, and performance of Ada
except when when used by heroic programmers.

On the other hand, Ada is not appropriate for some kinds of embedded
systems.   In particular, I don't think it is the right choice for small
embedded microcontrollers such as the I-8051.   It is not clear that
C is right for that environment either.   In fact, Forth has shown itself
to be highly effective on such platforms.

Richard Riehle

CTips wrote:
> It is a myth that C is easier/harder to comprehend than any other
> language. Comprehensibility (for even moderate sized programs) is a
> function of the amount and kind of abstraction added.

To a large extent, I agree with you. However, there is something to be
said for a language with as few "gotchas" as possible. For example, how
many C programmers know exactly what

  char s[4] = "Hello";

does without reaching for a book?

How about

  *p = *q = *r;

What does that do? What if two hundred lines earlier, control passed
through the following line?

  p = q = r;

Does that change your answer? Can you imagine a language where that
doesn't change your answer? The difficulty most certainly *is* a
language issue and not one of abstraction.

Josh

Jon Harrop wrote:
> 
> Jussi Jumppanen wrote:
>
> > The Zeus editor is written in 100% c++, and I sleep easy at
> > night knowing it does not contains these kinds of errors.
> 
> Have you run valgrind on it?

No. I have not found the need to run any sort of bounds checking 
programs on the Zeus source code.

I'm sure Zeus is no different to other software in that it has it's 
fair share of bugs. But in general I find these bugs are the result 
of bad programming logic and not so much the result of bad (ie unsafe) 
code.

Sure C++ lets you write unsafe code, but it is also very easy
to write safe code using C++.

Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, WordStar, Emacs) Text Editor
http://www.zeusedit.com

Jussi Jumppanen wrote:
> Jon Harrop wrote:
>> Jussi Jumppanen wrote:
>> > The Zeus editor is written in 100% c++, and I sleep easy at
>> > night knowing it does not contains these kinds of errors.
>> 
>> Have you run valgrind on it?
> 
> No. I have not found the need to run any sort of bounds checking
> programs on the Zeus source code.

Bounds checking is only one such source of errors. There are many others,
such as uninitialised variables, that are also checked by valgrind.

> I'm sure Zeus is no different to other software in that it has it's
> fair share of bugs. But in general I find these bugs are the result
> of bad programming logic and not so much the result of bad (ie unsafe)
> code.

If you haven't looked then you can't claim to know with any certainty.

> Sure C++ lets you write unsafe code, but it is also very easy
> to write safe code using C++.

You mean it is easy to assume that your C++ is safe provided you don't
actually look.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Gerry Quinn wrote:
>> The critical difference is that you _hope_ a segfault will occur in the
>> former case because, if it does not, your program can go on silently
>> producing erroneous results. That is far worse than a segfault.
> 
> Actually, it completely depends on circumstances.  If the program is a
> typical game, or a space vehicle that can't be reprogrammed, the first
> case is infinitely better - a chance of reasonable success vs.
> guaranteed complete mission failure.

If you're programming mission critical code then I'd hope you would remember
to catch and handle your own exceptions.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

"Jussi Jumppanen" <jussij@zeusedit.com> wrote in message
news:435B93BC.1360@zeusedit.com...
>
> Sure C++ lets you write unsafe code, but it is also very easy
> to write safe code using C++.
>
"Easy?"  Interesting choice of words.   Interesting placement of the
adjective in that sentence.

First, why would one want to choose a language that "let's you write
unsafe code," when there are equally good languages that make it
much harder to write unsafe code?  Second, C++ makes it easy to
write unsafe code.  This is a bit different from "letting" you write
unsafe code.

As the code gets larger, and becomes more complex, it becomes
easier and easier for the code to become unsafe. This is true of
nearly any software system regardless of language.   The question
is, which languages scale up best when I am writing large-scale
software systems.   C does not scale well.   C++ scales a little
better.   Java is OK, but works best for smaller systems than
C++.  Eiffel and Ada scale up better than any of those so far
mentioned.   Eiffel is probably a better choice than Java or
C++ in nearly every case.

On the other hand, C is best for certain classes or problems such
as embedded software on microcontrollers.  C++ and Ada do
not do well on microcontrollers.   C++ has a role in some graphics
environments and holds its own well there.   Safety is not a
major concern in most graphics.   Ada outshines C++ in large-scale
safety-critical embedded software systems such as avionics, and
space applications.   True, some people have chosen to use C++
for those kinds of applications -- and at eveyone's peril.

Richard Riehle

Josh Sebastian said:

> However, there is something to be
> said for a language with as few "gotchas" as possible. For example, how
> many C programmers know exactly what
> 
>   char s[4] = "Hello";
> 
> does without reaching for a book?

Most of them know it doesn't do spit, because it won't compile.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Richard wrote:
) Josh Sebastian said:
)
)> However, there is something to be
)> said for a language with as few "gotchas" as possible. For example, how
)> many C programmers know exactly what
)> 
)>   char s[4] = "Hello";
)> 
)> does without reaching for a book?
)
) Most of them know it doesn't do spit, because it won't compile.

GCC compiles it just fine, all you get is a warning.
Without reaching for a book, I would guess it's equivalent to:

  char s[4] = { 'H', 'e', 'l', 'l' };

which allocates four chars and puts 'H' 'e' 'l' 'l' in there.

So what's the gotcha ?  And why didn't your box compile it ?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Jon Harrop wrote:

> You mean it is easy to assume that your C++ is safe provided you don't
> actually look.

Always assume any program is unsafe.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!!

Willem wrote:

> ) Most of them know it doesn't do spit, because it won't compile.
>
> GCC compiles it just fine, all you get is a warning.
> Without reaching for a book, I would guess it's equivalent to:
>
>  char s[4] = { 'H', 'e', 'l', 'l' };
>
> which allocates four chars and puts 'H' 'e' 'l' 'l' in there.
>
> So what's the gotcha ?  And why didn't your box compile it ?

Because "Hello" is and only is { 'H', 'e', 'l', 'l', 'o', '\0' }, which 
exceeds the array size of 4.

Arrays are first-class objects in C++. You can't tell because everyone 
treats them as arrays, and they decay so easily.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand  <-- NOT a blog!!! 

Phlip wrote:
) Because "Hello" is and only is { 'H', 'e', 'l', 'l', 'o', '\0' }, which 
) exceeds the array size of 4.

So what ?
On my compiler, there's no gotcha.  Anyway, what the compiler does isn't
quite what I said, but almost.  What actually happens is that the string
"Hello" (including NUL-terminator) is stored in the object code somewhere,
and then 4 bytes of that are copied into s[] on initialisation.

) Arrays are first-class objects in C++. You can't tell because everyone 
) treats them as arrays, and they decay so easily.

The question was about C, not C++.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Willem said:

> Richard wrote:
> ) Josh Sebastian said:
> )
> )> However, there is something to be
> )> said for a language with as few "gotchas" as possible. For example, how
> )> many C programmers know exactly what
> )>
> )>   char s[4] = "Hello";
> )>
> )> does without reaching for a book?
> )
> ) Most of them know it doesn't do spit, because it won't compile.
> 
> GCC compiles it just fine, all you get is a warning.

"all"? A warning is a sign that something may be badly wrong.

> Without reaching for a book, I would guess it's equivalent to:
> 
>   char s[4] = { 'H', 'e', 'l', 'l' };
> 
> which allocates four chars and puts 'H' 'e' 'l' 'l' in there.
> 
> So what's the gotcha ?  And why didn't your box compile it ?

It's a constraint violation. It requires a diagnostic, which is why you got 
a warning. The C Standard says:


3.5.7 Initialization

[...]

Constraints

   There shall be no more initializers in an initializer list than
there are objects to be initialized.


Your code violates this constraint. Had you invoked your compiler in 
conforming mode, you would almost certainly have got an "error". Bear in 
mind that the Standard doesn't distinguish between "errors" and "warnings". 
It only discusses diagnostics. The code required the generation of a 
diagnostic (and for code to require this, it has to be pretty broken - i.e. 
it has to contain at least one constraint violation or syntax error).

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Willem wrote:
> Richard wrote:
> ) Josh Sebastian said:
> )
> )> However, there is something to be
> )> said for a language with as few "gotchas" as possible. For example, how
> )> many C programmers know exactly what
> )> 
> )>   char s[4] = "Hello";
> )> 
> )> does without reaching for a book?
> )
> ) Most of them know it doesn't do spit, because it won't compile.
> 
> GCC compiles it just fine, all you get is a warning.
> Without reaching for a book, I would guess it's equivalent to:
> 
>   char s[4] = { 'H', 'e', 'l', 'l' };
> 
> which allocates four chars and puts 'H' 'e' 'l' 'l' in there.

So an innocent "hello" turns into hell ;-)


August

Richard wrote:
) Willem said:
)
) <snip>
)> So what's the gotcha ?  And why didn't your box compile it ?
)
) It's a constraint violation. It requires a diagnostic, which is why you got 
) a warning. The C Standard says:
)
)  <snip>
)
) Your code violates this constraint. Had you invoked your compiler in 
) conforming mode, you would almost certainly have got an "error". Bear in 
) mind that the Standard doesn't distinguish between "errors" and "warnings". 
) It only discusses diagnostics. The code required the generation of a 
) diagnostic (and for code to require this, it has to be pretty broken - i.e. 
) it has to contain at least one constraint violation or syntax error).

So it's not a gotcha.  There's nothing weird about it.  It's perfectly
normal bad code, and the compiler perfectly normally complains about it.


Here's what started it:

)> ) Josh Sebastian said:
)> )
)> )> However, there is something to be
)> )> said for a language with as few "gotchas" as possible. For example, how
)> )> many C programmers know exactly what
)> )>
)> )>   char s[4] = "Hello";
)> )>
)> )> does without reaching for a book?

However, that code is not a 'gotcha' in any way.  On a lenient compiler,
you get a perfectly logical warning and it does what you would expect,
and on a strict compiler you get a perfectly logical error message.
It's not even undefined behaviour, so what's the deal ?



SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

In article <435bb6f9$0$49804$ed2e19e4@ptn-nntp-reader04.plus.net>, 
usenet@jdh30.plus.com says...
> Gerry Quinn wrote:

> >> The critical difference is that you _hope_ a segfault will occur in the
> >> former case because, if it does not, your program can go on silently
> >> producing erroneous results. That is far worse than a segfault.
> > 
> > Actually, it completely depends on circumstances.  If the program is a
> > typical game, or a space vehicle that can't be reprogrammed, the first
> > case is infinitely better - a chance of reasonable success vs.
> > guaranteed complete mission failure.
> 
> If you're programming mission critical code then I'd hope you would remember
> to catch and handle your own exceptions.

You would also hope, I assume, that I would use an alternate means to 
test for error conditions in languages that did not support exceptions.

- Gerry Quinn

Gerry Quinn wrote:
>> If you're programming mission critical code then I'd hope you would
>> remember to catch and handle your own exceptions.
> 
> You would also hope, I assume, that I would use an alternate means to
> test for error conditions in languages that did not support exceptions.

No. I would expect them to choose a suitable (safe) language rather than try
to make the best of a bad job.

How are you going to recover when your out of bounds error scribbles over
your OS?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

In article <C8L6f.4361$dO2.1753@newssvr29.news.prodigy.net>, 
adaworks@sbcglobal.net says...
> 
> C is not inherently better suited to performance than any other
> language.  An optimizing Ada compiler can produce code with
> equal perfomance.  Portability is an inherent characteristic of
> Ada.

Portability and performance are intrinsically conflicting.  Language 
constructs will invariably favour one kind of processor over another.  
Thus no language can be designed to be optimal on every system.  But a 
simple language that targets characteristics of common systems is 
likely to yield the greatest performance on average. 

- Gerry Quinn

Willem said:

> So it's not a gotcha.  There's nothing weird about it.  It's perfectly
> normal bad code, and the compiler perfectly normally complains about it.

Indeed. I agree entirely. In fact, that was the point I was making.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

CTips wrote:

<snip>

> It is a myth that C is easier/harder to comprehend than any other
> language. Comprehensibility (for even moderate sized programs) is a
> function of the amount and kind of abstraction added.

It depends on the application. A program making heavy use of
dynamically allocated multi-dimensional arrays will probably be more
difficult to understand if written in C than in Fortran 90+, using
ALLOCATABLE arrays. C programming requires facility with pointers,
which many programmers do find harder to comprehend than code without
pointers.

Many program written in C++, and c++ write Java, but not reverse.

Richard Heathfield wrote:
> Josh Sebastian said:
>
> > However, there is something to be
> > said for a language with as few "gotchas" as possible. For example, how
> > many C programmers know exactly what
> >
> >   char s[4] = "Hello";
> >
> > does without reaching for a book?
>
> Most of them know it doesn't do spit, because it won't compile.

Oviously I can't count, and you're as lenient as ever.

  char s[5] = "Hello";

Just for good measure, let's throw in a

  size_t s_len = strlen(s);

"An array of character type may be initialized by a character string
literal, optionally enclosed in braces. Successive characters of the
character string literal (including the terminating null character if
there is room or if the array is of unknown size) initialize the
members of the array." (C89)

Josh

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1dc636936042b47398a6cc@news.indigo.ie...
>
> Portability and performance are intrinsically conflicting.  Language
> constructs will invariably favour one kind of processor over another.
> Thus no language can be designed to be optimal on every system.  But a
> simple language that targets characteristics of common systems is
> likely to yield the greatest performance on average.
>
This is not true in the age of optimizing compilers.  A lot of progress has
been made over the past decade in the field of optimization.  Ada, when
optimized performs quite well, at least as well as C and certainly as well
as equivalent C++.  Of course, we need to understand the trade-off of
optimizing for speed versus storage.

Also, the fact that a language is close to the machine does not guarantee
performance.  It is quite easy to write a poorly performing program
in Assembler -- a program that performs badly but does so very fast.

Richard Riehle

Josh Sebastian said:

> 
> Richard Heathfield wrote:
>> Josh Sebastian said:
>>
>> > However, there is something to be
>> > said for a language with as few "gotchas" as possible. For example, how
>> > many C programmers know exactly what
>> >
>> >   char s[4] = "Hello";
>> >
>> > does without reaching for a book?
>>
>> Most of them know it doesn't do spit, because it won't compile.
> 
> Oviously I can't count, and you're as lenient as ever.

You are most welcome. :-)

> 
>   char s[5] = "Hello";
> 
> Just for good measure, let's throw in a
> 
>   size_t s_len = strlen(s);

As you well know, strlen requires a string as its input, and s isn't a 
string (as you also well know). This is hardly a gotcha - null termination 
is a well-known feature of the default C string model, and it is clear from 
a trivial inspection of the initialisation that no space has been provided 
for a null terminator.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/2005
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

In article <435c26f8$0$73627$ed2619ec@ptn-nntp-reader03.plus.net>, 
usenet@jdh30.plus.com says...
> Gerry Quinn wrote:

> >> If you're programming mission critical code then I'd hope you would
> >> remember to catch and handle your own exceptions.
> > 
> > You would also hope, I assume, that I would use an alternate means to
> > test for error conditions in languages that did not support exceptions.
> 
> No. I would expect them to choose a suitable (safe) language rather than try
> to make the best of a bad job.
> 
> How are you going to recover when your out of bounds error scribbles over
> your OS?

Can't remember that happening since the Spectrum days.  

The scenario in which it is likely (machines with tiny memories) is 
precisely the one in which C is most common, and for good reasons.

- Gerry Quinn

In article <jA07f.3688$D13.1071@newssvr11.news.prodigy.com>, 
adaworks@sbcglobal.net says...
> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
> news:MPG.1dc636936042b47398a6cc@news.indigo.ie...
> >
> > Portability and performance are intrinsically conflicting.  Language
> > constructs will invariably favour one kind of processor over another.
> > Thus no language can be designed to be optimal on every system.  But a
> > simple language that targets characteristics of common systems is
> > likely to yield the greatest performance on average.
> >
> This is not true in the age of optimizing compilers.  A lot of progress has
> been made over the past decade in the field of optimization.  Ada, when
> optimized performs quite well, at least as well as C and certainly as well
> as equivalent C++.  Of course, we need to understand the trade-off of
> optimizing for speed versus storage.

I have seen such claims for many languages, including Java.  Perhaps 
you would provide a link to an unbiased set of benchmark tests that 
demonstrate it.

My impression is that C tends to score rather highly in performance 
benchmarks.

- Gerry Quinn

Gerry Quinn wrote:
> In article <435c26f8$0$73627$ed2619ec@ptn-nntp-reader03.plus.net>,
> usenet@jdh30.plus.com says...
>> How are you going to recover when your out of bounds error scribbles over
>> your OS?
> 
> Can't remember that happening since the Spectrum days.

If you count the memory allocation tables for the current process as "OS"
then it happens today in most OSs.

> The scenario in which it is likely (machines with tiny memories) is
> precisely the one in which C is most common, and for good reasons.

Look at mobile phones...

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Gerry Quinn wrote:
> I have seen such claims for many languages, including Java.  Perhaps
> you would provide a link to an unbiased set of benchmark tests that
> demonstrate it.

Fortran vs C on some array benchmarks is probably a good bet. Fortran
compilers often do a lot of platform-specific cache-based optimisation that
a C compiler won't do.

You may also be interested in my ray tracer:

  http://www.ffconsultancy.com/free/ray_tracer/languages.html

> My impression is that C tends to score rather highly in performance
> benchmarks.

I wrote a C implementation of my ray tracer. It was a lot slower than the
C++. I am sure I could have optimised to run just as fast but it is
seriously tedious and boring work, even for this 50LOC program. The C was
already the longest implementation at about 200LOC.

So a more important point is that, if you have a non-trivial program,
there's no way you're going to be able to find the time to optimise the
whole thing by hand. You need a language expressive enough that its
compiler will generate efficient code for you. That language isn't C/C++.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

In article <435cde03$0$6498$ed2619ec@ptn-nntp-reader01.plus.net>,
Jon Harrop  <usenet@jdh30.plus.com> wrote:
    ...
>So a more important point is that, if you have a non-trivial program,
>there's no way you're going to be able to find the time to optimise the
>whole thing by hand. 

How often do you need to optimize the 'whole thing'? Maybe for a 50 line 
raytracer, but that's not really comparable to most 'real world' 
production software.

-Mike
-- 
http://www.mschaef.com

Jon Harrop wrote:
> Gerry Quinn wrote:
> > I have seen such claims for many languages, including Java.  Perhaps
> > you would provide a link to an unbiased set of benchmark tests that
> > demonstrate it.
>
> Fortran vs C on some array benchmarks is probably a good bet. Fortran
> compilers often do a lot of platform-specific cache-based optimisation that
> a C compiler won't do.

Yes.  There's lots of history of doing big array based FP in fortran.
Fortran compilers have been optimized for it.  Also there are no
pointers to worry about.

> You may also be interested in my ray tracer:
>
>   http://www.ffconsultancy.com/free/ray_tracer/languages.html
>
> > My impression is that C tends to score rather highly in performance
> > benchmarks.
>
> I wrote a C implementation of my ray tracer. It was a lot slower than the
> C++. I am sure I could have optimised to run just as fast but it is
> seriously tedious and boring work, even for this 50LOC program. The C was
> already the longest implementation at about 200LOC.
>
> So a more important point is that, if you have a non-trivial program,
> there's no way you're going to be able to find the time to optimise the
> whole thing by hand. You need a language expressive enough that its
> compiler will generate efficient code for you. That language isn't C/C++.

Depends on the size of the sections that do the work.  I've seen 10Kloc
programs that spend most of their time in 8 lines of code.  A few
programs also spread work all over the place and the whole thing must
be fairly fast.  The average is probably somewhere inbetween.

MSCHAEF.COM wrote:
> In article <435cde03$0$6498$ed2619ec@ptn-nntp-reader01.plus.net>,
> Jon Harrop  <usenet@jdh30.plus.com> wrote:
>     ...
>>So a more important point is that, if you have a non-trivial program,
>>there's no way you're going to be able to find the time to optimise the
>>whole thing by hand.
> 
> How often do you need to optimize the 'whole thing'? Maybe for a 50 line
> raytracer, but that's not really comparable to most 'real world'
> production software.

Indeed, it is much harder in the case of most real-world software because it
is not even clear what data structures and algorithms you should be using.

Think about commercial DSLs like Mathematica, Matlab, Mathcad, Maple. Most
of the time can be spent in many hundreds of thousands of lines of code.
Any you going to do a good job optimising that by hand in C? Even if you
could, the result would be so verbose as to be unmaintainable.

Mathematica is in a dialect of C and has been worked on for well over a
decade by many programmers. In 4 days I wrote an implementation in OCaml
that required two orders of magnitude less code and was asymptotically
faster at some essential operations. In 6 weeks I wrote an implementation
that was 1-2 orders of magnitude faster at a wide variety of operations. It
simply isn't feasible to do that kind of work in C. You're talking about
hand-optimising tens of thousands of lines of code.

Think about vector graphics software like Illustrator or Microsoft's Avalon.
For any given task, 80% of the time might be spent in 20% of the code, but
which 20% depends upon the task. It might be fill-rate bound, or
flattening-bound, or tesselating-bound or memory-bound or... so you have to
optimise them all.

Using an efficient HLL is the only practical solution, unless you're writing
a 50-line ray tracer, in which hand-optimising C is feasible.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Ufit <kot_tmp0SPAMSPAM@NOpoczta.fm> wrote:

> "Flaran" <flaran@gmail.com> wrote in message 
> news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> > I have a question just for the hell of it... If you had to choose
> > between Java and C++, which would you choose? Why and why not?
> > 
> C++ - for applications, Java - for web stuff.
> 
C++ for applications, PHP for web stuff ;-)

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Walter Bright <walter@nospamm-digitalmars.com> wrote:

> "Flaran" <flaran@gmail.com> wrote in message
> news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> > I have a question just for the hell of it... If you had to choose
> > between Java and C++, which would you choose? Why and why not?
> 
> I'd choose the D programming language, which is as powerful as C++ but much
> easier to program in. It compiles to native code, not a VM.
> 
D would be nice but as long as not even the C people use it, D won't
catch on C++ nor Java. D currently falls into the same category as
Oberon which someone else suggested.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Jon Harrop wrote:
[snip]
> Mathematica is in a dialect of C and has been worked on for well over a
> decade by many programmers. In 4 days I wrote an implementation in OCaml
> that required two orders of magnitude less code and was asymptotically
> faster at some essential operations. In 6 weeks I wrote an implementation
> that was 1-2 orders of magnitude faster at a wide variety of operations.
> It simply isn't feasible to do that kind of work in C. You're talking
> about hand-optimising tens of thousands of lines of code.

You wrote a Mathematica clone in 4 days? With all due respect, I don't buy
that: just looking up the math for all the stuff that is in there requires
more time; and at that point you have not typed a single line of code.
Clearly, I must be missing something here. Where can I find this
Mathematica implementation?


Best

Kai-Uwe Bux

"Otto Wyss" <otto.wyss@orpatec.ch> wrote in message
news:1h4ybpo.1aatuanat5q68N%otto.wyss@orpatec.ch...
> Walter Bright <walter@nospamm-digitalmars.com> wrote:
>
> > "Flaran" <flaran@gmail.com> wrote in message
> > news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> > > I have a question just for the hell of it... If you had to choose
> > > between Java and C++, which would you choose? Why and why not?
> >
> > I'd choose the D programming language, which is as powerful as C++ but
much
> > easier to program in. It compiles to native code, not a VM.
> >
> D would be nice but as long as not even the C people use it, D won't
> catch on C++ nor Java. D currently falls into the same category as
> Oberon which someone else suggested.

Quite a lot of C people use it. Drop by the D newsgroups on
news.digitalmars.com and see for yourself.

Rob Thorpe wrote On 10/22/05 06:45,:
> Alan Balmer wrote:
> 
>>On 20 Oct 2005 13:26:15 -0700, Tim Rentsch <txr@alumnus.caltech.edu>
>>wrote:
>>
>>
>>>Apparently Alan Balmer intends the word safe be read more in
>>>it's "regular" sense, of not being dangerous.  However, even
>>>using this meaning, the equation '!Correct == !Safe' isn't
>>>right.  Code to run a nuclear reactor that prevents the
>>>reactor from ever being turned on, or being run in any way,
>>>is (presumably) not correct, but it is still safe.
>>
>>No, it isn't. It causes the programmer to be fired.
> 
> 
> Looking at it that way their is no reason to use the word "safe" at
> all, we may as well use the word "correct" always.
> 
> I'm more happy with the normal definition Tim and Jon have used.
> 

Disagree. As with buildings, what a program does when it fails is
very much germane to its suitability. If the choice is between having
a "very correct" program that fails (in the few cases where it fails)
by crashing all memory and perhaps corrupting the hard disk, and a
"not so correct" program that fails with an error message, I would
pick the latter.

CTips wrote On 10/23/05 04:39,:
> adaworks@sbcglobal.net wrote:
> 
>>"Scott Moore" <samiamsansspam@Sun.COM> wrote in message
>>news:dj8oh5$qla$1@news1nwk.SFbay.Sun.COM...
>>
>>
>>>adaworks@sbcglobal.net wrote On 10/19/05 18:08,:
>>>
>>>
>>>
>>>>Well, yes.  C is a universal assembler with a few pathologies left over
>>>
>>>>from its original targeted platform.
>>>
>>>C is what happened when Algol and Fortran got drunk and spent the weekend
>>>together.
>>>
>>
>>In defense of C, the language was well-designed for its time and for its
>>targeted environment.  It has proven remarkably robust, having been
>>ported to a lot of different platforms.  It has nothing in it, however,
>>that cannot be done as easily and more safely with other languages.
> 
> 
> Performance (and, stretching a point, portability)
> 
> 
>>And it does contain features that, in our more modern age, are
>>unnecessary and potentially defect-inducing.
>>
>>Too many programmers are enchanted with the idea of a language that
>>is easy to write and not concerned enough with a language that is easy
>>to read.
> 
> 
> It is a myth that C is easier/harder to comprehend than any other 
> language. Comprehensibility (for even moderate sized programs) is a 
> function of the amount and kind of abstraction added. Too much 
> abstraction can be just as bad as too little. Also, if the writer picked 
> the "wrong" kind of abstraction (i.e. what the reader didn't expect) 
> even a well abstracted program can be difficult to understand.
> 

It is a myth that C has greater performance than other langauges. Portability
in C does not rise to the point of being merly a myth. More like outrightly
untrue.

Kai-Uwe Bux wrote:
> Jon Harrop wrote:
> [snip]
>> Mathematica is in a dialect of C and has been worked on for well over a
>> decade by many programmers. In 4 days I wrote an implementation in OCaml
>> that required two orders of magnitude less code and was asymptotically
>> faster at some essential operations. In 6 weeks I wrote an implementation
>> that was 1-2 orders of magnitude faster at a wide variety of operations.
>> It simply isn't feasible to do that kind of work in C. You're talking
>> about hand-optimising tens of thousands of lines of code.
> 
> You wrote a Mathematica clone in 4 days? With all due respect, I don't buy
> that: just looking up the math for all the stuff that is in there requires
> more time; and at that point you have not typed a single line of code.

Yes, it was not a clone. I implemented the core functionality of the
language so that the rest could be bootstrapped (written in Mathematica on
top of a minimal kernel written in OCaml). For example, you could write:

  In[1]:= #^2& /@ {1, 2, 3, 4}

meaning "map (fn x => x*x) [1, 2, 3, 4]" and get:

  Out[1]= {1, 4, 9, 16}

So it supported the basic syntax including infix operators, "functions",
set, delayedset, rule, delayedrule, lists, basic pattern matching, timing
and so on. I wrote some code, e.g. the differentiation function "D", in
Mathematica on top of my own implementation.

I made no attempt to implement all of the Mathematica functions like
FindMinimum, Fourier, Integrate and so on. Had I continued, I would have
implemented such functions in Mathematica and not in OCaml.

> Clearly, I must be missing something here. Where can I find this
> Mathematica implementation?

It is no longer available on my site but it was up for a while so I'm sure
someone out there has a copy.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Gerry Quinn wrote On 10/24/05 02:58,:
> In article <jA07f.3688$D13.1071@newssvr11.news.prodigy.com>, 
> adaworks@sbcglobal.net says...
> 
>>"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>>news:MPG.1dc636936042b47398a6cc@news.indigo.ie...
>>
>>>Portability and performance are intrinsically conflicting.  Language
>>>constructs will invariably favour one kind of processor over another.
>>>Thus no language can be designed to be optimal on every system.  But a
>>>simple language that targets characteristics of common systems is
>>>likely to yield the greatest performance on average.
>>>
>>
>>This is not true in the age of optimizing compilers.  A lot of progress has
>>been made over the past decade in the field of optimization.  Ada, when
>>optimized performs quite well, at least as well as C and certainly as well
>>as equivalent C++.  Of course, we need to understand the trade-off of
>>optimizing for speed versus storage.
> 
> 
> I have seen such claims for many languages, including Java.  Perhaps 
> you would provide a link to an unbiased set of benchmark tests that 
> demonstrate it.
> 
> My impression is that C tends to score rather highly in performance 
> benchmarks.
> 
> - Gerry Quinn

Sure, because most of the effort for compiler making goes into C.
That's not a language issue. Quite the contrary. In many cases
(which are documented in comp.compilers) C actually causes problems
because its ability to keep aliases to variable locations in the form
of pointers makes it difficult for the compiler to determine if,
for example, a variable can be held entirely in a register.

The bottom line is that the "performance" issue for C has not only
been a myth, but a traveling myth as well. When C originated, it was
supposed to gain performance because it put a lot of traditional
optimization work onto the programmer. For example, i++ and specifying
a local as registered specified actions that an optimizer could
determine automatically. The argument for C being more efficient was
that, due to the small computers of the time, C's lowered need for
optimization meant that it would outperform other compilers which
couldn't perform optimization because of compiler space concerns.

Now, all compilers have optimizers, and the space needed for the
compiler is no longer a concern. C has optimization, things like
"register" specs for locals typically are ignored, and the basis
for C being more efficient has changed to "it's a simpler language,
and so is easier to optimize". Of course, with C becoming more
complex with each official standard, that reason will have to
change as well.

Optimization is not in the language. If C avocates are going to
take that as "proof" of C being "more efficient", then you are
going to have to realize that the greater body of compiler theory
says that in fact C has a disadvantage there vs. other languages.

Walter Bright <walter@nospamm-digitalmars.com> wrote:

> > D would be nice but as long as not even the C people use it, D won't
> > catch on C++ nor Java. D currently falls into the same category as
> > Oberon which someone else suggested.
> 
> Quite a lot of C people use it. Drop by the D newsgroups on
> news.digitalmars.com and see for yourself.

Quite a lot is quite a lot relative. I'll change my mind when I see some
standard software like freetype library or Pango or the Linux kernel be
written in D.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

adaworks@sbcglobal.net wrote:

> Eiffel and Ada scale up better than any of those so far
> mentioned. Eiffel is probably a better choice than Java 
> or C++ in nearly every case.

Some years ago I remember reading on the Eiffel forum how 
many developers where finding the Eiffel IDE very unstable.

At the time I found it rather amusing considering the fact
the Eiffel IDE was written in Eiffel and this was the 
language that made it impossible to write "unsafe" code.

Maybe they should have written the IDE in c++ :)

Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, WordStar, Emacs) Text Editor
"The C/C++, Java, HTML, FTP, Python, PHP, Perl folding editor"
http://www.zeusedit.com

Jon Harrop wrote:

> You mean it is easy to assume that your C++ is safe provided 
> you don't actually look.

I find it easy to assume my C++ code is safe, because the bug 
count is low.

Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, WordStar, Emacs) Text Editor
"The C/C++, Java, HTML, FTP, Python, PHP, Perl folding editor"
http://www.zeusedit.com

"Otto Wyss" <otto.wyss@orpatec.ch> wrote in message
news:1h4yhh0.17haf6eefzj0lN%otto.wyss@orpatec.ch...
> Walter Bright <walter@nospamm-digitalmars.com> wrote:
>
> > > D would be nice but as long as not even the C people use it, D won't
> > > catch on C++ nor Java. D currently falls into the same category as
> > > Oberon which someone else suggested.
> >
> > Quite a lot of C people use it. Drop by the D newsgroups on
> > news.digitalmars.com and see for yourself.
>
> Quite a lot is quite a lot relative. I'll change my mind when I see some
> standard software like freetype library or Pango or the Linux kernel be
> written in D.

For a list of libraries and standard software written in D, see
www.digitalmars.com/d/dlinks.html

-Walter Bright
www.digitalmars.com/d/ the D Programming Language

Otto Wyss wrote:
> D would be nice but as long as not even the C people use it, D won't
> catch on C++ nor Java. D currently falls into the same category as
> Oberon which someone else suggested.

According to the popularity ratings from Tiobe 
(http://www.tiobe.com/tpci.htm) D is at #30. Oberon is (unfortunately) 
somewhere between #51 and #100.


August

In article <435d0a57$0$73593$ed2619ec@ptn-nntp-reader03.plus.net>,
Jon Harrop  <usenet@jdh30.plus.com> wrote:
   ...
>Mathematica is in a dialect of C and has been worked on for well over a
>decade by many programmers. In 4 days I wrote an implementation in OCaml
>that required two orders of magnitude less code and was asymptotically
>faster at some essential operations. 

I think you're vastly underestimating the complexities hidden by
Mathematica.

>In 6 weeks I wrote an implementation
>that was 1-2 orders of magnitude faster at a wide variety of operations. It
>simply isn't feasible to do that kind of work in C. You're talking about
>hand-optimising tens of thousands of lines of code.

No... I'm talking about profiling using real-world data/code sets, finding the
hot spots, and optimizing them.

>Think about vector graphics software like Illustrator or Microsoft's Avalon.

Two different things, BTW. Illustrator is an end user program, Avalon is
an imaging/UI stack. Acrylic is probably the closet thing Microsoft has
to Illustrator.

>For any given task, 80% of the time might be spent in 20% of the code, but
>which 20% depends upon the task. It might be fill-rate bound, or
>flattening-bound, or tesselating-bound or memory-bound or... so you have to
>optimise them all.

No... you have to optimize the cases for which you have performance
targets you do not meet. Even then, if you optimize 'all' of your
program, you won't have hand optimized all of the source code.

-Mike
-- 
http://www.mschaef.com

MSCHAEF.COM wrote:
> In article <435d0a57$0$73593$ed2619ec@ptn-nntp-reader03.plus.net>,
> Jon Harrop  <usenet@jdh30.plus.com> wrote:
>>In 6 weeks I wrote an implementation
>>that was 1-2 orders of magnitude faster at a wide variety of operations.
>>It simply isn't feasible to do that kind of work in C. You're talking
>>about hand-optimising tens of thousands of lines of code.
> 
> No... I'm talking about profiling using real-world data/code sets, finding
> the hot spots, and optimizing them.

Yes. We are talking about the same thing. The hot spots in an interpreter
are entirely dependent upon the code you're interpreting. For example:

  Fourier[l]

stresses only the built-in Fourier function.

  Fib[0] := 0
  Fib[1] := 1
  Fib[n_] := Fib[n-1] + Fib[n-2]
  Fib[30]

stresses non-tail recursion in the eval function.

  Dup[a___, x_, b___, x_, c___] := Dup[a, b, c, {2, x}]

stresses the pattern matcher.

These are all completely different parts of the implementation. To make user
code run faster in general, you must optimise them all.

>>Think about vector graphics software like Illustrator or Microsoft's
>>Avalon.
> 
> Two different things, BTW.

On the outside, yes. On the inside, they will have a lot of code in common.

>>For any given task, 80% of the time might be spent in 20% of the code, but
>>which 20% depends upon the task. It might be fill-rate bound, or
>>flattening-bound, or tesselating-bound or memory-bound or... so you have
>>to optimise them all.
> 
> No... you have to optimize the cases for which you have performance
> targets you do not meet. Even then, if you optimize 'all' of your
> program, you won't have hand optimized all of the source code.

Yes. I am not saying that you will have to hand optimise all of the source.
I am saying that the 20% of the source that you will want to optimise is
too much to do by hand. You need tools that automate these tasks for you.
Choosing a "faster" language is an obvious way to do this that is often
overlooked.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1dc6c08c4533a29898a6cf@news.indigo.ie...
>
> I have seen such claims for many languages, including Java.
>
Java, as long as it is dependent on a JVM designed over interpreted
bytecode, will never be noted for its performance.  It's performance,
however, is quite satisfactory in those domains where it is appropriate.

Ada is a different story.   The code produced by early Ada compilers
was dog-days slow.  The compilers were slow.  The executables were
slow.  Over the years, compiler developers have learned how to make
Ada more performance-intensive.   This is so much the case, with
optimizing compilers, that it has become an attractive alternative
for large-scale embedded software systems.

Keep in mind that Ada is not dependent on a JVM.  Rather, it is
targeted, cross-compiled, to a system in the native code of that
system.

Now then, performance also needs to be considered as a development
issue.  We can develop reusable, extensible, modular Ada code quite
quickly in Ada.

Richard Riehle

In article <lEf7f.6865$7h7.339@newssvr21.news.prodigy.com>,
 <adaworks@sbcglobal.net> wrote:
>
>"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>news:MPG.1dc6c08c4533a29898a6cf@news.indigo.ie...
>>
>> I have seen such claims for many languages, including Java.
>>
>Java, as long as it is dependent on a JVM designed over interpreted
>bytecode, will never be noted for its performance.  It's performance,
>however, is quite satisfactory in those domains where it is appropriate.

Most modern JVM's are not interpreted, they're compiled. This 
has the potential to offer real-world performance benefits:

* The actual machine code can more closely target the actual machine.

* Inlining decisions can be made based on profiling the current
  workload.

* More things can be inlined (even dynamically dispatched methods)

* The ability to rearrange data structures at runtime can improve
  locality of reference considerably. (This isn't limited to bytecode
  style languages, of course).

I think 'never' is a pretty strong word.

-Mike
-- 
http://www.mschaef.com

Flaran writes:

> I've learned a bit from this... And that is that people like to be
> hostile... Maybe we can just end this totally?

Welcome to amUSENET.  :-\

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

<adaworks@sbcglobal.net> writes:

> Let's face it, from Dr. Stroustrups original vision, this language has
> evolved into a very messy collection of features overlaid by a set
> of workarounds, overlaid by obscurely designed libraries.  The
> longer it lives, the messier it gets.  The emperor, it seems, really
> does not have any clothes.

Wait a minute..... I thought you just said he had TOO MANY clothes.....

-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

adaworks@sbcglobal.net wrote:
> Now then, performance also needs to be considered as a development
> issue.  We can develop reusable, extensible, modular Ada code quite
> quickly in Ada.

Here is a simple example of a concurrent producer/consumer
program using Ada. The producer and consumer tasks communicate
through a shared buffer. When the buffer is full the producer
suspends. When the buffer is empty the consumer suspends.

The program is written modularly, in three files.
One file, containing the program entry point, is named
Buffer_Main.adb
One file, containing the public interfaces for the
producer and consumer tasks is called
Prod_Con_Buffer.ads.
The last file, containing the implementation of the
tasks and their shared buffer is called
Prod_Con_Buffer.adb.

with Prod_Con_Buffer;

-----------------------------------------------------------------------
-- Procedure Buffer_Main does nothing except provide a context in
-- which the package Prod_Con_Buffer is elaborated.
-- Elaboration of Prod_Con_Buffer creates the tasks Producer and
-- Consumer. It also creates the shared buffer Buffer.
-----------------------------------------------------------------------
procedure Buffer_Main is
begin
   null;
end Buffer_Main;

-----------------------------------------------------------------------
-- Producer Consumer example with shared data communication buffer.
-- Producer must suspend when the buffer is full.
-- Consumer must suspend when the buffer is empty.
-----------------------------------------------------------------------

package Prod_Con_Buffer is
   task Producer;
   task Consumer;
end Prod_Con_Buffer;

-----------------------------------------------------------------------
-- Producer Consumer using shared buffer implementation
-----------------------------------------------------------------------
with Ada.Text_Io;
with Ada.Integer_Text_Io;

package body Prod_Con_Buffer is
   Num_Elements : constant := 2**3;
   --------------------------------------------------------------------
   -- Define a modular type to be used as the index for Buffer_Type.
   -- Modular integers have a range mod some value. In this case the
   -- value is Num_Elements. All arithmetic on modular integers is
   -- modular. All results fall within the valid range of values for
   -- the type.
   --------------------------------------------------------------------
   type Buffer_Index is mod Num_Elements;
   type Buffer_Type is array(Buffer_Index) of Integer;

   End_Of_Data : constant Integer := Integer'First;

   --------------------------------------------------------------------
   -- Define the interface and private data for the shared buffer
   --------------------------------------------------------------------
   protected Buffer is
      entry Put(Item : in Integer);
      entry Get(Item : out Integer);
   private
      Buf : Buffer_Type;
      Count : Natural := 0;
      Put_Index : Buffer_Index := 0;
      Get_Index : Buffer_Index := 0;
   end Buffer;

   --------------------------------------------------------------------
   -- Define the implementation of the shared buffer
   --------------------------------------------------------------------
   protected body Buffer is
      -----------------------------------------------------------------
      -- Entry Put is called by the producer.
      -- The entry blocks when Count = Num_Elements
      -----------------------------------------------------------------
      entry Put(Item : in Integer) when Count < Num_Elements is
      begin
         Buf(Put_Index) := Item;
         Put_Index := Put_Index + 1;
         Count := Count + 1;
      end Put;
      -----------------------------------------------------------------
      -- Entry Get is called by the consumer.
      -- The entry blocks when Count = 0
      ----------------------------------------------------------------
      entry Get(Item : out Integer) when Count > 0 is
      begin
         Item := Buf(Get_Index);
         Get_Index := Get_Index + 1;
         Count := Count - 1;
      end Get;
   end Buffer;
   --------------------------------------------------------------------
   -- The Producer task iterates through the values from 1 through 50.
   -- Each iteration it writes a value to the buffer using the Put
   -- entry. If the buffer is full the Producer will suspend.
   -- The selective entry call applies a time-out to the suspension.
   -- The time-out set below is 0.05 seconds. If the Put does not
   -- execute within 0.05 seconds the Producer withdraws from
suspension
   -- and prints "Producer Waiting".
   -- After iterating through all 50 values the Producer calls Put
   -- one last time with the value End_Of_Data, which is a constant
   -- value representing the most negative value represented by an
   -- integer.
   --------------------------------------------------------------------
   task body Producer is
   begin
      for Num in 1..50 loop
         loop
            select
               Buffer.Put(Num);
                  Ada.Text_Io.Put_Line("Put" & Integer'Image(Num));
                  exit;
            or
               delay 0.05;
               Ada.Text_Io.Put_Line("Producer Waiting");
               end select;
         end loop;
      end loop;
      Buffer.Put(End_Of_Data);
   end Producer;
   --------------------------------------------------------------------
   -- Task Consumer executes a simple loop to read values from the
   -- shared buffer. The loop exits and the task terminates upon
   -- reading End_Of_Data.
   -- Each time through the loop Consumer delays for 0.1 seconds.
   --------------------------------------------------------------------
   task body Consumer is
      New_Value : Integer;
   begin
      loop
         Buffer.Get(New_Value);
         exit when New_Value = End_Of_Data; -- exit loop
         Ada.Integer_Text_Io.Put(New_Value);
         Ada.Text_Io.New_Line;
         delay 0.1;
      end loop;
   end Consumer;

end Prod_Con_Buffer;

The output of this program is:
Put 1
Put 2
Put 3
Put 4
Put 5
Put 6
Put 7
Put 8
Put 9
          1
Producer Waiting
Put 10
          2
Producer Waiting
Producer Waiting
Put 11
          3
Producer Waiting
Put 12
          4
Producer Waiting
Put 13
          5
Producer Waiting
Put 14
          6
Producer Waiting
Put 15
          7
Producer Waiting
Put 16
          8
Producer Waiting
Put 17
          9
Producer Waiting
Put 18
         10
Producer Waiting
Put 19
         11
Producer Waiting
Put 20
         12
Producer Waiting
Put 21
         13
Producer Waiting
Put 22
         14
Producer Waiting
Put 23
         15
Producer Waiting
Put 24
         16
Producer Waiting
Put 25
         17
Producer Waiting
Put 26
         18
Producer Waiting
Put 27
         19
Producer Waiting
Put 28
         20
Producer Waiting
Put 29
         21
Producer Waiting
Put 30
         22
Producer Waiting
Put 31
         23
Producer Waiting
Put 32
         24
Producer Waiting
Put 33
         25
Producer Waiting
Put 34
         26
Producer Waiting
Put 35
         27
Producer Waiting
Put 36
         28
Producer Waiting
Put 37
         29
Producer Waiting
Put 38
         30
Producer Waiting
Put 39
         31
Producer Waiting
Put 40
         32
Producer Waiting
Put 41
         33
Producer Waiting
Put 42
         34
Producer Waiting
Put 43
         35
Producer Waiting
Put 44
         36
Producer Waiting
Put 45
         37
Producer Waiting
Put 46
         38
Producer Waiting
Put 47
         39
Producer Waiting
Put 48
         40
Producer Waiting
Put 49
         41
Producer Waiting
Put 50
         42
         43
         44
         45
         46
         47
         48
         49
         50


This program works without change to the source
code on any platform targeted by an Ada compiler.

Jim Rogers

"MSCHAEF.COM" <mschaef@eris.io.com> wrote in message
news:XNqdnRuZ1YGkBMDeRVn-qw@io.com...
> In article <lEf7f.6865$7h7.339@newssvr21.news.prodigy.com>,
>  <adaworks@sbcglobal.net> wrote:
> >
> >"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
> >news:MPG.1dc6c08c4533a29898a6cf@news.indigo.ie...
> >>
> >> I have seen such claims for many languages, including Java.
> >>
> >Java, as long as it is dependent on a JVM designed over interpreted
> >bytecode, will never be noted for its performance.  It's performance,
> >however, is quite satisfactory in those domains where it is appropriate.
>
> Most modern JVM's are not interpreted, they're compiled. This
> has the potential to offer real-world performance benefits:
>
I am not worried about the JVM being compiled or interpreted.  It is
the bytecode that is interpreted by the JVM.   If the Java program
is not in the form of bytecode, it suddenly loses one of its few
real benefits:  that of being portable to any machine with a JVN.

Richard Riehle

"Chris Sonnack" <Chris@Sonnack.com> wrote in message
news:8u7rl1lrbu9j4lunotbm00vhncs0e8qn32@4ax.com...
> <adaworks@sbcglobal.net> writes:
>
> > Let's face it, from Dr. Stroustrups original vision, this language has
> > evolved into a very messy collection of features overlaid by a set
> > of workarounds, overlaid by obscurely designed libraries.  The
> > longer it lives, the messier it gets.  The emperor, it seems, really
> > does not have any clothes.
>
> Wait a minute..... I thought you just said he had TOO MANY clothes.....
>
Dr. Stroustrup's original vision was truly inspired and a work of genius.
Over time, C++ does seem to have acquired "too many clothes."   So, I
mixed my metaphors.

Richard Riehle
> -- 
> |_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
> |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
> |_____________________________________________|_______________________|

In article <djjb23$4rf$1@news1nwk.SFbay.Sun.COM>, 
samiamsansspam@Sun.COM says...
> Gerry Quinn wrote On 10/24/05 02:58,:

> > My impression is that C tends to score rather highly in performance 
> > benchmarks.

> Sure, because [..]

> Optimization is not in the language. If C avocates are going to
> take that as "proof" of C being "more efficient", then you are
> going to have to realize that the greater body of compiler theory
> says that in fact C has a disadvantage there vs. other languages.

I didn't propose any proof.  I said that C tends to do well on 
benchmarks.  You admit as much, above.

- Gerry Quinn

In article <435cddac$0$6498$ed2619ec@ptn-nntp-reader01.plus.net>, 
usenet@jdh30.plus.com says...
> Gerry Quinn wrote:
> > In article <435c26f8$0$73627$ed2619ec@ptn-nntp-reader03.plus.net>,
> > usenet@jdh30.plus.com says...
> >> How are you going to recover when your out of bounds error scribbles over
> >> your OS?
> > 
> > Can't remember that happening since the Spectrum days.
> 
> If you count the memory allocation tables for the current process as "OS"
> then it happens today in most OSs.

Not in my experience.

Then again I don't use C but C++, in which most (though not all) 
unnecessary use of pointers can easily be eliminated.  

If your pointer is out of bounds, your program is bugged anyway.  
Unless you're writing huge amounts of data through it, it probably will 
cause problems by writing on your other data or failing to write in the 
correct place.

- Gerry Quinn

Scott Moore wrote:
> Rob Thorpe wrote On 10/22/05 06:45,:
> > Alan Balmer wrote:
> >
> >>On 20 Oct 2005 13:26:15 -0700, Tim Rentsch <txr@alumnus.caltech.edu>
> >>wrote:
> >>
> >>
> >>>Apparently Alan Balmer intends the word safe be read more in
> >>>it's "regular" sense, of not being dangerous.  However, even
> >>>using this meaning, the equation '!Correct == !Safe' isn't
> >>>right.  Code to run a nuclear reactor that prevents the
> >>>reactor from ever being turned on, or being run in any way,
> >>>is (presumably) not correct, but it is still safe.
> >>
> >>No, it isn't. It causes the programmer to be fired.
> >
> >
> > Looking at it that way their is no reason to use the word "safe" at
> > all, we may as well use the word "correct" always.
> >
> > I'm more happy with the normal definition Tim and Jon have used.
> >
>
> Disagree. As with buildings, what a program does when it fails is
> very much germane to its suitability. If the choice is between having
> a "very correct" program that fails (in the few cases where it fails)
> by crashing all memory and perhaps corrupting the hard disk, and a
> "not so correct" program that fails with an error message, I would
> pick the latter.

I would too, but those are question of correctness and useful error
handling, not type safety.

Gerry Quinn wrote:
> Then again I don't use C but C++, in which most (though not all)
> unnecessary use of pointers can easily be eliminated.

Sure. That doesn't remove this class of bugs though.

> If your pointer is out of bounds, your program is bugged anyway.

Yes. If you access an array out of bounds then your program is not
necessarily buggy - it could have been fed incorrect input and you expected
to handle it via an exception.

> Unless you're writing huge amounts of data through it, it probably will
> cause problems by writing on your other data or failing to write in the
> correct place.

Other way around, if you've got a lot of data then there's a better chance
of accidentally hitting it.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

In article <8nj7f.6912$7h7.1267@newssvr21.news.prodigy.com>,
 <adaworks@sbcglobal.net> wrote:
   ...
>I am not worried about the JVM being compiled or interpreted.  It is
>the bytecode that is interpreted by the JVM.   

Modern JVM's compile bytecode on the fly into machine code. That is, when 
a method is called, at run time, the JVM takes the bytecode sequence, 
compiles it into machine code (once) and then calls that. You can call 
that interpreted if you like, but to do so is to misunderstand what 
bytecode means for performance:

1. Slower program startup time (as the system compiles methods)

2. Possibly faster running time (for the reasons I list in the
   grandparent to this post)

If the second never happens, it'll be because of extra time spent doing 
safety checks and supporting more dynamic programming techniques. (IMHO)

-Mike
-- 
http://www.mschaef.com

Dnia 17 Oct 2005 13:39:44 -0700, Flaran napisa�(a):

> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?

Take a look at:
http://www.piotr-wlodarek.pl/articles/Programming-Languages-Comparison.aspx 


-- 
| Piotr 'Qertoip' W�odarek
| www.piotr-wlodarek.pl
`-> Software Engineering 4 Those Who Care About The Craft

Walter Bright sade:
> "Flaran" <flaran@gmail.com> wrote in message
> news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> 
>>I have a question just for the hell of it... If you had to choose
>>between Java and C++, which would you choose? Why and why not?
> 
> 
> I'd choose the D programming language, which is as powerful as C++ but much
> easier to program in. It compiles to native code, not a VM.
> 
> -Walter Bright
> www.digitalmars.com C, C++, D programming language compilers
> 
> 

The development of D was quite interesting. I remember all those who
hated every step towards C++, they never wanted the "ugly" features that
"cluttered" C++ and made it such a "beast", but at the end D adopted a
lot of the same features; I remember especially the template-debates
and all the fuss about operator overloading.

Despite the facts that the stand-alone letter D is an ugly symbol
for a programming language from a synesthetic perspective and that
I perceive you as a *bit* bias in your simple comparison above:

	C++ beats D anyday! Why? Because I'm a beastmaster!

=)

Seriously, D added little value too an already overcrowded scene.
Perhaps versioning and the unit testing are the more positive things
added, but otherwise nothing really interesting and conceptually
new was incorporated.

As most programming langauges D has found its public, I myself
will never touch it as it lacks the beauty of C++. But I would
choose it over, say, Euphoria. And even though I hate Java, I
would choose it over D.

And to the OP, it doesn't matter which language you choose,
they will both work if you learn them (even D will),

but for the love of god, don't choose Euphoria!

TIT

"TIT" <spamo@noon.com> wrote in message
news:1130259096.8e384dcc7b333bcce58b3bdaca7852d6@teranews...
> Despite the facts that the stand-alone letter D is an ugly symbol
> for a programming language from a synesthetic perspective and that
> I perceive you as a *bit* bias in your simple comparison above:

Bias is an interesting word in this context. Consider that I did the
original design of D, based solely on my desire to fix problems with C++
that clearly would never get fixed. Bias implies I have some agenda for D
that is other than simply believing it is a better programming language.
Nobody has paid me to write D, D wasn't created in order to sell some other
product, there is no agenda behind it other than it being a better
programming language, etc. Consider also my very large personal investment
in C and C++ compiler technology - if anything, I should be biased against
D.

> Seriously, D added little value too an already overcrowded scene.
> Perhaps versioning and the unit testing are the more positive things
> added, but otherwise nothing really interesting and conceptually
> new was incorporated.

I agree that just scanning the feature list of D does not make a compelling
case for it. The compelling case for it over C++, however, becomes apparent
after using it for a while. Your source code typically shrinks by 30% over
equivalent C++ code. If you're one of those folks who subscribe to the idea
that the number of bugs and complexity of code is proportional to its source
code size, this is a huge win. Add on to that the bug-reducing features like
array bounds checking, contracts, unit testing, guaranteed initialization,
etc., and there is a big reduction in cost.

> As most programming langauges D has found its public, I myself
> will never touch it as it lacks the beauty of C++.

C++:
    std::vector<int> a;
D:
    int[] a;

and:

C++:
    complex<double> c;
    c = (complex<double>(6,2) + complex<double>(-1,3)) /
complex<double>(0,3);
D:
    cdouble c;
    c = (6 + 2i - 1 + 3i) / 3i;

Ok, you're the first who thinks C++ is more beautiful <g>, and I am curious
why.

-Walter Bright
www.digitalmars.com/d/ the D Programming Language

MSCHAEF.COM wrote On 10/24/05 19:32,:
> In article <lEf7f.6865$7h7.339@newssvr21.news.prodigy.com>,
>  <adaworks@sbcglobal.net> wrote:
> 
>>"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>>news:MPG.1dc6c08c4533a29898a6cf@news.indigo.ie...
>>
>>>I have seen such claims for many languages, including Java.
>>>
>>
>>Java, as long as it is dependent on a JVM designed over interpreted
>>bytecode, will never be noted for its performance.  It's performance,
>>however, is quite satisfactory in those domains where it is appropriate.
> 
> 
> Most modern JVM's are not interpreted, they're compiled. This 
> has the potential to offer real-world performance benefits:
> 
> * The actual machine code can more closely target the actual machine.
> 
> * Inlining decisions can be made based on profiling the current
>   workload.
> 
> * More things can be inlined (even dynamically dispatched methods)
> 
> * The ability to rearrange data structures at runtime can improve
>   locality of reference considerably. (This isn't limited to bytecode
>   style languages, of course).
> 
> I think 'never' is a pretty strong word.
> 
> -Mike

The problem is that Java compilers significantly underperform vs.
conventional languages. For whatever reason, there are not high
optimization compilers for the language. I don't personally want
"just ok" optimization for embedded and other applications, I want
"first class" performance.

The other issue with Java is because of its extensive library pull-in,
the binaries tend to be massive.

adaworks@sbcglobal.net wrote On 10/24/05 22:27,:
> "MSCHAEF.COM" <mschaef@eris.io.com> wrote in message
> news:XNqdnRuZ1YGkBMDeRVn-qw@io.com...
> 
>>In article <lEf7f.6865$7h7.339@newssvr21.news.prodigy.com>,
>> <adaworks@sbcglobal.net> wrote:
>>
>>>"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
>>>news:MPG.1dc6c08c4533a29898a6cf@news.indigo.ie...
>>>
>>>>I have seen such claims for many languages, including Java.
>>>>
>>>
>>>Java, as long as it is dependent on a JVM designed over interpreted
>>>bytecode, will never be noted for its performance.  It's performance,
>>>however, is quite satisfactory in those domains where it is appropriate.
>>
>>Most modern JVM's are not interpreted, they're compiled. This
>>has the potential to offer real-world performance benefits:
>>
> 
> I am not worried about the JVM being compiled or interpreted.  It is
> the bytecode that is interpreted by the JVM.   If the Java program
> is not in the form of bytecode, it suddenly loses one of its few
> real benefits:  that of being portable to any machine with a JVN.
> 
> Richard Riehle
> 
> 

There isn't any difference between a JIT and a JVM. They both accept
bytecode.

August Karlstrom wrote On 10/24/05 16:20,:
> Otto Wyss wrote:
> 
>>D would be nice but as long as not even the C people use it, D won't
>>catch on C++ nor Java. D currently falls into the same category as
>>Oberon which someone else suggested.
> 
> 
> According to the popularity ratings from Tiobe 
> (http://www.tiobe.com/tpci.htm) D is at #30. Oberon is (unfortunately) 
> somewhere between #51 and #100.

The site sez:

The popular search engines Google, MSN, and Yahoo! are used to calculate the ratings.

Fair enough. These calculate pretty well with sample searches I performed:

Search string              Results
=============================================
java programming language  30,700,000
C programming language     55,600,000
C++ programming language   16,400,000

etc.

However, I also did a search:

Sex programming language   3,910,000

Clearly this "sex" is an up and coming programming language we should
all learn !

August Karlstrom <fusionfive@comhem.se> wrote:

> Otto Wyss wrote:
> > D would be nice but as long as not even the C people use it, D won't
> > catch on C++ nor Java. D currently falls into the same category as
> > Oberon which someone else suggested.
> 
> According to the popularity ratings from Tiobe 
> (http://www.tiobe.com/tpci.htm) D is at #30. Oberon is (unfortunately)
> somewhere between #51 and #100.
> 
Nice comparison but ... . On freshmeat.net there are

# C    (7712 projects)
# Java (4396 projects) 
# C++  (3969 projects) 

Unfortunately freshmeat.net doesn't has categories for D or Oberon so
it's not possible to determine the project count. 

If e.g. Digital mars were listed as a project there, the count could be
determined through the dependences but only if all D projects define the
dependency. BTW that's also the only way to find wxWidgets projects.

On sourceforge.net there are

C++    (16476 projects)
Java   (16379 projects)
C      (15703 projects)
D      (25 projects)
Oberon (0 projects)

albeit there are probably also some dead projects.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

adaworks@sbcglobal.net wrote:
> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
> news:MPG.1dc6c08c4533a29898a6cf@news.indigo.ie...
> 
>>I have seen such claims for many languages, including Java.
>>
> 
> Java, as long as it is dependent on a JVM designed over interpreted
> bytecode, will never be noted for its performance.  It's performance,
> however, is quite satisfactory in those domains where it is appropriate.
> 
> Ada is a different story.   The code produced by early Ada compilers
> was dog-days slow.  The compilers were slow.  The executables were
> slow.  Over the years, compiler developers have learned how to make
> Ada more performance-intensive.   This is so much the case, with
> optimizing compilers, that it has become an attractive alternative
> for large-scale embedded software systems.
> 
> Keep in mind that Ada is not dependent on a JVM.  Rather, it is
> targeted, cross-compiled, to a system in the native code of that
> system.
> 
> Now then, performance also needs to be considered as a development
> issue.  We can develop reusable, extensible, modular Ada code quite
> quickly in Ada.
> 
> Richard Riehle
> 
> 
I was introduced to Ada almost twenty years ago by Richard Conn. At the 
time the DoD demanded everything in Ada. I understand DoD no longer has 
that stringent requirement. Do we know why?

-- 
Joe Wright
"Everything should be made as simple as possible, but not simpler."
                     --- Albert Einstein ---

Walter Bright sade:
> "TIT" <spamo@noon.com> wrote in message
> news:1130259096.8e384dcc7b333bcce58b3bdaca7852d6@teranews...
> 
>>Despite the facts that the stand-alone letter D is an ugly symbol
>>for a programming language from a synesthetic perspective and that
>>I perceive you as a *bit* bias in your simple comparison above:
> 
> 
> Bias is an interesting word in this context. Consider that I did the
> original design of D, based solely on my desire to fix problems with C++
> that clearly would never get fixed. Bias implies I have some agenda for D
> that is other than simply believing it is a better programming language.
> Nobody has paid me to write D, D wasn't created in order to sell some other
> product, there is no agenda behind it other than it being a better
> programming language, etc. Consider also my very large personal investment
> in C and C++ compiler technology - if anything, I should be biased against
> D.
> 

Yes, I know you're the original designer of D. I think you're
overinterpreting the word in this context.

thefreedictionary.com
bias - a partiality that prevents objective consideration of an issue or 
situation

> 
>>Seriously, D added little value too an already overcrowded scene.
>>Perhaps versioning and the unit testing are the more positive things
>>added, but otherwise nothing really interesting and conceptually
>>new was incorporated.
> 
> 
> I agree that just scanning the feature list of D does not make a compelling
> case for it. The compelling case for it over C++, however, becomes apparent
> after using it for a while. Your source code typically shrinks by 30% over
> equivalent C++ code. If you're one of those folks who subscribe to the idea
> that the number of bugs and complexity of code is proportional to its source
> code size, this is a huge win. Add on to that the bug-reducing features like
> array bounds checking, contracts, unit testing, guaranteed initialization,
> etc., and there is a big reduction in cost.
> 
> 
>>As most programming langauges D has found its public, I myself
>>will never touch it as it lacks the beauty of C++.
> 
> 
> C++:
>     std::vector<int> a;
> D:
>     int[] a;
> 
> and:
> 
> C++:
>     complex<double> c;
>     c = (complex<double>(6,2) + complex<double>(-1,3)) /
> complex<double>(0,3);

Sure, this is just awkward.

> D:
>     cdouble c;
>     c = (6 + 2i - 1 + 3i) / 3i;
> 
> Ok, you're the first who thinks C++ is more beautiful <g>, and I am curious
> why.

Aren't you a bit shallow now? =)
C++ may not be the perfect language, but it suits my needs nearly perfectly.
The beauty lies in the entire language. It's wonderful. I can admit
that D brings an extra layer of default safety compared to C++, and many
like and need that, but I'm happy with the "complexity"* of C++,
and I'm enjoying the language still even more with each new project.
I don't need to fix it to be satisfied, although I'm a bit curious
about Theta right now.

TIT

* I'm quoting everyone who complains on C++ and refuses to switch
to a more suitable language for their needs.

Walter Bright <walter@nospamm-digitalmars.com> wrote:

> Bias is an interesting word in this context. Consider that I did the
> original design of D, based solely on my desire to fix problems with C++
> that clearly would never get fixed.

I completely agree that it would be nice if C/C++ would be succeeded by
D but at the current state this won't happen simply because there is too
much C/C++ code around. 

To start this process D has to concentrate on a niche (e.g. the small
libraries currently written in C) or you need a top grade reference
project. Just consider what would happen if the currently released
Minix3 were written in D. Anybody doing OS studies had to know D and
probably will use it for other work as well.

The problem is you (the D community) has to do this preliminary work.
Nobody else will translate the 4000 lines of code in Minix3 unless you
do it yourself. Or if you want to position D as the language for
libraries you have to translate a significant amount of them yourself.
Since this might involve quite some work better plan for a rather small
niche. And only after you have savely secured your niche try to expand
to larger areas.

As I think again Minix3 might be a good choice since they need more
reasons to beat Linux but better check with the Minix community first if
such an effort is welcomed.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

"TIT" <spamo@noon.com> wrote in message
news:1130273132.98bc8159411b589280ad88bc013bae3a@teranews...
> Walter Bright sade:
> > "TIT" <spamo@noon.com> wrote in message
> > news:1130259096.8e384dcc7b333bcce58b3bdaca7852d6@teranews...
> >>Despite the facts that the stand-alone letter D is an ugly symbol
> >>for a programming language from a synesthetic perspective and that
> >>I perceive you as a *bit* bias in your simple comparison above:
> > Bias is an interesting word in this context. Consider that I did the
> > original design of D, based solely on my desire to fix problems with C++
> > that clearly would never get fixed. Bias implies I have some agenda for
D
> > that is other than simply believing it is a better programming language.
> > Nobody has paid me to write D, D wasn't created in order to sell some
other
> > product, there is no agenda behind it other than it being a better
> > programming language, etc. Consider also my very large personal
investment
> > in C and C++ compiler technology - if anything, I should be biased
against
> > D.
> Yes, I know you're the original designer of D. I think you're
> overinterpreting the word in this context.
>
> thefreedictionary.com
> bias - a partiality that prevents objective consideration of an issue or
> situation

I'm curious what non-objective bias I could have had that caused me to set
aside decades of experience with C++ and start D.

"Scott Moore" <samiamsansspam@Sun.COM> wrote in message
news:djm06h$523$1@news1nwk.SFbay.Sun.COM...
> These calculate pretty well with sample searches I performed:
>
> Search string              Results
> =============================================
> java programming language  30,700,000
> C programming language     55,600,000
> C++ programming language   16,400,000
>
> etc.
>
> However, I also did a search:
>
> Sex programming language   3,910,000
>
> Clearly this "sex" is an up and coming programming language we should
> all learn !

Not exactly. According to http://www.tiobe.com/tpci.htm the search string
would be:
+"sex programming" -tv -channel
which gives 661 results when I try it on Google.
+"D programming" -tv -channel
gives 80,900. For C, it's 1,800,000. C++: 1,660,000. Java: 3,190,000.

Oberon: 728. ulp!

Otto Wyss wrote:
> On sourceforge.net there are
> 
> C++    (16476 projects)
> Java   (16379 projects)
> C      (15703 projects)
> D      (25 projects)
> Oberon (0 projects)

Not so sure about the last figure. At least there is the Optimizing 
Oberon-2 Compiler at http://sourceforge.net/projects/ooc (written in C 
and Oberon-2).


August

Walter Bright wrote:
> According to http://www.tiobe.com/tpci.htm the search string
> would be:
> +"sex programming" -tv -channel
> which gives 661 results when I try it on Google.
> +"D programming" -tv -channel
> gives 80,900. For C, it's 1,800,000. C++: 1,660,000. Java: 3,190,000.
> 
> Oberon: 728. ulp!

It's not quite that bad. The current version of "standard" Oberon is 
Oberon-2 and most people seem to call it Oberon-2 (it's like saying ANSI 
C whenever you mention C). Taking that into account I get about 4300 
hits from Google. I wonder if the guys at Tiobe has thought about that.


August

Walter Bright wrote On 10/25/05 14:32,:
> "Scott Moore" <samiamsansspam@Sun.COM> wrote in message
> news:djm06h$523$1@news1nwk.SFbay.Sun.COM...
> 
>>These calculate pretty well with sample searches I performed:
>>
>>Search string              Results
>>=============================================
>>java programming language  30,700,000
>>C programming language     55,600,000
>>C++ programming language   16,400,000
>>
>>etc.
>>
>>However, I also did a search:
>>
>>Sex programming language   3,910,000
>>
>>Clearly this "sex" is an up and coming programming language we should
>>all learn !
> 
> 
> Not exactly. According to http://www.tiobe.com/tpci.htm the search string
> would be:
> +"sex programming" -tv -channel
> which gives 661 results when I try it on Google.
> +"D programming" -tv -channel
> gives 80,900. For C, it's 1,800,000. C++: 1,660,000. Java: 3,190,000.
> 
> Oberon: 728. ulp!
> 
> 

Hardly fair, since the Sex programming language (tm) specifically *requires*
you to watch TV, while performing it...er...programming in it.

BIAS ! Bias I say !

August Karlstrom wrote On 10/25/05 16:56,:
> Walter Bright wrote:
> 
>>According to http://www.tiobe.com/tpci.htm the search string
>>would be:
>>+"sex programming" -tv -channel
>>which gives 661 results when I try it on Google.
>>+"D programming" -tv -channel
>>gives 80,900. For C, it's 1,800,000. C++: 1,660,000. Java: 3,190,000.
>>
>>Oberon: 728. ulp!
> 
> 
> It's not quite that bad. The current version of "standard" Oberon is 
> Oberon-2 and most people seem to call it Oberon-2 (it's like saying ANSI 
> C whenever you mention C). Taking that into account I get about 4300 
> hits from Google. I wonder if the guys at Tiobe has thought about that.
> 
> 
> August

The search "oberon sex" gives 195,000 results !

Think about that now.

Other goodies:

Dog programming language

2,140,000

(note "programming language", not "programming" as in TV channels).

Nude programming language

1,060,000

Bush programming language

2,080,000

(hey, our president programs)

And th' winner be:

Dead programming language

5,000,000 !

Yea ha !

Otto Wyss wrote:
> August Karlstrom <fusionfive@comhem.se> wrote:
>> Otto Wyss wrote:
>> > D would be nice but as long as not even the C people use it, D won't
>> > catch on C++ nor Java. D currently falls into the same category as
>> > Oberon which someone else suggested.
>> 
>> According to the popularity ratings from Tiobe
>> (http://www.tiobe.com/tpci.htm) D is at #30. Oberon is (unfortunately)
>> somewhere between #51 and #100.
>
> Nice comparison but ... . On freshmeat.net

LOL. I immediately went to freshmeat as well. I've seen that Tiobe data
before and it looked very suspicious to me.

> there are 
> 
> # C    (7712 projects)
> # Java (4396 projects)
> # C++  (3969 projects)

# OCaml (61 projects)
# ML    (32 projects)
# Lisp (82 projects)

> On sourceforge.net there are
> 
> C++    (16476 projects)
> Java   (16379 projects)
> C      (15703 projects)
> D      (25 projects)
> Oberon (0 projects)

OCaml (Objective Caml) (51 projects)
Standard ML (135 projects)
Lisp (320 projects)

I think it is fair to say that such FPLs have 2 orders of magnitude fewer
users, although OCaml is being adopted much more rapidly than the others,
AFAIK.

Also, most of the "ML" and "Standard ML" projects are actually in OCaml. I
have counted before:

http://caml.inria.fr/pub/ml-archives/caml-list/2005/02/6a0543eb9408bbe75cb00f679690803f.fr.html
http://caml.inria.fr/pub/ml-archives/caml-list/2005/02/09b7f564516839890ae3b3b394ac0e4c.fr.html

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Scott Moore wrote:
> The search "oberon sex" gives 195,000 results !
> 
> Think about that now.
> 
> Other goodies:
> 
> Dog programming language
> 
> 2,140,000
> 
> (note "programming language", not "programming" as in TV channels).
> 
> Nude programming language
> 
> 1,060,000
> 
> Bush programming language
> 
> 2,080,000
> 
> (hey, our president programs)
> 
> And th' winner be:
> 
> Dead programming language
> 
> 5,000,000 !

So? All your searches are unquoted.


August

"TIT" <spamo@noon.com> wrote in message
news:1130273132.98bc8159411b589280ad88bc013bae3a@teranews...

[snip]

> C++ may not be the perfect language, but it suits my needs nearly
perfectly.
> The beauty lies in the entire language. It's wonderful.

Come on now! Isn't "wonderful" putting just a bit too much grease on? It
sounds like you're biased towards C++. Which other programming languages
have you used (i.e. written more than, say, 1K lines of code)?

I use C++ daily, and it has taken me many years to learn (all) the tricks
and quirks. I still get bitten regularly. Just the other day I forgot the
fact that the STL containers requires that the elements are copyable. I had
defined a non-trivial class and given it a suitable constructor, but forgot
about the copy-constructor and assignment-operator. So the code compiled
fine, but crashed at run-time. I hate it when the compiler adds these
default copy constructors, instead of just complaining at compile time.

There are lots of ugly spots in C++, particularly the requirement to be
backwards compatible with C. Thus a lot of "potentially unsafe" operations
are allowed in C++, like e.g. pointer arithmetic, even though they are
rarely - if ever - needed.

Templates are amazing. They are just like black magic. When I look at Boost
or Loki, I'm impressed with the ingenuity of the designers. It's like
watching McGyver and seeing what kinds of stuff he can make out of ordinary
household items. But there is NO WAY I'll ever be able to do anything like
that. It's maybe only 10% or less of the professional C++ users that
actually can write stuff like that.

And still there are features missing from the language. Functional
programming is just not practical with C++. The STL actually encourages
functional programming with algorithms like for_each(), but having to write
intricate combinations of bind2nd, mem_fun_ref, etc. is not only completely
illegible, it's plain ugly. Boost has some features to improve on this, but
it's still ugly.

Then there is the whole business of exception safety and thread safety. It's
verbose and error-prone. I've given up solving these problems, and therefore
by design all my applications are single-threaded, and I try to avoid the
use of exceptions as much as possible.

For instance, when writing to an output stream, if you need to write
hexadecimal values you could naively write:
    os << std::hex << value << std::dec;
but what if an exception is thrown when outputting the variable "value".
It's not enough to catch the exception, because now all future output to the
stream is suddenly in hexadecimal, since the base specifier is sticky. Sure,
this can be solved, but then the code becomes more complicated and verbose.
Ordinary users are sure to be bitten by this.

So, to end this rant: I was provoked by your choice of words. For all its
faults, I like C++, but I wouldn't call it "wonderful" :-)

-Michael.

Michael J�rgensen wrote:
> "TIT" <spamo@noon.com> wrote in message
> news:1130273132.98bc8159411b589280ad88bc013bae3a@teranews...
>> C++ may not be the perfect language, but it suits my needs nearly
> perfectly.
>> The beauty lies in the entire language. It's wonderful.
> 
> ...I like C++, but I wouldn't call it "wonderful" :-)

You guys really need to try OCaml. :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

In article <435e0801$0$6499$ed2619ec@ptn-nntp-reader01.plus.net>, 
usenet@jdh30.plus.com says...
> Gerry Quinn wrote:
> > Then again I don't use C but C++, in which most (though not all)
> > unnecessary use of pointers can easily be eliminated.
> 
> Sure. That doesn't remove this class of bugs though.
> 
> > If your pointer is out of bounds, your program is bugged anyway.
> 
> Yes. If you access an array out of bounds then your program is not
> necessarily buggy - it could have been fed incorrect input and you expected
> to handle it via an exception.

I don't think that makes sense.  The system considered as a whole 
(whatever is feeding your program input and your program) is buggy.  If 
your program is designed to write to arbitrary memory locations based 
on the input it receives, it is not necessarily buggy itself, though it 
sounds like a dangerous tool.

If you intended to test for array boundaries, using exceptions or 
another mechanism, and you forgot, then the program is buggy.

- Gerry Quinn

In article <435f1876$0$38705$edfadb0f@dread12.news.tele.dk>, ccc59035
@vip.cybercity.dk says...

> I use C++ daily, and it has taken me many years to learn (all) the tricks
> and quirks. I still get bitten regularly. Just the other day I forgot the
> fact that the STL containers requires that the elements are copyable. I had
> defined a non-trivial class and given it a suitable constructor, but forgot
> about the copy-constructor and assignment-operator. So the code compiled
> fine, but crashed at run-time. I hate it when the compiler adds these
> default copy constructors, instead of just complaining at compile time.

But the containers worked fine!  Your problem was making copies, when 
copies didn't work right.  You might have the same problem if you 
copied a pointer in C.

> There are lots of ugly spots in C++, particularly the requirement to be
> backwards compatible with C. Thus a lot of "potentially unsafe" operations
> are allowed in C++, like e.g. pointer arithmetic, even though they are
> rarely - if ever - needed.

If you don't need them, don't use them.
 
> Templates are amazing. They are just like black magic. When I look at Boost
> or Loki, I'm impressed with the ingenuity of the designers. It's like
> watching McGyver and seeing what kinds of stuff he can make out of ordinary
> household items. But there is NO WAY I'll ever be able to do anything like
> that. It's maybe only 10% or less of the professional C++ users that
> actually can write stuff like that.

The point of templates is, IMO, to be written on very rare occasions to 
create libraries that will see a lot of re-use.  Most programmers 
should never have to write them, but they should be able to use 
libraries created with them.

> And still there are features missing from the language. Functional
> programming is just not practical with C++. The STL actually encourages
> functional programming with algorithms like for_each(), but having to write
> intricate combinations of bind2nd, mem_fun_ref, etc. is not only completely
> illegible, it's plain ugly. Boost has some features to improve on this, but
> it's still ugly.

That's not a missing feature, it's a pointless addition.  Ignore.

- Gerry Quinn

Michael J�rgensen sade:
> "TIT" <spamo@noon.com> wrote in message
> news:1130273132.98bc8159411b589280ad88bc013bae3a@teranews...
> 
> [snip]
> 
> 
>>C++ may not be the perfect language, but it suits my needs nearly
> 
> perfectly.
> 
>>The beauty lies in the entire language. It's wonderful.
> 
> 
> Come on now! Isn't "wonderful" putting just a bit too much grease on? It
> sounds like you're biased towards C++. Which other programming languages
> have you used (i.e. written more than, say, 1K lines of code)?

You mean like BETA, ObjC, Cyclone, CLisp, ..., Commodore Basic
So, because I actually like C++, I'm suddenly ignorant?
Sure, "wonderful" might have been a tad too strong.

<snip>
> There are lots of ugly spots in C++, particularly the requirement to be
> backwards compatible with C. Thus a lot of "potentially unsafe" operations
> are allowed in C++, like e.g. pointer arithmetic, even though they are
> rarely - if ever - needed.
> 

There's nothing like the Standard to tell you what's safe or not.

<snip>
> Then there is the whole business of exception safety and thread safety. It's
> verbose and error-prone. I've given up solving these problems, and therefore
> by design all my applications are single-threaded, and I try to avoid the
> use of exceptions as much as possible.
> 

Exceptions are a vital part part of C++ and can actually be used without
introducing errors.

<snip>
> So, to end this rant: I was provoked by your choice of words. For all its
> faults, I like C++, but I wouldn't call it "wonderful" :-)
> 
> -Michael.
> 
> 

Hey, if usenet has thaught us anything it's provocation =)

TIT

"Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
news:MPG.1dc95b03ce553ba398a6e2@news.indigo.ie...
> In article <435f1876$0$38705$edfadb0f@dread12.news.tele.dk>, ccc59035
> @vip.cybercity.dk says...

[snip]

> > And still there are features missing from the language. Functional
> > programming is just not practical with C++. The STL actually encourages
> > functional programming with algorithms like for_each(), but having to
write
> > intricate combinations of bind2nd, mem_fun_ref, etc. is not only
completely
> > illegible, it's plain ugly. Boost has some features to improve on this,
but
> > it's still ugly.
>
> That's not a missing feature, it's a pointless addition.  Ignore.

Huh?

Instead of writing

std::vector<char> p;
for (char *p=begin(); p!=end(); ++p) {
  do_something(p);
}

you can write something like
std::vector<char> p;
for_each(p.begin(), p.end(), do_something);

This avoids the explicit loop. However, using the STL in this manner
requires functional programming, and the C++ language does not support it
natively. It can be simulated with templates, but quickly becomes very ugly.

IMO, for_each() is useless except in the simplest of all simple cases, for
the reasons stated above.

-Michael.

Walter Bright sade:
> "TIT" <spamo@noon.com> wrote in message
> news:1130273132.98bc8159411b589280ad88bc013bae3a@teranews...
> 
>>Walter Bright sade:
>>
>>>"TIT" <spamo@noon.com> wrote in message
>>>news:1130259096.8e384dcc7b333bcce58b3bdaca7852d6@teranews...
>>>
>>>>Despite the facts that the stand-alone letter D is an ugly symbol
>>>>for a programming language from a synesthetic perspective and that
>>>>I perceive you as a *bit* bias in your simple comparison above:
>>>
>>>Bias is an interesting word in this context. Consider that I did the
>>>original design of D, based solely on my desire to fix problems with C++
>>>that clearly would never get fixed. Bias implies I have some agenda for
> 
> D
> 
>>>that is other than simply believing it is a better programming language.
>>>Nobody has paid me to write D, D wasn't created in order to sell some
> 
> other
> 
>>>product, there is no agenda behind it other than it being a better
>>>programming language, etc. Consider also my very large personal
> 
> investment
> 
>>>in C and C++ compiler technology - if anything, I should be biased
> 
> against
> 
>>>D.
>>
>>Yes, I know you're the original designer of D. I think you're
>>overinterpreting the word in this context.
>>
>>thefreedictionary.com
>>bias - a partiality that prevents objective consideration of an issue or
>>situation
> 
> 
> I'm curious what non-objective bias I could have had that caused me to set
> aside decades of experience with C++ and start D.
> 
> 

Forget that the word was ever used.

TIT

Michael J�rgensen wrote:
> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
> news:MPG.1dc95b03ce553ba398a6e2@news.indigo.ie...
> Instead of writing
> 
> std::vector<char> p;
> for (char *p=begin(); p!=end(); ++p) {
>   do_something(p);
> }
> 
> you can write something like
> std::vector<char> p;
> for_each(p.begin(), p.end(), do_something);

Yes, this transformation is hugely useful in real functional programming
languages (where the above might be written "iter do_something p") but it
simply isn't usable from C++ due to lack of closures, GC, etc.

This is one of the main reasons that FPLs are much more succinct than C++.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop <usenet@jdh30.plus.com> wrote:

> Otto Wyss wrote:
> > Nice comparison but ... . On freshmeat.net
> 
> LOL. I immediately went to freshmeat as well. I've seen that Tiobe data
> before and it looked very suspicious to me.
> 
IMO freshmeat gives the best impression of how often a language is used
in OpenSource projects since only projects which reach a certain level
are published. Of course that doesn't say anthing about the quality. 

I'd rather like if freshmeat would allow for a much finer clasification
of projects and also impose a penalty for wrong (mostly too many)
classifications. I've already made a suggestion but they probably don't
listen to a single person.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Michael J�rgensen <ccc59035@vip.cybercity.dk> wrote:

> faults, I like C++, but I wouldn't call it "wonderful" :-)
> 
I don't like C++ but I haven't seen any other language which suits my
need better. So far I've coded in Assembler, Algon, Fortan, Pascal,
Portal, Ada, Modula, Oberon, Cobol, PL/1, Smalltalk, Perl, Java, C/C++
and probably some forgotten. The only language I really liked was Portal
but as luck goes it died first.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

Otto Wyss wrote On 10/26/05 12:23,:

> I'd rather like if freshmeat would allow for a much finer clasification
> of projects and also impose a penalty for wrong (mostly too many)
> classifications. I've already made a suggestion but they probably don't
> listen to a single person.

Pure discrimination. What does being married have to do with coding ?

Oh my god.  I have to submit that to bash.org.

"Walter Bright" <walter@nospamm-digitalmars.com> wrote in message
news:A9Sdna8q2IIt-sXeRVn-vA@comcast.com...
>
> "Flaran" <flaran@gmail.com> wrote in message
> news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
> > I have a question just for the hell of it... If you had to choose
> > between Java and C++, which would you choose? Why and why not?
>
> I'd choose the D programming language, which is as powerful as C++ but much
> easier to program in. It compiles to native code, not a VM.
>
I have  been hearing about D for some time now, but have not had the time
to look at it.   So, I finally investigated it.   What I found was a
well-designed
language that is clearly superior to either C or C++ in many respects.  I will
not enumerate them here, but if all the code now written in C and C++ were
instead being written in D, productivity would increase, errors would decrease,
and programs would be more reliable.

D would eliminate much of the sheer silliness that characteizes the current
version of C++.   For example, no more #ifndef foolishness.  Typedef actually
means what is sounds like it means...well, more than what one can get from
C or C++.   A few of the pathological features of C are retained such as the
drop-through on a "switch" statement, but most of the language design cleans
up the truly horrible and antiquated features of C and C++.  It is even an
improvement over Java.    I recommend it for anyone who needs to write
reliable code with a minimum of anxiety.

I was also struck with how much D seems to have learned from Ada.  Perhaps
the designer simply recognized some of the sensible ideas already in Ada and
did not look at Ada at all.  For safety-critical software, I still prefer Ada,
but
I find D to be an intelligently designed language that thoughtful designers
should
consider as a reasonable -- no, improved -- alternative to C and C++.

There are some things I would want to see added to the D language, but at its
present stage of development, its evolution toward further improvement should
proceed cautiously.

Richard Riehle

<adaworks@sbcglobal.net> wrote in message
news:8nj7f.6912$7h7.1267@newssvr21.news.prodigy.com...
> If the Java program
> is not in the form of bytecode, it suddenly loses one of its few
> real benefits:  that of being portable to any machine with a JVN.

The JVM is *not* what makes Java programs portable. What makes them portable
is the Java language spec has removed "undefined" and "implementation
defined" behavior and made them defined, predictable behavior. That's the
secret to language portability.

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

adaworks@sbcglobal.net wrote:
> There are some things I would want to see added to the D language, 

Added? It's already "everything but the kitchen sink" as C++, as Eiffel, 
as Ada...


August

"August Karlstrom" <fusionfive@comhem.se> wrote in message
news:7GW7f.36815$d5.193710@newsb.telia.net...
> adaworks@sbcglobal.net wrote:
> > There are some things I would want to see added to the D language,
>
> Added? It's already "everything but the kitchen sink" as C++, as Eiffel,
> as Ada...
>
And still a simpler, more straightforward design than C++.   The fact
that a language has features does not make it evil, especially when
those features are orthogonal to the underlying architecture of
that language.   C++ has become a language full of kludges that
seem more designed as workarounds for problems inherent in
its current design.

As to Eiffel, you clearly are unfamiliar with the language or have a
preconceived bias towards it.  This language is elegant and simple
in its fundamental design.   Perhaps you dislike assertions.  Perhaps
you dislike exceptions.  Perhaps you dislike multiple inheritance.
Eiffel is easy to learn and devoid of the inconsistencies that seem
to characterize C++.

As to Ada, with the exception of tasking, it is not nearly as complicated
as most people are led to believe.   It does have a design based on a
different philosophy than many other languages.  Certain aspects of
the language such as its visibility rules serve to make it more suitable
for software engineering than its competitors.   However, those
visibility rules are misunderstood by most people who approach
Ada for the first time.   For me, once I understood the notion of
scope and visibility, everything else in Ada came so easily that
I find it one of the most friendly languages currently available.

What to add to D?   I like the typedef feature and would like to see
a wee bit more power in that feature.   I did not see a model of
assertions, a la "design by contract," in D.   From a software
engineering perspective, that would be useful.

D is certainly as good as Java.   In my mind, it is a little better.  I like
the delegate function idea in C# and that might be useful.  I did not
see whether functions could be first-class objects in D.  Perhaps I
missed that, but if it is not a feature of D, I think it would useful
if it were.

For serious software engineering languages, what alternatives would
you propose?   Remember that some languages scale up better than
others when building large software systems.   Ada probably scales
up better than most alternatives.  Eiffel is pretty good, though its
largest actual compilation unit is the class.   C++ begins to turn into
a pile of software mush and becomes horrible to maintain when it
is used for really big software.   Oh, yes, it _can_ be used for
large-scale software but for every success there will be a lot
of failures.

D is on the right track.  It needs to evolve a little bit more, but as I
noted earlier, evolve with care and caution.   At present, it seems
to be a better design than either C or C++.

Richard Riehle

"August Karlstrom" <fusionfive@comhem.se> wrote in message
news:7GW7f.36815$d5.193710@newsb.telia.net...
> adaworks@sbcglobal.net wrote:
> > There are some things I would want to see added to the D language,
>
> Added? It's already "everything but the kitchen sink" as C++, as Eiffel,
> as Ada...

Whether or not that's a bad thing depends on the quality of the features,
how they fit together, and how well they support the various programming
paradigms. After all, I can't see criticizing a machine shop because it has
a large selection of machine tools ready for use.

-Walter Bright
www.digitalmars.com/d/ the D programming language

<adaworks@sbcglobal.net> wrote in message
news:4AZ7f.7108$q%.3811@newssvr12.news.prodigy.com...
>
> C++ has become a language full of kludges that
> seem more designed as workarounds for problems inherent in
> its current design.

One example:

C++: std::vector<int> a;
D: int[] a;

The current C++ thinking is to avoid core features of the language like
arrays and use instead the STL library. This leads to a lot of detritus. D's
thinking is to fix the core features.

> What to add to D?   I like the typedef feature and would like to see
> a wee bit more power in that feature.   I did not see a model of
> assertions, a la "design by contract," in D.   From a software
> engineering perspective, that would be useful.

It's there: www.digitalmars.com/d/dbc.html

> D is certainly as good as Java.   In my mind, it is a little better.  I
like
> the delegate function idea in C# and that might be useful.

Delegates are there as well: www.digitalmars.com/d/function.html#closures

> I did not
> see whether functions could be first-class objects in D.  Perhaps I
> missed that, but if it is not a feature of D, I think it would useful
> if it were.

D supports functors by supporting overloading of () for structs and classes.
Dynamic closures are also supported.

-Walter Bright
www.digitalmars.com/d/ the D Programming Language

In article <435f5918$0$38650$edfadb0f@dread12.news.tele.dk>, ccc59035
@vip.cybercity.dk says...
> "Gerry Quinn" <gerryq@DELETETHISindigo.ie> wrote in message
> news:MPG.1dc95b03ce553ba398a6e2@news.indigo.ie...

> > > And still there are features missing from the language. Functional
> > > programming is just not practical with C++. The STL actually encourages
> > > functional programming with algorithms like for_each(), but having towrite
> > > intricate combinations of bind2nd, mem_fun_ref, etc. is not onlycompletely
> > > illegible, it's plain ugly. Boost has some features to improve on this,but
> > > it's still ugly.

> > That's not a missing feature, it's a pointless addition.  Ignore.

> Instead of writing
> 
> std::vector<char> p;
> for (char *p=begin(); p!=end(); ++p) {
>   do_something(p);
> }
>
> you can write something like
> std::vector<char> p;
> for_each(p.begin(), p.end(), do_something);
> 
> This avoids the explicit loop. However, using the STL in this manner
> requires functional programming, and the C++ language does not support it
> natively. It can be simulated with templates, but quickly becomes very ugly.
> 
> IMO, for_each() is useless except in the simplest of all simple cases, for
> the reasons stated above.

In other words, it's a pointless addition because it doesn't work.  
(The same applies in spades to the complicated macros with which some 
people have tried to do the same with - or to - C.)

If you want to do functional programming, you should use a language 
that is designed for it.  There is no point abusing C++, then claiming 
that C++ has a problem when it doesn't work out.

- Gerry Quinn
 

"Walter Bright" <walter@nospamm-digitalmars.com> wrote in message
news:98adncJTiMkr8_3eRVn-ug@comcast.com...
>
> "August Karlstrom" <fusionfive@comhem.se> wrote in message
> news:7GW7f.36815$d5.193710@newsb.telia.net...
> > adaworks@sbcglobal.net wrote:
> > > There are some things I would want to see added to the D language,
> >
> > Added? It's already "everything but the kitchen sink" as C++, as Eiffel,
> > as Ada...
>
> Whether or not that's a bad thing depends on the quality of the features,
> how they fit together, and how well they support the various programming
> paradigms. After all, I can't see criticizing a machine shop because it has
> a large selection of machine tools ready for use.
>
Correct.   Tools that are designed for the purpose of providing solutions
to the actual problems being solved are useful.   Workaround tools, designed
to compensate for inadequacies of other tools are a waste of time.  One of
my favorite examples from C++ is the #ifndef silliness.  but there are lots of
other, more subtle, examples.

What I find strange is that so many programmers accept these features as if
they are a natural part of programming. I like the fact that the features of D
are designed, for the most part, to map the solution space to the problem
space in straightforward manner.  When the language contains features,
or tools, that help me focus on the client problem instead of the programming
environment problems, that is a good thing.   C++ is simply obsolete.   Those
who are so fond of it simply have not admitted it yet.

Twenty years from now, programmers will look back on C++ and wonder why
any sensible person was willing to put up with the annoyances inherent in
the language.

Richard Riehle

<adaworks@sbcglobal.net> wrote:

> not enumerate them here, but if all the code now written in C and C++ were
> instead being written in D, productivity would increase, errors would decrease
> and programs would be more reliable.
> 
Fine, so it only needs someone to convert all C/C++ code to D. You
probably agree this isn't a practical suggestion. Nobody will do this
work.

Most software projects depends to a certain extend on other software. I
for one depend on wxWidgets and will sure switch to D when wxWidgets
switches to D. Agreed, an uptodate kept API would be sufficiant but
since I debug and extend wxWidgets from time to time I'm faced with C++
again. I guess wxWidgets and most other projects are in the same
situation and depend too much on other C/C++ projects as I do.

O. Wyss

-- 
Development of frame buffer drivers: http://linux-fbdev.sf.net
Sample code snippets for wxWidgets: http://wxcode.sf.net
How to build well-designed applications: http://wyoguide.sf.net
Desktop with a consistent look and feel: http://wyodesktop.sf.net

<adaworks@sbcglobal.net> wrote in message
news:kZ48f.9402$Zv5.3878@newssvr25.news.prodigy.net...
>
> "Walter Bright" <walter@nospamm-digitalmars.com> wrote in message
> news:98adncJTiMkr8_3eRVn-ug@comcast.com...
> >
> > "August Karlstrom" <fusionfive@comhem.se> wrote in message
> > news:7GW7f.36815$d5.193710@newsb.telia.net...
> > > adaworks@sbcglobal.net wrote:
> > > > There are some things I would want to see added to the D language,
> > >
> > > Added? It's already "everything but the kitchen sink" as C++, as
Eiffel,
> > > as Ada...
> >
> > Whether or not that's a bad thing depends on the quality of the
features,
> > how they fit together, and how well they support the various programming
> > paradigms. After all, I can't see criticizing a machine shop because it
has
> > a large selection of machine tools ready for use.
> >
> Correct.   Tools that are designed for the purpose of providing solutions
> to the actual problems being solved are useful.   Workaround tools,
designed
> to compensate for inadequacies of other tools are a waste of time.  One of
> my favorite examples from C++ is the #ifndef silliness.  but there are
lots of
> other, more subtle, examples.

Often when I point out a problem with C++, such as use of uninitialized
variables, people will say there is no problem because XYZ compiler has an
extension to deal with that, or one can run Lint over it, or valgrind, etc.
The fact that considerable effort has been expended to build these tools
indicates that C++ does have significant problems. And the problem with
these extensions/tools is that they are not part of standard C++, so they
are not necessarilly available, installed properly, or work consistently,
and even worse, getting programmers to consistently use them is difficult.

Fixing the problem in the language means that it's always there, and its use
becomes either inevitable or at least trivial. In other words, it becomes
standard practice.


> What I find strange is that so many programmers accept these features as
if
> they are a natural part of programming. I like the fact that the features
of D
> are designed, for the most part, to map the solution space to the problem
> space in straightforward manner.  When the language contains features,
> or tools, that help me focus on the client problem instead of the
programming
> environment problems, that is a good thing.   C++ is simply obsolete.
Those
> who are so fond of it simply have not admitted it yet.
>
> Twenty years from now, programmers will look back on C++ and wonder why
> any sensible person was willing to put up with the annoyances inherent in
> the language.

C++ was designed 20 years ago. At the time, it was a big advance. But there
have been a lot of new ideas and better ways of doing things devised since
then, and a lot of things that were right 20 years ago are obsolete today.
For example, the fundamental lack of universal character support in C++. The
over- reliance on text preprocessing, for another. These problems can't be
fixed while retaining backwards compatibility. But at some point, the need
for modernization gets stronger than the need to be backwards compatible
with every obsolete feature.

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

"Otto Wyss" <otto.wyss@orpatec.ch> wrote in message
news:1h53rj0.ntvfp51camj5vN%otto.wyss@orpatec.ch...
> <adaworks@sbcglobal.net> wrote:
>
> > not enumerate them here, but if all the code now written in C and C++
were
> > instead being written in D, productivity would increase, errors would
decrease
> > and programs would be more reliable.
> >
> Fine, so it only needs someone to convert all C/C++ code to D. You
> probably agree this isn't a practical suggestion. Nobody will do this
> work.

Of course they won't. But D can directly hook up to C code, as it conforms
to the C ABI.

> Most software projects depends to a certain extend on other software. I
> for one depend on wxWidgets and will sure switch to D when wxWidgets
> switches to D. Agreed, an uptodate kept API would be sufficiant but
> since I debug and extend wxWidgets from time to time I'm faced with C++
> again. I guess wxWidgets and most other projects are in the same
> situation and depend too much on other C/C++ projects as I do.

I've looked at converting wxWidgets to D, and it's an overwhelming job given
the size of it.

Alan Balmer coughed up:
> On Tue, 18 Oct 2005 11:21:17 -0700, Scott Moore
> <samiamsansspam@Sun.COM> wrote:
>
>> Alan Balmer wrote On 10/18/05 08:24,:

....[rip]...

>>> That proves that you are an unsafe programmer, but says nothing about
>>> the language ;-)
>>
>> We'll be out to take the bumpers, doors and airbags off your car.
>> Also, you will only have two speeds, 0 and 100 miles an hour.
>>
>> It should only be a problem if you are an unsafe driver.
>
> If we're inventing random analogies, I'll let you jump out of a plane
> at 10,000 feet without a parachute. No problem unless you can't fly.

Broken analogy.  You didn't understand how Scott's analogy is not broken.


> C++ doesn't force anyone to write unsafe code,

That's not the discussion.  The point is that C++ has many /more/ ways of 
writing unsafe code than does Java, to pick one language.  Think operator 
overloading, no garbage collection, unrestrained pointer arithmetic.


> and silly analogies
> don't change that.
>
> Bad code can be written in any language, and silly analogies don't
> change that either.


And this is broken logic.  That you can write bad code in any language says 
nothing.  What's important is the quality of code that a language /lends/ 
itself to on average.  C++ is a maintenance disaster.



-- 
"Realtor" and "realty" are pronounced "reel'-tor" and
"reel'-tee", *not* "reel'-a-tor" and "reel'-i-tee" !!!!
If you pronounce them with the extra syllable, you will
sound like a complete idiot.

On Fri, 28 Oct 2005 04:08:18 GMT, "Thomas G. Marshall"
<tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote:

>Alan Balmer coughed up:
>(...)
>> C++ doesn't force anyone to write unsafe code,
>
>That's not the discussion.  The point is that C++ has many /more/ ways of 
>writing unsafe code than does Java, to pick one language.  Think operator 
>overloading, no garbage collection, unrestrained pointer arithmetic.
>
>

Java also has operator overloading. Garbage collection is easily
tricked into no collection at all, due to circular references: you
only have to use Swing to get that problem. The intensive use of
introspection is a nice way to get knee-deep into problems. So Java
has *lots* of ways to write unsafe code. One of the best recent
imporvements in Java: mix generics with introspection, and you'll have
a nice Molotov cocktail

"Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> writes:

> > C++ doesn't force anyone to write unsafe code,
> 
> That's not the discussion.  The point is that C++ has many /more/ ways of 
> writing unsafe code than does Java, to pick one language.  Think operator 
> overloading, no garbage collection, unrestrained pointer arithmetic.

One's safety belt is other's deadly trap.

Nowdays I am working on an embedded operating system, used in industruial
robots.  That's definitely not the place where you want to use garbage
collected languages.  As they might get somebody killed ;-)

ImRe

In article <58h3m19phkea86uvvuub1qc2du9hk92fmr@4ax.com>,
Zara  <dlm0-hbge@dea.spamcon.org> wrote:
  ...
>Java also has operator overloading. Garbage collection is easily
>tricked into no collection at all, due to circular references: you
>only have to use Swing to get that problem. 

You're confusing garbage collection with reference counting. One of the 
advantages of garbage collection over ref counts is that it correctly 
disposes of circular structures.

The way to make GC fail to reclaim memory is to retain references to 
unused memory. GC changes memory mamagement from managing blocks (nodes 
of the graph) to managing references (edges of the graph).

-Mike
-- 
http://www.mschaef.com

Zara coughed up:
> On Fri, 28 Oct 2005 04:08:18 GMT, "Thomas G. Marshall"
> <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote:
>
>> Alan Balmer coughed up:
>> (...)
>>> C++ doesn't force anyone to write unsafe code,
>>
>> That's not the discussion.  The point is that C++ has many /more/ ways of
>> writing unsafe code than does Java, to pick one language.  Think operator
>> overloading, no garbage collection, unrestrained pointer arithmetic.
>>
>>
>
> Java also has operator overloading.

Java does *not* have operator overloading.  There is nothing you can do to 
define your own operators.

Do not confuse the dual meaning of '+' (addition, string concat) as some 
form of operator that you have control over overloading.


> Garbage collection is easily
> tricked into no collection at all, due to circular references

BULLSHIT.  You have got to learn what you are talking about.  Java uses a 
Mark And Sweep algorithm, not a reference count!


>: you
> only have to use Swing to get that problem. The intensive use of
> introspection is a nice way to get knee-deep into problems. So Java
> has *lots* of ways to write unsafe code.

Not the issue.  The issue is whether or not it lends itself to unsafe code 
as much as c++ does.

....[rip]...

-- 
http://www.allexperts.com is a nifty way to get an answer to just about
/anything/.

MSCHAEF.COM coughed up:
> In article <58h3m19phkea86uvvuub1qc2du9hk92fmr@4ax.com>,
> Zara  <dlm0-hbge@dea.spamcon.org> wrote:
>  ...
>> Java also has operator overloading. Garbage collection is easily
>> tricked into no collection at all, due to circular references: you
>> only have to use Swing to get that problem.
>
> You're confusing garbage collection with reference counting.

No, they are both forms of garbage collection: he's confusing the mechanism 
by which they are achieved: reference counts OR mark and sweep.  Any other 
techniques might be a subject for a general CS group.

There is an issue about how free java implementations are to implement the 
precise algorithm for GC.  I strongly doubt anyone will find any jvm that 
uses reference counting.


> One of the
> advantages of garbage collection over ref counts is that it correctly
> disposes of circular structures.
>
> The way to make GC fail to reclaim memory is to retain references to
> unused memory. GC changes memory mamagement from managing blocks (nodes
> of the graph) to managing references (edges of the graph).
>
> -Mike



-- 
http://www.allexperts.com is a nifty way to get an answer to just about
/anything/.

Thomas G. Marshall wrote On 10/27/05 21:08,:

>>C++ doesn't force anyone to write unsafe code,
> 
> 
> That's not the discussion.  The point is that C++ has many /more/ ways of 
> writing unsafe code than does Java, to pick one language.  Think operator 
> overloading, no garbage collection, unrestrained pointer arithmetic.
> 

Whats unsafe about operator overloading ? Ditto Garbage collection.

Imre Palik ) wrote On 10/27/05 23:37,:
> "Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> writes:
> 
> 
>>>C++ doesn't force anyone to write unsafe code,
>>
>>That's not the discussion.  The point is that C++ has many /more/ ways of 
>>writing unsafe code than does Java, to pick one language.  Think operator 
>>overloading, no garbage collection, unrestrained pointer arithmetic.
> 
> 
> One's safety belt is other's deadly trap.
> 
> Nowdays I am working on an embedded operating system, used in industruial
> robots.  That's definitely not the place where you want to use garbage
> collected languages.  As they might get somebody killed ;-)
> 
> ImRe

There are gcol algorithims that don't impact real time performce. The collection
process can be run only when the processor is completely idle, and constructed
in such a way that it is both interruptable and preemptable.

Scott Moore coughed up:
> Thomas G. Marshall wrote On 10/27/05 21:08,:
>
>>> C++ doesn't force anyone to write unsafe code,
>>
>>
>> That's not the discussion.  The point is that C++ has many /more/ ways of
>> writing unsafe code than does Java, to pick one language.  Think operator
>> overloading, no garbage collection, unrestrained pointer arithmetic.
>>
>
> Whats unsafe about operator overloading ? Ditto Garbage collection.

Nothing unsafe about garbage collection---re-read the post.

Operator overloading...this is tiring to explain over and over.  See the 
following excellent explanation by Jon Skeet:

http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/775d088c5e5cc434

Remember, that this is a C# person in a C# newsgroup fighting back the 
myriad of C#-former C++ followers.

It boils down to making code that is horrendously hard to maintain.


-- 
Everythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupyournose.

Scott Moore wrote:
>
> There are gcol algorithims that don't impact real time performce. The collection
> process can be run only when the processor is completely idle, and constructed
> in such a way that it is both interruptable and preemptable.

Many real time control systems never have a time when the processor is
completely idle during steady state operations. Of course, running when

the processor is completely idle implies a separate garbage collection
thread.

Many real time systems use no threading because of the additional
complexities
created for reliability and temporal determinism analyses.

Once you allow the use of multiple threads in real time control systems
you
must also consider multiple cpu cores, if not multiple cpu chips. A
garbage
collection thread could conceivably run on its own core, which would
always
be idle except during the execution of the garbage collector. In that
case,
the garbage collection could easily interfere with the primary
processing
of the program.

On the other hand, if the processor was never completely idle, the
garbage collection thread would never run. The result would be
eventual complete exhaustion of dynamically allocated memory.

Real time control systems often cannot endure timing creep or
latency instability. Real time control systems often need to directly
address hardware, which means they must use languages offering the
ability to specify hardware addresses. That ability will also cause
an associated garbage collection system to apply locks to all memory
being collected in a multi-threaded system. Those locks impose
extra overhead on both the garbage collection system and the base
application. Extra overhead of this sort can cause unacceptable
timing problems.

Jim Rogers

Thomas G. Marshall wrote On 10/28/05 11:40,:
> Scott Moore coughed up:
> 
>>Thomas G. Marshall wrote On 10/27/05 21:08,:
>>
>>
>>>>C++ doesn't force anyone to write unsafe code,
>>>
>>>
>>>That's not the discussion.  The point is that C++ has many /more/ ways of
>>>writing unsafe code than does Java, to pick one language.  Think operator
>>>overloading, no garbage collection, unrestrained pointer arithmetic.
>>>
>>
>>Whats unsafe about operator overloading ? Ditto Garbage collection.
> 
> 
> Nothing unsafe about garbage collection---re-read the post.
> 
> Operator overloading...this is tiring to explain over and over.  See the 
> following excellent explanation by Jon Skeet:
> 
> http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/775d088c5e5cc434
> 

The posting above describes operator overloading as an "inconvience", but I don't
see the case for it being unsafe, certainly not in the same catagory as having
unbounded array accesses. I'm not trying to be pedantic here. The concept of "unsafe"
is being linked here with "inconvient".

jimmaureenrogers@worldnet.att.net wrote On 10/28/05 13:01,:
> Scott Moore wrote:
> 
>>There are gcol algorithims that don't impact real time performce. The collection
>>process can be run only when the processor is completely idle, and constructed
>>in such a way that it is both interruptable and preemptable.
> 
> 
> Many real time control systems never have a time when the processor is
> completely idle during steady state operations. Of course, running when
> 
> the processor is completely idle implies a separate garbage collection
> thread.
> 
> Many real time systems use no threading because of the additional
> complexities
> created for reliability and temporal determinism analyses.
> 

Sorry, but I have worked for many people who held these theories about
their code, and the code didn't bear it out. What in fact was happening was
that they were mixing various amounts of polling and other time wasting
activities into the system, then calling the system "busy". There are
many ways to fool yourself that you aren't polling when you are.
A typical scenario is where the interrupt handler sets some flags, then
the tasks running wake up, check those flags, then give up their timeslice
when the flags don't prescribe action needed. That's not a non-polling
algothim, that's moving the status of a pheripheral to a flag, then
polling that in round robin fashion.

The idea of a "fully busy" processor for real time is against the
entire concept of real time in any case. If the machine is fully
occupied, then it is on the edge of failing, because if its load increases
even a little, it then fails. The theory of real time computing is that
the CPU is run far below its load level to keep the latency to handle
real time events low. Given this, yes, you always have idle time on
the CPU, and that time can be used as I mentioned.

I have worked on several projects which had an "overloaded CPU" and
the problem was solved by eliminating polling and other wasted work,
which resulted in dramatic decreases in CPU workload.

"Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com>
wrote in message news:jgu8f.9$L56.4@trndny05...
> Operator overloading...this is tiring to explain over and over.  See the
> following excellent explanation by Jon Skeet:
>
>
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/775d088c5e5cc434
>
> Remember, that this is a C# person in a C# newsgroup fighting back the
> myriad of C#-former C++ followers.
>
> It boils down to making code that is horrendously hard to maintain.

Operator overloading works well when one is attempting to extend the
arithmetic and container types to support new ones, such as matrices, big
numbers, etc.

But it's gotten a bad reputation because of abuses like overloading >> to
mean output. It is not only aesthetically ugly, it is not exception safe nor
thread safe. Unfortunately, this usage was blessed and incorporated into the
C++ Standard, so a number of C++ programmers think it's the right way to do
operator overloading.

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

Scott Moore wrote:
> jimmaureenrogers@worldnet.att.net wrote On 10/28/05 13:01,:
> > Scott Moore wrote:
> >
> >>There are gcol algorithims that don't impact real time performce. The collection
> >>process can be run only when the processor is completely idle, and constructed
> >>in such a way that it is both interruptable and preemptable.
> >

>
> Sorry, but I have worked for many people who held these theories about
> their code, and the code didn't bear it out. What in fact was happening was
> that they were mixing various amounts of polling and other time wasting
> activities into the system, then calling the system "busy". There are
> many ways to fool yourself that you aren't polling when you are.
> A typical scenario is where the interrupt handler sets some flags, then
> the tasks running wake up, check those flags, then give up their timeslice
> when the flags don't prescribe action needed. That's not a non-polling
> algothim, that's moving the status of a pheripheral to a flag, then
> polling that in round robin fashion.
>
> The idea of a "fully busy" processor for real time is against the
> entire concept of real time in any case. If the machine is fully
> occupied, then it is on the edge of failing, because if its load increases
> even a little, it then fails. The theory of real time computing is that
> the CPU is run far below its load level to keep the latency to handle
> real time events low. Given this, yes, you always have idle time on
> the CPU, and that time can be used as I mentioned.
>
> I have worked on several projects which had an "overloaded CPU" and
> the problem was solved by eliminating polling and other wasted work,
> which resulted in dramatic decreases in CPU workload.

I agree with what you just said, but that is different from what
I first responded to. You specified that the garbage collector could
run when the processor was completely idle (see the quotation above).
This is far different than when the processor is not fully occupied.

Jim Rogers

Walter Bright said:

> Operator overloading works well when one is attempting to extend the
> arithmetic and container types to support new ones, such as matrices, big
> numbers, etc.

Yes, and it is in precisely these circumstances that I pine for operator 
overloading in C.

> 
> But it's gotten a bad reputation because of abuses like overloading >> to
> mean output. It is not only aesthetically ugly, it is not exception safe
> nor thread safe. Unfortunately, this usage was blessed and incorporated
> into the C++ Standard, so a number of C++ programmers think it's the right
> way to do operator overloading.

Just a teensy-weensy little nit - I think you'll find that >> is overloaded 
to mean input, not output. :-)

Operator overloading, used well, can be a boon. Abused, it's a bane. It 
seems to me that the whole iostream thing was one of those "Oh! I wonder 
if..." moments which seems, in the pit of the night, to be a really good 
idea, and then it got sort of locked in thereafter. I can see no other 
justification for it.

Some years ago, on one of my admittedly rare C++ projects, I needed to write 
a routine to get all specified items out of one container and into another. 
Rather mischievously (but with a poker face), I asked three colleagues - 
separately - their opinion on which operator would be the best to overload 
for this purpose. The first said +=, because I was adding to the new 
container. The second, who was rather less experienced, suggested -=, 
because I was removing from the old container. The third advised me to use 
*=, because I wanted all specified items from the old container and * means 
"everything"!!

None gave me what I still consider to be the correct answer - "why on earth 
would you want to overload an operator for that?"

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

On Sat, 29 Oct 2005, Richard Heathfield wrote:
>
> Some years ago, on one of my admittedly rare C++ projects, I needed to write
> a routine to get all specified items out of one container and into another.
> Rather mischievously (but with a poker face), I asked three colleagues -
> separately - their opinion on which operator would be the best to overload
> for this purpose. The first said +=, because I was adding to the new
> container. The second, who was rather less experienced, suggested -=,
> because I was removing from the old container. The third advised me to use
> *=, because I wanted all specified items from the old container and * means
> "everything"!!
>
> None gave me what I still consider to be the correct answer - "why on earth
> would you want to overload an operator for that?"

   Because it's there!  Silly question. ;)

   I discovered about five years ago that it was possible, with injudicious 
use of operator overloading and templating, to create customized infix
"operators" invoked as "foo &(op)& bar". So if you asked me, and I didn't
feel like giving the "why on earth" answer (probably because I assumed
you knew better, and were just asking for fun), I'd suggest

     new_container &(gets_specified_elements_from)& old_container;

;-)

   (By the way, how are the elements "specified"? It seems like the 
operation is trinary, at least, which makes it hard to express in
operator-overloading terms anyway.)

-Arthur,
exercise for the interested reader

"Scott Moore" <samiamsansspam@Sun.COM> wrote in message
news:djtqe4$slf$1@news1nwk.SFbay.Sun.COM...
>
> Whats unsafe about operator overloading ? Ditto Garbage collection.
>
Operating overloading, C++ style, makes it easy to create obfuscated
code.   Several posts following this one make this point.   Is obfuscated
code unsafe?   Perhaps it is not unsafe as written, but it easily evolves into
unsafe code as it is maintained over time.   At first, this is simply an
"inconvenience."    It gradually creeps into the realm of nuisance, and
finally, becomes unsafe.
>
Garbage collection is not always unsafe.   It can be unsafe for certain
classes of real-time, safety-critical, embedded systems.   For most
situations, automatic garbage collection is a good thing.

Richard Riehle

jimmaureenrogers@worldnet.att.net wrote:
) I agree with what you just said, but that is different from what
) I first responded to. You specified that the garbage collector could
) run when the processor was completely idle (see the quotation above).
) This is far different than when the processor is not fully occupied.

Processors are either idle or running.  They might be idle for
small slices of time, but 'not fully occupied' is only relevant
if you take the average over some period of time.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

In article <djuo5h$u8$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>, 
invalid@invalid.invalid says...

> Some years ago, on one of my admittedly rare C++ projects, I needed to write 
> a routine to get all specified items out of one container and into another. 
> Rather mischievously (but with a poker face), I asked three colleagues - 
> separately - their opinion on which operator would be the best to overload 
> for this purpose. The first said +=, because I was adding to the new 
> container. The second, who was rather less experienced, suggested -=, 
> because I was removing from the old container. The third advised me to use 
> *=, because I wanted all specified items from the old container and * means 
> "everything"!!
> 
> None gave me what I still consider to be the correct answer - "why on earth 
> would you want to overload an operator for that?"

And the operators in question are the very ones that are my pet hate in 
this regard - when you overload +, ++, += etc., the other operators are 
unchanged.  So x++ now means something different from x+=1.

Again, though, the possibility of abuse is not entirely the fault of 
the language.

- Gerry Quinn

Scott Moore coughed up:
> Thomas G. Marshall wrote On 10/28/05 11:40,:
>> Scott Moore coughed up:
>>
>>> Thomas G. Marshall wrote On 10/27/05 21:08,:
>>>
>>>
>>>>> C++ doesn't force anyone to write unsafe code,
>>>>
>>>>
>>>> That's not the discussion.  The point is that C++ has many /more/ ways 
>>>> of
>>>> writing unsafe code than does Java, to pick one language.  Think 
>>>> operator
>>>> overloading, no garbage collection, unrestrained pointer arithmetic.
>>>>
>>>
>>> Whats unsafe about operator overloading ? Ditto Garbage collection.
>>
>>
>> Nothing unsafe about garbage collection---re-read the post.
>>
>> Operator overloading...this is tiring to explain over and over.  See the
>> following excellent explanation by Jon Skeet:
>>
>> http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/msg/775d088c5e5cc434
>>
>
> The posting above describes operator overloading as an "inconvience", but 
> I
> don't see the case for it being unsafe, certainly not in the same catagory
> as having unbounded array accesses. I'm not trying to be pedantic here. 
> The
> concept of "unsafe" is being linked here with "inconvient".

Two Huge problems with your reply here.

1. No, it does not make the case that it is merely inconvenient.  His 
assertion is that it is very hard to immediately tell what is going on, look 
at his example again.  In a multitude of posts elsewhere I've made the point 
that you need to code for the (even very senior) engineer who is reading it 
at 3am and hopped on caffeine.

2. Even if it did (it does not) make the case for mere inconvenience, 
inconvenience all by itself lends itself to unmaintainable code.  You need 
to make the reading of the code as much as a no brainer as you can.

-- 
"Gentlemen, you can't fight in here! This is the War Room!"

Richard Heathfield coughed up:
> Walter Bright said:
>
>> Operator overloading works well when one is attempting to extend the
>> arithmetic and container types to support new ones, such as matrices, big
>> numbers, etc.
>
> Yes, and it is in precisely these circumstances that I pine for operator
> overloading in C.
>
>>
>> But it's gotten a bad reputation because of abuses like overloading >> to
>> mean output. It is not only aesthetically ugly, it is not exception safe
>> nor thread safe. Unfortunately, this usage was blessed and incorporated
>> into the C++ Standard, so a number of C++ programmers think it's the 
>> right
>> way to do operator overloading.
>
> Just a teensy-weensy little nit - I think you'll find that >> is 
> overloaded
> to mean input, not output. :-)
>
> Operator overloading, used well, can be a boon. Abused, it's a bane. It
> seems to me that the whole iostream thing was one of those "Oh! I wonder
> if..." moments which seems, in the pit of the night, to be a really good
> idea, and then it got sort of locked in thereafter. I can see no other
> justification for it.
>
> Some years ago, on one of my admittedly rare C++ projects, I needed to 
> write
> a routine to get all specified items out of one container and into 
> another.
> Rather mischievously (but with a poker face), I asked three colleagues -
> separately - their opinion on which operator would be the best to overload
> for this purpose. The first said +=, because I was adding to the new
> container. The second, who was rather less experienced, suggested -=,
> because I was removing from the old container. The third advised me to use
> *=, because I wanted all specified items from the old container and * 
> means
> "everything"!!
>
> None gave me what I still consider to be the correct answer - "why on 
> earth
> would you want to overload an operator for that?"

Hence the danger.

Hence the reasons for not having it in the first place.

We must all deal with, and manage, engineers in the real world.  To stretch 
things absurdly, I could make the argument that a 8 year old with a loaded 
gun might be safer in some parts of the country.  I could (let's say) dig up 
an article about 1 kid in the middle of nowhere who actually was saved by 
such.  It would of course, be ignoring the real danger.

-- 
"Gentlemen, you can't fight in here! This is the War Room!"

adaworks@sbcglobal.net coughed up:
> "Scott Moore" <samiamsansspam@Sun.COM> wrote in message
> news:djtqe4$slf$1@news1nwk.SFbay.Sun.COM...
>>
>> Whats unsafe about operator overloading ? Ditto Garbage collection.
>>
> Operating overloading, C++ style, makes it easy to create obfuscated
> code.   Several posts following this one make this point.   Is obfuscated
> code unsafe?   Perhaps it is not unsafe as written, but it easily evolves
> into unsafe code as it is maintained over time.   At first, this is simply 
> an
> "inconvenience."    It gradually creeps into the realm of nuisance, and
> finally, becomes unsafe.
>>
> Garbage collection is not always unsafe.   It can be unsafe for certain
> classes of real-time, safety-critical, embedded systems.   For most
> situations, automatic garbage collection is a good

s/good/spectacular

> thing.
>
> Richard Riehle



-- 
"Gentlemen, you can't fight in here! This is the War Room!"

Richard Heathfield wrote:
> Walter Bright said:
>
> > Operator overloading works well when one is attempting to extend the
> > arithmetic and container types to support new ones, such as matrices, big
> > numbers, etc.
>
> Yes, and it is in precisely these circumstances that I pine for operator
> overloading in C.
>
> >
> > But it's gotten a bad reputation because of abuses like overloading >> to
> > mean output. It is not only aesthetically ugly, it is not exception safe
> > nor thread safe. Unfortunately, this usage was blessed and incorporated
> > into the C++ Standard, so a number of C++ programmers think it's the right
> > way to do operator overloading.
>
> Just a teensy-weensy little nit - I think you'll find that >> is overloaded
> to mean input, not output. :-)
>
> Operator overloading, used well, can be a boon. Abused, it's a bane. It
> seems to me that the whole iostream thing was one of those "Oh! I wonder
> if..." moments which seems, in the pit of the night, to be a really good
> idea, and then it got sort of locked in thereafter. I can see no other
> justification for it.
>
> Some years ago, on one of my admittedly rare C++ projects, I needed to write
> a routine to get all specified items out of one container and into another.
> Rather mischievously (but with a poker face), I asked three colleagues -
> separately - their opinion on which operator would be the best to overload
> for this purpose. The first said +=, because I was adding to the new
> container. The second, who was rather less experienced, suggested -=,
> because I was removing from the old container. The third advised me to use
> *=, because I wanted all specified items from the old container and * means
> "everything"!!
>
> None gave me what I still consider to be the correct answer - "why on earth
> would you want to overload an operator for that?"

Exactly.  When I first saw operator overloading I thought it was a very
interesting and useful idea.

Not any longer.  The problem is AFAICT there are only two big reasons
for overloading operators:-
1. brevity
2. to make mathematical expression appear as they would in mathematics

Brevity can be achieved by using short names for common operations.
Pick a 5 letter name it's only a few more characters than + and -.  Eg
"set-" for subtract from set.

Many people enamoured of maths like being able to make it's notation
look as it normally does.  This is wonderful in theory, the problem is
programs contain so much normal integer maths.  So in situations where
it's done it becomes very difficult to extricate the integer operations
from the vector ops for instance.  The only good guide becomes the
declaration of the variables, which may be pages away.

"Zara" <yozara@terra.es> wrote in message
news:58h3m19phkea86uvvuub1qc2du9hk92fmr@4ax.com...
> On Fri, 28 Oct 2005 04:08:18 GMT, "Thomas G. Marshall"
> <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote:
>
> >Alan Balmer coughed up:
> >(...)
> >> C++ doesn't force anyone to write unsafe code,
> >
> >That's not the discussion.  The point is that C++ has many /more/ ways of
> >writing unsafe code than does Java, to pick one language.  Think operator
> >overloading, no garbage collection, unrestrained pointer arithmetic.
> >
> >
>
> Java also has operator overloading. Garbage collection is easily
> tricked into no collection at all, due to circular references: you
> only have to use Swing to get that problem. The intensive use of
> introspection is a nice way to get knee-deep into problems. So Java
> has *lots* of ways to write unsafe code. One of the best recent
> imporvements in Java: mix generics with introspection, and you'll have
> a nice Molotov cocktail
>
If you really want safe code, use Ada with SPARK.   Yes, you can
write unsafe code in any language, but Ada makes it more difficult.
You cannot fool the compiler.  You must jump through hoops to
use unsafe constructs.   And, in the end, you can develop just as
fast, just as easily, and end up with highly maintainable code.

Richard Riehle

"Thomas G. Marshall" <tgm2tothe10thpower@replacetextwithnumber.hotmail.com>
wrote in message news:XTK8f.4476$lg7.3131@trndny02...
> adaworks@sbcglobal.net coughed up:
> > "Scott Moore" <samiamsansspam@Sun.COM> wrote in message
> > news:djtqe4$slf$1@news1nwk.SFbay.Sun.COM...
> >>
> >> Whats unsafe about operator overloading ? Ditto Garbage collection.
> >>
> > Operating overloading, C++ style, makes it easy to create obfuscated
> > code.   Several posts following this one make this point.   Is obfuscated
> > code unsafe?   Perhaps it is not unsafe as written, but it easily evolves
> > into unsafe code as it is maintained over time.   At first, this is simply
> > an
> > "inconvenience."    It gradually creeps into the realm of nuisance, and
> > finally, becomes unsafe.
> >>
> > Garbage collection is not always unsafe.   It can be unsafe for certain
> > classes of real-time, safety-critical, embedded systems.   For most
> > situations, automatic garbage collection is a good
>
> s/good/spectacular
>
> > thing.
> >
I see, Thomas, that you are a fan of regular expressions.   However, the
word "spectacular" may be a little too much when discussing built-in
[default] automatic garbage collection.

One of the issues with garbage collection is that there are so many ways
to do it, each of which has its own virtues.    When to use mark and sweep
versus reference counting versus free list and on and on, is an interesting
problem.   So, I prefer an implementation that includes a default method
for GC, but allows me to override that default as necessary.   GNAT Ada
is such an implementation.   I can select the built-in implementation of the
storage pool package, or I can write my own version, using standard features
of the language design.   Now that is what I might call "spectacular."

>  Richard Riehle

adaworks@sbcglobal.net wrote:

> Garbage collection is not always unsafe.   It can be unsafe for certain
> classes of real-time, safety-critical, embedded systems.   For most
> situations, automatic garbage collection is a good thing.
> 

To do garbage collection properly requires, in many cases, as much 
attention to detail as doing manual memory management. Case in point: 
consider a stack implemented as follows:

void push_fooStack(fooStack * stack, Foo * foo)
{
   stack->stack[stack->top] = foo;
   stack->top++;
}

void pop_fooStack(fooStack * stack)
{
   stack->top--;
}

This will result in situations where GC would not clean up memory that 
is logically garbage.

In any large-scale project that we do, we observe two rules:
- we must be able to traverse all the "objects" that are logically in use.
- we must be able to monitor the allocation and freeing of all memory.

This allows us to do a much more precise job of controlling memory 
allocation and deallocation. For instance, this allows us to detect 
exactly where memory leaked. It also allows us to detect allocations 
that can be converted to stack (alloca()) allocation or to an arena 
based allocator.

See http://users.bestweb.net/~ctips for some of the mechanics.

On a somewhat different note, what is the state of multiprocessor GC 
these days? Does it still require halt-the-world and/or lock-every-time 
to clean up all garbage?

Gerry Quinn wrote:

> In article <435f5918$0$38650$edfadb0f@dread12.news.tele.dk>, ccc59035
> @vip.cybercity.dk says...
> 
<snip>
> 
>>Instead of writing
>>
>>std::vector<char> p;
>>for (char *p=begin(); p!=end(); ++p) {
>>  do_something(p);
>>}
>>
>>you can write something like
>>std::vector<char> p;
>>for_each(p.begin(), p.end(), do_something);
>>
<snip>
>>IMO, for_each() is useless except in the simplest of all simple cases, for
>>the reasons stated above.
> 
> 

IMO, the right way to traversals of a collection, applying a function to 
each element of a collection is to separate the two into two separate 
phases. So, instead of something like
   for_each(foos.first(), foos.last(), do_something)
write the following
   fooCollection foos;
   foo *		gather[N];
   n = traverse_foos(foos, N, gather);
   assert( n <= N );
   for( i = 0; i < n; i++ ) {
     do_something(gather[i]);
   }

This idiom decouples the traversal from the function-application, and 
has quite a few other side-effects. [E.g. if the collection is a graph, 
one only has to write the post-order traversal routine, and then one can 
do post-order and reverse-post-order by changing the direction of i]

One benefit which surprised me when I encoutered it is that it is faster 
than the other way of doing things (basically passing a function pointer 
to a traversal). I expected the D-cache-miss rate of walking a 
collection twice to degrade performance. After measurements it turns out 
that this idiom allowed the compiler to generate tighter loop for the 
traversals, and to replace indirect function calls with direct function 
calls, both of which more than compenstated for the extra L1-miss traffic.

A drawback of this idiom is that one has to know a lower-bound on the 
collection size at the point at which the idiom is used. For collections 
where the size is known, we've taken to using the equivalent of:
   N = nelements_fooCollection(foos);
   gathers = alloca(N * sizeof(foo *));

adaworks@sbcglobal.net coughed up:
> "Thomas G. Marshall"
> <tgm2tothe10thpower@replacetextwithnumber.hotmail.com> wrote in
> message news:XTK8f.4476$lg7.3131@trndny02...
>> adaworks@sbcglobal.net coughed up:
>>> "Scott Moore" <samiamsansspam@Sun.COM> wrote in message
>>> news:djtqe4$slf$1@news1nwk.SFbay.Sun.COM...
>>>>
>>>> Whats unsafe about operator overloading ? Ditto Garbage collection.
>>>>
>>> Operating overloading, C++ style, makes it easy to create obfuscated
>>> code.   Several posts following this one make this point.   Is
>>> obfuscated code unsafe?   Perhaps it is not unsafe as written, but
>>> it easily evolves into unsafe code as it is maintained over time.
>>> At first, this is simply an
>>> "inconvenience."    It gradually creeps into the realm of nuisance,
>>> and finally, becomes unsafe.
>>>>
>>> Garbage collection is not always unsafe.   It can be unsafe for
>>> certain classes of real-time, safety-critical, embedded systems.
>>> For most situations, automatic garbage collection is a good
>>
>> s/good/spectacular
>>
>>> thing.
>>>
> I see, Thomas, that you are a fan of regular expressions.   However,
> the word "spectacular" may be a little too much when discussing
> built-in [default] automatic garbage collection.
>
> One of the issues with garbage collection is that there are so many
> ways
> to do it, each of which has its own virtues.    When to use mark and
> sweep versus reference counting versus free list and on and on, is an
> interesting problem.   So, I prefer an implementation that includes a
> default method for GC, but allows me to override that default as
> necessary.   GNAT Ada
> is such an implementation.   I can select the built-in implementation
> of the storage pool package, or I can write my own version, using
> standard features of the language design.   Now that is what I might
> call "spectacular."

No, let's pick only mark-and-sweep, for yucks.  Given a language that has no 
gc and then granted by bright light from the sky and choral singing 
"whaaaaaaaa" a GC based language with MaS GC.  The latter is viewed as 
spectacular.

adaworks@sbcglobal.net wrote:

> If you really want safe code, use Ada with SPARK. 

Or, perhaps, use C with splint.

In either case, the formal properties that are checked are quite 
inadequate for proving either safey or correctness in a program. These 
tools, and any others which attempt to reason about formal properties of 
programs, are limited
- by the capability of the proof engine(s).
- by the fact that the assertion (in general) is no more succint than 
the program, so that the user is basically writing the same code twice.
- lead to some intesting problems when code is changed [if a function is 
changed, what happens in its callers? If an assertion fails in the 
caller, is it because the assertion was too tight, or because the change 
was incorrect?]

CTips wrote:
> adaworks@sbcglobal.net wrote:
>
> > If you really want safe code, use Ada with SPARK.
>
> Or, perhaps, use C with splint.
>
> In either case, the formal properties that are checked are quite
> inadequate for proving either safey or correctness in a program. These
> tools, and any others which attempt to reason about formal properties of
> programs, are limited
> - by the capability of the proof engine(s).
> - by the fact that the assertion (in general) is no more succint than

You might want to look again at SPARK.
It adds more than assertions.
SPARK requires special notations to be added to what is otherwise
normal Ada code. Those notations are used by the inference engine as
directives for formal analysis beyond what is performed by the Ada
compiler itself.

The SPARK process starts with translation of system requirements
into Z notation. Z notation is a formal requirements description
language. The act of translating requirements into Z often
discloses faults in the requirements themselves.

We all know that no program will be correct and safe if the
requirements upon which the program is constructed are not
correct.

Once the Z notation is stabalized, and all requirements have
been negotiated to some a level of quasi-stability, the SPARK
process translates the Z notation into special comment blocks
for Ada code. The SPARK inference engine reads those comment
blocks and uses their information to increase its knowledge
of what the code is supposed to achieve. This increased
knowledge allows the inference engine to identify subtle
errors in the code not found by the Ada compiler itself.

> the program, so that the user is basically writing the same code twice.
> - lead to some intesting problems when code is changed [if a function is
> changed, what happens in its callers? If an assertion fails in the
> caller, is it because the assertion was too tight, or because the change
> was incorrect?]

The programmer actually writes the program several times, but that
is not a problem if the result is a significant reduction in
test and debug effort. The overall cost of development using SPARK
can be a small fraction of the overall development cost for a
similar system without the use of SPARK.

Ada, even without SPARK, has always provided syntactic tools
not found in C. Those tools allow the Ada compiler to accomplish
as much or more than Splint with greater cohesiveness and
flexibility.

For instance, one can assert that a variable must have certain
properties, such as the value for a heading in degrees must be
a value between 0.0 and 359.99. A C compiler has insufficient
syntactic information to assert that for a variable wherever
it is used in a program. An Ada compiler provides all the
information the compiler needs.

type Degrees is new Float range 0.0..359.99;

Every variable of type Degrees will then have a value
restriction to the specified range.

The compiler will not allow just any Float value to be passed
to a function where a Degrees value is specified. It will
flag such an attempt as an invalid type for the parameter.

If the definition of Degrees changes some time due to a change
in system requirements, then the definition of the type itself
is all that needs to be changed in the program.

type Degrees is new Float range -180.0..179.99;

There are no "interesting problems" when the code is changed
in this manner.

Jim Rogers

CTips coughed up:
> adaworks@sbcglobal.net wrote:
>
>> Garbage collection is not always unsafe.   It can be unsafe for certain
>> classes of real-time, safety-critical, embedded systems.   For most
>> situations, automatic garbage collection is a good thing.
>>
>
> To do garbage collection properly requires, in many cases, as much
> attention to detail as doing manual memory management. Case in point:
> consider a stack implemented as follows:
>
> void push_fooStack(fooStack * stack, Foo * foo)
> {
>   stack->stack[stack->top] = foo;
>   stack->top++;
> }
>
> void pop_fooStack(fooStack * stack)
> {
>   stack->top--;
> }
>
> This will result in situations where GC would not clean up memory that
> is logically garbage.

No, in java that would clean up just fine.  All objects are /only/ reachable 
by references, and only references get stored in the array.  The memory in 
the objects themselves gets reclaimed by the GC.  The only question is 
precisely /when/ that will happen, which is a non-issue in the vast vast 
majority of apps.


-- 
Framsticks.  3D Artificial Life evolution.  You can see the creatures that
evolve and how they interact, hunt, swim, etc. (Unaffiliated with me).
http://www.frams.alife.pl/

Jussi Jumppanen coughed up:
> Jon Harrop wrote:
>
>> You mean it is easy to assume that your C++ is safe provided
>> you don't actually look.
>
> I find it easy to assume my C++ code is safe, because the bug
> count is low.

Which says nothing about the effort expended to reach the point where the 
bug count is low.  Your arguments are not taking very little into account.


-- 
Framsticks.  3D Artificial Life evolution.  You can see the creatures that
evolve and how they interact, hunt, swim, etc. (Unaffiliated with me).
http://www.frams.alife.pl/

Thomas G. Marshall wrote:
> CTips coughed up:
> 

>>To do garbage collection properly requires, in many cases, as much
>>attention to detail as doing manual memory management. Case in point:
>>consider a stack implemented as follows:
>>
>>void push_fooStack(fooStack * stack, Foo * foo)
>>{
>>  stack->stack[stack->top] = foo;
>>  stack->top++;
>>}
>>
>>void pop_fooStack(fooStack * stack)
>>{
>>  stack->top--;
>>}
>>
>>This will result in situations where GC would not clean up memory that
>>is logically garbage.
> 
> 
> No, in java that would clean up just fine.  All objects are /only/ reachable 
> by references, and only references get stored in the array.  The memory in 
> the objects themselves gets reclaimed by the GC.

See what I mean about GC requiring as much programmer expertise as 
manual memory allocation? Anyone care to explain to the poster the 
potential for memory leakage that he appears to have missed?

CTips coughed up:
> Thomas G. Marshall wrote:
>> CTips coughed up:
>>
>
>>> To do garbage collection properly requires, in many cases, as much
>>> attention to detail as doing manual memory management. Case in point:
>>> consider a stack implemented as follows:
>>>
>>> void push_fooStack(fooStack * stack, Foo * foo)
>>> {
>>>  stack->stack[stack->top] = foo;
>>>  stack->top++;
>>> }
>>>
>>> void pop_fooStack(fooStack * stack)
>>> {
>>>  stack->top--;
>>> }
>>>
>>> This will result in situations where GC would not clean up memory that
>>> is logically garbage.
>>
>>
>> No, in java that would clean up just fine.  All objects are /only/ 
>> reachable
>> by references, and only references get stored in the array.  The memory 
>> in
>> the objects themselves gets reclaimed by the GC.
>
> See what I mean about GC requiring as much programmer expertise as
> manual memory allocation? Anyone care to explain to the poster the
> potential for memory leakage that he appears to have missed?

You're right.  I missed that the pop didn't null out anything.

Actually, I missed the entire thing---I didn't read it at all.  I saw that 
you were passing things by pointers, assumed C/C++, and jumped whole-hog 
into GC being facilitated by reference only access.

My mistake---my apologies.

*However*, you are way off the mark if you think that merely knowing to null 
out references is somehow equivalent to the expertise required for manual 
allocation.


-- 
"His name was Robert Paulson. His name was Robert Paulson. His name was 
Robert
Paulson..."

Thomas G. Marshall wrote:
> CTips coughed up:

> 
> *However*, you are way off the mark if you think that merely knowing to null 
> out references is somehow equivalent to the expertise required for manual 
> allocation.
> 

Again, shows how little you've thought about how GC can be inhibited. 
Here's an example of another case

foo* gah(void)
{
   foo * f = malloc(sizeof(*f));
   fill_in(f);
   return f;
}

void
func()
{
    foo * f = gah();
    bar(f);
}

void
bar(foo * f)
{
   do_short(f);

   do_something_time_and_memory_consuming();
}

Now, when will the object allocated in gah() get garbage collected? 
[assume both fill_in() and do_short() have no side-effects]

Where should references be nulled out so as to allow GC to occur as soon 
as logically possible?

Zara wrote:
> Garbage collection is easily tricked into no collection at all, due to
> circular references: you only have to use Swing to get that problem.

No. An old, rarely used and unreliable form of garbage collection called
"reference counting" suffers from the inability to collect cycles. Modern
garbage collectors are both efficient and reliable.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

CTips wrote:
> adaworks@sbcglobal.net wrote:
>> Garbage collection is not always unsafe.   It can be unsafe for certain
>> classes of real-time, safety-critical, embedded systems.   For most
>> situations, automatic garbage collection is a good thing.
> 
> To do garbage collection properly requires, in many cases, as much
> attention to detail as doing manual memory management.

In imperative languages like Java, maybe. In all languages, definitely not.
For example, garbage collection is basically essential in functional
programming languages.

Consider the Java equivalent of this OCaml function to thread multiplication
by a given integer over a list of integers:

# let f x = List.map (( * ) x);;
val f : int -> int list -> int list = <fun>
# f 3 [1;2;3;4];;
- : int list = [3; 6; 9; 12]

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Jon Harrop wrote:

> CTips wrote:
> 
>>adaworks@sbcglobal.net wrote:
>>
>>>Garbage collection is not always unsafe.   It can be unsafe for certain
>>>classes of real-time, safety-critical, embedded systems.   For most
>>>situations, automatic garbage collection is a good thing.
>>
>>To do garbage collection properly requires, in many cases, as much
>>attention to detail as doing manual memory management.
> 
> 
> In imperative languages like Java, maybe. In all languages, definitely not.
> For example, garbage collection is basically essential in functional
> programming languages.
> 
> Consider the Java equivalent of this OCaml function to thread multiplication
> by a given integer over a list of integers:
> 

> 
And what does this have to do with the stack example? Are you claiming 
that it is not possible to write code that has similar kinds of dangling 
references in OCaml? Or are you claiming that there is a more efficient 
idiom for implementing a known-maximum-size stack in OCaml?

Mutable objects in ML (and, presumably, in OCaml) give rise to the same 
set of head-aches for GC as in Java.

Jon Harrop wrote:

> Zara wrote:
> 
>>Garbage collection is easily tricked into no collection at all, due to
>>circular references: you only have to use Swing to get that problem.
> 
> 
> No. An old, rarely used and unreliable form of garbage collection called
> "reference counting" suffers from the inability to collect cycles. Modern
> garbage collectors are both efficient and reliable.
> 
Except in a multi-processor environment. In which case:
- modern garbage collectors are either not efficient or are not reliable
- reference counting ends up being quite attractive.

CTips wrote:
> Thomas G. Marshall wrote:
> > CTips coughed up:
>
> >
> > *However*, you are way off the mark if you think that merely knowing to null
> > out references is somehow equivalent to the expertise required for manual
> > allocation.
> >
>
> Again, shows how little you've thought about how GC can be inhibited.
> Here's an example of another case
>
> foo* gah(void)
> {
>    foo * f = malloc(sizeof(*f));
>    fill_in(f);
>    return f;
> }
>
> void
> func()
> {
>     foo * f = gah();
>     bar(f);
> }
>
> void
> bar(foo * f)
> {
>    do_short(f);
>
>    do_something_time_and_memory_consuming();
> }
>
> Now, when will the object allocated in gah() get garbage collected?
> [assume both fill_in() and do_short() have no side-effects]
>
> Where should references be nulled out so as to allow GC to occur as soon
> as logically possible?

You're certainly correct that in many languages garbage collection is
difficult to use.  In C you must:-
* Avoid situations like the one in the stack above, also avoiding
similar situations in structs and temporary buffers.
* Avoid loading binary data that looks like a pointer but isn't.
* Avoid ever bringing random stuff of the stack/heap into pointer
locations, pointers must all be nulled out or filled in straight away.

These things are far easier in the languages where GC originated
though, such as lisp.

Rob Thorpe wrote:
>
> These things are far easier in the languages where GC originated
> though, such as lisp.
> 
BS. You get the same situation as shown above when using a 
PROG/PROG*/PROGN (or BLOCK, or any number of equivalent forms).

CTips wrote:
> Rob Thorpe wrote:
> >
> > These things are far easier in the languages where GC originated
> > though, such as lisp.
> >
> BS. You get the same situation as shown above when using a
> PROG/PROG*/PROGN (or BLOCK, or any number of equivalent forms).

I don't quite understand the example you've given above.  Could you
explain how the problem with garbage collection occurs.  As far as I
can see there is a reference to f all the way through the code, so the
initially allocated memory cannot be freed.

Anyway, there are always situations where the GC can be fooled, in any
language, there are simply fewer of them in some languages than others.

I was referring mainly to the other problems though, specifically:-

* Situations like the one in the stack above, also avoiding
similar situations in structs and temporary buffers.

- Stack problem would not occur in idiomatic lisp, since the programmer
would use push and pop.
- Structures and temporary buffers exhibit the same problems as they do
in C, c'est la vie.

* Avoid loading binary data that looks like a pointer but isn't.

- Data in arrays or data structures is not tagged as being a pointer,
so there is no chance of the GC being confused.

* Avoid ever bringing random stuff of the stack/heap into pointer
locations, pointers must all be nulled out or filled in straight away.

- Almost impossible to do in lisp, memory is always initialised.

Similar things can be said for many other new languages and functional
languages.

CTips coughed up:
> Thomas G. Marshall wrote:
>> CTips coughed up:
>
>>
>> *However*, you are way off the mark if you think that merely knowing to 
>> null
>> out references is somehow equivalent to the expertise required for manual
>> allocation.
>>
>
> Again, shows how little you've thought about how GC can be inhibited.

You are apparently arrogant, and enjoy using a derogatory tone.

....[inappropriate example snipped]...

What is all this?  C/C++ examples?  Give me java examples of how garbage 
collection does not work or is difficult (they of course exist, but you're 
not showing them in java).  Or at least re-read the subject line: we're 
contrasting the two languages here, and listing what is in the favor of 
each.

If written in java, your examples would either be difficult to find ways to 
safely null references out, or need to be re-written entirely!

Now there are [java] situations I've been in where the GC had to be 
carefully nudged.  In such cases you make sure that (simply):

        <axiom>
        Your algorithm, even though it might be less
        efficient computationally, is written with the
        GC in mind.
        </axiom>

The point is that java has specific designs /from the very beginning/ to 
allow garbage collection to work.  Most importantly, a lack of arbitrary 
pointers [and] reference-only access to objects.




-- 
"I don't want FOP, God dammit!  I'm a DAPPER DAN MAN!"

Flaran wrote:
> I have a question just for the hell of it... If you had to choose
> between Java and C++, which would you choose? Why and why not?

It totaly depends upon personal taste.
both java and C++ are object oriented. But deal with different fields.
It just like choosing apple or orrange.

Chris Dollin wrote:

> int example()
>     {
>     int values[2] = {17, 42};
>     values[-124] += 1;
>     return values[77];
>     }
>
> int main() { return example(); }
>

Yaaaarghhhhhhhhhhhhh......
Garbage in Garbage Out.......
Computer/Compiler, They belive in Systematic and Sane programs( As they
are very Polite).
They Obey Your orders atleast it is better, or else we people would
have been slaves ;)
> --
> Chris "electric hedgehog" Dollin
> Il Principe - Byzantium - Hansa - Antike - King's Progress
> Farfalia - Mu - Havoc - Tigris & Euphrates [kartenspiel]

Chris Dollin wrote:

> int example()
>     {
>     int values[2] = {17, 42};
>     values[-124] += 1;
>     return values[77];
>     }
>
> int main() { return example(); }
>

Yaaaarghhhhhhhhhhhhh......
Garbage in Garbage Out.......
Computer/Compiler, They belive in Systematic and Sane programs( As they
are very Polite).
They Obey Your orders atleast it is better, or else we people would
have been slaves ;)
> --
> Chris "electric hedgehog" Dollin
> Il Principe - Byzantium - Hansa - Antike - King's Progress
> Farfalia - Mu - Havoc - Tigris & Euphrates [kartenspiel]

Rob Thorpe wrote:
> CTips wrote:
> 
>>Rob Thorpe wrote:
>>
>>>These things are far easier in the languages where GC originated
>>>though, such as lisp.
>>>
>>
>>BS. You get the same situation as shown above when using a
>>PROG/PROG*/PROGN (or BLOCK, or any number of equivalent forms).
> 
> 
> I don't quite understand the example you've given above.  Could you
> explain how the problem with garbage collection occurs.  As far as I
> can see there is a reference to f all the way through the code, so the
> initially allocated memory cannot be freed.

exactly.

> 
> Anyway, there are always situations where the GC can be fooled, in any
> language, there are simply fewer of them in some languages than others.
> 
> I was referring mainly to the other problems though, specifically:-
> 
> * Situations like the one in the stack above, also avoiding
> similar situations in structs and temporary buffers.

there is no way of avoiding this. Also, it occurs very naturally in 
LISP, since its really linked to scope rules.
> - Stack problem would not occur in idiomatic lisp, since the programmer
> would use push and pop.

Depends. If you had any interest in efficiency ... (but then, why use 
LISP if that is a concern)

> - Structures and temporary buffers exhibit the same problems as they do
> in C, c'est la vie.
> 
> * Avoid loading binary data that looks like a pointer but isn't.
> 
> - Data in arrays or data structures is not tagged as being a pointer,
> so there is no chance of the GC being confused.

Agreed. The Boehm style collectors that are needed for untagged 
languages such as C are approximate because of this concern. But the 
problems I'm pointing out are not specific to C.

> * Avoid ever bringing random stuff of the stack/heap into pointer
> locations, pointers must all be nulled out or filled in straight away.
> 
> - Almost impossible to do in lisp, memory is always initialised.
> 
> Similar things can be said for many other new languages and functional
> languages.
> 

Yup. But like I said, I'm not concerned about problems which will occur 
when GC'ing C, but will occur when GC'ing languages like Java, ML and 
LISP. (I haven't thought about what would happen in a pure functional 
language such as Haskell)

CTips wrote:
> Jon Harrop wrote:
>> CTips wrote:
>>>To do garbage collection properly requires, in many cases, as much
>>>attention to detail as doing manual memory management.
>> 
>> In imperative languages like Java, maybe. In all languages, definitely
>> not. For example, garbage collection is basically essential in functional
>> programming languages.
>> 
>> Consider the Java equivalent of this OCaml function to thread
>> multiplication by a given integer over a list of integers:
> 
> And what does this have to do with the stack example?

This has nothing to do with your stack example.

I am pointing out that your statement "To do garbage collection properly
requires, in many cases, as much attention to detail as doing manual memory
management" is incorrect because you failed to take into account the wealth
of functionality that is infeasible with manual memory management (e.g.
first-class lexical closures).

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Thomas G. Marshall wrote:

> CTips coughed up:
> 
>>Thomas G. Marshall wrote:
>>
>>>CTips coughed up:
>>
>>>*However*, you are way off the mark if you think that merely knowing to 
>>>null
>>>out references is somehow equivalent to the expertise required for manual
>>>allocation.
>>>
>>
>>Again, shows how little you've thought about how GC can be inhibited.
> 
> 
> You are apparently arrogant, and enjoy using a derogatory tone.

:) absolutely. Though the word you're looking for is "condescending" - 
anyone who likes talking about subjects about which he knows little 
should be condescended to once in a while. It may help them think about 
a problem before replying next time.

> ...[inappropriate example snipped]...
> 
> What is all this?  C/C++ examples? 

Nope. C-like psuedo code. With malloc thrown in to show explicitly where 
the memory would be allocated.

  Give me java examples of how garbage
> collection does not work or is difficult (they of course exist, but you're 
> not showing them in java). 

If you can't understand the point of the example as written, I suspect 
rewriting it in Java would be of no use.

> Or at least re-read the subject line: we're 
> contrasting the two languages here, and listing what is in the favor of 
> each.

If you're so anal about thread-drift, why didn't *you* change the subject?

> If written in java, your examples would either be difficult to find ways to 
> safely null references out, or need to be re-written entirely!

Go ahead, be my guest. Trapping references because of scope rules and 
parameter passing is an old problem. Try and find a way around it that 
involves adding "ptr = 0;" statements, as you blithely stated in 
previous post.

> Now there are [java] situations I've been in where the GC had to be 
> carefully nudged.  In such cases you make sure that (simply):
> 
>         <axiom>
>         Your algorithm, even though it might be less
>         efficient computationally, is written with the
>         GC in mind.
>         </axiom>
> 
> The point is that java has specific designs /from the very beginning/ to 
> allow garbage collection to work.  Most importantly, a lack of arbitrary 
> pointers [and] reference-only access to objects.

Your statement is java is garbage collectable. Granted. All I said was 
that if you want garbage collection to work effectively, you need to pay 
the same level of attention to your code as you do when you want 
efective manual memory management.

CTips coughed up:
> Thomas G. Marshall wrote:
>
>> CTips coughed up:
>>
>>> Thomas G. Marshall wrote:
>>>
>>>> CTips coughed up:
>>>
>>>> *However*, you are way off the mark if you think that merely knowing to
>>>> null
>>>> out references is somehow equivalent to the expertise required for 
>>>> manual
>>>> allocation.
>>>>
>>>
>>> Again, shows how little you've thought about how GC can be inhibited.
>>
>>
>> You are apparently arrogant, and enjoy using a derogatory tone.
>
> :) absolutely. Though the word you're looking for is "condescending"


You've been given enough latitude on my part.

<PLONK>

Have fun with the folks willing to put up with it.

....[rip]...


-- 
With knowledge comes sorrow.

Jon Harrop wrote:

> CTips wrote:
> 
>>Jon Harrop wrote:
>>
>>>CTips wrote:
>>>
>>>>To do garbage collection properly requires, in many cases, as much
>>>>attention to detail as doing manual memory management.
>>>
>>>In imperative languages like Java, maybe. In all languages, definitely
>>>not. For example, garbage collection is basically essential in functional
>>>programming languages.
>>>
>>>Consider the Java equivalent of this OCaml function to thread
>>>multiplication by a given integer over a list of integers:
>>
>>And what does this have to do with the stack example?
> 
> 
> This has nothing to do with your stack example.
> 
> I am pointing out that your statement "To do garbage collection properly
> requires, in many cases, as much attention to detail as doing manual memory
> management" is incorrect because you failed to take into account the wealth
> of functionality that is infeasible with manual memory management (e.g.
> first-class lexical closures).
> 
Um... and in what way would manual memory management inhibit lexical 
closures? Is there some theoretical reason which you can point to in 
support of that statement?

BTW: what would a closure mean in C? Given the lack of nested functions 
in C, does it really mean anything? For what its worth, I've implemented 
and used both partial argument binding and stack frame cloning in C [+ 
asm] for a couple of projects, so its pretty clear that the mechanics of 
closures are definitely compatible with manual memory management.

Das coughed up:
> Chris Dollin wrote:
>
>> int example()
>>     {
>>     int values[2] = {17, 42};
>>     values[-124] += 1;
>>     return values[77];
>>     }
>>
>> int main() { return example(); }
>>
>
> Yaaaarghhhhhhhhhhhhh......
> Garbage in Garbage Out.......
> Computer/Compiler, They belive in Systematic and Sane programs( As they
> are very Polite).
> They Obey Your orders atleast it is better, or else we people would
> have been slaves ;)

Looking for an acrostic........

YGGOCCTSSAPTOY

nope,

Maybe all of them?

YGIGOCCTBISASPATAVPTOYOA[L]IIBOEWPWHBS

Nope.

Googling on parts of it---Nope.

You lost me.  {shrug}





>> --
>> Chris "electric hedgehog" Dollin
>> Il Principe - Byzantium - Hansa - Antike - King's Progress
>> Farfalia - Mu - Havoc - Tigris & Euphrates [kartenspiel]



-- 
With knowledge comes sorrow.

CTips wrote:
> Rob Thorpe wrote:
> > CTips wrote:
> >
> >>Rob Thorpe wrote:
> >>
> >>>These things are far easier in the languages where GC originated
> >>>though, such as lisp.
> >>>
> >>
> >>BS. You get the same situation as shown above when using a
> >>PROG/PROG*/PROGN (or BLOCK, or any number of equivalent forms).
> >
> >
> > I don't quite understand the example you've given above.  Could you
> > explain how the problem with garbage collection occurs.  As far as I
> > can see there is a reference to f all the way through the code, so the
> > initially allocated memory cannot be freed.
>
> exactly.

I fail to see how this is a problem.  The memory is still visible so it
is not GCed.  The functions may still continue to use f.

What is the problem you're trying to emphasis?

> >
> > Anyway, there are always situations where the GC can be fooled, in any
> > language, there are simply fewer of them in some languages than others.
> >
> > I was referring mainly to the other problems though, specifically:-
> >
> > * Situations like the one in the stack above, also avoiding
> > similar situations in structs and temporary buffers.
>
> there is no way of avoiding this. Also, it occurs very naturally in
> LISP, since its really linked to scope rules.

Which bit of the above to you refer?  The problem with structs and
temporary buffers is fairly universal to programming languages really.
I don't see how scope comes into it, scope in lisp isn't that much
different to other languages anyway.

> > - Stack problem would not occur in idiomatic lisp, since the programmer
> > would use push and pop.
>
> Depends. If you had any interest in efficiency ... (but then, why use
> LISP if that is a concern)

In almost every case where you need stack of some type of data the
obvious thing is to make them into a list.  You might concievably use
an array, but I can't think of a good reason to, I doubt it would be
more efficient.

Modern lisp compilers are pretty good, so you might use lisp even if
efficiency is relevant.

> > - Structures and temporary buffers exhibit the same problems as they do
> > in C, c'est la vie.
> >
> > * Avoid loading binary data that looks like a pointer but isn't.
> >
> > - Data in arrays or data structures is not tagged as being a pointer,
> > so there is no chance of the GC being confused.
>
> Agreed. The Boehm style collectors that are needed for untagged
> languages such as C are approximate because of this concern. But the
> problems I'm pointing out are not specific to C.

Yes.  I just added one that is.

> > * Avoid ever bringing random stuff of the stack/heap into pointer
> > locations, pointers must all be nulled out or filled in straight away.
> >
> > - Almost impossible to do in lisp, memory is always initialised.
> >
> > Similar things can be said for many other new languages and functional
> > languages.
> >
>
> Yup. But like I said, I'm not concerned about problems which will occur
> when GC'ing C, but will occur when GC'ing languages like Java, ML and
> LISP. (I haven't thought about what would happen in a pure functional
> language such as Haskell)

OK.  It's certainly true of every language that uses GC that the
programmer must be aware of it.  The problem is that normal GCs are not
psychic.


PS. I have a friend though who has developed a GC that is.  It does not
begin collecting in the obarray, but rather in his own mind.  When he
activates it  parts of the universe which he do not impinge on him will
cease to exist.  So you should be thankful for this conversation :)

Michael J�rgensen coughed up:
> <adaworks@sbcglobal.net> wrote in message
> news:yNl5f.17428$6e1.2854@newssvr14.news.prodigy.com...
>>
>> "Alan Balmer" <albalmer@att.net> wrote in message
>> news:4qgal1pfc024fset0k61vv0tkp8nr9hrbl@4ax.com...
>>>
>>> C++ doesn't force anyone to write unsafe code, and silly analogies
>>> don't change that.
>>>
>> True. C++ does not force anyone to write unsafe code.  It does, however,
>> make it so much easier to do so.   If you are a practicing C++ 
>> programmer,
>> you realize how easy it is to make errors that are never detected by the
>> compiler.
>
> "much easier"? Which language are you comparing C++ to now? C, Java, or
> something else?
>
> I find C++ compilers much more helpful than C compilers when it comes to
> finding bugs. I migrated from C to C++ four years ago, and it is my
> experience that the compiler catches many *more* errors that previously 
> used
> to be found at runtime.

There are C programmers I've known who use a C subset of C++ compilers for 
this reason.  There are additional things that I've discovered.  One of the 
things (at least this used to be the case back when things were rotten) is 
that enums in C map to integers, but without typechecking.  In C++ they map 
to integers, but maintain the type of the enum.

Don't know if this is still the case in C99, but I remember being dismayed 
that I could, for example, pass the element of one enum as an actual 
parameter whose formal parameter was declared as an enum of a different 
type, since they were all /just/ integers. C++ fixed that.

....[rip]...

-- 
With knowledge comes sorrow.

Jon Harrop coughed up:
> Zara wrote:
>> Garbage collection is easily tricked into no collection at all, due to
>> circular references: you only have to use Swing to get that problem.
>
> No. An old, rarely used and unreliable form of garbage collection called
> "reference counting" suffers from the inability to collect cycles. Modern
> garbage collectors are both efficient and reliable.

When I was first getting in to java, I paid out of pocket for Sun's 
propaganda seminar about java (then in beta).  They were discussing 
reference counting as the technique.

I know that this was quickly abandoned, probably because of circular 
references.  I don't know if RC made its way into 1.0 or not, but I at least 
hope not.

-- 
With knowledge comes sorrow.

Rob Thorpe wrote:
> Which bit of the above to you refer?  The problem with structs and
> temporary buffers is fairly universal to programming languages really.
> I don't see how scope comes into it, scope in lisp isn't that much
> different to other languages anyway.

Not in the presence of closures.

> In almost every case where you need stack of some type of data the
> obvious thing is to make them into a list.  You might concievably use
> an array, but I can't think of a good reason to, I doubt it would be
> more efficient.

Consing can be substantially slower (e.g. in SBCL-compiled Lisp) so an array
is likely to be faster.

> Modern lisp compilers are pretty good, so you might use lisp even if
> efficiency is relevant.

You know my stance on that. ;-)

>> Yup. But like I said, I'm not concerned about problems which will occur
>> when GC'ing C, but will occur when GC'ing languages like Java, ML and
>> LISP. (I haven't thought about what would happen in a pure functional
>> language such as Haskell)
> 
> OK.  It's certainly true of every language that uses GC that the
> programmer must be aware of it.  The problem is that normal GCs are not
> psychic.

Yes. The critical point is that a language with GC does no worse than a
language without. In many cases, languages with GC do a lot better (of
course, that's the whole point of using a GC).

I can't believe someone just stole my pumpkin... :-(

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

CTips wrote:
> Depends. If you had any interest in efficiency ...

If you have an interest in efficiency then you would use the built-in stack
implementation. If you have an interest in robustness then you would use a
list.

If you want a relevant example of OCaml code being vastly more efficient and
simpler than C++ code thanks to garbage collection (amongst other things),
compare the OCaml to the required to implement sets as balanced binary
trees.

> Yup. But like I said, I'm not concerned about problems which will occur
> when GC'ing C, but will occur when GC'ing languages like Java, ML and
> LISP. (I haven't thought about what would happen in a pure functional
> language such as Haskell)

You can hold on to references unnecessarily in any language, including
Haskell. In practice, I have _never_ had a problem with this. The nearest
I've had is caches growing too large and data being regenerated
unnecessarily.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

CTips wrote:
>> I am pointing out that your statement "To do garbage collection properly
>> requires, in many cases, as much attention to detail as doing manual
>> memory management" is incorrect because you failed to take into account
>> the wealth of functionality that is infeasible with manual memory
>> management (e.g. first-class lexical closures).
>
> Um... and in what way would manual memory management inhibit lexical
> closures? Is there some theoretical reason which you can point to in
> support of that statement?

Yes. The reason is simply that the scope of values is not trivially defined
in the presence of closures because they can capture and carry values in
their environment. Some languages provide a poor man's version of closures
often known as "downward closures", e.g. Ada. For more information on this,
look at any discussions of upward and downward closures.

> BTW: what would a closure mean in C? Given the lack of nested functions
> in C, does it really mean anything?

There is no equivalent in C. In C++, you can get some of the functionality
with "function objects" but you have to handle the environment yourself.
This is so tedious and error prone that functional constructs are rarely
used in C++, whereas they are trivial to use in functional languages.

> For what its worth, I've implemented 
> and used both partial argument binding and stack frame cloning in C [+
> asm] for a couple of projects, so its pretty clear that the mechanics of
> closures are definitely compatible with manual memory management.

Sure. I don't dispute that for C, C++, Java, C# etc. but this cannot be
generalised to more advanced languages like Lisp, ML, Haskell and so on.
Try to write my example in C++, for example, noting the fact that the
function is itself curried.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

TIT coughed up:
> Walter Bright sade:
>> "Flaran" <flaran@gmail.com> wrote in message
>> news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
>>
>>> I have a question just for the hell of it... If you had to choose
>>> between Java and C++, which would you choose? Why and why not?
>>
>>
>> I'd choose the D programming language, which is as powerful as C++ but 
>> much
>> easier to program in. It compiles to native code, not a VM.
>>
>> -Walter Bright
>> www.digitalmars.com C, C++, D programming language compilers
>>
>>
>
> The development of D was quite interesting. I remember all those who
> hated every step towards C++, they never wanted the "ugly" features that
> "cluttered" C++ and made it such a "beast", but at the end D adopted a
> lot of the same features; I remember especially the template-debates
> and all the fuss about operator overloading.
>
> Despite the facts that the stand-alone letter D is an ugly symbol
> for a programming language from a synesthetic perspective and that
> I perceive you as a *bit* bias in your simple comparison above:
>
> C++ beats D anyday! Why? Because I'm a beastmaster!
>
> =)
>
> Seriously, D added little value too an already overcrowded scene.
> Perhaps versioning and the unit testing are the more positive things
> added, but otherwise nothing really interesting and conceptually
> new was incorporated.
>
> As most programming langauges D has found its public, I myself
> will never touch it as it lacks the beauty of C++. But I would
> choose it over, say, Euphoria. And even though I hate Java, I
> would choose it over D.
>
> And to the OP, it doesn't matter which language you choose,
> they will both work if you learn them (even D will),
>
> but for the love of god, don't choose Euphoria!

but for the love of God, don't choose Perl.  ;)  I'll shout this one from 
the rooftops now.  Back in ten minutes.

-- 
With knowledge comes sorrow.

TIT coughed up:
> Walter Bright sade:
>> "Flaran" <flaran@gmail.com> wrote in message
>> news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
>>
>>> I have a question just for the hell of it... If you had to choose
>>> between Java and C++, which would you choose? Why and why not?
>>
>>
>> I'd choose the D programming language, which is as powerful as C++ but 
>> much
>> easier to program in. It compiles to native code, not a VM.
>>
>> -Walter Bright
>> www.digitalmars.com C, C++, D programming language compilers
>>
>>
>
> The development of D was quite interesting. I remember all those who
> hated every step towards C++, they never wanted the "ugly" features that
> "cluttered" C++ and made it such a "beast", but at the end D adopted a
> lot of the same features; I remember especially the template-debates
> and all the fuss about operator overloading.
>
> Despite the facts that the stand-alone letter D is an ugly symbol
> for a programming language from a synesthetic perspective and that
> I perceive you as a *bit* bias in your simple comparison above:
>
> C++ beats D anyday! Why? Because I'm a beastmaster!
>
> =)
>
> Seriously, D added little value too an already overcrowded scene.

{Chuckle}  Well there's always E:

http://erights.org/elang/index.html

And F:

http://www.fortran.com/F/

{sigh} and G:

http://en.wikipedia.org/wiki/G_programming_language

Wait a minute!  Is there a pattern here?????

No H, but alas, there *are* a couple of Z's....



-- 
With knowledge comes sorrow.

CTips wrote:
> Jon Harrop wrote:
>> Zara wrote:
>>>Garbage collection is easily tricked into no collection at all, due to
>>>circular references: you only have to use Swing to get that problem.
>> 
>> No. An old, rarely used and unreliable form of garbage collection called
>> "reference counting" suffers from the inability to collect cycles. Modern
>> garbage collectors are both efficient and reliable.
>
> Except in a multi-processor environment. In which case:
> - modern garbage collectors are either not efficient or are not reliable
> - reference counting ends up being quite attractive.

Reference counting's inability to collect cycles makes it unsuitable for
general purpose programming languages as the obvious representation of
graphs will leak memory.

Java is likely to be good for multi-processor environments requiring
concurrent garbage collection:

  http://research.sun.com/techrep/2000/abstract-88.html

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Rob Thorpe wrote:
> CTips wrote:
>> Rob Thorpe wrote:
>> > These things are far easier in the languages where GC originated
>> > though, such as lisp.
>>
>> BS. You get the same situation as shown above when using a
>> PROG/PROG*/PROGN (or BLOCK, or any number of equivalent forms).
> 
> I don't quite understand the example you've given above.  Could you
> explain how the problem with garbage collection occurs.

CTips is saying that you can accidentally keep hold of unnecessary
references, resulting in a form of "memory leak" even though you're using
garbage collection. This is entirely true.

However, it does not substantiate his claim that "To do garbage collection
properly requires, in many cases, as much attention to detail as doing
manual memory management", which is not true in general. Specifically, it
is debateably true in the context of Java but is well known that this is
not the case in the context of FPLs.

> Similar things can be said for many other new languages and functional
> languages.

Lisp and ML both predate Java, IIRC.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Thomas G. Marshall wrote:

> And F:
>
> http://www.fortran.com/F/
>
> {sigh} and G:

This vigilant, self-appointed Defender of Fortran :) wonders why you
"sigh". F is a well-designed subset of modern Fortran. I used it for
about a year and liked it. Later I went beyond the F subset, but I
think it is a good procedural teaching language in the spirit of
Pascal, with the bonus of being a subset of a "production" language.

adaworks@sbcglobal.net coughed up:
> "Jussi Jumppanen" <jussij@zeusedit.com> wrote in message
> news:4354FBB0.5114@zeusedit.com...
>>>
>> For example the Ariane space craft was written in the
>> safest language of them all, ADA. But this did not stop
>> it form literally crashing :)
>>
> Certainly one can write stupid software in any language.  However,
> Ada is much safer than C++.   The error, in Ariane V reused perfectly
> good software from Ariane IV.  On Ariane IV the software performed
> exactly as it should have.  The engineers failed to take into 
> consideration
> that the performance characteristics of Ariane V were different.  They
> went ahead and reused software they had not verified for the new
> rocket design.  Now that was a stupid mistake in requirements engineering,
> not in language choice.
>
> Consider that your doctor, before prescribing a perfectly good medicine
> fails to evaluate you for allergies for that medicine.   You die.  Was it
> the fault of the otherwise benign medicine of the the fault of the 
> physician
> who didn't do his job right?   Penicillin saves lives.  It also kills 
> people
> who are allergic to it.
>
> On the other hand, C++ is so full of gotchas, so error-prone that one 
> could
> not classify it as safe.   A program that compiles, in C++, might go 
> execute
> after deployment for a long time before a surprising error manifests 
> itself.
> In Ada there is a strong model of error checking, early in the development
> process, and the compiler is an aid in this process.
>
> Ariane V did not crash because of Ada, but in spite of it.  If it had been
> programmed in C++, under the same stupid engineering model, it would
> have crashed.   On the other hand, I can easily envison it crashing on
> some other occasion because of C++, not in spite of it.
>
> The more time I spend with C++, the more amazed I am that anyone
> would use it for any kind of software where dependability is important.
>
> Richard Riehle


Just looking through the examples given in BS or Lippman, and I get shivers 
down my spine in sympathy to the poor wretch at 3 am trying to find the race 
condition that only manifests itself after a minimum of 6 hours running and 
is buried deep in an oddly written destructor obscured by some operator 
overloading, such as + and = but += being forgotten.


-- 
Doesn't /anyone/ know where I can find a credit card company that emails me
the minute something is charged to my account?

Otto Wyss coughed up:
> Ufit <kot_tmp0SPAMSPAM@NOpoczta.fm> wrote:
>
>> "Flaran" <flaran@gmail.com> wrote in message
>> news:1129581584.744842.215830@g44g2000cwa.googlegroups.com...
>>> I have a question just for the hell of it... If you had to choose
>>> between Java and C++, which would you choose? Why and why not?
>>>
>> C++ - for applications, Java - for web stuff.
>>
> C++ for applications, PHP for web stuff ;-)
>
> O. Wyss

java or c# for applications.  java or c# for web stuff.  java if you happen 
to not be on a windows pc.


-- 
Doesn't /anyone/ know where I can find a credit card company that emails me
the minute something is charged to my account?

beliavsky@aol.com coughed up:
> Thomas G. Marshall wrote:
>
>> And F:
>>
>> http://www.fortran.com/F/
>>
>> {sigh} and G:
>
> This vigilant, self-appointed Defender of Fortran :) wonders why you
> "sigh". F is a well-designed subset of modern Fortran. I used it for
> about a year and liked it. Later I went beyond the F subset, but I
> think it is a good procedural teaching language in the spirit of
> Pascal, with the bonus of being a subset of a "production" language.


That {sigh} modifies the G not the F, so grab a beer and chill. ;)

And after all that has been said about fortran lately, I'm beginning to 
wonder if it wouldn't be better served by adopting a new name altogether. 
There is a kneejerk reaction to it, much like that toward Cobol, which is 
probably historically deserved (maybe?) but not any longer.  {long shrug 
with palms up}

I honestly don't know why such predudices exist when the dislike is for no 
voiced reason.


-- 
Doesn't /anyone/ know where I can find a credit card company that emails me
the minute something is charged to my account?

Kai-Uwe Bux coughed up:

....[rip]

> But I agree that C++ makes it about as easy to something silly as to do
> something right. Unfortunately, to some people the silly way looks always
> more natural.

Or more fun.

Let's not forget the engineers (who do exist in droves) that code in 
esoteric ways in order to show to others that they can.  It is all to common 
a phenomenon.


-- 
Doesn't /anyone/ know where I can find a credit card company that emails me
the minute something is charged to my account?

Thomas G. Marshall wrote:
> I honestly don't know why such predudices exist when the dislike is for no
> voiced reason.

The dislike is for plenty of voiced reason - Fortran is still taught by
physicists to physicists because they don't know any better.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com

Rob Thorpe wrote:
> CTips wrote:
> 
>>Rob Thorpe wrote:
>>
>>>CTips wrote:
>>>
>>>
>>>>Rob Thorpe wrote:
>>>>
>>>>
>>>>>These things are far easier in the languages where GC originated
>>>>>though, such as lisp.
>>>>>
>>>>
>>>>BS. You get the same situation as shown above when using a
>>>>PROG/PROG*/PROGN (or BLOCK, or any number of equivalent forms).
>>>
>>>
>>>I don't quite understand the example you've given above.  Could you
>>>explain how the problem with garbage collection occurs.  As far as I
>>>can see there is a reference to f all the way through the code, so the
>>>initially allocated memory cannot be freed.
>>
>>exactly.
> 
> 
> I fail to see how this is a problem.  The memory is still visible so it
> is not GCed.  The functions may still continue to use f.
> 

Lets look at it again; forgive me if my syntax is a little off, its been 
about a decade since I wrote my last major LISP app.

Consider:

(let
    ((f fill-in))
    (do-it f))

(defun do-it (f)
    (let
      ((x do-something f))
      (do-something-very-expensive-not-using-f x)))

In both cases, the scope of f is to the end of the let in which it is 
defined. Conceptually, f will be a reference to the object returned by 
(fill-in) till the let is exited.

The actual lifetime of that object, however, is only till some point 
inside the function do-something. After that point its last use has 
occured and (the object referred to by) f can be reclaimed.

There is a disconnect between the last use and the expiry of the last 
reference to the object. GC can only kick in when the last reference has 
gone away. Manual reclaimation can occur as soon as the last use has 
occured.

Nulling pointers (in an imperative language) is an attempt to move the 
last reference closer to the last use. However, as the example above 
illustrates, it may be impossible to accomplish this.

Jon Harrop wrote:

> Thomas G. Marshall wrote:
> 
>>I honestly don't know why such predudices exist when the dislike is for no
>>voiced reason.
> 
> 
> The dislike is for plenty of voiced reason - Fortran is still taught by
> physicists to physicists because they don't know any better.
> 

Unfortunately, there is a very good reason to use FORTRAN - the 
compilers for numerical applications are way better, particularily in 
multi-processor environments. This is partly because of the attention 
paid to optimizations for numerical apps by FORTRAN compiler writers, 
and partly because of the language.

I haven't revisited the problem in several years, but when I last looked 
at it, for equivalent numerical programs in C & FORTRAN, the FORTRAN 
programs performed much better than the C programs. Enough so that I 
wound up recommending the use of FORTRAN over C for a physical chemistry 
app I was helping someone write.

Jon Harrop wrote:


> Try to write my example in C++, for example, noting the fact that the
> function is itself curried.

Which example? Is there a link to it?

If its just a matter of currying a function, that's kind of trivial in a 
C-like language. Even in de-facto C (*NOT* ANSI compliant, or 
type-safe), I can define:

   curried_func * f0 = curry(fn, 3); /* setup curried object; fn has 3 
arguments */
   f1 = curry_arg(f0, arg0);
   f2 = curry_arg(f1, arg1);

   /* all of the following are equivalent */
   fn(arg0, arg1, arg2);
   call_curried(f0, arg0, arg1, arg2);
   call_curried(f1, arg1, arg2);
   call_curried(f2, arg2);

If such an ability were important, one could easily extend C to support 
currying. It helps that C only has call-by-value, so there is no issues 
about the meaning of a curried call-by-reference argument.

Jon Harrop wrote:

> CTips wrote:
> 
>>>I am pointing out that your statement "To do garbage collection properly
>>>requires, in many cases, as much attention to detail as doing manual
>>>memory management" is incorrect because you failed to take into account
>>>the wealth of functionality that is infeasible with manual memory
>>>management (e.g. first-class lexical closures).
>>
>>Um... and in what way would manual memory management inhibit lexical
>>closures? Is there some theoretical reason which you can point to in
>>support of that statement?
> 
> 
> Yes. The reason is simply that the scope of values is not trivially defined
> in the presence of closures because they can capture and carry values in
> their environment. Some languages provide a poor man's version of closures
> often known as "downward closures", e.g. Ada. For more information on this,
> look at any discussions of upward and downward closures.
> 

I still don't see why GC is required to implement closures. If you have 
an object whose life-time must be the >= the life-time of the closure 
that captures it, then that just means that it can not be freed till 
after the last use of the closure. Thats a matter of book-keeping, not 
something deep.

Can you come up with a simple example of some closure whose 
implementation *REQUIRES* GC?