Fog Creek Software
Discussion Board

memory management

The diff between the productivity in C++ versus VB was not memory management paradigm but API:  the VB programmer didn't have to belabor with the details of Win32.  Sure part of Win32's complexity is memory management, but fundamentally Win32 is a huge API that is abstracted for the VB programmer (who loses some flexibility ... but usually he or she doesn't care).  Look at how much harder it is to write Hello World (or Notepad) in C++ Win32 than VB6.

In general I find claims that manual memory management in C++ was the source of "a lot" of bugs or heartache are exagerrated ... probably mostly by Java and .NET evangelists.  Auto memory management is a good thing in most scenarios, but if you really want me to be productive make sure I have (a) good tools, and (b) good libraries.

I agree with rest of article though, he digs pretty deep.

Thursday, June 17, 2004

You are right.

On Windows, C++ had the Win32 API and the MFC framework.

Visual Basic had the extremely powerful component orientation.

THIS is what made the difference.

Thursday, June 17, 2004

Try working with COM from within C++ and then from within C# or VB. You'll know the difference.

Green Pajamas
Thursday, June 17, 2004

I really don't understand the problem with API complexity (but perhaps that's because I don't really understand the problem with API complexity...). Sure some aspects of the Win32 API are complex and hard to fathom but you only have to work it out once and then you're done. You write some code that makes it easier to use and put that code in a library and use that in future. By doing this you get to understand the problem to a level that's lower than you'd probably choose to, but at least you do understand it.

If you only need part of the API (such as just needing the SChannel aspects of SSPI) then you write wrappers that let you do that easily and ignore the bits (like Kerberos auth) that you don't much care for. If you then need to use another part of that API you can either extend your wrappers or write new, focussed, classes for the new bits you need. If you find that your wrappers are at too high a level for a particular problem you can revisit them, refresh your understanding and then decide at how to craft the abstraction that you need for this version of the problem...

The key point is that you take this hit just the once, generally. From then on you have code that you've adjusted to how your mind deals with that particular problem; you have tests and whatever level of docs you feel comfortable with... If you need to go deeper you can, you don't have someone else's abstraction as the only way to do things...

OK, so the guy's in VB-land or .Net-city don't ever need to do this (except when they do because they need something that the people who wrote their runtime didn't expect them to need and they have to delve into the raw API to achieve it...). Personally, I'd rather be used to doing this stuff, and know that I'm capable of doing it rather than work at someone else's level of abstraction and then suddenly find that they don't cut the mustard and realise that it's hard to get up to speed on the lower level stuff just so that I can work out how to get the last 5% of functionality that I need to finish my app by tomorrow...

It's not as though you write C++ production code like those MSDN samples and do everything the hard way using bare API calls and have to copy the same 4 or 5 lines time and time again every time you want to access GetFileVersionInfo()... Oh, you do? Well that's your problem then, not the complexity of the API, just that you're failing to add value...

Hmm, turned into a bit of a rant; decided to rant more in private....

Len Holgate (
Thursday, June 17, 2004

You're a more capable programmer if you can manage the details at the low level, but you're also working harder than your VB counterpart when it comes to addressing more common business requirements.  Because no amount of wrappers and layers and "code re-use" in unmanaged C++ is going to make doing the straightforward business stuff as efficient as can be done in a higher level environment like .NET.

Thursday, June 17, 2004

But then .net is not high enough. If you deal with mouse
clicks or window styles in your business code, then even
.net is not giving you abstraction needed for fast creation of
end-user solutions.

In the end it's just personal taste for how much do you
want  to spend creating your own layers and how much
control you need. As long as MS gives us options to do
whatever we like I see no problem with .net or HTML.

I'll be in trouble when Petzold style books go out of print or
MS stops supporting good old C or if they throw out Win32
from MSDN. Everything else is acceptable.

But on the other side, if I was starting today my first Hallo
World ever, I don't think that I would have chosen C. You
really need to put a lot of work into fundamental stuff just
to be able to show a simple window and some editable

And a question for Len Holgate.

I am like you when I look at MSDN examples or Petzold
style code looking at these as just examples. Then I
use bits from there and turn them into easy to use library.
This is something that you start doing after a lot of practice
and few bad designed spaghetti programs.

But I have never seen a single book that guides you there.
It's when I look at VB code or C# code in similar books
that scares me away. Maybe there are people who write
elegant and easy to use VB/C#/Java libraries and we are
missing that part of the game.

Thursday, June 17, 2004

"Wrapper layers" is the whole point of the .NET Framework (not the CLR, but the Framework class libraries).  And its predecessors as well (VB6 et al).  They've provided wrappers around the most common Win32 API use cases so that you don't have to write them yourself.

In some cases, the wrappers suck (the ASP.NET CDONTS email wrapper comes to mind), but in such situations, the underlying API is still there, and you're perfectly free to go off and create your own spiffy new wrapper if you like.

Whether or not you choose to learn the API or just get by with what you're given is another subject completely.  Some people actually code for a paycheck, and their employer finds it more cost effective to buy a 3rd party component than let their programmers fiddle with the Win32 API for 3 days.  Nothing wrong with that.

Seems like there's an awful lot of low-level language snobbery on this board today...

Thursday, June 17, 2004

Brad - agree that there's a time and a place for higher level code and that many of the problems that need solving in the enterprise are best done using .Net or Java or whatever. As Joel has said before, the problem comes along when the abstraction leaks (or simply fails to provide services that you need and that you know are there in the underlying API).

VPC - I wouldn't recommend new programmers who're going to work on 'business' apps to learn C either; learn C#, most of my big clients are moving that way (albeit slowly). Agree 100% with 'as long as we have the choice'... Re the 'where are the books' comment, I don't know. I don't think they exist. It seems that perhaps the only way to learn this stuff is to make the mistakes and then realise that there's a better way... :(

Joe - 'some people actually code for a paycheck'  I'm sure a lot of people do, I know I do. I also know that you often can't solve all your problems with one toolset. .Net is great for some stuff, really really great; but not for everything. Until it's great for everything, some clients will need people who know the old way. Knowing which approach to select is often the hard bit as it may not be obvious that the higher level route will only get you 95% of the way there and leave you with 5% of really hard stuff...

I don't think it necessarilly "low level language" snobbery; it may come across like that, but, from my point of view it's just that I've been there and done that and worked around the resulting problems... Also, because I've built up a pile of wrappers and library code over the years I find that often these 'more productive' languages aren't actually that much more productive than using 'my own runtime'...

My point was that the fact that the underlying API might be complicated is not as big a problem as Joel makes out; you solve that problem once - or you google for code that has already been written to solve that problem. Sure .Net solves lots of these problems very nicely for a certain subset of development projects but it doesn't fit for all of them, at the moment. Until it does; until we see MS Office .Net (100% managed) and IIS.Net (100% managed) I don't think it will because at present MS appear to be focusing on the standard 'business app' in 'the enterprise'. Whilst there are apps other than 'business apps' to write there will be a place for lower level coders and a place and a need for the underlying APIs.

As Joel says, for a lot of these business apps a thin web client is good, or .Net is good; but I'm not going to be telling my clients that they should rewrite all of their high performance real-time trading code in C# just yet; as much as some of their staff may want to because getting C# on the CV is cool...

Len Holgate (
Friday, June 18, 2004

*  Recent Topics

*  Fog Creek Home