Stuck in the Slow Lane

Been writing in C++ lately.  Man, I feel disconnected, alone, naked.  So many pointers, deref'ing, addresses, pseudo-maniacal linked lists all over the place.  Where's ArrayList when you need it, or managed arrays.  I want my managed code back.  Please, give it back. 

Was this what is was like to program, you know, before?  I don't remember it being so harsh.  I suppose you never do until after you've been shown the way.  Then everything becomes so much easier, you get so much more productive, your brain is happy, and you forget the past, forget the struggle, the fight against the machine, the compiler and the language. 

Header files.  Need I say more?  Giant header files, ever member function listed.  Monstrous class declarations, poorly factored code.  It's a nightmare.  You laugh.  You think you are free of the horror.  But just wait.  It sneaks back up on you.  Before you know it your back in the hard-cruel world, stuck in the slow lane waiting for a compile.

Wouldn't it be grand if the operating system refused to load apps written in anything but IL?


Comments (11)

  1. Jerry Pisk says:

    Where’s ArrayList? Isn’t stl::vector good enough? Given the type control it’s actually better than Arraylist…

    And how does managed code save you from poor code is beyond me.

  2. Matt says:

    STL…. (* shivers *)

  3. Tony says:

    I agree with Jerry.

    I can’t wait until the blogs are full of notes of people using poor design philosophies in IL-based code that makes things just too scary.

    And the limitations of IL could be the root cause of some of these poor design patterns.


    Use the right tool for the job.


    Learn to be effective with the tool.


    You’ll stop complaining about languages.

  4. Scott Allen says:

    Maybe you should re-introduce yourself to the magic of the preprocessor. With a little polish, anything could look like an ArrayList. Here is something to paste into a header file to get you started.

    #define obstack_finish(h)

    ( ((h)->next_free == (h)->object_base

    ? (((h)->maybe_empty_object = 1), 0)

    : 0),

    (h)->temp = __PTR_TO_INT ((h)->object_base),


    = __INT_TO_PTR ((__PTR_TO_INT ((h)->next_free)+(h)->alignment_mask)

    & ~ ((h)->alignment_mask)),

    (((h)->next_free – (char *)(h)->chunk

    > (h)->chunk_limit – (char *)(h)->chunk)

    ? ((h)->next_free = (h)->chunk_limit) : 0),

    (h)->object_base = (h)->next_free,

    __INT_TO_PTR ((h)->temp))

    Now, isn’t that elegant?

  5. Matt says:

    The preprocessor is EVIL.

  6. Jerry Pisk says:

    If preprocessor is evil why does C# have one? It’s not a full blown one like in C/C++ but it’s still there.

  7. Matt says:

    Duh! Evil Empire. 😉

  8. Jeff Dillon says:

    I had this exact same feeling… It was the year 1999 and I started using Java. You know I think there are a lot of .NET/C# programmers out there that seriously don’t know that they are seeing a technology that just about all of the enterprise comnunity was sold on 4-5 years ago.

    Welcome to the 21st century.

  9. Matt says:

    Dude, I was using Java in 95. I know what you mean though.

  10. Hey Matt, I have the same feeling as you have whenever I have to code using unmanaged C++. I also was an early Java lover, and than a C# early one 🙂

    I agree that STL does good things in C++, BUT you need to spend TIME (which means MONEY of course) to understand even how to use a Sort algorithm from STL. And you need to browse the help for finding the right interfaces you need to implement to your classes to allow I don’t know what STL method work on your objects.

    Array.Sort from .NET is an example of why is .NET better than STL. It does not make you implement IComparable to be able to sort an array of objects of your class. Instead, .NET offers a Sort method that takes two parameters: the array of objects to be sorted and the array of the keys of the objects. If the keys are objects that are already IComparable, now, you don’t have to spend that much time to get your array sorted: you only need to get the keys into another array.

    I agree, it may not be the optimal code, but for many situations it will fit the needs, and you’ll sell your product earlier. Which means more free TIME, and still get the same MONEY.

    I’m not a materialistic person as you may suppose by reading what I wrote above, but however, I don’t agree that you ALWAYS need to code optimally from the strict code point of view. Sometimes the optimal code gets its factors from other sides like the speed of typing, the speed of thinking, the speed of understanding. Not always the memory and processor time used by the code to run.

    And the libraries should anticipate this. STL doesn’t (in my opinion).

  11. PS: Now that I’ve start talking about STL, I just want to say one more thing I don’t like about it:

    It uses too much templates.

    Generics (templates) are great, when we look at them, generally. But when you need a simple alogrithm to apply to your objects or some simple class to implement I don’t know which behavior, you shouldn’t be supposed to SPEND that much time understanding how the STL algorithm or class was created, and how it allows you to do the work ONLY after you completely understood the templates that it uses in the definition.

    I din’t see the prototype of .NET Framework 2.0 yet, but I hope and believe that Microsoft will not (better, did not) think the same way like the creators of STL when adding Generics-based classes and algorithms to .NET Framework. Generics are awesome and needed for a long time in several places, like Generic Collections, but I think that it’s better to avoid them when the classes/algorithms’ uses will be restricted by SPENDING TOO MUCH TIME understanding how they were designed.

    The best .NET Framework could be developed is, as I think it is: allowing BOTH rapid development AND optimal development from the code point of view. As far I saw, Microsoft kept both these concepts in mind, and STL creators didn’t.

Skip to main content