Linus Torvalds doesn't like C++

  • Just wanted to share this with you C++ users. Ha ha!
    "Linus Torvalds on C++":

  • looks like only flaming.

  • Moderators

    Well, he is known for his dislike of C++. Still, Subsurface is now Qt-based :D

  • AH AH !!!
    Very nice thanks for sharing :)
    I like c++, but Linus seems to be a very praticall programer, I like the way he speaks his mind.

  • As c++ continues to "evolve" I begin to agree with Torvalds more and more. Which is odd, seeing how I am technically a c++ guy. It would seem the standard committee is very committed to make c++ even harder and less appealing to developers, in what I'd guess is an attempt to keep their salaries high, since most of the people on the committee are largely employed as "c++ experts".

    The committee keeps on expanding the language and throwing new stuff at developers to solve problems the language can easily solve internally. C++11 has expanded the language by about 50% for what I'd confidently evaluate as negligible improvements. So, making a language 50% larger and more complex for 5% increase of productivity and performance - "that does not for a very good language make". And it seems that the insanity has just began, there is even more bloat scheduled for the next release of c++, once again throwing new tools to solve problems in the worst possible way,

  • Moderators

    [quote author="utcenter" date="1390483199"]It would seem the standard committee is very committed to make c++ even harder and less appealing to developers[/quote]

    So true :)

  • Moderators

    Yeah, a mail from 2007 managed to get referenced in our forum.

    Considering that Linus subsurface program was just recently ported to C++... maybe he got more amendable in the last seven years.

  • That's the thing about committees - can you really trust people to do the right thing, when they are a bunch of different people with different affiliations, loyalty to different companies with different interests, each and every one of them pulling things his own way?

    In such scenarios, the outcome is at best a huge compromise, big enough to make enough committee members happy at the expense of gradually turning the language into an atrocity. I really don't see myself using C++ in 2015.

  • C++98:

    bool my_compare( const std::string &a, const std::string &b )
    { ... }
    std::sort( l.begin(), l.end(), my_compare );
    for ( std::vectorstd::string::const_iterator it = l.begin(); it != l.end(); ++it )
    { ... }


    std::sort( l.begin(), l.end(), []( const std::string &a, const std::string &b ){ ... } );
    for ( auto it : l )
    { ... }

    about 100% improvement in productivity

    I must be using it wrong :-)

  • [quote author="utcenter" date="1390483199"]..... and less appealing to developers.
    I feel you utcenter,some of the syntax in c++11 is so bad that the only thing that would push someone to commit it to mind is having no other option.But still, I personally find C++ to be a good balance point for developers who deal with both high level and low level stuff .You often have provide good UIs and figure out why that hardware driver is giving erroneous data.Not many languages can provide the flexibility C++ provides.

    A word of advice to the c++ standard comity and to us-- designers of things people use --in general, AIM FOR EASE OF USE and LISTEN TO YOUR COSTUMERS .Sometimes we get lost in the coolness of a technology and loose sight of problems the technology is intended to solve in the first place.

  • [quote author="utcenter" date="1390484115"]That's the thing about committees - can you really trust people to do the right thing, when they are a bunch of different people with different affiliations, loyalty to different companies with different interests, each and every one of them pulling things his own way?

    In such scenarios, the outcome is at best a huge compromise, big enough to make enough committee members happy at the expense of gradually turning the language into an atrocity. I really don't see myself using C++ in 2015. [/quote]

    Could you show us some features which turn c++ into an atrocity?


    boost up a lot of productivity if you use a lot of stl like algorithms

    Rvalue reference?

    I think this one is hard for most of the developers but also a pretty practical feature to have(big performance boost up in some cases)

    atomic, multithread?

    in c++14 or c++17, may support GPGPU too, for me this is a good news

    range-based for loop?

    I don't see that why range based for loop is good to have in c# but bad for c++

    variadic template?

    For those who craft high quality template library, this is a very important features to save them from extremely messy codes.Most of the developers don't need to deal with it(there are many developers don't even know how basic recursive work)?


    zero cost performance, save a lot of typing and make the codes become more flexible.With the help of IDE, we know the return type without a hassle.

    other libraries?

    Although the library is not perfect, but it is good to have a bigger one

    c++, java and c# want to provide flexibility, performance and productivity(ease of use blah blah blah) at the same times.When things get ugly(can't find a good balance), java and c# would prefer flexibility and productivity over performance, but c++ will prefer flexibility and performance over productivity(Whatever, it is a system programming from the beginning, it has to keep the promise)

    c++ is huge, but we don't need to know all of it to write good codes, A tour of c++ only 180 pages.

  • [quote author="stereomatching" date="1392011802"]
    Could you show us some features which turn c++ into an atrocity?

    Exactly, my point! In my example, c++11 reduce my code by half! Where are the atrocity examples? And I mean the one that c++11 force you to do... If you were already writing bad code before, no update to the language will help you.

  • [quote author="stereomatching" date="1392011802"][/quote]

    Lambdas and range based for loop... those were long overdue. I honestly can't give anyone credit for doing something so trivial that should have been done so long ago. Threading and and atomics - same thing, a little too little and a little too late.

    And yet, atrocities with lambdas have already found their way in the RT API, where you have to nest one lambda inside another lambda inside another lambda in order to specify async event handlers. You end up with a wall of code that goes against every modern programming principle, and doesn't even have an identifier to remind you what is it that it actually does. Granted, RT is microsoft, but still applies for a good example how lambdas can turn into an atrocity.

    Rvalue references and move semantics - that is the solution to an "issue" that should have been solved internally, throwing more language features at developers to do something that can happen automatically is an atrocity. There aren't that many different situations where you'd want to move and reuse stuff, and in 99.99% of the cases the compiler can tell if it is applicable to and do it automatically. Adding language features for the 0.01% of other cases is hardly justified, especially since in the rare cases it is needed you can implement it without C++11. You really need a whole new language feature, additional constructor type and extra operators to change the values of two pointers?

    Variadic templates are a powerful feature, but immensely ugly and unintuitive to use. I honestly wish I could meet the person responsible for the new features syntax and congratulate him... Another example - the syntax to specify template return type, what better way to implement that than to use the indirection operator and put the return type at the back of the function...

    What you seem to fail to realize is that performance DOES NOT necessarily have to impede flexibility and productivity. You can have a well performing language that is easy and fast to use, something that Qt itself has contributed to C++ by providing workarounds for many of the std "atrocities".

    The age old joke in the industry that "C++ is deliberately made so complex and awkward to keep salaries of C++ developers higher"... 5 years ago I would not agree with that, today I am not so sure. Whatever the agenda of the standard committee is, it has very little to do with making C++ a "better" language. Adding long overdue features other languages have had for a decade and implementing them in the ugliest possible way does not really contribute to making a language "better", it just ensures the language will not slip completely out of use. I think this is the balance the committee aims for - bring as little improvement as possible to keep the language alive and in use but bring them improvements in the ugliest possible way, so the language continues to be and even gets an even bigger pain the lower back area to use.

    The approach I chose for myself in the future is clear - C plus code generation. You can do everything in C, and you don't have to conform to a workflow conceived by what I very much doubt will pass for "rationally thinking human beings". You can easily implement ANY language feature in C using code generation. C for me is very close to what a perfect language should be - small, portable and unambiguous. Yes, it is very slow to use directly, but with code generation you can have every language feature you want, you can still have time-saving features of C++, plus it compiles even faster because code can be generated on demand, whereas the C++ compiler starts code generation only after you invoke the compiler, so it has to generate all code and then compile it.

    Using C does not only improve portability but compatibility as well. C has changed very little in the last decades, it is a stable foundation and you can expect that your custom code generated language features will work everywhere, nothing like the years of wait until C++ compiler vendors catch up with the standard. Nothing like MS's "additions" to C++ which render all your code incompatible with anything else but MS products. So, in a way you you also gain independence.

    Last but not least, using code generation you can do meta programming that will put C++ to shame. I mean meta-programming on the high level and large scale, which has potential for productivity improvement proportional to that of C++ compared to C.

    This way I have the best of both worlds - standard as well as problem-specific custom language features plus the raw performance of native code, and since it is only C, platform support is even better, since C does reach a little further than C++ in terms of platform support. And since it is all good old C, you can still link to and use all the quality libraries out there.

  • Some interresting points.

    First, the fact that a feature was overdue, does not make it an « atrocity », might make the language less attractive, no more. And show me any good feature of any language and I’ll show you a way to misuse and abuse it, just a fact of life.

    But where I always drop out of those arguments is when the proposed solution, like Linus, is to use C. I guess I have a more of a practical view of the problem, and in practice:

    C code is practically C++ code as well (practically, the differences are minor). Therefor, all the « goodness » of your perfect language, absolutly no compromises.

    C++ does add some « goodness » of its own, even if it’s just some syntax sugar to agglomerate data and functionalities (as classes), that, alone, saves me time.

    You are not forced in any way to learn, know and use every single feature of the language, including language extensions.

    Item 3. might be problematic as you have to define a subset of C++ to use for a successful project, but C does not fully solve that problem. MS has C additions too (you conviniently choose not to mention), same for GCC, there is more than one C standard now and the C standard itself defines optional features as well. So even if you do C, you still have to define your subset. C just make the task easier because of its smaller scope.

    For me, the advantages of 2. beat the drawbacks of 3.

    C++ started as « C with classes » more than 30 years ago, it was C plus code generation. If I understand correctly, your approach is to do the same, starting from scratch and getting it right this time. I truly hesitate between admiration, excitement and pessimism :-) Probably something that is scope limited and tailored for your project's needs will work for you.

  • bq. utcenter

    I prefer the standard solution.Yes, c is small, I could create or mimic the features I need(c++ could do that too, and it is much more powerful than c), but why do I have to recreate the wheel which c++ already implemented?Why not just make use the "standard" already implemented by c++?

    Create your own "language features" is fascinating for many programmers, you create them, use them, familiar with them and like them.But other's programmers need to spend more times to study your own "standard", this is simply a waste of times.

  • ^
    One of the reasons I decided to make “my own language” is because it really helps to know how things work and what happens internally, this saves a lot of frustration in cases where developer intent fails to materialize in reality. And above all, I am doing my best to make it as “logical” as possible, which sharply contrasts with a lot of choices made in C++ that I simply could not describe as logical. Also the standard makes very few guarantees, leaves a lot of “wiggle room” by not only not providing implementation guidelines for certain features, but deliberately providing none so that compiler vendors can do as they please. You end up with zero binary compatibility between different compilers, and of course who could forget the occasional ABI breaks. And for what? Supporting now extinct platforms? When was the last time you targeted a machine that did not have 8 bits in a byte? Have you ever?

    On the surface C++ is all fine and dandy, but the more you use it, the more you learn the standard and the details about particular implementations you cannot help but wonder “why”… And who knows maybe it is just me, but when I see something that does not behave the way I need it to, my first reaction is to make it rather than conform to it, which is the very reason I began programming, because at the time the “professional” software I used had too much stuff left to be desired.

    bq. Create your own “language features” is fascinating for many programmers

    C++ started this way, and for a long time it was absent the things I talk about. But then it got standardized, which IMO is what indirectly spoiled it. Not the very fact it was standardized but the fact this came with a standard committee, which mutated C++ from “one man’s vision of a better programming language” into a “everyone pushing his own way” mess. I guess the reason Stroustrup decided to standardize it was because he wanted the language to get more exposure. This worked… partially, by providing a standard with a committee Stroustrup ensured the language is being adopted by more industry players, but this came at a cost – the cost of allowing to mangle with it. He should have aimed at popularizing the language amongst developers instead, which might have been slower to spread it, but would have kept it cleaner and more useful to developers. Had C++ been easier to use it would be more popular, but Stroustrup’s approach to implementing the language made him dependent on the industry, so he had no choice but to give in to and give away the language to the committee and live with it.

    So, I am basically doing what he should have done – using a subset of C as an “intermediate” language, this way existing C compilers can be reused and if popularity for this language is to be intended, I will not have to allow the industry to mangle with it just so that they are willing to write a compiler for it.


    @sandy.martel – it is true, and when I said “I prefer C”, what I should have said is “I prefer a very small and portable subset of C”.

    And yes, as I mentioned above, you are correct that I am doing sort of the same thing as Stroustrup, I’ve spent time analyzing the factors which lead to the spoilage of C++ and I am taking precautions to avoid them. But I do not plan on making a “niche” language, on the contrary, I am aiming a little higher than creating a “general purpose programming language”. Whether it will succeed only time will tell, I will make it available to the general public when it is “production ready”. As for familiarizing people with it, I think the best way to do that would be to make the entire process of creating the language available as a training course. It beats reading a 1300 page book that only tells you “what”, but not “why” and “how”.

    And I know that when people hear “a new programming language” what they make out of it is more like “oh no, yet another programming language”. I agree we already have enough of those, and enough fragmentation. I want to bring a change to programming proportional to that of moving from punched cards to digital memory or moving from platform specific assembly to portable C. Both of those took place in the 20th century, and I dare say everything since then has only been slightly incremental, nothing groundbreaking. And if there is one groundbreaking thing that should happen to programming in the 21th century, it should be all those incremental steps converging into an easier to use and more universal programming language. And no, I don’t plan on making a “Swiss army knife” – the Swiss army knife might be a knife and a saw and a bunch of other things, but it is not as good as a knife should be, nor as good as a saw should be, it is a compromise for when you are on the go. There never will be a tool that fits all needs, but what I aim to create is more of a “universal workshop” with a wide assortment of quality dedicated tools, which is entirely doable. So that you don't need to have to be a "programmer" in order to program any more than you have to be a professional cyclist to ride a bicycle.

    Which brings us to another, more recent quote by Torvalds - "a good programmer does not look at the stars, he looks at his feet" - something I agree with, and something dictated by the currently available tools, which do require to give up a lot and adopt a rather odd mindset to become a proficient programmer. It is like saying "you need to know chemistry to be a good photographer" and 25 years ago that was true, until digital photography changed that and made chemistry knowledge obsolete for photography. I want to make it easier to program so you don't "have to look at your feet", so more people can retain their vision of the big picture and get the tools needed to implement it. Not everyone is born with a silver spoon up his bottom so he can hire a bunch of "worker drones" to accomplish his vision.

  • [quote author="sierdzio" date="1389777966"]Well, he is known for his dislike of C++. Still, Subsurface is now Qt-based :D[/quote]

    I don't think Torvalds will deny that C++ is a better match for application development. His dislike of C++ is on grounds OS development, or at least considerably large-scale projects, at least compared to something like subsurface, for which I'd say even C++ is overkill. And last, but not least, the decision to port it to C++ has very little to do with the actual language, and more to do with switching to a more reliable and portable application framework, e.g. Qt, which just happened to be C++ and cannot be used with C. I expect a programmer of his rank has actually abstracted the core logic from the UI well enough so that the actual port is just the UI part, and not some radical and inspirational full rewrite in C++ :)

  • bq. utcenter

    I forgot to tell you something, we can't solve the problem of "rvalue reference" elegantly without the new feature, because c++03 just lack the concept of "rvalue reference".

    ex :
    std::vector<heavyObject> A;
    for(size_t i = 0; i != 100000; ++i){

    without rvalue reference, how could you make sure when the vector
    size increase, the heavyObject can "move" to the right place when the size of the vector increase?if it is a two dimension array like

    std::vector<std::vector<heavyObject>> A;

    The performance will go down to toilet compare to the one which moveable.And I believe the examples I mentioned above are common case but not some "special case(0.1% to occur)" .

    you say we could use pointer or something like shared_ptr?This would make the codes become harder to use and maintain.Consider the case

    ps : neglect any exception
    //in this case, you have to take care of the memory by yourself
    std::vectorstd::string* some_factory(int style)
    std::vectorstd::string *result = new std::vectorstd::string;

    return result;

    someone may say, just use smart pointer, like shared_ptr
    but our purpose is "return the resource without any useless copy"
    but not "shared the resource", besides, object with reference count is more expensive.
    //what if we could just return the resource without any useless copy?
    //by this way, I don't even need to care about the exception safe
    std::vectorstd::string some_factory(int style)
    std::vectorstd::string result;

    return result;

    There are other example, like

    std::string A = B + C + D + E + ......

    How could the RVO or NRVO optimize the return value?

    without rvalue reference, we can't implement the "perfect swap"

    template<typename T>
    void swap(T &&a, T &&b)
    T temp = std::move(a);
    b = std::move(a);
    a = std::move(temp);

    There are many topics about rvalue reference, which explain what is it and why do we need them, if you find it hard to understand or unworth to understand, you could neglect it but still enjoy the performance boost up come by rvalue reference.

    Before c support RAII, I will stick to c++ no matter what.c is impossible to do something like RAII in c++ can do(template + class + destructor make RAII become possible, c just lack the concepts).I am tired to write something like this

    int a = (int) malloc (100);
    if(a == NULL) goto Clean_Up;
    int b = (int) malloc (100);
    if(b == NULL) goto Clean_Up;
    int c = (int) malloc (100);
    if(c == NULL) goto Clean_Up;
    //and so on.....

    //When you add or remove any pointer from the codes, you have to alter the Clean_Up too
    //this really piss me off, in c I have no choice but to follow this kind of coding style
    //in c++, I have more choices
    //...and so on

    RAII, something *c can not do *
    std::vector<int> a(100);
    std::vector<int> b(100);
    std::vector<int> c(100);
    //and so on

    //I don't need goto nor alter any clean up codes when I add or remove any vector
    //I will never "forget" to do that, this save me a lot of times

    I know how to write clean codes by c++(every language can write bad codes), manage the resource elegantly and effectively.
    but in c, I have to manage the resources manually, and this make the codes become much more harder to read and maintain

  • You sound like you view the various language features as some mysterious, precious and unreproducible magic. As I already mentioned RAII, RTTI, polymorphism, templates and pretty much everything can be done in C, and it is not all that hard to do at that.

    bq. but in c, I have to manage the resources manually, and this make the codes become much more harder to read and maintain

    That was the case for the majority of the C++ lifespan as well. If you were a "vanilla" C++ user and not a Qt developer, you'd realize the irony in your stance - you've already relied on tons of generated code, something done by both the C++ compiler and even more so by the Qt moc. You just view that as something taken for granted and merely to be used, and not as something you can easily do yourself and have way much more control over it, and therefore more flexibility.

    bq. I am tired to write something like this...

    You and me both, I don't know why you keep thinking about "programming the C way" when what I talk about is program in a very different way, just using some generated C for "portable assembly". And that is another reason to make my own language, because what you see as a "tedious necessity" and a reason not to use a language I see as something that can easily be automated, implemented only once by you and used on demand as much as you need. How hard is it to iterate through the local scope, generate a destructor call for every object that has one and then append it in reverse order to the local scope and get the "destructors" in the correct order (unlike your example ;)

    I never ever talked about doing "C programming" - what I talk about is just using C, but the language and its features and workflow have nothing to do with the C programming experience. As a matter of fact, programming in that language, depending on the task, can be anywhere from significantly to tremendously faster than C++ and as a "side effect" - that much easier.

    BTW I keep wondering how come people talk about C so negatively, like it is not something even worth using, and yet programming language usage stats based on search engine queries, job offerings and stuff like that says that C is and has pretty much always been the most widely applied programming language the last few decades.

  • bq. ucenter

    just do what you want and create your own favorite language by c(I don't see any reason why c++ can't do that), I have no interest to reinvent the wheel, as a humble, vanilla programmers, I would follow the widely adopted standard which could understand by many programmers but not some "self-created" language which only known by one or a few programmer(s).For me, "everything make by myself are better" is simply an arrogant sign, but this may not suit for some genius.

    bq. As I already mentioned RAII, RTTI, polymorphism, templates and pretty much everything can be done in C

    Please show us your language features(template, RAII, inheritance, polymorphism) which much more easier to control, manipulate(created by c), prove to us that reinvent the wheel is worth to do(except of "I can learn more by that way") by showing us cleaner, more efficient examples. Let us see how good you really are, let everybody judge it, not just insist that "I am very good, my language is even better", let us compare what c++ can do and your "beautiful, much better control, faster, easier to use, self-created language features".Talk is cheap, show us your codes(As bjarne said, "I have yet to see a program that can be written better in C than in C++, I don't believe such a program could exist").

    bq. By “better” I mean smaller, more efficient, or more maintainable. The myth that “C is simpler and more efficient” have caused (and causes) untold numbers of beginners to concentrate on obscure workarounds and difficult-to-master techniques, rather than learning how to use more powerful supporting features. Many then fall in love with their obscure and complex code, considering it a sign of expert knowledge. It is amazing what people can fail to learn when they are told that it is difficult and useless. The only reason I know of to use “plain C” rather than a suitable subset of C++ is lack of tool support on a given platform.

    Hope that you are a genius but not one of those "beginners" who fall in love with your own obscure and complex code.

  • ^^ Don't worry, when it is done it will be on the market.

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.