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?

Matt

Comments

• Anonymous
  June 10, 2004
  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.
• Anonymous
  June 10, 2004
  STL.... (* shivers *)
  
• Anonymous
  June 10, 2004
  The comment has been removed
• Anonymous
  June 10, 2004
  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),
  (h)->next_free
  = __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?
• Anonymous
  June 10, 2004
  The preprocessor is EVIL.
  
• Anonymous
  June 10, 2004
  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.
• Anonymous
  June 10, 2004
  Duh! Evil Empire. ;-)
• Anonymous
  June 10, 2004
  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.
• Anonymous
  June 10, 2004
  Dude, I was using Java in 95. I know what you mean though.
• Anonymous
  June 10, 2004
  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).
• Anonymous
  June 10, 2004
  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.