Become a fan of Slashdot on Facebook


Forgot your password?
Programming IT Technology

Memory Checker Tools For C++? 398

An anonymous reader writes "These newfangled memory-managed languages like Java and C# leave an old C++ dev like me feeling like I am missing the love. Are there any good C++ tools out there that do really good memory validation and heap checking? I have used BoundsChecker but I was looking for something a little faster. For my problem I happen to need something that will work on Windows XP 64. It's a legacy app so I can't just use Boosts' uber nifty shared_ptr. Thanks for any ideas."
This discussion has been archived. No new comments can be posted.

Memory Checker Tools For C++?

Comments Filter:
  • um (Score:5, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @05:45AM (#19408479)
    boost::shared_ptr is not a memory checker, it's a reference-counted smart pointer, and works fine in legacy apps (such as compiled under VC++ 6).
  • Re:two points (Score:5, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @05:52AM (#19408509)
    Boehm's garbage collector is used in Inkscape -- and they did gradually introduce its use, so you can start using it for some things and gradually extend the usage.

  • valgrind, libgc (Score:2, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @05:53AM (#19408517)
    Use valgrind. It's for Linux only, but what it does is invaluable for most of the tasks. I don't know of any other tool of such help.

    Note this is not 'memory management tool', but one to help you find and clean up the memory leaks. There is no way to do proper garbage collection using the STL's allocators, though there is a 'gc' library [] which tends to do the job. Haven't used it, though projects like Mono [] use it extensively.
  • Purify (Score:2, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @05:54AM (#19408525)
    Purify works quite well. It is big and slow, and doens't play nicely with ACE_Tao stuff sometimes (tao do cleaver things that scare s purify sometimes)
  • valgrind and gc.h (Score:1, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @05:57AM (#19408535)
    Use valgrind to find the bugs and Hans Boehm's GC to not have to fix them.

    If you didn't already know of such tools then go do some research; what you want probably already exists.

  • STLPort (Score:4, Informative)

    by kazade84 ( 1078337 ) on Wednesday June 06, 2007 @05:58AM (#19408541)
    I know this isn't exactly what the article is looking for. But, if you are using the STL (which you SHOULD be!) you may be interested to know that the STLPort [] STL implementation includes a debug mode which contains loads of error checking to make sure you aren't misusing STL.
  • Re:two points (Score:4, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @06:02AM (#19408567)
    gcc 4.2 includes a good part of tr1 as was released (late) a few weeks ago.

    shared_ptr is a blessing and a curse. It saves you from manually destructing objects held in a collecton (good) but too many developers use it for lifetime management (bad).

  • by Photo_Nut ( 676334 ) on Wednesday June 06, 2007 @06:04AM (#19408581)
    PageHeap is a debugging tool for Windows created by Microsoft. It does what you want.

    For more information look here: []
  • Valgrind (Score:5, Informative)

    by bms20 ( 827647 ) on Wednesday June 06, 2007 @06:06AM (#19408593)
    Use valgrind : It is (in my opinion) the best tool available for this purpose. In fact, I develop C++ exclusively on linux first because of valgrind, then port to Win32 later. By the way, you're not missing out on anything special by not programming in Java or C#. Both of those languages are slow, and introduce their own language complexities. -bms20
  • Re:Boost? Ugh (Score:1, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @06:13AM (#19408623)
    That's a pretty harsh comment. Would you mind please giving some examples?

    Personally, I find that

    shared_ptr f (new Foo); ... // don't need to worry about when 'delete f' happens!

    and also scoped_ptr are simple to use and very useful.

    As with a lot of things there can sometimes be a tradeoff between the slope of the learning curve and the expressive power that you get as a result. Yes, there are more than a couple of Boost libraries that are over my head and where I write "standard" code instead. But Boost is not all-or-nothing - you should just use the bits that you like.

  • Re:Valgrind (Score:3, Informative)

    by HRogge ( 973545 ) on Wednesday June 06, 2007 @06:35AM (#19408723)
    If you still think Java/C# are slow, especially in terms of memory management you might want to read this: tp09275.html []
  • by Rezonant ( 775417 ) on Wednesday June 06, 2007 @06:43AM (#19408763)
    It's true that MMGR is single thread only, and if your program allocates and frees memory on multiple threads you should choose another alternative. However, many many programs only allocate and free memory on one thread, and for those MMGR is simple to use and is pretty damn good at finding leaks, overruns and similar problems.
  • Re:Boost? Ugh (Score:2, Informative)

    by oergiR ( 992541 ) on Wednesday June 06, 2007 @06:43AM (#19408765)
    You are misinformed. You probably don't have any experience with Boost, nor do you get your facts right. Boost consists of different parts, and for using boost::shared_ptr you need only a couple of headers. There is even a tool that extracts the necessary bits for you [].

    Its bloated , has a wierd syntax that differs from the C++ norm and doesn't solve any problem that isn't already solved or could be done quite easily by standard C++ anyway.
    boost::shared_ptr has been in standard library implementations for a couple of years now as std::tr1::shared_ptr. It will most likely be included in the next C++ standard []. Apparently the C++ standard committee did think that shared_ptr solves problems that the old C++ standard does not.
  • Re:I've used... (Score:5, Informative)

    by TapeCutter ( 624760 ) on Wednesday June 06, 2007 @06:52AM (#19408805) Journal
    If you use MS compilers the memory debug stuff is in crtdbg.h, IIRC it has been there in one form or another since V1.5 but for some reason seems too obscure for the average Windows programmer to find. ;)

    It is a very handy feature for finding leaks, buffer overflows, ect. The only other product I've used to find memory problems on recent incarnations of Windows is Purify. The MS solution is infinitely simpler because it's built into the environment and it's narrowly focused on memory problems. To state the obvious and in fairness to Purify, MSDev is infuriatingly fussy when it comes to building debug modules for IBM's Purify.
  • Re:um (Score:3, Informative)

    by RegularFry ( 137639 ) on Wednesday June 06, 2007 @06:54AM (#19408817)
    It's an alternative to needing a memory checker, though, so it would provide an valid solution to the problem for a new application.
  • by Anonymous Coward on Wednesday June 06, 2007 @06:57AM (#19408835)
    I used to select tools for my team. For UNIX, I selected Purify and for Windows, BoundsChecker. After a few days with BoundsSlacker, **all** and I mean every one of my team was asking for Purify for Windows licenses. 17 licenses later and our code crashes have dropped byat least 90%.

    Yes, it isn't cheap. Just do it. You'll thank me.

    The productivity increase alone will make it worthwhile for management.
  • Re:STLPort (Score:5, Informative)

    by Chris_Jefferson ( 581445 ) on Wednesday June 06, 2007 @07:02AM (#19408863) Homepage
    Actually, yes they do. In g++ use " -D_GLIBCXX_DEBUG ", in VC++ enable debugging. You'll get all these errors and more. I don't understand why everyone seems to know this part of stlport and don't realise other librarys have it as well.
  • Re:Boost? Ugh (Score:3, Informative)

    by Cyberax ( 705495 ) on Wednesday June 06, 2007 @07:12AM (#19408901)
    You don't usually need to build anything to use BGL - it's mostly header-only library. It has only two small helper files.

    And Boost.Build is muuuuuch more powerful than makefiles. You can try to use Boost.Build v2 in your own projects - it's very very useful.
  • Re:Boost? Ugh (Score:2, Informative)

    by rabidgnat ( 923944 ) on Wednesday June 06, 2007 @07:36AM (#19408997)
    In 1.34, Boost made a Windows install tool that makes it much more easy to use. Just run the installer, put it in the directory you want, and change the Visual Studio settings to include $BOOST_ROOT. You could easily get going in 5 minutes

    By the way, if you're not developing for Boost and aren't using one of 8 or 9 libraries, you don't *have* to run their build system. Just pointing Visual Studio or GCC to $BOOST_ROOT is all you need to do. It sounds like taking 5 minutes to read the "getting started" page would have saved you a lot of grief ;)
  • Re:Boost? Ugh (Score:1, Informative)

    by dzorz ( 706431 ) on Wednesday June 06, 2007 @07:41AM (#19409023)
    Boost is a collection of a lots of libraries and you can use only pieces that suite you. For example, shared_ptr has a very simple usage pattern and solves a problem that wasn't that easy to solve. It is already included in TR1. You really can't say that shared_ptr is bloated, too complicated or that it is a nightmare to compile - it only needs header files!
    I would also recommend checking scoped_ptr, boost::random, boost::threads, boost::date_time and boost::filesystem. I use them all extensively in a single library that has to compile on gcc (Mac & Linux), MSVC80 and (!) Borland C++.
    As for the complaints about the boost build system - bjam. I really have to disagree with you. You *don't* need to use it. Use it only to compile boost libraries, and then integrate them using whatever tool you want. I personally recommend cmake - it generates Xcode, MSVC, Borland projects or simple Makefiles among others... I use it to generate all of these.
    Yes, it generates awful error messages, but, one could argue that STL and template metaprogramming in general generate awful error messages. It is something that is deemed to be fixed in new C++ standard.
    I will agree with grandparent that some boost libraries are mental masturbation - boost::lambda comes to my mind :-) Some boost libraries rely on really ugly hacks (e.g. in boost::serialization - order of include files matters!!) and produce very bloated code, but you should judge it on a library per library basis.
  • by Tronster ( 25566 ) on Wednesday June 06, 2007 @08:07AM (#19409149) Homepage
    Last week on Gamasutra was a good article on memory leak detection, and how to role your own tool:

    "Monitoring Your PC's Memory Usage For Game Development" []

    While the title says it's for game development, I found that the meat of the article applies to any windows developer.
  • Re:Valgrind (Score:3, Informative)

    by Idaho ( 12907 ) on Wednesday June 06, 2007 @08:10AM (#19409167)

    Use valgrind : It is (in my opinion) the best tool available for this purpose. In fact, I develop C++ exclusively on linux first because of valgrind, then port to Win32 later.

    It's been a few years since I last programmed in C++, but Valgrind indeed really saved the day on a regular basis. Also look into (KDE-)frontends if you think looking at text output is not very convenient. Couldn't agree more with this part, it's the best tool I've seen - and it's free software, too.

    By the way, you're not missing out on anything special by not programming in Java or C#. Both of those languages are slow, and introduce their own language complexities. -bms20

    Afraid I have to disagree here though. First of all, a language is not the thing that's "slow" or "fast". It may be the case that no very efficient compilers or virtual machines exist (for a particular language). I will admit that it is hard(er) to create efficient implementations of some languages (functional languages, logic-based languages), but C# and Java are definitely not among those. Second, Java VM's used to be slow in 1997. It's 2007 now, I'd suggest you try again (and be surprised). Third, I definitely do not agree that "you're not missing out on anything special" by using C++ instead of any garbage collected language (not necessarily Java or C#). For one, you're (do I need to state the obvious here?) missing out on garbage collection! I would say garbage collection is a clear advantage in the vast majority of programming scenario's. I would even argue that it's the biggest practical advancement in programming since the introduction of the procedural paradigm - perhaps even more important than object orientation.

    Last of all, you're complaining about "language complexities" in Java/C# and (thereby) suggesting C++ is better in this regard? Hmm, I guess my sarcasm detector must be broken or something :D
  • Re:Boost? Ugh (Score:2, Informative)

    by marnek ( 932402 ) on Wednesday June 06, 2007 @08:30AM (#19409279)
    If I saw v1 + v2, how would I know if it's adding the numerical vectors v1 and v2 or appending v2 to the end of v1 ? What if v1 and v2 are not numerical? Or do you think people should just intuitively know that for numerical vectors the + operator means element-wise addition and otherwise it means concatenation?
  • Re:two points (Score:3, Informative)

    by master_p ( 608214 ) on Wednesday June 06, 2007 @08:39AM (#19409331)
    Boehm's gc is very very good...on par with Java's collector and others. The source needs cleaning up, and some configuration bugs to be ironed out, but it is very good.

    In order to use it, you just have to include 'gc.h' in your files, which replaces 'new' with 'gcnew' using macros. Alternatively, you can bypass the standard library and provide a replacement for 'malloc' and 'free', but I did not manage to do that (due to the configuration bugs mentioned above).
  • Re:I've used... (Score:1, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @08:53AM (#19409431)
    I use VLD instead, it gives much more useful info to trace memory leaks than the standard crtdbg.h stuff.... (i.e. a stack trace of where the memory was actually allocated) r.asp []
  • Memory Validator (Score:4, Informative)

    by sdt ( 7606 ) on Wednesday June 06, 2007 @09:30AM (#19409755) Homepage
    Have a look at memory validator []. I don't know if it supports 64 bit applications, but it has a great list of features [] and is the only decent memory validation tool I've ever seen on Windows.
  • by John Betonschaar ( 178617 ) on Wednesday June 06, 2007 @09:34AM (#19409801)
    [i]A few years ago I also tried out Insure++ from Parasoft, which seemed to be of similar, if not slightly better, quality.[/i]

    We 'use' Insure++ as well, but unfortunately 'using it' is limited to tracking down arcane, semi-valid C++ constructs in our code that Insure++ b0rks on. Insure++ supposed to be a pretty advanced tool, but it is not actively maintained anymore and it's full of limitations that make it almost unusable for existing codebases. Especially stuff with templates, stuff using classes from external namespaces and dodgy C++ constructs that compile without warnings on every compiler I know will make Insure++ instrumentation fail. Also, linking the instrumented source files together fails on 1 out of every 10 object files, especially if they also link against third-party static libs (.a on linux). Sometimes you can fix this, but most of the time it is completely unclear why the thing fails. This effectively rendere the whole tool useless as you cannot be sure there will be no problems left in the non-instrumented parts of your codebase. And in those cases instrumentation *does* work, the output you'll get when running the instrumented binaries is sometimes really unclear, confusing or downright nonsense.

    Last but not least, Parasoft support is awful. We've been told some of our linkage problems, for which we filed bug reports, would be fixed in a later release. No new version was released for 1.5 years, and on multiple inquiries about this we did not even get a reply. Then, all of a sudden Parasoft released a new version a while ago, which we found out about 4 months later as they did not bother to notify us about it...
  • Re:two points (Score:5, Informative)

    by d00ber ( 707098 ) on Wednesday June 06, 2007 @09:48AM (#19409943) Journal
    Also, shared_ptr has been promoted to the draft standard C++-0x so you can use std::shared_ptr.

    You'll be able to use C++-0x in gcc-4.3 with a switch.

    I also heard that std::auto_ptr is being deprecated (not removed) I guess in favor of rvalue references.

    Finally, there [] is a motion to include garbage collection in the C++ language. This is sponsored by none other than Hans Boehm among others.

    I realize this doesn't help immediately.
  • Re:Valgrind (Score:4, Informative)

    by Rogerborg ( 306625 ) on Wednesday June 06, 2007 @10:00AM (#19410127) Homepage
    Agreed. I am not a fan of Linux development environments, but there really is nothing like Valgrind available for Windows, so run as much of your code as possible through Valgrind on Linux. I'd say that it is worth the effort, even if you have no intention of supporting a Linux distribution.
  • Memory Validator (Score:2, Informative)

    by Gedalia ( 254273 ) on Wednesday June 06, 2007 @10:10AM (#19410261) Homepage
    I have had pretty results from Memory Validator from Software Verify. ( l [] ) It'll slow down your app but I think it does a better job keeping things close to real time then purify.

    Fight Entropy!!! Fight Entropy!!! Figth Etnropy! !
    iFgth Etnrop!y ! giFth tErno!py ! giFt htrEno!p y! --- Well maybe
  • by Heir Of The Mess ( 939658 ) on Wednesday June 06, 2007 @10:17AM (#19410327)
    Use a testing framework like Parasoft's CPP stuff uct=CppTest []
  • SmartHeap (Score:1, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @10:40AM (#19410623)
    SmartHeap []
  • by Anonymous Coward on Wednesday June 06, 2007 @10:43AM (#19410677)
    The following CRT/Win32 functions can come in handy when diagnosing memory leaks and heap corruption.

    Use _CrtSetDbgFlag to get the memory manager to test the heap periodically during use among other things. Or use _CrtCheckMemory to do it strategically.

    Using _CrtMemCheckpoint and _CrtMemDumpAllObjectsSince can check to see if any heap blocks have been left on the heap in a range of code. You can use _CrtSetBreakAlloc to break on the allocation to locate the point where a widowed block was allocated.

    You can also use GetProcessHeaps and HeapValidate to check heap integrity. In particular, it can be used to check all heaps in the process.

  • Re:two points (Score:3, Informative)

    by julesh ( 229690 ) on Wednesday June 06, 2007 @10:49AM (#19410733)
    Second, I believe that there are a number of garbage collectors available as libraries for C++. I've heard boehm's garbage collector mentioned numerous times. My question is, are any of these libraries any good? Are they really practical to use in real world applications? Do you have to modify all of your types to use it, or can primitive and stl types work with it?

    I've deployed Boehm GC in real world applications before now, and consider the quality of the collector pretty good. It isn't a real-time collector, but on a reasonably low-end computer (350MHz PII) running applications with average memory requirements (total ~50MB in objects of around 100 bytes - 2K in size) delay times were minimal (around 10ms, which I arranged to occur after event processing when it was found that no new event was waiting, hence was rarely detected by the user). You can use any type you want with it -- there are at least three different approaches:

    * Make your classes inherit from a 'gc' base class
    * Use a placement new operator (e.g. "new (GC) MyObject;" or "new (PointerFreeGC) char[16384];")
    * Use the provided 'malloc' replacement library to replace all dynamic memory allocations with a GC allocation.

    I chose to go the second route, because it gave me the most control. I had to spend a little time debugging problems caused by forgetting to include the (GC), but certainly less than I would have spent debugging undeleted objects had I not used the collector.
  • Re:um (Score:3, Informative)

    by ( 1108067 ) on Wednesday June 06, 2007 @11:07AM (#19410983) Homepage Journal

    "leave the ugly but solid code alone until necessary."

    If its ugly its not solid. Ugly code is hard to understand at first glance, and its easy to introduce an error. Or do you consider code that's easy to make a mistake with as actually being "maintainable"?

    If its ugly, there's probably a non-ugly way to do the same thing that's better, more efficient, AND more maintainable.

    Remember, 90% of the investment in code is in the ongoing maintenance. Having to "relearn" all the "cute little hacks" that make that ugly POS code work, every time you have to change something, is a waste of resources. That ugly code is usually a monument to the "there's not enough time to do it right, but there's always enough time to do it over ... and over ... and over" and "ship it now - fix it later."

    I've written enough ugly code to know that if its ugly, I'm not approaching the problem properly.

  • Re:two points (Score:2, Informative)

    by ( 1108067 ) on Wednesday June 06, 2007 @11:13AM (#19411079) Homepage Journal

    "Finally, there is a motion to include garbage collection in the C++ language. "

    Call me old-fashioned, but I hope that's one that they will throw in the garbage. Call it something else if you're going to have garbage collection as an integral part. As a set of libraries, or as a compiler-time switch, fine - but not as part of the core. That's not C++, that's D [].

  • Re:Boost? Ugh (Score:3, Informative)

    by swillden ( 191260 ) * <> on Wednesday June 06, 2007 @11:23AM (#19411231) Homepage Journal

    It's not primarily meant for production use, rather it is a _testbed_ for future improvements to the C++ standard library. Pretty much a place where they intentionally test the bounds of the C++ language and check what kind of features would make sense in the standard.

    Huh? Where did you get that idea? The Boost libraries most definitely are intended for production use, in a wide variety of environments. From the home page:

    Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use.

    They do aim to define and refine libraries so that they may eventually be appropriate for standardization, but the *primary* purpose of the Boost libraries is to provide tools that working programmers need, to get their production work done.

  • GCC mudflap (Score:3, Informative)

    by MORB ( 793798 ) on Wednesday June 06, 2007 @11:25AM (#19411273)
    If you can afford to make your app compile with mingw's gcc (or cygwin's gcc but mingw should be easier), then you may be able to use mudflap, which is a memory debugging system integrated into gcc. You just need to pass -fmudflap, and gcc will instrument the program at compilation time.

    One thing is that it used not to properly instrument some really basic C++ operation in gcc 4.1 (I don't remember what exactly, something like copy construction of an object containing pointers) and was reporting spurious leaks because of that. It may have been fixed in 4.2.

    Search for "mudflap" in the following page: ze-Options.html#Optimize-Options []
    As well as ing [] (maybe slightly outdated)
  • by ChriSindri ( 567408 ) <> on Wednesday June 06, 2007 @11:47AM (#19411641)
    Application Verifier [] comes in x86, ia64 and amd64 flavors.

    This tool allows you to enable PageHeap for your process, which is heap corruption detection built into the OS heap implementation. Upon freeing a block of memory, PageHeap will break into your debugger spewing tracing that a block has been corrupted. It can also provide the call stack when the block was allocated. Newer heap validation features are available in progressively more recent OS releases.
  • by Anonymous Coward on Wednesday June 06, 2007 @11:54AM (#19411781)
    Following MS tools are absolutely free:
    - Use umdh that is a part of the Debugging tools for windows to track memory leaks. nstallx86.mspx []. Following article explains how to use it [].
    - Whatever you do make sure you have proper symbols. Following article explains how to get symbols from MS symbol server. ebugstart.mspx []
    - Use paged heap to track all other issue like memory overruns, double free and all other sorts of heap corruption. ws/appcompatibility/appverifier.mspx []
    - Please note that if you run you application with app verifier checks on you need to run it under a debugger. I would strongly suggest windbg or cdb instead of visual studio because it has extensions that would greatly help you to track down the issue ("!analyze -v" "!avrf" "!heap -p -a "). For more details see windbg help. If your application is a service then you might consider running your machine under kd, which would trap all unhandled exceptions and application verifier reports.
    - Following link has a very good windbg tutorial [].
    That is all you need to debug any kind of heap issues.

  • Re:two points (Score:2, Informative)

    by stonecypher ( 118140 ) <stonecypher@gmail. c o m> on Wednesday June 06, 2007 @12:03PM (#19411945) Homepage Journal
    GCC got TR1 support two weeks ago. MSVS got it two years ago. Look in stdext:: in MSVS2k5.
  • Re:two points (Score:3, Informative)

    by akeru ( 15942 ) on Wednesday June 06, 2007 @12:44PM (#19412641)
    You can also use the Boehm garbage collector as a leak checker. Rather than collecting garbage, it reports on (and, I *think*, frees) memory that was 'forgotten' without being properly released.
  • Re:Boost? Ugh (Score:2, Informative)

    by stonecypher ( 118140 ) <stonecypher@gmail. c o m> on Wednesday June 06, 2007 @12:46PM (#19412669) Homepage Journal
    By definition it is both. It is important to remember that no candidate library may be admitted to C++ if it isn't production ready. The idea that Boost is not meant for production use suggests that you too might do well with a bit of catching up on the ol' intents-and-philosophies set.
  • Re:two points (Score:4, Informative)

    by d00ber ( 707098 ) on Wednesday June 06, 2007 @12:49PM (#19412697) Journal
    My understanding is that it will be opt-in. I think manual management will be the default.

    They don't want to remove the old ways (including malloc/free). And they don't want to penalize people who don't use garbage collection. In other words, if you don't want to use garbage collection you won't be paying for it in code size/runtime.

    But for them that do... It might be nice to offer it.

  • Re:Valgrind (Score:2, Informative)

    by stonecypher ( 118140 ) <stonecypher@gmail. c o m> on Wednesday June 06, 2007 @01:08PM (#19412977) Homepage Journal

    Speed isn't everything. If your server application is network or database bound then stability and API richness is considerably more important than speed of execution.

    "Speed isn't everything. Why, if you start with a situation where other problems are choking you, you don't even have to think about speed!" That's called tautology [].

    By the by, the programming languages you just argued for are ADA, PHP and Visual Basic.NET, whose libraries are enormous in comparison to Java or C#. Now, I do a fair amount of PHP when I'm bored, so don't get up in arms when I say this. That said, I want to point something out: there are very, very few genuinely large scale services written in PHP, C#, Java, ADA, or any of those languages.

    When it comes down to it, there are two costs: programmer time and hardware time. If you're network blocked, you buy a bigger network pipe; a dedicated box with a dedicated guaranteed ten megabit unmetered line for a year costs about a week and a half of a programmer's salary.

    But, more importantly, you never, ever, EVER get network blocked. That just doesn't happen on engineered systems. The network moves faster than any software you or anyone you know will ever write. Sure, one given pipe might fill; you just upgrade the pipe. It's relatively straightforward to find gigabit, and if you know what you're doing you can go up from there; you have almost certainly never in your life seen a system that can push a gigabit of data. Even just filling static HTTP requests at that speed can bring a heavy duty, well tuned box to its knees. I happen to be friends with a tech at one of the giant shared hosting farms; his company has over 200,000 customers, and it takes them a Quad Athlon to service the average 100 megabit pipe filled with average wordpress blogs.

    Now, I'm not saying the richness of the API doesn't matter. I'm just saying that positing a system based on filling the network is a little like designing the heater in the car in case the sun goes out. If you have enough users to fill a pipe, you can afford the next pipe up, or you need to be less retarded in setting your prices. The pipe has nothing to do with your selection of language.

    And, frankly, the idea that you have to step away from real languages to get a real API is silly. Or, haven't you ever actually looked through the standard libraries of languages like C++ and Erlang?

    After all, does it matter that your app completes 2ms faster if it has to wait 500ms for the database to return?

    If your database is taking a half second to return, you've got incredibly serious problems. And yes, in the real world, a 2ms lag matters because of the queueing problem. Have a look at one of those graphs where a modern stage server like Lightstreamer or YAWS compares itself to Apache. Apache tends to drop off logarithmically. Every time you lag 2ms, that's two more MS of customers you have to deal with during the next query.

    This is a limit flow problem, and most people get limit flow problems if you use a toilet as an analogy. Your webserver is similar to a toilet that doesn't have a stopgap. That means the bowl is always slowly filling with usage (ie, not water - say this is a train station) and you have to flush it every so often to keep things clean. The train station was well designed 50 years ago, but as population has gone up, the facilities are feeling the strain.

    Now, there's a point at which you say "does it really matter if the toilet takes three minutes to flush, if it's 20 minutes between trains?" Well, actually, yes, because that means each toilet can only service six and two thirds people per train arrival. At home-bound rush hour, you're going to get an enormous line of people outside the bathroom that keeps getting longer and longer.

    The problem with Apache is that the longer the line is, the slower the toilet flushes. See the issue now

  • Re:um (Score:2, Informative)

    by Anrego ( 830717 ) on Wednesday June 06, 2007 @01:48PM (#19413593)
    Ugly code is really unavoidable. It's going to happen. While you should always try to write good, clean, maintainable code, circumstances can conspire against you. Project requirements can change half way through development with a timeline that doesn`t allow for going back and changing code properly. And of course there are always people who have ample time to write good code, but just don`t know how/don`t care.

    After having worked on what I could only describe as some of the ugliest code on the face of the earth (written by people who previously made a living writing throw away code for PhD types (the kind of code that you use to find an answer, then never use again)) I would say the _real_ problem that makes one want to just go hang themselves in the server room with some cat5 is lack of documentation.

    Nothing compounds poorly written code as much as poor (or non-existent over here) documentation. If you _have_ to hack code to make something work in a hurry... COMMENT THE CRAP OUT OF IT. Put a huge comment block, with asterisks and exclamation points and a link to the page in your projects documentation manager describing why you did it, what should be done down the road when time allows, and an apology note to the next guy who has to work on the code.
  • by Anonymous Coward on Wednesday June 06, 2007 @03:01PM (#19414755)
    That example happened something like 5 or 6 years ago. Maybe try it on MSVC++ with CString?
  • Re:rtti (Score:3, Informative)

    by MenTaLguY ( 5483 ) on Thursday June 07, 2007 @06:47PM (#19430865) Homepage

    All they would need is a more robust run-time type information system.

    No, not at all. The current C/C++ specifications permit compilers to transform code in ways that can interfere with a garbage collector. Fortunately compilers do not do that as often as they could, but it seems like something important that should be addressed.

    See Hans' paper Simple Garbage-Collector Safety [] for details.

All seems condemned in the long run to approximate a state akin to Gaussian noise. -- James Martin