Software Development

What I find funny is that when C and C++ were climbing the popularity mountain, C++ proponents were trashing C and C proponents were trashing assembly. Oh, and vice versa of course. Today, C seems to have won its argument. It's no longer the language for all situations. But if you're going to do something even remotely low level, need some high level constructs, keep it simple and readable and you want it small and fast, you go to C. You don't go to assembly or C++.

I still like assembly. It's fun and fast. And you get to control how the cache is used moreso than you would in any other language. You also have access to non-temporal moves and custom prefetching. No high level language has access to any of this. So assembly does have its place. But it's been confined to the recesses of the inner most loops that require speed.

I used to program mostly in C, but in recent years, I've grown to like C++ more and more. I still don't like parts of it. In fact, I've often said that I hate all languages. The reason being that they all get in my way. They all slow me down. But I have to admit that C++ is the language that gets in my way the least. It is the language that I am the most productive in. It is the language that I need to work around the language the least. And that's why it's my favourite language even though I hate it.

What do I personally hate about it? I'm not going to go back through my blog to see what exactly I wrote. What I do know is that I don't like the 'private' keyword. I think that should be abolished. I've said it many times that anyone that uses the private keyword should be banned from ever programming again. The only time the private keyword should be used is if you can no longer derive a class. C++ should have had the final keyword instead of private. Once data is no longer accessible by derived classes, then deriving should no longer be possible. I've seen too much code get mangled out of control because of the private keyword. What I find amazing is how many people defend this keyword just because everyone tells them they should make everything private when possible. Horrible advice as that is, this is what they do. Public isn't bad. Certainly nowhere near as what people claim and certainly better than private. Public and protected is all you need. Are there exceptions to this? There is one such case where I use private. It's when I don't want anyone to invoke a certain method, I put it in the private section. And when I say no one, I mean that nothing in the entire software should invoke this method. So why should the method exist at all if nothing invokes it? Because the default constructor is always available by default. Put it into the private section and no one can invoke it.

Something else I don't like is but an annoyance. These are all gotchas. Invoking the default constructor within a declaration must not use brackets (edit: when declared inside a function or method). You must leave omit the brackets otherwise the compiler takes the statement as a declaration of a function.

A var(); // Will compile, but won't do what you think.
A var;   // Will call default constructor.

There are other things you gotta watch out for. The diamond problem is one of them. Trying to invoke a base class' constructor from a derived class constructor won't work within the body of the constructor. It will only work within the initializer list.

// Assume B is derived from A.

// This will compile, but won't do what you think.
B::B()
{
  A();
}

// You have to do it this way.
B::B() : A()
{
}

Invoking custom constructors of members is also done via the initializer list.

For C programmers, using the initializer list seems tedious and unnecessary. However, the initializer list provides many features that are simply inaccessible anywhere else.

If anything, it's these little things that make the learning curve so high. I remember when pointers were a big deal. I don't think pointers are an issue at all. Any programmer worth a damn should know how to deal with them. I don't buy any excuses about pointers. C++ now has a LOT of mechanisms to deal with them. So much so that I no longer have a second thought about them when I do use them. RAII has removed most of the need for pointers and more complicated memory management. RAII works well with exceptions as well.

About exceptions, I don't like them. Unfortunately, there is one place where they cannot be avoided. It's within constructors. If something happens that an object can't be constructed properly, the only thing you can do is throw an exception since you can't return anything.

Why don't I like exceptions? Because they mess up the code. I'd rather use a goto than an exception. That's how bad I think exceptions really are. They're slow, ugly, difficult to read, mess up your code and are just a huge pain in the ass. Don't think this is just my opinion. Exceptions have been debated for ages. I still like checking error codes and acting appropriately. This is another area where I think DirectX got it right, or COM in general. For all the criticism COM gets, the error handling isn't something that was put in as an afterthought.

We can get into the OO debate, but I won't do that here.

What do I like about C++? I like that it has signed and unsigned numbers. I recently found out that right shifting negative numbers is undefined. I've never had problems with it and am glad that on the PC, most C++ compiler companies have opted to use an arithmetic shift. A lot of stuff like this is shared with C and I'm comfortable with the syntax of C. As for C++ specific issues, classes where you have constructors and destructors is a nice feature for initialization and cleanup. I've grown to really like initializer lists. I like the ability to do placement new when necessary. I like the concept of grouping similar functionality together. Again, the concept of interfaces and implementations as done by DirectX is something I see as done correctly. The feature of having classes allows this to be done implicitly within the language. C can still have access to these interfaces, but it's a little more cumbersome.

I'm really liking STL and templates. To be able to apply the same algorithm on arbitrary types is too much of an advantage. One of the things I REALLY like isn't even about the language itself. It's about the ability to easily use C and assembly functions and vice versa. People often think that using C++ functions is difficult because of the name mangling. While that is certainly an obstacle, there are MANY ways around this. The Windows OS will automatically mangle any C++ names done by a MS compiler. There are also tools that will mangle any C++ name for other compilers. So if you want to invoke a C++ method, you can do it. If you want to invoke a static function, there's an easier way. You can just declare it as extern "C" within C++.

One thing that bothers me is that C++ doesn't have properties or closures. STL requires the use of functors which are simply operator() methods declared within a struct or class. That's a pain to set up. In Borland C++ Builder, they use callbacks all the time for events and using functors would be impossibly tedious. So they added properties and closures. You can now specify any object method as an event handler (which is a closure). Properties are used with closures and members alike. You can define a publicly visible property that reads and write its value somewhere else. You can make it read-only, write-only or read-write. You can specify another internal member to store or retrieve that data. Or you can specify a method for reading and another method for writing. You can use any combination you can think of. It also supports features for serialization. By setting a default value within the property, it will only save out the actual value if it's different from the default value. If it were not for Borland C++ Builder, I think I would have left C++ behind. I'm not sure what I'd be using, C possibly, but the features mentioned in this paragraph are what makes C++ a joy to code in. It's one of those things that you can't just explain. Once you use it, you'll never want to go back.

What did Zed Shaw say that made C++ suck so bad?

First, I'm an old school C++ coder too, but quit using it during the
"Great Template Metaprogramming Plague of 2000".[/QUOTE]

I tried to look up what he means by this plague.  I could only find references to Boost.  Not sure what the issues were exactly, but I don't like Boost either.

[QUOTE]Because the
majority of the system's work is inside POSIX and system calls, C++ just
becomes a huge bother to do the same thing [as opposed to C, ed.].  Just something as simple as
sockets becomes a major operation, and the OOP doesn't help.[/QUOTE]

Wait! What?  Sockets are the same thing whether you do it in C or C++.  They are OS calls.  WTF is he smoking?  And OOP doesn't help?  I think I know what he's talking about here.  Trying to use sockets in an OO way doesn't work very well.  I've talked in the past about using helper classes and using independent modules.  The socket engine then simply sends the incoming messages to each of the modules and those modules each get a turn AFTER all the messages are read by the socket handler.  Each of those modules then get to pass messages to the socket handler to be sent out.  Unless you do something similar to this, you're going to have a world of hurt trying to get anything done in on OO fashion.  In C, it's pretty standard stuff.  You don't really have a choice but to do it this way.

This is an example where just because you have circular saw, it doesn't mean you should use it to hammer a nail.  Or alternatively, not everything is a nail.

[QUOTE]Now for the rant answer, and if you like C++, stop right here:[/QUOTE]

Too late.

[QUOTE]With that being said, and no offence to you, but everything you said as
C++ advantages are total bunk.  The semantics of destructors are
incredibly confusing, especially with exceptions.  You have to do all
the same memory checks, use valgrind, make sure you've got destructors,
and then that's made more complex by templates, object lifecycles,
exception rules, etc..  Frankly C++ doesn't have better memory
management than C, it just has more complex management.[/QUOTE]

It's ironic that he says the other guy's assertions about C++ advantages were bunk and yet everything Zed says here is pure nonsense.  The semantics of destructors are incredibly confusing?  What?  The object gets destroyed, then the local members, then the base classes.  Sure, it can get confusing with multiple inheritance and any diamond relationship, but those should be few and far between.  And even when they do happen, the order of destruction shouldn't matter much.

The rest is just tossing a bunch of things in the air without any explanation.  Valgrind will help you find memory leaks.  Like I said, if you can't handle pointers with all the tools at your disposal within C++, you need to find something else to do.  Memory management can be a LOT easier in C++.  Sure, it can be more complicated.  But that is true in C or anything else where you manage memory.  C++ has tools like RAII, STL and smart pointers to make memory management easier.  Use them.

[QUOTE]Proof of that is how I had to use valgrind to find a memory leak in 0MQ.
No matter what, unless the language has a GC built-in, then C will have
simpler and more predictable memory usage.[/QUOTE]

Predictable?  It's the same thing.  For stuff on the heap, you allocate and deallocate stuff regardless if you're in C or C++.

[QUOTE]Next, the string support is idiotic.  You seriously haven't tried to just
craft basic strings in c++ have you?  Something as simple in *every*
language as:

bstring test = bformat("I want %d ponies", count);

Turns into a giant mountain of bizarre << output to a pseudo file like
thing that has a massive chain of inheritance and is slow as dirt.  The
type safety on these string outputs means you're constantly augmenting
all your own types with converters and friend functions just so you can
put crap into a damn string.  I couldn't imagine trying to use the
string output stream stuff to craft messages and things.  It'd be a
nightmare, and I know because I tried to do it.[/QUOTE]

I agree with Zed here.  I still use C style strings.  I use VCL's AnsiString when I use Borland C++ Builder because it's so much easier and does provide easy formatting functionality.  For Unicode, I use IBM's ICU library and is available for a host of different languages.  It provides all the functionality I could ever want.

Streams in C++ are a horrible abomination.  I try to never use them.  Streams are a dataflow concept and C++ is an imperative language.  It's like water and oil.  They don't mix.  At least not in C++.

I do want to mention that C++ does have the ability to use strings in a safe way that is also easy to use.  I've mentioned two such examples.  Unfortunately, the C++ community likes std::string.  So going to C++ and using something else from std::string would likely pose a problem.

[QUOTE]Even something as simple as casting a float to an int is a pain in the
ass involving some weird template like syntax that frankly makes no
sense.[/QUOTE]

What?  It's just a conversion.  You don't need to use C++ style casting operators.  I don't think I've ever seen anyone convert a float to an int using a C++ style cast.  That's overkill.  The C++ style casting operators are for classes so that you can cast up, down or coerce the type.

[QUOTE]Next is all the bizarre fascination with const.[/QUOTE]

Const is great.  You don't need to use it although STL does require it in some places.  Just don't use it.  Compilers are fairly good at producing decent code that you likely won't notice much performance loss.  I like const not for any performance gains, but for type safety.  If you're not into that, then it's no wonder you're annoyed.

[QUOTE]Then there's the stupidity of templates or even just basic class
structures forcing your code to gravitate into .h files[...][/QUOTE]

It's in .h files because templates tend to be inline.  When you specify a type parameter, the compiler needs to generate code for that type and it can only do that by looking up the header file that you included.  It's not voodoo.

[QUOTE]Now, next comes the answer "oh just use boost".  Riiiiiigghhtt, boost is
soo much more usable.  Remember the Plague of 2000?  If I wanted to fry
my brain trying to figure out how to add two numbers with templates I'd
go use LISP.  Boost is also huge, takes forever to build, is almost
always out of date on every distro, and people avoid projects that
depend on it when building systems.[/QUOTE]

Ok, so the plague is about Boost.  I don't use Boost either.  But adding two numbers together is rather simple using templates.  It just happens to use functional programming.  The syntax is strange though.  Still, Boost != C++.

His last point that "if C is good enough, then use that" is a good one.  In fact, use whatever you think is best.  But his arguments against C++ are mostly garbage.  He doesn't seem to understand much of what C++ is about.  That in itself could be an argument against C++.  It takes a long time to understand C++.  Heck, C is rather difficult too in this respect.

There was another reply to Zed Shaw [URL=http://blog.codeimproved.net/2010/07/whats-wrong-with-c/]here[/URL].  I agree with a lot of it.

[QUOTE][...]or they used C++ at the beginning of the 90s.[/QUOTE]

I really have to agree with this point.  C++ of the early 90s is not today's C++.  It took me a long time to get around to this fact.  Today, I use STL and even implement my own containers.  This has given me a better understanding of the ideology behind STL and how it's meant to work.  I use RAII as much as I can.  If I use pointers, I don't let user functions and methods handle the ownership haphazardly.  I set up a class (or several classes) that will provide management of these resources as if they were OS handles.  You request them, set their value, and release them.  When you pass it around, the new object will also request access.  Never do you allocate or delete them unless it's something very simple and temporary.  Sure, GC's already do all of this.  But I use custom management because that's what I want and because every C++ programmer should already have tools to handle all of this by plugging in their library or unit files.  Otherwise, use STL containers or other forms of automatic memory management.

The first point he brings up is long compile times.  Precompiled headers do help.  If your project is so big that changing a single file will cause everything to recompile, then you have too many dependencies.  There is no reason why anyone should need to recompile everything all the time.  This is about coupling.  I don't see too many programmers giving much of a damn about this.  They just include whatever they think they need and never think about it twice.  It's not including library headers that's the problem.  It's including headers from your own code.  Those tend to change and if you change a header file that is included by all .cpp files, then you're in for a world of hurt.  There are ways to split up your header files.  Some people are so adverse to this, it makes me cringe.

Next point is that you need to include third party libraries for pretty much everything you want to do.  I don't have a problem with this.  In fact, I much prefer this to the way Java does it.  With Java, if there's a problem with the library, you're pretty much screwed.  This used to happen all the time.  Sockets were a big problem before they allowed the handling of multiple sockets within a single thread.  Java also had a big problem with GUI's with numerous incarnations.  Namespaces were also a big deal when javax stuff was moved to the main java tree, often rearranging the hierarchy in the process.  I simply cannot endorse a view that a BFL (Big Fucking Library) is better than using what you believe is best.

Next point is lack of reflection.  I don't get this.  It's C++.  However, if you want some form of reflection, you can use libraries that will tell you what function any piece of code is within.  You can get the function name, class name, source file, line number, all of that.  It's called the debug libraries in Windows OS.  Heck, I've used it in Borland C++ projects that use different name mangling by having Borland output a map file, read that in, convert the names to the MS version and output a CODEVIEW4 debug file for my project.  This can all be done automatically by the compiler.  At runtime, you can then use the debug libraries to obtain the debug info at any point of execution.  Does it take more work?  Sure.  But once you have these tools, it's simple.  It's just about learning a new API.  I often write my own wrapper functions to simplify certain things.  To get a function name of a callback, I just invoke GetFunctionName(funcptr).  Done.  I'm sure you can do all this in Linux as well.  There are libraries that will help you manipulate ELF or DWARF files.

Then it's lack of type inference.  I don't get this.  Sure, it'd be nice when dealing with iterators for example.  And that is coming.  But overall, C++ is has fairly relaxed rules about types.  Take a look at MODULA-2 if you want to really complain about type inference.

Localization & internationalization is a valid complaint.  This is not about the language, but the environment.  Depending on what you use, there are different ways of doing this.  Windows OS has a lot of functionality for this.  So does Linux.  So putting this in the language can help.  From my POV, I think it's up to the developer to make sure it's done correctly.

Template errors are a valid complaint.  They are truly horrible.  Some errors are nowhere near the culprit.  I understand why the errors are done this way.  Doesn't change the fact that they suck.

Functional programming support is the next item up for bid.  I use Borland that has simple closures.  Just a function pointer that also holds a pointer to the object.  This is so useful that I cannot imagine C++ not having it.  This means I have a different view of C++.  I've been privileged to have closures and properties.  I don't see how others use C++ without it.  What's even worse is that Stroustrup is dead set against including properties in the C++ language.

The objection about tools is ridiculous.  There are plenty of great tools available.  On Linux, KDevelop with Valgrind, gdb ,gprof and git is hard to beat.  On Windows, there are likewise plenty of useful tools.  I like Code::Blocks for a free IDE.  There are plenty of others available that will do just about anything you want.

One last point that has not really been talked about is threading.  Threading is difficult regardless of what language you use.  Understanding the principles behind threading can only be learned after many hours of development.  Just reading a book about deadlocks, race conditions and other issues won't tech you anything until you see it firsthand.

So does C++ suck?  Without closures and properties, it does.  Even with them, the language slows me down.  But it slows me down the least of all languages.  I actually enjoy using C++ when I get to use the tools it provides.  The problem I have is that those tools within the language itself aren't always the best solution.

Does C++ suck for the reasons that others claim?  I don't think so.  C++ does have a high learning curve.  I think that's all you can say about C++ really.  The rest are issues once you start trying to use the features of the language.  They all seem to be about frustrations that come about when learning the language.  Some issues are valid.  However, we'll never reach a consensus on what features are "correct" and which are "wrong".  What I see is not a language that tries to be everything to everyone, but rather a language that lets the developer decide what is best.  For that reason alone, C++ should not suck.  Only problem is that there are still no closures and no properties.  The next revision might provide closures.  Without properties, C++ still has a long way to go.

In case you've noticed, I want to say that C++ is good.  I really do.  I like programming in it.  But it's not C++.  It's Borland's version of C++.  I have no problem coding in standard C or C++ in other people's projects.  In those situations, I keep wishing I had properties and closures.  And then I move on and implement it a different way.

Out of all the languages out there, standard C++ is still on top of the list in my view.  Borland's version of C++ is easily #1.  Funny that the extra features are based on Pascal of all languages.  What I can say with certainty is that LISP completely sucks and C++ doesn't.  If I mean C++ doesn't suck or doesn't suck completely is left intentionally ambiguous.