[arandr0x]

I've read some of the drafts and the final spec of the APIs I care most about, for example, the concurrency API (which I like a lot... I'm not solely complaining!). Do I need to watch every talk on every C++ feature before anybody in the C++ community will want to talk to me? Because I'm paid to actually write code. (I mean normally. Today my boss isn't back from vacation so you get to read my rants on HN.)

Here are the C++ subjects of interest to me:

* geometric primitives. Not having basic geometry by now is insane.

* concurrency, I think the API as it is is good, but some of the APIs around atomics (mostly the difference between compare_exchange_weak and compare_exchange_strong) are not clear, I have had to explain those to coworkers before. Why can't we have something called test_and_set like on atomic_flag that's an OK default? Also, while I perfectly understand why that's the case, atomics have deleted copy constructors and that tends to generate compiler errors. I don't get why compilers can't just generate default constructors that don't copy the atomic like all my coworkers keep having to write and potentially introduce errors in

* filesystem API, very excited for that but sort of worried it will not work on every platform and especially that it'll work terrible on windows. I have to write Windows/Linux/iOS/Android C++ so a bunch of my gripes are "the standard is inconsistently supported" and I supposed that's not the job of the standards committee to enforce... but maybe they could stop inventing new stuff for Microsoft to screw up...

* few other misc things. The fact X const& and const X& are both valid leads to every project having its own "standard" of const placement and it's not great to read, etc. not major stuff. But things that are of concerns to working programmers.

I'm not really complaining, I love C++ and being a C++ programmer and you couldn't pay me enough to go integrate idiosyncratic web frameworks. However I think you must admit that the C++ community, beyond the language itself, is a little exclusive and not super friendly to people who are not as knowledgeable as others. I have a little time to learn some of this stuff, and I would be happy to, but I will never be an expert like most of the standard committee is. Based on your message I think that makes me and my opinion not welcome? If so that's OK, but, um, there's a lot more of me than there are of them in this industry.

(edited for formatting)

[chris_wot]

On the X const& and const X& issue, I wish that everyone would use X const& and never const X& - it would make the rule that "the thing on the left is the subject of the const" much easier.

[mattnewport]

The standards committee is a volunteer effort. Some of the most active participants have employers who consider their involvement as part of their job responsibilities so they are at least partly being sponsored by their employers but plenty of people involved in the standardization process and attending conferences are not paid by anyone for their participation and are in fact paying the costs of attending out of their own pocket. Hardly anyone in the C++ community is directly paid to sit around learning more about the language. If you wanted a career where you didn't have to put in learning on your own time to keep your skills current I think you picked the wrong one.

It's a fairly involved process to get a new library standardized. Functionality that's not included in the standard library may be missing because it's hard to get agreement on what is required, because there isn't anyone sufficiently motivated to drive it through standardization or because the committee just hasn't got round to it yet.

I don't consider this particularly problematic in many cases. Some functionality probably shouldn't be part of the standard IMO. For example, there's been some effort to standardize a 2D graphics library and I'm of the opinion that should not be part of the C++ standard. I'm inclined to think the same thing for geometric primitives, for similar reasons. Certain types of library are better left to competing open source libraries for now I believe.

Implementations are not the domain of the standards committee. It's rather inconsistent to demand relatively niche new library functionality for geometric primitives at the same time as wanting the committee to stop adding things to the standard faster than Microsoft can keep up however.

Concurrency is complicated and there are a lot of pitfalls which the standard library has gone to great lengths to avoid. It sounds like you're misunderstanding the best way to use atomics but without knowing more about your use case I'm not clear exactly how.

Coding standards are not really the domain of the standard and some things that have multiple possible ways to write them have to be maintained for backwards compatibility. If you want to standardize things like const placement however, tools for automatic formatting and transformation of C++ are getting better all the time thanks to clang/llvm.

C++ occupies a niche which necessitates it being a bit less beginner friendly than some languages and a bit more demanding on users putting in the effort to learn the language. That's what makes it fairly uniquely suited to certain use cases. I don't see that as a bad thing. I don't really know what you're asking for to be honest. My advice to anybody who uses C++ as a major part of their career to invest a decent amount of time into learning it better though, just as I'd advise them to spend time learning more in any domain that is a big part of their professional life.

[arandr0x]

Thank you for replying in-depth, I didn't expect it. I actually agree with you re: 2D graphics(I was aware of it already), I just think geometry is different because it has wider applications. Your viewpoint is consistent though.

Again, I think concurrency is one of the parts the standard library does best. (And I think part of the specifics of this is it has primitives like async and future that are higher level and are much easier to explain. I happen to write lock free data structures often enough that finding blog posts at a good level to explain the API for atomic to my code reviewers is a need/bother for me, but there are also plenty of concurrency use cases where I don't need atomics, and I also read that there was a plan to allow parallel execution for most of the algorithms in the standard lib, I don't know if that's in MSVC yet but that's an example of things I like).

I don't blame the standards committee for implementors. In general, it must be terribly difficult to be on the standards committee, and have to deal with stuff implementors have already done, stuff they won't do, and stuff they are telling you they are doing but will not do right in the end. OTOH, as a end user, you have to understand that I have to deal with implementors, and they affect how I think of a given C++ feature, some of which look awesome in the text but are impractical because of implementor differences. I'm not alone: every C++ dev I know has a subset of C++ features they have deemed "practical", based on things like implementation performance, compiler error messages, how many characters the function names have, etc., and part of the problem is it's not the same subset for all C++ devs. Sometimes I wonder if there shouldn't be a subset of the standard (and I don't mean the C subset!) that's earmarked as beginner-safe and compilers could enforce the, well, beginner-safeness of code that is meant to be foolproof... but I suppose your angle is code meant to be foolproof should either never allow a beginner within 50 feet of it or be written in Java (or Rust?). Which, I get.

I would like to clear up a misunderstanding that I think you had: I do not spend zero time learning about C++. I'm not super confident and I think by HN standards I am not very experienced in C++ (or anything else), I'm definitely not at the level where people at CppCon would want me in the room, but people at my workplace do come to me for help with that stuff a bunch of the time. I tend to volunteer to explain newer or more complicated parts, etc. I'm a mid-level dev generally and C++ is my main language, and I'm not significantly more ignorant than my coworkers about it. If that is below the threshold at which you will consider someone worthy of talking about C++ on the Internet, maybe that's why C++ doesn't have that many beginner-friendly communities around.

[mattnewport]

I have no threshold for when someone is worthy to talk about C++ on the Internet. What I don't particularly like is people complaining about things they don't seem to have made much effort to understand. I'm happy to answer questions for people who genuinely want to learn about C++ (my top 5% ranking for C++ answers on Stack Overflow attests to that I think).

There's never been a better time to learn C++ - there's a wealth of free resources online from conference videos to blogs to podcasts like CppCast. C++ standardization is more active than ever and the language is getting better with each update to the standard and there is a real effort to also make it simpler which I believe is mostly succeeding. Implementations have also improved a lot in recent years. It's just the pace of change is such that there is work to do to effectively communicate that fact to people who don't pay much attention to the development of the language.

I think if you want a long term career in this industry you need to dedicate at least ~5 hours / week of your own time to professional development on an ongoing basis. If you work with C++ on a daily basis then spending some of that time working through CppCon videos (I like to watch at 1.25x speed) and other free online resources is a good idea IMO. I'd also advocate writing a bunch of small programs from scratch to explore unfamiliar features or libraries. Working through programming interview type problems can be good practice, or just try things out to satisfy your own curiosity. I'd say getting in the habit of writing a small program to experiment with something new was the biggest factor in increasing my comfort level and understanding of the language.

[arandr0x]

> I think if you want a long term career in this industry you need to dedicate at least ~5 hours / week of your own time to professional development on an ongoing basis. If you work with C++ on a daily basis then spending some of that time working through CppCon videos (I like to watch at 1.25x speed) and other free online resources is a good idea IMO.

Then I know what I'm doing tonight. I like the computational geometry aspect much better than the programming language part. The thing with C++ is very often the stuff you don't know sneaks up on you at the worst time when starting on a new library, or trying to reuse code more complex than you're used to. It's strange to think of it as something to study, but 5h/week is something I could do instead of more overtime.

>What I don't particularly like is people complaining about things they don't seem to have made much effort to understand.

The main thing I was complaining about was C++ takes (relatively to e.g. Python) a ton of work to understand accurately, but also to explain properly to other people. You must know that from answering on StackOverflow too. (There are features of C++ I don't use because I/my coworkers don't yet know them, and studying will help me with that, but I can't complain about them yet!) StackOverflow is actually great for C++ though, so thank you for answering on it. Usually there's always an answer with a detailed explanation even for strange code samples. Often it's through reading the other people's questions that I can understand how a construct can be useful in practice.

[mattnewport]

In my experience C++ may seem more complex to understand initially than something like Python but once you invest some time to really understand it then it is much less mysterious / less of a black box than an interpreted or JITed language, particularly when dealing with anything performance sensitive, because nothing is hidden from you under layers of abstraction that persist at runtime yet are relatively opaque to your debugging or profiling tools.

One of the nice features about C++ IMO is that there is very little "magic" in the standard library. Unlike some languages, all the features of the standard library can be implemented with standard language facilities that are available to you for use in your own code. Some of the more complex areas of the language however are there primarily to support library authors writing very general code and you don't need to fully grok them to be an effective user of the language. Learning about some of them over time however will likely pay dividends for your own code even if you are not writing widely used libraries.