7 ms·

It is one language. Many of those subsets are not mutually exclusive. Regardless of what your preference is, if you claim to know C++ you need to at least know

It is one language. Many of those subsets are not mutually exclusive. Regardless of what your preference is, if you claim to know C++ you need to at least know some of its basic features, such as references, streams, templates, STL, etc. (features that have been around for a long time). And if you claim expertise, to at least be familiar with basic features from the new standards.

TickleSteve 10y ago
true, they're all overlapping subsets.... The point being that the way you structure your software in each of those styles is very, very different. They're all idiomatic C++.... just different idioms. In fact, thinking about it, thats what it is... C++ is a multi-idiom language.
- ratboy666 10y ago
  Sure, with an execution model that is so complex that it takes scientific experimentation to determine the /best/ (in terms of execution speed) to write code to manipulate a simple memory mapped device. (This, from the lecture). That is so complex, it is the only language that I need the language at hand to read someone else's code. Not a library reference, a /language/ reference. Indeed, I am maintaing one C++ application. This is a wrapper for CEF3 (https://cefbuilds.com/ https://cefbuilds.com/). This is the Chromium browser as a library. I have to support the library and wrapper on two platforms: Linux 64 bit and Windows 64 bit. Note that the usual Windows build uses the Microsoft C++ compiler. But, I am uses mingw. This requires source code edits to compile! I blame the complexity of the language. Indeed, C++ is so difficult that the shop I work for (which is, by the nature of our product, very conservative) has gone to Java instead.
  - pjmlp 10y ago
    We did the same in 2006, and are mainly a Java/.NET consulting shop nowadays, but I still use C++ on side projects. Given language difficulty, while I hope never to maintain C++ code that makes use of SFINAE, Java's simplicity is misleading. The language might appear simple, but mastering the whole Java eco-system (JSE, JEE, Spring, embedded, Android, features per JDK version), performance monitoring tools, commercial JDKs and IDEs, isn't that easier either.
    - satysin 10y ago
      There is nothing "simple" about Java once you get past the basics. When you get into the EE world it gets extremely complicated.
      - pjmlp 10y ago
        Which is exactly my point. Also the reason I argue that those that think Go will be kept simple, just aren't prepared for the eventual mainstream enterprise adoption. Imagine when IBM or similar, releases their vision of GoEE.
        satysin 10y ago
        I think Go depends in if Google want to take it from a language that solves their problems well to one that solves generic enterprise problems.
      - qwertyuiop924 10y ago
        No. There's everything simple about Java. The semantics of Java are actually pretty simple, at least compared to C++. What's complicated are the monstrosities people build with Java, but those aren't inherent in the language. Saying that Java is complicated because EE exists is like saying that C is complicated because Linux exists: Complexity can be built atop simplicity. And for some reason, Java is a complexity magnet.
        MereInterest 10y ago
        I would say that the complexity of a language and the complexity of programs within that language are inversely correlated. Java is a very simple language, but as a result, the programs written in it must be more complicated to make up for the shortcomings of the language. As an example, Java's lifetime rules are much simpler than those of C++. At some point after all references are gone, the object will be garbage collected. Simple. But as a result of this simplicity, you don't know when the finalizer will be called. You can't use it, for example, to flush and close a file, because you don't know when file will be closed. Instead, you need to use try/except/finally, and so you can't add this to an existing class, because it would require code modification from all the users of the class. Up until Java 8 and lambda functions, functions could not be passed as arguments to other functions. Therefore, the developer needed to make an entirely new classes derived from "Callable". Complexity that came from the simplicity of the language. C++ has a lot of complexity in the language itself. I won't deny that. What I will argue is that the complexity of the language enables simplicity in programs. Edit: Lambda statements came in Java 8, not Java 7.
  - TickleSteve 10y ago
    Platform API differences != language complexity. These are two different things, platform differences are normally handled by a simple abstraction layer (or ifdefs if you're into masochism).
Scea91 10y ago
If you claim expertise you have to be more than familiar with the basic features. Thats not expertise.
- partycoder 10y ago
  Strictly speaking, that's true. But in terms of knowing the latest features, it might be hard to keep up with the latest developments in C++, especially since even if a standard is released, it takes some time for compilers to implement them.
dunkelheit 10y ago
Your list of common features is a bit too broad. For instance a common sentiment among game programmers is "STL is shit, you better don't touch it at all".
- caseymarquis 10y ago
  What's the reasoning? I haven't regularly used c++ for ~8 years, but I know the basics. I thought the downside to STL was increased executable size? If there are no generic constraints I can imagine issues popping up; effectively using generics in .NET often means using a non-generic abstract base class, building the generic class on top of that, and then constraining the generic type to the abstract class. A pain compared to Java, where you have runtime type erasure, but worth it IMO for the better reflection. I figure there's some similar quirk/gotcha in c++?
  - dunkelheit 10y ago
    I guess the main gripe is performance. Using STL containers involves lots of implicit heap allocations and copying things around (this last thing should have improved after the introduction of move semantics, does anyone have any numbers on that?). Most of the times performance is perfectly acceptable but a few cases when it is not + inertia can give rise to this anti-STL sentiment. Here for example std::string takes a beating: https://news.ycombinator.com/item?id=8704318 https://news.ycombinator.com/item?id=8704318

TickleSteve 10y ago

true, they're all overlapping subsets.... The point being that the way you structure your software in each of those styles is very, very different. They're all idiomatic C++.... just different idioms. In fact, thinking about it, thats what it is... C++ is a multi-idiom language.

ratboy666 10y ago
Sure, with an execution model that is so complex that it takes scientific experimentation to determine the /best/ (in terms of execution speed) to write code to manipulate a simple memory mapped device. (This, from the lecture). That is so complex, it is the only language that I need the language at hand to read someone else's code. Not a library reference, a /language/ reference. Indeed, I am maintaing one C++ application. This is a wrapper for CEF3 (https://cefbuilds.com/ https://cefbuilds.com/). This is the Chromium browser as a library. I have to support the library and wrapper on two platforms: Linux 64 bit and Windows 64 bit. Note that the usual Windows build uses the Microsoft C++ compiler. But, I am uses mingw. This requires source code edits to compile! I blame the complexity of the language. Indeed, C++ is so difficult that the shop I work for (which is, by the nature of our product, very conservative) has gone to Java instead.
- pjmlp 10y ago
  We did the same in 2006, and are mainly a Java/.NET consulting shop nowadays, but I still use C++ on side projects. Given language difficulty, while I hope never to maintain C++ code that makes use of SFINAE, Java's simplicity is misleading. The language might appear simple, but mastering the whole Java eco-system (JSE, JEE, Spring, embedded, Android, features per JDK version), performance monitoring tools, commercial JDKs and IDEs, isn't that easier either.
  - satysin 10y ago
    There is nothing "simple" about Java once you get past the basics. When you get into the EE world it gets extremely complicated.
    - pjmlp 10y ago
      Which is exactly my point. Also the reason I argue that those that think Go will be kept simple, just aren't prepared for the eventual mainstream enterprise adoption. Imagine when IBM or similar, releases their vision of GoEE.
      - satysin 10y ago
        I think Go depends in if Google want to take it from a language that solves their problems well to one that solves generic enterprise problems.
    - qwertyuiop924 10y ago
      No. There's everything simple about Java. The semantics of Java are actually pretty simple, at least compared to C++. What's complicated are the monstrosities people build with Java, but those aren't inherent in the language. Saying that Java is complicated because EE exists is like saying that C is complicated because Linux exists: Complexity can be built atop simplicity. And for some reason, Java is a complexity magnet.
      - MereInterest 10y ago
        I would say that the complexity of a language and the complexity of programs within that language are inversely correlated. Java is a very simple language, but as a result, the programs written in it must be more complicated to make up for the shortcomings of the language. As an example, Java's lifetime rules are much simpler than those of C++. At some point after all references are gone, the object will be garbage collected. Simple. But as a result of this simplicity, you don't know when the finalizer will be called. You can't use it, for example, to flush and close a file, because you don't know when file will be closed. Instead, you need to use try/except/finally, and so you can't add this to an existing class, because it would require code modification from all the users of the class. Up until Java 8 and lambda functions, functions could not be passed as arguments to other functions. Therefore, the developer needed to make an entirely new classes derived from "Callable". Complexity that came from the simplicity of the language. C++ has a lot of complexity in the language itself. I won't deny that. What I will argue is that the complexity of the language enables simplicity in programs. Edit: Lambda statements came in Java 8, not Java 7.
- TickleSteve 10y ago
  Platform API differences != language complexity. These are two different things, platform differences are normally handled by a simple abstraction layer (or ifdefs if you're into masochism).

Scea91 10y ago

If you claim expertise you have to be more than familiar with the basic features. Thats not expertise.

partycoder 10y ago
Strictly speaking, that's true. But in terms of knowing the latest features, it might be hard to keep up with the latest developments in C++, especially since even if a standard is released, it takes some time for compilers to implement them.

dunkelheit 10y ago

Your list of common features is a bit too broad. For instance a common sentiment among game programmers is "STL is shit, you better don't touch it at all".

caseymarquis 10y ago
What's the reasoning? I haven't regularly used c++ for ~8 years, but I know the basics. I thought the downside to STL was increased executable size? If there are no generic constraints I can imagine issues popping up; effectively using generics in .NET often means using a non-generic abstract base class, building the generic class on top of that, and then constraining the generic type to the abstract class. A pain compared to Java, where you have runtime type erasure, but worth it IMO for the better reflection. I figure there's some similar quirk/gotcha in c++?
- dunkelheit 10y ago
  I guess the main gripe is performance. Using STL containers involves lots of implicit heap allocations and copying things around (this last thing should have improved after the introduction of move semantics, does anyone have any numbers on that?). Most of the times performance is perfectly acceptable but a few cases when it is not + inertia can give rise to this anti-STL sentiment. Here for example std::string takes a beating: https://news.ycombinator.com/item?id=8704318 https://news.ycombinator.com/item?id=8704318