benlast ([info]benlast) wrote,
@ 2004-07-29 09:01:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Current mood: cheerful
Current music:9 Beet Stretch

I Counted Them All Back In...
A while ago I mused on programming languages (as programmers are wont to do), and concluded that the best thing about languages like Python (and, I now admit, Java) is the freedom from all the hideous memory management that Some Other Languages have to do.

Raymond Chen's blog has an interesting example of querying information from an Explorer window.  Interesting not for the way in which it introspects down through the multiple-interface objectery[1] of Windows to get at the data, but because it exemplifies, for me, the reasons I dislike C++, and Windows C++, so much.

Take a look (should you feel like it) at his final example (at the end of that page).  He excuses the ugliness by saying "because I put everything into one huge function instead of breaking them out into subfunctions", and indeed, this is partly an excuse.  But look at the actual code; that ever-deepening cascase of nested ifs matched by the sudden flurry of CoTaskMemFree and Release calls.  I have to wonder how much simpler this would be in a dynamic language, with grown-up memory management.  But, as Raymond often points out, that's legacy for ya.

The syntax of C++ also grates, after a good couple of years now with the simpler, more streamlined Python; stuff like if (SUCCEEDED(pwba->QueryInterface(IID_IServiceProvider, (void**)&psp))) just... looks ugly (though I can still read it perfectly well), but I think it's the sheer effort required to do anything via COM and the Windows API that I remember - the slow trudge through looking up IIDs, playing with QueryInterface and trying to work out who owned what.  It was a lot of work for what was often very little effect and I don't miss it at all.

But then I'm a curmudgeonly old Hector at the best of times...

[1] I don't know if this is a real word, but it should be, shouldn't it?  Like an orangery is to oranges.


(6 comments) - (Post a new comment)


[info]grimmtooth
2004-07-29 06:54 am UTC (link)
Oddly enough, I'm a bit of a "curmudgeonly old Hector" most of the time when it comes to coding, and I don't have much to say against C/C++ when it comes to memory management. In many ways I view the newer languages with thier spiffy memory management and garbage collection as a bit ... suspect because it's virtually impossible to prove that it works without soaking an app on a PC for days or weeks.

Also, 'modern' OS virtual memory tends to obfuscate actual memory consumption to a certain extent, making it even more iffy when evaluating a long-running app (such as a server) for memory leaks.

But, as with other languages, you either accept it or you don't. It certainly isn't enough of an issue to turn me away from Python. At least, not until my first critical app blows up on a memory issue :-)

(Reply to this) (Thread)

[info]benlast
2004-07-29 07:19 am UTC (link)
I preferred the previous photo, Grimmtooth!

Interesting point; I'd rather have all my memory management in one place (ie, the interpreter and/or GC) which is used in systems all over the world than have it scattered through my code in lots of little explicit allocate/release calls :) I think the chances of me getting a couple of those wrong are a lot higher than there being a major memory snafu in Python...

I should really have explained "curmudgeonly old Hector" for non-Brits...

regards
b

(Reply to this) (Parent)(Thread)
Hector
[info]benlast
2004-07-29 07:23 am UTC (link)
http://www.davethewave.co.uk/hector/hector.htm

(Reply to this) (Parent)

[info]grimmtooth
2004-07-29 09:32 am UTC (link)
Which photo, this one? :-)

I don't deny the convenience, only that things hidden away tend to erode my confidence a bit.

This also plays into my ego-stroking notion that "coding is no place for wimps" :-)

Incidentally, I don't think the odds of there being a memory snafu in Python are as long as you might think. I could be wrong, but it seems to me that just about every maintenance rev includes fixes for memory leaks. So, if memory leaks are an inevitability (and odds are they are), havine one centralized place for them to occur on every bit of code that hits that 'sweet spot' can be devastating.

Fortunately, thier unit testing catches the really nasty ones before we ever see them.

Having said all that,and to your main point, I can recall discussions at Amiga DevCons back in they day when they were deciding on the best path forward for AmigaOS memory management. There were two camps: one that said it was just a bad idea, that it would slow down the system, and another than felt it was a good idea. Then there were camps in camps, mine being that if memory management were to be done, it should be done automatically and at the OS level, not at the app level, mostly because it could be darn near foolproof if done right.

So if Python falls into the category of an 'os' to the interpreted code, then the exe is the right place for it. But if Python is an app, as I view it, it will probably never achieve the bulletproof level that I should be required.

I suspect it depends on which side of that fence you fall as to how your view is shaded.

(Reply to this) (Parent)
Baked in memory management is not a panacea
(Anonymous)
2004-07-29 11:01 am UTC (link)
We just today found an issue in one of our products because of baked in memory management and garbage collection. It turns out that a resource was being held because the garbage collector was taking its time in cleaning stuff up. We had to force a garbage collection to get everything properly taken care of because there is no way to explicitly destroy the objects we are using.

Granted this is on .NET and not Python, Java, etc. using COM interop to some legacy COM objects we have, but the point is that relying on garbage collection can be troublesome if you're not careful.

Also, the problems pointed out in the entry are as much or more due to Windows and COM vs. C++. C++ seems to get a worse rap than it deserves because MFC, COM and the Windows API is most people's exposure to a large collection of C++ classes and interfaces and it is not very well done.

In the general case I do not consider C++ memory management hideous and I think properly utilized is superior to most other management schemes, given that the constructor is called once an object goes out of scope. Unless you are writing low level objects, most C++ needn't have very many instances of memory management, if any at all. The fact that the Windows API and COM make this much more difficult than it needs to be is not C++'s fault.

Also, as noted in the article you reference with the code, the various objects and interfaces were designed for use from 'a scripting language like JScript or Visual Basic'. I don't think C++ is necessarily the best tool for this particular job.

And all this being said, when possible I reach for Python.

(Reply to this) (Parent)
Is it in adderss that he improves?
(Anonymous)
2007-01-11 11:34 am UTC (link)
Hi all!


Bye

(Reply to this)

(6 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…