6 ms·

C++ shows that in theory you can fix any flaw in an existing programming language as long as you maintain backwards compatibility by simply adding more features

• flavio81 9y ago
  >C++ shows that in theory you can fix any flaw in an existing programming language as long as you maintain backwards compatibility by simply adding more features. Well, "adding more features" can't be done "simply" if you want to "maintain backwards compatibility"; indeed, in the process of doing this is that the "flaws" are potentially augmented.
• pjmlp 9y ago
  They also have removed features that were deprecated in C++11 and C++14.
  • humanrebar 9y ago
    Yes! These are underrated items on the change list. Establishing precedents and habits for removing harmful things (like trigraphs) is very important to the future of the language.
  • gcp 9y ago
    There's some funny ones there. std::random_shuffle because it relies on rand() which may be bad, but ironically most (all?) the rng's that are in the standard library would be considered "bad" by modern standards.
    • ska 9y ago
      "bad" for what purpose? The linear congruent stuff and Mersenne twisters, for example, are leaps and bounds better than a typical rand() implementation, and very appropriate for many uses.
      • gcp 9y ago
        Sure, but we have generators now that are both faster and better, so there's no point in using the standard ones, aside for convenience.
        • ska 9y ago
          aside for convenience. You say that as if it is a small thing. Convenience, lack of additional code to maintain, consistency across platforms - for many projects these things will easily trump any algorithmic improvements from using something else.
• duneroadrunner 9y ago
  You can use the SaferCPlusPlus library[1] to get closer to "java safety". C++ compile times are a problem. Apparently there is a C++ interpreter[2]. Anyone have any experience with it? [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://root.cern.ch/cling https://root.cern.ch/cling
• rb808 9y ago
  > I often have to modify headers that are included almost everywhere. I think this problem started with templates - previously you wrote abstract base classes (interfaces) and concrete classes had most of the code changes. I avoided templates where possible largely because of this.
• jackcviers3 9y ago
  > keyboard bashing is a cheap price to pay for what you're getting back Only if your program is trivial. That is, if you can afford to run it over and over with results you can verify in the output as being incorrect, sure, keyboard bashing works. Most of us work on programs that have been made trivial by abstracting the complexity into a framework or protocol library - like a web server. You can keyboard bash out a correct rest implementation on top of a routing library in minutes. The problem domain is tiny(but really flexible!), and largely automated by code generation in most languages. The programmer is only there to cross some t's and dot some i's. It would be a waste of productivity to write your own http server from the ground up. Writing one is non -trivial. For every new programming language that wants to serve web apps, a webserver must be written in that language. Having a compiler that verifies or does more for you on a non-trivial program is great. Not saying c++ is the right language here, just that a statically compiled program with an expressive type system catches more errors at compile time. Some/(most) bugs are unapparent in localized, repeated runs and unit tests that really only ever test a small subset of the range of possible inputs. I like easy as much as the next programmer, I just mourn the fact that we can't seem to provide a safe, simple and easy in the same programming language.
• gcp 9y ago
  Other than out of bounds memory accesses and legacy code I feel there is not much that can go wrong. If only we could stop at single-threaded applications :-) I'm not convinced modern C++ stops all issues with pointers/iterators and ownership either. But it's hard to tell because every large-enough application inevitable has to interface with legacy pointer code.
  • albinofrenchy 9y ago
    The point about legacy pointer code is valid, but the benefit of the newer pointer / iterator / ownership stuff isn't really that it is in and of itself a magic bullet. What it does do is make it easy to reason about how pointers are used across the application. Also worth noting that even with legacy libraries, you can wrap a given pointer with std::unique_ptr or std::shared_ptr and provide a custom deleter and maintain reasonable safety guarantees.
    • gcp 9y ago
      I do get it's easier. I use std::unique_ptr when interfacing with legacy code because I like that I need an explicit .release() to relinquish ownership. It's self-documenting. But I was considering modern C++ compared to, for example Rust. I'm not sure if the memory safety issue that Rust solves still exists as strongly with a purely modern C++ codebase...but then again I never run into those either. For threads it's no contest between Rust and C++, although TSAN is pretty damn nice.
  • mempko 9y ago
    Pointers are great! Without pointers, the web would not exist!
• zone411 9y ago
  Your complaint about the slow compilation times might be addressed partially by Modules, expected for C++20. VS 2015 Update 1 and Clang already have experimental support.
  • frozenport 9y ago
    Modules help, but you're still trucked if you change an underlying header.
  • jcelerier 9y ago
    in my experience when testing the current modules implementation, PCHs are still a good deal faster; if you use CMake they are dead easy to set-up so you may as well use them today.
• ksk 9y ago
  C++ is a tool for low level systems programming. Why would you compare that with GO? Also, I would argue that C++ is _WAY_ more popular than GO. It allows you to be productive in the real world, utilizing legacy code, legacy libraries, APIs, etc. Very few projects are 100% greenfield.
  • iamnewhereqwer 9y ago
    Many desktop apps are still written in C++.
    • ksk 9y ago
      Sure, people will ultimately use the tool they think is right for the job, given the people they've hired, etc. C++'s strength isn't UI programming (might be generalized to things that require more input from designer's than programmers), but writing high-performance, low-abstraction code (which could very well be the dominant factor in the success of the desktop app, hence the choice).
    • copx 9y ago
      "Many" is an understatement here. Pretty much every Windows desktop app is written in C++ and Windows runs on over 90% of all desktops. Adobe will never rewrite Photoshop in Rust or whatever. If you thought burying COBOL was hard.. C++ will outlast humanity. I can already hear the Alien scientists: "An amazingly intricate and convoluted language for such a primitive species. The mismatch between their mental abilities and their language might explain the bug which caused the incident.."
      • staticassertion 9y ago
        You wouldn't have to rewrite Adobe. You could rewrite one component of it (0 cost FFI). That's fair more reasonable. I think Servo is proving that Rust has a lot of potential for slowly replacing a C++ codebase, piece by piece.
        • pjmlp 9y ago
• staticassertion 9y ago
  > C++ shows that in theory you can fix any flaw in an existing programming language as long as you maintain backwards compatibility by simply adding more features. I feel like C++ proves exactly that you can't.
  • eslaught 9y ago
    > I feel like C++ proves exactly that you can't. Depends on what you mean. At a minimum, I think it's clear that C++ has avoided a Python 2/3 style split in the community. This means that otherwise relatively conservative users (I'm thinking of users on supercomputers in this case) are upgrading quickly to new C++ compilers and standard versions. On the other hand, C++ has always been a kitchen sink sort of language, and it is even more so now. As codes age, they tend to grow and not shrink in the feature set they use, and so long-lived codes will probably never completely escape the demons of previous versions, regardless of how nice the shiny new features are.
    • dzdt 9y ago
      Lol. At my work I am still eagerly awaiting the arrival of C++11.
      • EpicEng 9y ago
        That's not the point. The point is that, when you get it, you won't encounter a list of breaking changes and your code will continue to work.
        • ernst_klim 9y ago
          >you won't encounter a list of breaking changes and your code will continue to work. Sure, that's why my gstreamermm app refused to build when I switched to --std=c++17
          • EpicEng 9y ago
            Here's the list: https://stackoverflow.com/questions/6399615/what-breaking-changes-are-introduced-in-c11 https://stackoverflow.com/questions/6399615/what-breaking-ch... Was it one of those? If not then the fault was with your code or the implementation, not the spec. The language itself is very good at maintaining backward compatibility.
• jjaredsimpson 9y ago
  nit: Aren't pointer arguments also pass by value? The data is the memory address not the underlying pointed-to object.