ObfusCo > The List > cpp

C++ Blog

C++ is killing me. I find it hard to believe anybody actually thinks this stuff is good to use. Get a life and use Eiffel or something for crying out loud.

• 9) Why is it that none of the STL documentation I've found explains how to pass things around, or how to allocate things? This is stuff you wouldn't have to worry about in Java because you wouldn't have many options, but in C++ I don't know if I should be allocating them on the stack or the heap, and I don't know how to pass them around among functions.
• 8) Doesn't this kind of stuff reinforce my desire to stay the hell away from C++?
• 7) Doesn't it strike anybody else as utterly wrong to have all the private members listed in the class in the .h? Shouldn't they all be hidden in the .cpp? Well, all I know is, I shouldn't have to recompile files which use the public interfaces just because I changed the internal workings. But since the internal workings are in the .h, then the .h is invalidated and Make decides everything has to be rebuilt. What a huge piece of stinking feces!
• 6) It bugs me that you can't write something like super::fn() but instead have to explicitly write the name of the superclass because then if you are down a couple levels in an inheritance chain (which is probably not the best design in the world, sure) you can end up writing the wrong one and screwing yourself.
• 5) So what the bloody hell is the point of letting us declare things as unsigned when compilers don't even warn you if you assign from a signed value?
• 4) It bugs me that if you have a const thing, you have to give it a value right away. It causes several problems:
  1. You end up putting the type declaration for a variable right where it is given its value, which I think is ugly: I want to be able to have all the declarations at the very start of the routine.
  2. If you have two routes through the routine (you know, if you have like one if-else statement) then you either have to cast things to be non-const, or you have to put in multiple return statements because the declaration has to happen where the item has its value set, so you can't have a return after the if-else. I hate having more than one return because then when you go to debug it, you have to find all the places where the value is returned and monitor them. Having one exit point is a lot cleaner (and forces you to think about the ending conditions; making sure you tie up the loose ends, as it where, rather than just returning in the middle of a loop or something).
  I kind of wish the compiler would let it not have a value until I give it one, and from there on out be const?
• 3) Trying to set the member values in the constructor using the :() notation sucks ass when the values are anything other than really slap-ass-simple types. So if you have an array that you need to copy over, it sucks. It just smacks of a hack - sure, it will work in some situations and be nice, but then a lot of the time you are going to not be able to use it at all.
• 2) The fact that when you have an array it calls the default constructor, and the idea that a constructor should ensure that an object is fully defined just don't mix well at all. Sure, you can have an array of pointers to object, but that kinda sucks in plenty of situations.
• 1) You'd think that since the whole point of a constructor is to initialize all the data, there would be a way to get the fancy-pants compiler to warn you when some data hasn't been.