> Anyhow, I see no reason to continue to argue with a
> fictional character lacking a basic grasp of memory
> management.

It was a quick sample put together in about 5 seconds. Alas, I wasn't the one initially deleting memory I didn't allocate in the first place, which I would say also shows somebody lacking of a basic grasp of memory management. Or perhaps I can use your convenient handwaving you use here?

>Indeed, why are you deleting something you didn't >create?

>Perhaps an unusual creational pattern (factory or >something) is used. Its rather beyond the scope of the >example though - let us say that this class's role is as >an adopter of its constructor argument.

I know memcpy is evil. I also know that a 5 second example hastily thrown together (in 6 seconds it probably would have read sizeof((*c)) or something equally horrible) to prove a point is not terribly indicative of anything, as you ably demonstrated with your initial example and the further need to rationalize it above. The point being that you need to allocate something before deallocating it.

I don't see a reason to be unduly harsh, but hey, whatever floats your boat. I guess I should be happy that I gave you a better code snippet to prove your point than you put together?

I've had no experience with smalltalk, so I can't comment on how it works with copy issues, but I know Python, a dynamically typed language, has some issues that are specifically addressed by the copy module

http://www.python.org/doc/current/lib/module-copy.html

with objects containing objects and reference semantics.

Have a good one, Todd. Sorry to have wasted your time.

> Indeed, why are you deleting something you didn't create?
> Is this an example of how to create a "dumb pointer"
> r" object in C++?
>
> Also, Merry, why would you use memcpy() in C++ instead of
> a copy contstructor?

Reflex. I've been going through a lot of C lately and I didn't give this a whole lot of thought. It should probably be more like

_c = new Something(c);

So yeah, I'm guilty as charged about having a C background and occasionally bring some of that over to C++. I occasionally use () around the condition in if statements in Python, too. More baggage from one language to another that isn't needed.

I regularly work in 4 different languages and my mind occasionally gets a little muddled.

That doesn't change the fact that generally speaking deleting memory you did not allocate, like in this example, is not a good practice. Personally, I think it's rather appropriate that a fictional character argue about a fictional code sample.

[snip]

> > The paper is in my read list so I can't comment on it.
> But
> > after skimming through the examples and the conclusions
> it
> > seems that the authors have some bias toward C++, as
> they
> > try use the C++ solution to the problem to every other
> > language.
>
> Fair language comparisons are very hard - that's why I
> don't do them - but clearly authors and the OOPSLA program
> committee didn't think the paper was sloppy.

Just to clarify I don't think the paper is sloppy. AFAICS it's pretty good. But I still think the authors are trying to code a C++ solution in languages other than C++, not trying to solve a problem.

> > IMHO it would be better to present a problem to
> different
> > groups using different languages and see they
> implementing
> > it.> ...
> >
> > An interesting fact is that the tenth program was
> written
> > by a newly hired college graduate with no experience in
> > Haskell, other than a previous ten-day self study of
> the
> > Haskell Report.
>
> It is nice to see someone trying to get experimental data.
> It's very hard to consider all factors, though.

Yes. The authors acknowledge this, saying the experiment doesn't prove anything. But still is quite amusing :)

> > We could also use the sources for each ICFP available,
> as
> > several different languages are used to solve the same
> > problem, each using a different design.
> >
>
> That reminds me: From ICFP Programming Contest 2003 rules:
> "The contest offers direct, head-to-head comparison of
> language technology and programming skill. We have a range
> of prizes for the winners: cash awards, books, invitations
> to the conference for students, and, of course, unlimited
> bragging rights. The prizes will be awarded at ICFP 2003
> in Uppsala this August."
>
> The results are here:
>
> http://www.dtek.chalmers.se/groups/icfpcontest/results.html

I was part of a team trying to compete in ICFP 2003, so I knew about the winning entry. AFAIK C++ didn't give a competitive edge to the winner, the algorithm did (and it could be written in any language). Also if the author didn't have access to 16 dual processor machines he could never use this tactic, so I don't think it is a valid argument for C++ (or any language this year). Seeing the results of the other years we can see a pattern of winning entries. It's usually of smart hackers using FPLs, so either FPLs give them an edge or FPLs attracts smart people ;)


> -- Bjarne Stroustrup: http://www.research.att.com/~bs

>
> I was part of a team trying to compete in ICFP 2003, so I
> knew about the winning entry. AFAIK C++ didn't give a
> competitive edge to the winner, the algorithm did (and it
> could be written in any language). Also if the author
> didn't have access to 16 dual processor machines he could
> never use this tactic, so I don't think it is a valid
> argument for C++ (or any language this year). Seeing the
> results of the other years we can see a pattern of winning
> entries. It's usually of smart hackers using FPLs, so
> either FPLs give them an edge or FPLs attracts smart
> people ;)

Actually, I was surprised that *any* C++ programmers would enter that forum. Most would never have heard of it. Maybe the offer of "unlimited bragging rights" attracted attention beyond the usual functional programming community.

I have noticed a pattern: When C++ programs succeed it's very often credited to "other factors" or it is even claimed that the success was "despite the use of C++". On the other hand, a failure is attributed to C++ without any possibility of excuses.

Unfortunately, I can't say I'm surprised, and the effect can be observed for any successful language. However, C++ is so prominent that the effect is embarrasingly (for the professional software community) common and obvious.

For a sampling of successful C++ projects, see http://www.research.att.com/~bs/applications.html . I have actually heard the claim, that these were *all* lucky accidents, but I find that a bit hard to believe.

-- Bjarne Stroustrup: http://www.research.att.com/~bs

That reminds me: From ICFP Programming Contest 2003 rules:
"The contest offers direct, head-to-head comparison of
language technology and programming skill. We have a range
of prizes for the winners: cash awards, books, invitations
to the conference for students, and, of course, unlimited
bragging rights. The prizes will be awarded at ICFP 2003
in Uppsala this August."

The results are here:

http://www.dtek.chalmers.se/groups/icfpcontest/results.html

Interesting. You need a whole team of programmers to solve that problem? With better programming models you can get kids to do it in an afternoon:

http://www.squeakland.org/school/drive_a_car/html/Drivecar12.html

Of course, looking at the rules, the squeak etoys programming model is much too alien to fit into the problem description as given.

"designers should give people enough rope to shoot themselves in the foot"

I'd argue that there are tools better suited for shooting in the foot than rope :-)