back to article C++ Daddy Bjarne Stroustrup outlines directions for v17

Calm yourselves, readers. The Spring 2015 C++ Standards Committee Meeting takes place next week in Lenexa, Kansas. And at that meeting much of the discussion is expected to consider C++ 17, a major revision of the programming language due in 2017. C++ is currently in version 14, which was released last year, but last week C++ …

Page:

  1. Voland's right hand Silver badge

    Direction number one

    Put the poor thing out of its misery. Let's face it - it now looks like the creature from The Fly.

    Do the C++ and Java fans like it or not, a lot of the modern stuff like functional programming constructs heavily depend on late evaluation and runtime type checking. Trying to fit this square peg into the round hole of the strict compile time type check has resulted in a horryfying generics and lambda syntax in both. C++ (and Java) were not the most easy to comprehend language before that. With that, they are almost as bad to read as sysadmin (not professionally written) Perl.

    Just taking one look at the C++ (and Java 8 for that matter) shenanigans to implement any of the recent "must have" programming language features is enough. This thing has outlived its time, it is time for it to be put into maintenance mode instead of having new features grafted onto it.

    1. Martijn Otto

      Re: Direction number one

      I am quite sad I can only downvote your post once. There's not a single thing in your I agree with, except your criticism of Java (that thing needs to be taken out back and shot - with a rifle).

      1. Anonymous Coward
        Anonymous Coward

        Re: Direction number one

        @martijn, I'm happy to have Java taken out and shot, but if this is to happen, it's only fair that Java is allowed to stand behind your beloved c++.

    2. Anonymous Coward
      Anonymous Coward

      Re: Direction number one

      Languages evolve… the problem C++ was trying to solve in the early 90's is somewhat different to the problem being solved today.

      I recently started doing some serious C++ work using Qt and I was pleasantly surprised just how much the language had evolved and how much there was that made it truly feel like "managed code" languages such as C# and Java, but without the Windows-isms of C# or the quirks of Java.

      It has got to be by far one of the most universal programming languages, second only to C, as it will run on all kinds of platforms, not just general-purpose operating systems but real-time kernels and bare-iron too.

      1. Michael Wojcik Silver badge

        Re: Direction number one

        I recently started doing some serious C++ work using Qt and I was pleasantly surprised just how much the language had evolved

        The problem isn't C++ the language, which can indeed be very good if used judiciously by someone dedicated to the craft. (That sort of programmer is rare, true; but then the other sort will write crap in any language.)

        The problem is the vast corpus of existing C++ code. I've seen tens of thousands of lines of C++, in more than a hundred projects, from perhaps a few dozen organizations / teams / individuals. Nearly all of it is horrible: inconsistent, nearly unreadable, ill-conceived, and dangerous. Most of it fails to use even constructs from the '98 standard when it should, much less newer features. I don't know how many classes I've seen that muck up things like basic memory handling, for example by using default copy constructors and assignment operators when the class contains dynamically-allocated storage.

        Most of the decent C++ source I've seen is in textbooks - Stroustrop's own, Meyers' Effective C++, etc. But those models aren't adopted by most C++ programmers, it seems. C++ provides far too much freedom to an undisciplined development team, and most of them are undisciplined.

        So working with an existing C++ code base - and greenfield projects are relatively uncommon - generally means a three-way Hobson's choice: a huge refactoring effort, copying the broken style of the old code, or writing new code in a better but inconsistent style (and increasing surprise for later maintainers).

        There's no way for C++17 to fix that, though. Stroustrop's plans for it are reasonable. But as with previous updates, they'll help the good programmers much more than the bad ones, and they can't fix existing code.

    3. John Lilburne

      Re: Direction number one

      Indeed C++ has lost its way. It was once a language for developing major applications that could be maintained over a long period. No more. Software development has become more concerned with thin apps running in a browser on top of a back end database. Which get thrown away after a couple of years. I know a number of people that say that hardly any of the code they wrote 5 years ago exist any more. Either the website they wrote it for has gone, the company has gone, or the UI has been replaced.

      In such an environment the trend is to bash out code and move on. Languages have evolved to aid that hack and trash development process. So we have people coming out of CompSci courses that have little understanding of writing systems that can be maintained and repurposed for two decades or more. All they want to do is get a working prototype as quickly as possible, and move on.

      The C++ committee has spent the last several years pandering to short-termism.

      1. Anonymous Coward
        Anonymous Coward

        Re: Direction number one

        Ah, Agile development.

        As for C++, it was always, after the first couple of iterations (when programs had to be rewritten for each release) over-complicated and far too fond of black boxes. There seem to be endless class libraries for this handling and that handling, each with a massive book that makes the bible look short and concise. Every developer seemed to choose their own subset as few can keep the whole language in their head, usefully, at one time (unlike C) and not a few resort to writing straight C with a few C++ handy extras. The result is expense, complexity, inconsistency, lack of long term maintainability and frequent inefficiency plus some very obscure bugs.

        I'm sure there are beautiful, intelligible and efficient C++ applications. I just have not seen (at a code level) very many, well, none actually.

        I suspect we could all have been saved a lot of pain if Modula 2 or even Ada had taken over.

      2. joeldillon

        Re: Direction number one

        The other guy kind of covered this, but what do you think that web browser and back end database are written in? People writing stuff in high level languages that don't require deep understanding isn't exactly a new thing, it's just a couple of decades ago it was Visual Basic. There will always be 'hard' systems languages and 'easy' scripting languages because they address different areas of development.

        1. Ian Joyner Bronze badge

          Re: Direction number one

          joeldillon >>The other guy kind of covered this, but what do you think that web browser and back end database are written in? People writing stuff in high level languages that don't require deep understanding isn't exactly a new thing, it's just a couple of decades ago it was Visual Basic. There will always be 'hard' systems languages and 'easy' scripting languages because they address different areas of development.<<

          No - C and C++ are full of accidental complexity not essential complexity. C++ exposes all of this accidental complexity. Some people mistake this for being comprehensive and 'deep understanding'. It's quite the opposite - those with real deep understanding of computing realise what a horrendous mess C++ is. Those with deep understanding keep things simple, elegant, and complete without resorting to the mess of C++.

    4. Anonymous Coward
      Anonymous Coward

      Re: Direction number one

      "a lot of the modern stuff like functional programming constructs heavily depend on late evaluation and runtime type checking"

      Well for a start functional isn't that modern , its been around for decades and if it was really that good and really brought anything useful to the table beyond a few non essential fancy features it would have caught on years ago like OO did.

      Secondly, late evaluation and run time type checking requires lower level code to do this - its not done by the OS. What do you think this runtime/interpreter code is usually written in? Languages like C and C++ exist so high level fluffy coders like yourself don't have to do the hard stuff and can have the ironic luxury of whining that the hard stuff no longer needs to be done.

      1. Kristian Walsh

        Re: Direction number one

        "a lot of the modern stuff like functional programming constructs heavily depend on late evaluation and runtime type checking"

        Actually not even this is true - runtime type-checking is not essential - it only makes the task easier for the compiler/runtime authors, but if you look at a typical dynamic/late program using functional patterns, you'll see that in most cases the type of data being worked on is actually known, or can be defined, just by looking at the code.

        The type-agnostic statement of "An object with a field called X which I treat as an integer, and a method Y that I pass a Timestamp to" is another way of saying " class FooInterface { public: int X; void Y(Timestamp& t) }; ". If the compiler can do that intermediate step for you, then you can be just as expressive in a statically-typed language, while retaining the other advantages of static typing.

        This is the approach that Microsoft took with C# - it looks like you're writing "late-binding" code, but the compiler is generating specific template instantiations and interfaces behind your back to make things work. It's quite surprising to see how seldom you actually have to resort to real late binding.

        C# is an example of a language that, like C++, and unlike Java, has evolved steadily over the years to adapt to the needs of developers - what started out as a bad copy of Java is now a very nice language for developing applications, with some very nice syntactical features, like the "async" keyword.

      2. Michael Wojcik Silver badge

        Re: Direction number one

        Well for a start functional isn't that modern , its been around for decades and if it was really that good and really brought anything useful to the table beyond a few non essential fancy features it would have caught on years ago like OO did.

        I find it difficult to conceive how anyone with any significant programming experience could believe that software development is a meritocracy. Do they not have critical thinking where you live?

    5. John Savard Silver badge

      Re: Direction number one

      This is an argument for putting "the modern stuff like functional programming constructs" in some new language, and not trying to graft it on to C++. It is not an argument for abandoning a language which is still very useful. Of course, if that "modern stuff" becomes so important that interest in C++ declines, then one can talk about "maintenance mode" - but at the moment, languages which produce efficient executables without the overhead of runtime type checking are still very much needed.

  2. h4rm0ny

    D

    I wish D had achieved greater uptake. It was (is?) essentially C++ done again but "knowing what we know now".

  3. Herby

    Will anyone really understand the language?

    As the language grows, it (by nature) becomes more complex. The C language (for example) is described (an older version) in a book by the originators (K & R) that is only a 1/2 inch thick (I just measured it!). C++ in its originator book (from a bunch of years ago, I don't have it in front of me, but Bjarne DID sign my copy) is about 1.5 inches thick. Given this the language is at least three times as complex, and getting more so. Most "modern" languages (I include C++ here) are getting more complex by the minute, and they are getting too complex for one person to "know" without propping open some sort of reference. The problem is that the complexities are getting ignored and people use a "known subset" and fake the rest of it.

    Of course it gets worse when you need to link against some library, and (in C++) everything gets redefined because the author that it would be "cute". Then you attempt to learn another set of exceptions just to get your "simple task" done. It is a never ending task.

    Of course it gets worse. A book on python (Programming Python by Mark Lutz) is even thicker (a good 3 inches) and learning the language is even more difficult. It is a never ending task.

    As mentioned before "The nice thing about standards is that there are so many". To which I add: "and they are getting more complex!"

    I long for the Fortran 66 (an improvement over Fortran II) days, but that is just me.

    Yes, I did program a machine with Fortran II as its most complex language. It was a while ago!

    1. Dan 55 Silver badge

      Re: Will anyone really understand the language?

      There's the time you take in learning a known subset and faking the rest of it (also known learning the parts of the language you need when you need to and having that knowledge on hand for future projects) vs. the time you take in programming everything laboriously by hand like in a language which you can know completely like C.

      C++ gives you powerful tools and doesn't actively get in your way and stop you trying to do something. Other languages like Fucking Java just stop you doing things unless you rubber-stamp data through three or more classes.

      1. Bronek Kozicki
        Trollface

        Re: Will anyone really understand the language?

        "learning the language is even more difficult. It is a never ending task."

        Good, that's how it should be.

        1. Ian Joyner Bronze badge

          Re: Will anyone really understand the language?

          Software development is an essential complexity. The complexity in C++ is self-inflicted accidental complexity.

      2. Anonymous Coward
        Anonymous Coward

        Re: Will anyone really understand the language?

        "C++ gives you powerful tools and doesn't actively get in your way and stop you trying to do something. "

        True, But there comes a point when its time to say "Enough - any further changes should be put in libraries". There's been enough fucking around with the language - personally I've only just grokked C++ 2011 , never mind 14 and it seems to be a law of diminishing returns wrt functionality.

        "So what?" you might say, "just use the bits you need/know." Thats fine, except its getting to the point where everyone knows a different subsection of C++ and just uses that subsection for everything, which means when someone elses come to debug/update/maintain that code the odds are getting shorter that the maintenance coder won't understand a lot of it and it becomes a maintenance nightmare with knock on repercussions for the project.

        1. Kristian Walsh

          Re: Will anyone really understand the language?

          In C, everyone knows the core language and standard library (well, they think they do...), but everyone goes about every data structure problem in their own, unique way. You get landed with maintaining that code, you need to learn the peculiarities of this one guy's hybrid linked-list/b-tree data structures and his unique take on string storage.

          In C++ everyone knows the core language, and a subsection of the standard library, but at least they know that there is stuff in there that they do not know, and may have to learn in future if needed. However, everyone's "unique subset" is still a subset of an agreed whole. Once you're forced to learn that subset to maintain someone's code, it can be of use in other tasks. ( Like replacing someone's unique take on a particular type of container with a proven and maintainable version from the standard library)

          1. Anonymous Coward
            Anonymous Coward

            Re: Will anyone really understand the language?

            "You get landed with maintaining that code, you need to learn the peculiarities of this one guy's hybrid linked-list/b-tree data structures and his unique take on string storage."

            And in C++ instead of yet-another-b-tree-implementation you get landed with another guys idea of what a templated abstracted inheritence tree should be. Normally involving endless factory methods and 10 levels of inheritence. In C it simply would be too much work to implement anything close to that so people are forced to simplify their mental designs.

            Thats not an argument for C over C++, I'd be the first to admit that some standard things in C are just too painful - but C++ offering more standard functionality simply means it'll be abused in a higher level way than C.

        2. Adam Inistrator

          Re: Will anyone really understand the language?

          "Any new feature should be put in libraries". Like any developer you long for simplicity ... but you seem to forget the famous saying that everything should be as simple as possible BUT NO SIMPLER. There are relatively few C++ programmers so the average comment here is from programmers who dont use and dont really understand C++ and instead conceitedly grandstand their ignorance to mostly more of the same. bleh!

      3. Christian Berger

        Re: Will anyone really understand the language?

        "There's the time you take in learning a known subset and faking the rest of it ,,, vs. the time you take in programming everything laboriously by hand like in a language which you can know completely like C."

        In my experience typical problems in IT are easier to solve than reading into the library that does it, then finding out it won't work and trying to find out what you did wrong before finding out that you either misunderstood the interface of the library, or the library has a bug nobody found before.

    2. Tom 7 Silver badge

      Re: Will anyone really understand the language?

      The more you understand about programming the more you will understand the language. And possibly other languages too.

      The number of times I, and many colleagues, used to say 'Why would anyone want to do that FFS' only to later on another project going 'Wow! That's beautiful'.

  4. Phil Endecott

    Scribd

    Commenting only to say how awful Scribd, on which the linked presentation is stored, seems to be.

    I am allowed to view 3 of te 5 pages (on my iPad), at which point I am told that I must download their "free mobile app" in order to read the last two. FUCK YOU SCRIBD. I will not install some app just to view this! Bjarne, is this what you wanted? If not, maybe try Google Docs? Or just host it on your own website FFS!

    </rant>

    1. Dan 55 Silver badge
      Stop

      Re: Scribd

      It wasn't Bjarne that put it on Scribd. Really El Reg should also host the PDF and put a plain link to it in the article, they do that for the podcast.

    2. Anonymous Coward
      Anonymous Coward

      Re: Scribd

      I thought it was something broken on their site and left it at that. Perhaps I am right in a way…

    3. JLV
      Thumb Down

      Re: Scribd

      @Phil - upvote.

      Ha, ha, you're better off than me - I've NoScript'ed scribd a long time ago, on the basis that it is unnecessarily obnoxious and intrusive even on a regular webpage. Hate that site.

      Either you make your contents available publicly, or you do not. Either way is fine.

      Putting it on scribd === FAIL

      So this nice writeup appeared as a blank rectangle for me. Yeah, yeah, I could temp allow scribd.js on Noscript. But... it's scribd, that buzzard's not worth feeding.

      </curmudgeon>

  5. jake Silver badge

    Whatever.

    I've never seen anything that C++ can do that I can't do in K&R more easily.

    1. Alfred

      Re: Whatever.

      Maybe you've got your eyes closed. I have found many, many things that are much easier to do in C++ than in C.

      1. Anonymous Coward
        Joke

        Re: Whatever.

        Perhaps he meant resource leaks and bugs?

    2. Brewster's Angle Grinder Silver badge

      Re: Whatever.

      Unfortunately, I'm old enough to remember assembler programmers saying the same things about C.

      1. jake Silver badge

        @Brewster's Angle Grinder (may I call you BAG?) was: Re: Whatever.

        K&R is, to all intents & purposes, assembler. It's just easier to type/read across multiple platforms. Which is/was kind of the point of the language.

        1. Brewster's Angle Grinder Silver badge

          Re: @Brewster's Angle Grinder (may I call you BAG?) was: Whatever.

          @jake I found it got in the way, wasn't flexible and didn't give much back if you didn't need portability. (And I did do some K&R) And back then, most humans were better than compilers, especially on the register-starved, segmented x86.

          Strong typing, overloading (*cough* C99 tgmath abomination), and references helped make up for that.

    3. Kristian Walsh

      Re: Whatever.

      I've never seen anything a Japanese speaker can write that I couldn't write in English more easily.

      Or, to elaborate: 正直なところ、私は日本語を話す方法を知っていません。私はオンライン翻訳ツールを使用してこのテキストを生成するいた。

  6. James 47

    asio

    I::was::never::a::big::fan::of::boost::asio

    string_view? is that what's now string_ref?

  7. Moonshine
    Happy

    C++ haters: What about performance?

    I don't think C++ is going down the pan any time soon, simply because of one thing: If you have performance-critical systems then C++ is a sound choice. There's no interpreter, unpredictable JIT or garbage collection. It has proven success record, excellent support (paid and free) and huge developer community.

    OS development, real time systems, network software and drivers: Without C++ they would slow your whole system down and instead people would be complaining about "too many layers of cr@p, inefficient software, I remember when..., etc).

    C++ is here to stay and keeps doing its job.

    BTW I'm not a C++ evangelist, I like Python too.

    1. Brewster's Angle Grinder Silver badge
      Joke

      Re: C++ haters: What about performance?

      There are no "haters", merely those who can program C++ and those who aren't smart enough to. (Mobile Users: Joke Icon)

    2. jake Silver badge

      Re: C++ haters: What about performance?

      "OS development"

      Define "OS". Do you mean the kernel/monitor, or do you mean the massive amounts of shovel-ware that Cupertino and Redmond seem to think makes up an Operating System?

      "real time systems, network software and drivers"

      All K&R and/or assembler, not C++.

      1. Moonshine

        Re: C++ haters: What about performance?

        Define "OS"

        By OS I mean Kernel, Monitor, Hardware drivers, UI Shell, plus a bit of the "shovel-ware" such as browser, editors, whatever. Performance is everything on these components, it can make-or-break. C++ can give you this and allow some OOD implementation. Absolute no-brainer.

        All K&R and/or assembler, not C++.

        By K&R you mean C? Why not say just "C"? It's less to type. Yes, that would be a good choice also, but why choose it over C++? That does not make sense, it just smacks of personal choice, idealism, stubbornness and missed opportunities.

        Assembler? What, your joking right?, lots of development time, no portability, hard to maintain.

        1. Dan 55 Silver badge
          Windows

          Re: C++ haters: What about performance?

          "C" could be taken to mean C89 which is far too newfangled with stuff like type checking the function parameters and the POSIX spec. With "K&R" you know that the reader will be in no doubt that you're talking about the late-70s version of the language where stack overflows were real stack overflows and if they are in doubt then you will also have the opportunity to correct them which is even better.

          1. Moonshine

            Re: C++ haters: What about performance?

            Apologies, I didn't realise I was addressing K&R Fundamentalists. I respect that some feel compile-time Type Checking be the work of the Devil, also that the K&R blessed holy syntax checker is sacred.

          2. ST Silver badge

            Re: C++ haters: What about performance?

            > "C" could be taken to mean C89 which is far too newfangled with stuff like type checking the function parameters and the POSIX spec.

            I don't think the "far too newfangled" qualifier reasonably applies to C89. The C Standard is currently at C11. C89 is 26 years old. Maybe it's time to retire it.

          3. Michael Wojcik Silver badge

            Re: C++ haters: What about performance?

            C89 which is far too newfangled with stuff like type checking the function parameters and the POSIX spec

            POSIX and its successors (SUS) are not, and have never been, part of the C specification (ISO 9899).

            With "K&R" you know that the reader will be in no doubt that you're talking about the late-70s

            Technically "K&R" C goes all the way up until 1989, for the US, and 1990 for the rest of the world. (And, of course, K&R implementations continued to be used, and even produced, well after 1989, since it took a while for people to catch up to the standard. And similarly with later standards. Does Microsoft have a conforming C99 snprintf yet, for example? The Visual C docs suggest that no, they still just have _snprintf with incorrect, and stupid, return-code semantics. Sigh.)

            But, yes, I take your point. Jake seems to be using "K&R" to show his disdain for function prototyping and the like. Well, I've been writing commercial C since before standardization too, and I'm quite glad to have the C89 / C90 innovations, and some of the C99 ones as well. (I have no use for C94, but then who does?)

            He's also wrong about the "portable assembler" rubbish - even K&R C was hugely different from the assembly language of any major processor family, in concept, structure, abstraction, etc - but clearly that canard will never die. Programmers do love their category errors.

        2. Anonymous Coward
          Anonymous Coward

          Re: C++ haters: What about performance?

          "Assembler? What, your joking right?, lots of development time, no portability, hard to maintain."

          Compilers can't do everything. Some specific operations have to be done in assembler even if that assembler is wrapped up in a C function. Eg: interrupt calling, processor ring level switching

          Buy yourself a ticket on the clue train sometime.

          1. Ian Joyner Bronze badge

            Re: C++ haters: What about performance?

            Blotter: >>"Assembler? What, your joking right?, lots of development time, no portability, hard to maintain."

            Compilers can't do everything. Some specific operations have to be done in assembler even if that assembler is wrapped up in a C function. Eg: interrupt calling, processor ring level switching

            Buy yourself a ticket on the clue train sometime.<<

            Assembler is only needed on machines with flawed architectures that expose implementation details like CPU registers. Everything you might want to in assembler could be built into a HLL and compiler. But on the best machine I know, there is no assembler - all system software is built in ALGOL-based languages with interrupt handling, event handling for multiprocessing, etc. There is a special language for OS (NEWP), which provides specific constructs for specific instructions like context switching, but that is still ALGOL-based and never low-level like assembler or even C.

            It's time for the computing community to think different and challenge the very foundations and assumptions on which it is built.

      2. Dexter

        Re: C++ haters: What about performance?

        Jake wrote:

        "real time systems, network software and drivers"

        All K&R and/or assembler, not C++.

        --------------------------

        I must have been imagining all the real time systems and network software I've written in C++ over the last 20 years (device drivers I'll agree with, never seen one of those in C++). Many of those would have been exceedingly painful to do in C and would have resulted in unmaintainable code.

        C++ is a solid systems language which gives the same performance as C but is much easier to write and maintain.

        Just because you can't conceive of it, don't assume nobody else can.

    3. Anonymous Coward
      Anonymous Coward

      Re: C++ haters: What about performance?

      I don't think C++ is going down the pan any time soon, simply because of one thing: If you have performance-critical systems then C++ is a sound choice. There's no interpreter, unpredictable JIT or garbage collection. It has proven success record, excellent support (paid and free) and huge developer community.

      It'll linger around, but I don't see many new projects using it. As for unpredictable, take a look at the varying behaviour of STL implementations. Support isn't great either - I so love C++ compiler errors and stacktraces.

      OS development, real time systems, network software and drivers: Without C++ they would slow your whole system down and instead people would be complaining about "too many layers of cr@p, inefficient software, I remember when..., etc).

      Looking at the OS I'm using, the kernel is C and a little assembler, the drivers are C, the windowing system is C. All the real time systems I've worked on? C and a little assembler. Even the RDBMS (PostgreSQL) is C. As for speed, C is lighter and more predictable. For higher level stuff, Java runs rings around it unless you can waste many magnitudes more time fine tuning your C++ code.

      C++ is here to stay and keeps doing its job.

      What job, annoying people who have to maintain older codebases like Open/LibreOffice and giving Stroustrup the opportunity to foist more of his bad language design on us?

      BTW I'm not a C++ evangelist, I like Python too.

      How's that significant whitespace working out ;-)

      1. Moonshine

        Re: C++ haters: What about performance?

        As for unpredictable, take a look at the varying behaviour of STL implementations

        STLs vary across implementations, but each implementation is predictable in itself. However, a single implementation of a JIT, garbage collector plus other runtime management routines is unpredictable and uncontrollable by its very nature. You cannot have it both ways.

        C is lighter and more predictable. For higher level stuff

        C it's just as predictable as C++, because both compile into machine code executables (not bytecode), and are consistent at runtime; there's no comparison to be made here.

        Java runs rings around it unless you can waste many magnitudes more time fine tuning your C++ code.

        No, the opposite is actually true. C++ is compiled into machine code and runs, end-of. Java is compiled into bytecode which needs a JVM at runtime, which cannot hope to optimise to the same degree as a compiler. For evidence, google "performance c++ vs java" or see:

        http://benchmarksgame.alioth.debian.org/u64q/java.html.

        1. Anonymous Coward
          Anonymous Coward

          Re: C++ haters: What about performance?

          STLs vary across implementations, but each implementation is predictable in itself.

          Then I respectfully suggest you've not used many implementations. The standard(s) leave an awful lot of leeway for implementers to do things differently.

          C it's just as predictable as C++, because both compile into machine code executables (not bytecode), and are consistent at runtime; there's no comparison to be made here.

          Really? You think the class hierarchy complexity of a typical std::string implementation compiles to something as simple and predictable as glib's string abstraction?

          C++ is compiled into machine code and runs, end-of. Java is compiled into bytecode which needs a JVM at runtime, which cannot hope to optimise to the same degree as a compiler.

          That C++ has to be optimised at compile time. A "hotspot" JIT virtual machine can progressively optimise at runtime. Most studies show that while C++ code can be hand tweaked to outperform the Java equivalent, the degree of skill and time involved are extremely costly. For most typical programming tasks a language such as C# or Java is a better bet.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2021