Why C++ Is Not “Back”

[Jibz]

http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/

C++11 just came out recently and it seems like there is this big resurgence in interest in C++ development.

Now don’t get me wrong.  C++11 is fantastic!  I am in just about 100% agreement with all of the changes that have been made.  C++ has definitely become much easier to use and it has even become more powerful.

There is one thing it didn’t become though—and this is the most important—more simple.

...

My point of this post is not to bash C++ or bash people using C++ or teaching C++, but rather to blunt the message that seems to be being preached by an over eager C++ community.

Everyone is not going to become a C++ developer and they shouldn’t need to be.  While C++ may have the ability to make your program more efficient (in certain scenarios,) it is extremely unlikely to make you more efficient at creating your program (except in some extreme cases.)

So, I am glad C++ got a much needed overhaul, but I don’t think it is going to make a comeback any time soon, and that is a good thing.

I think this post has some very good points, and it reflects some of my thoughts about C++ lately. The recent changes are (largely) good, and C++ can be very elegant and terribly efficient, it is just really really hard to write good C++ code, and unless you need that extra edge on performance, there are many languages that will make your life a lot easier, especially if you are learning to program.

[vlastimil]

Well, I may be biased, but I have a different perspective.

I think C++ is perceived as hard and C# as easy mainly because the tools and libraries used during development. C# has much much better support than plain old C++ in Visual Studio when designing user interface. Also, there is one (tens of megabytes big) core library for C#, but nothing like that for C++. Many C++ developers fear STL and even if they don't, it is only basic algorithms and you may run into binary compatibility if you use it in module interfaces. There is no "one" GUI framework (and MFC sucks).

When actually writing code, C++ does pretty well. In C++11+STL, you don't have to use new/delete at all. You get safety, efficiency and predictability (compared to garbage collection). But how much time is actually spent writing code? When working in C# on a simple tool, I would say that not much. Most of the code is generated and managed for you by the IDE and you only need to fill in a few gaps. That is something no tool currently does for C++ and that is why is it perceived as difficult. If you had to type everything the C# IDE does for you manually, the picture would be different.

Of course, it is easy in C++ to start writing bad code, but is is now also easy to write good one.

[Renegade]

Also biased here.

I think it all really depends on what you want to do and how you want to do it. I mainly use C# because it's fast, and I'm more interested in getting something done and working than in efficiency and elegant code. I commit horrible sins. Regularly.

If you had to type everything the C# IDE does for you manually, the picture would be different.

+1

My view is that the IDE should do most of the grunt work for you, and free you up to be creative. The language and IDE shouldn't get in the way - they should help you along. This is why I refuse to code any JavaScript in anything other than Aptana -- it does the work and lets me do the creation.

[wraith808]

^ Totally agreed renegade.  And I also see as an architect very much that the newer programmers that I mentor don't *get* some stuff, because they don't know what goes on under the covers.  And so they can't make good decisions devoid of this knowledge.

We process millions of rows of data a day.  Someone slowed it down considerably, and I had to figure it out and fix it.  The culprit?  Enum.HasFlag.  MS put it there, right?  And it's a lot easier than bitwise comparisons- so the person used it.  But this put everything in and make everything easy is removing the problem solving from new engineers- making them truly into 'code monkeys'.  Yes, I know, in most situations, the difference in something like this wouldn't be noticeable.  But see that I noted that this was in a loader that loaded millions upon millions of records from financial entities daily?  The developer just coming in wouldn't even know that- and indeed this one didn't.  You have to know how something is done before you use it, so that you can make good decisions about when to use it.

Oh, and if you're interested- from my research on using that construct:

Except in the simplest of cases, the Enum.HasFlag carries a heavy performance penalty in comparison to writing out the code manually. Consider the following code:

Code: (csharp)

[Flags]
public enum TestFlags
{
    One = 1,
    Two = 2,
    Three = 4,
    Four = 8,
    Five = 16,
    Six = 32,
    Seven = 64,
    Eight = 128,
    Nine = 256,
    Ten = 512
}


class Program
{
    static void Main(string[] args)
    {
        TestFlags f = TestFlags.Five; /* or any other enum */
        bool result = false;

        Stopwatch s = Stopwatch.StartNew();
        for (int i = 0; i < 10000000; i++)
        {
            result |= f.HasFlag(TestFlags.Three);
        }
        s.Stop();
        Console.WriteLine(s.ElapsedMilliseconds); // *4793 ms*

        s.Restart();
        for (int i = 0; i < 10000000; i++)
        {
            result |= (f & TestFlags.Three) != 0;
        }
        s.Stop();
        Console.WriteLine(s.ElapsedMilliseconds); // *27 ms*        

        Console.ReadLine();
    }
}

Over 10 million iterations, the HasFlags extension method takes a whopping 4793 ms, compared to the 27 ms for the standard bitwise implementation.

My view is that the IDE should do most of the grunt work for you, and free you up to be creative. The language and IDE shouldn't get in the way - they should help you along. This is why I refuse to code any JavaScript in anything other than Aptana -- it does the work and lets me do the creation.

Try Jetbrains Webstorm (or phpstorm).  I have, and haven't gone back.  A lot lighter that Aptana, and just as good.

[Jibz]

I totally agree with the idea that knowing what happens behind the scenes gives you far more potential for writing good code -- though sometimes it can get in the way of quickly writing code that is good enough . I think perhaps C is a better starting point for getting this knowledge though, since it is so much smaller as a language.

I think you are perhaps falling into the trap of defending C++, when the article isn't really attacking C++ (unless you view is that C++ should be used by everybody for everything). The author even repeatedly says he likes C++, and is just trying to point out that the recent interest does not mean that everybody should start using C++.

[mouser]

For me, the major problem with the new C++0x is that it's hard for me to see the audience for it.  It seems to me to be almost a last gasp that is going to turn into more of a poison pill..

C++ is my native language -- i've been coding in c++ for 25+ years, and I still love it.

But I just don't see the new stuff being added as satisfying anyone.

If you really want to dig into the more modern programming language ideas.. you are not going to want all of the legacy backward-compatibility messiness that C++ is committed to supporting.  The backward compatibility is one of the real strengths of C++ but it makes the language much less clean.

And on the other side of the coin, if you are coding in C++ because of the backward compatibility stability and large code bases, and are attracted to the lean and mean C++ principles, then all of these new features in C++0x are probably not only things you weren't wanting, but may cause you some concern that you're now going to have more incompatibility issues with old compilers, etc.

It seems to me that the new C++0x may really just hasten the extinction of C++.  I'm just hopefull it will help inspire the next breed of programming languages.

[mouser]

Perhaps a better way to say what i was trying to say is that, C++ is now trying to do two things that are very fundamentally at odds with each other:

It is trying to continue the C++ tradition of being strictly backwards compatible, for which it pays a very heavy price in terms of simplicity and consistency, while at the same time trying to absorb the more modern advances in programming language design.

Trying to do both of these things feels to me like you are courting disaster.

And you have to ask yourself -- who is clamoring for this?  The people who want to use modern programming language features don't want to be tied to ugly backwards compatibility compromises.  And the people for whom backwards compatibility is of top importance, I can't imagine they would welcome all of these new features.

There is a big market for modern programming language design -- C++0x is never going to be at home here because of all the cruft baggage it has to carry from its past.  And there is a smaller market for legacy C/C++ code -- this market is not going to be thrilled with these new features.

I just don't see an audience for C++0x.

Now I still think there *IS* a market for a new modern programming language that embraces the control over resources and the emphasis on performance that C++ has always focused on. That's something that I've been waiting a long time for.  But it's not going to be C++0x, it's going to be a new language that doesn't have to carry the baggage of backward compatibility that C++0x is burdened with.

[Jibz]

Languages like D, Go, and Rust are often mentioned in the context of systems programming languages.

[mouser]

I gave D a good long look a while back.. it's definitely got the feel of an evolved C++, but didn't quite do it for me, and I have concerns about its longevity.

Never heard of Rust, going to give it a look.

I'd love to be involved in designing a new modern language that could capture the spirit of C++..

[mwb1100]

The biggest problem with C++ is that it lacks a large, high level standard (or standard enough) library for things like network communication, file and directory operations (beyond reading and writing files).    In C++ you have to decide if you want to roll your own or choose from one one of several competing alternatives and get it integrated into your build system.  Boost is the closest thing to this, but even Boost is far from universally used.

Then if you pull something down from the internet that looks to be useful, you have to make sure it'll work with your chosen library/libraries, decide to port it to those if necessary, or pull in yet another dependency (and hope there are no conflicts).

All of this exists for other languages to some extent, but it's far worse for C++.  Herb Sutter has indicated that a focus for the next stages of C++ standardization will be to try to extend the library to address this:

I’ve been beating the drum this year (see the last section of the talk) that the biggest problem facing C++ today is the lack of a large set of de jure and de facto standard libraries.

There's also an indication that the C++ standardization process will try to move somewhat faster than the historically glacial pace it's taken in the past:

ISO C++ standardization is accelerating. Major companies are dedicating more people and resources to C++ standardization than they have in years. Over the next 24 months, we plan to ship three Technical Specifications and a new C++ International Standard.

Both of these goals are probably more difficult with C++ than other languages because C++ standardization is pretty truly a committee driven process - there is no single stakeholder that can dictate things as there is for most other languages. But it appears that many players in the C++ standardization process are trying to move it along (http://www.isocpp.org). Unfortunately, people who work on GCC don't seem to be represented very strongly at isocpp.org. Possibly because there's a significant cost - Gold at $10,000 per year, Silver at $5,000 per year, or Bronze at $1,000 per year.