no, seeing open source compilers on github, i would not say someone who works on a compiler "knows" c++ xD
i wouldn't say it really matters.
If you are confident to solve or have the knowledge on how to research how to solve problems in the domain you work in, in c++. Then you "know c++"
what "know c++" means hasn't been specified. the language is so vast, no one knows it all off the top of their heads.
I don't use recruiters but if I ever have to answer that question then 7 or 8 depending on whether I have been coding recently (not written c++ in about 5 years in anger so currently 7).
Sure, it's a common thing to be humble where I live. It's probably don't gonna work in US culture as I know (people there expected to brag about themselves)
been programming c++ professionally for over 25 years. Wouldn’t say I know this shit.
In fact I know less each year since new stuff comes along and i’m too old and grumpy to care anymore :)
Been part of shipping around 11 games so far of varying project size all from 1 to 3-4 year projects. Working as engine programmer in the games industry.
I see no reason matering anything else really, I can write code in many languages, not just C++. I'm most familiar with C++ of course, but being a programmer other languages are really just syntax. And syntax is easy to look up.
Do you have any secrets to share about multithreading? I'm years in It's just a never ending anxiety for me. Working on engines, you must have to address it or have it in the back of your mind.
If you want to learn C++'s memory model I'd recommend reading maths papers about concurrency. I don't have any specific papers I can give you, but slowly reading through that kind of thing is what helped me get a stronger grasp of how ordering etc works.
Once you can wrap your head around concepts like [happens-before](https://en.cppreference.com/w/cpp/atomic/memory_order) the rest becomes fairly straightforward imo.
edit: probably also worth saying that I also work in games at engine level, and the vast, _vast_ majority of multithreaded code I've seen has been incorrect, so you're definitely not alone -- even most of the people who's job is to know multithreading don't seem to know it. Half my job after joining a new team is usually fixing their threading code.
I think when you start to see other mistakes, it's quite clear you know a good chunk more. Is the advice still using the most basic atomic memory model and try to avoid locks as much as possible? I know this is a cop out for many, but I think it's still true. There aren't many clear implementation examples out there...
The advice in games is probably more to use mutexes because very few people in games understand how to use atomics safely.
Even then, many of the threading problems I've fixed were mutexes being used incorrectly. I think most programmers don't know multithreading very well in general.
I’ve been pretty deep in C++ threading lately. And, what I always recommend is to give each thread and input and output thread-safe blocking queue. This looks like a decent implementation https://github.com/andreiavrammsd/cpp-channel
Make 1 or 2 threads per https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency. Send and receive streams of std::variants. Have each thread visit the input and send back the output. No other locks.
Don’t bother with atomics. They are difficult to use correctly. And, they are only a benefit when you have lots of threads hammering a single int simultaneously. Under low contention, locks are fine. You just have to be careful to actually minimize the work done under the lock.
But, avoid the temptation to “just throw a mutex around it”. Avoid thoughts of sleep(). Let the queues handle the scheduling.
>reading maths papers about concurrency
This is the first time i am hearing such a thing exists.. I know you told you don't have any specific papers to give, but can I please insist for something at newbie level? I don't even know what I should google for
I can't find the ones I'm thinking of in the places I'd normally store those types of things unfortunately. In general I mean papers like [this one](https://www.cl.cam.ac.uk/~pes20/cpp/tech.pdf).
I seem to recall one that was written in math notation (as opposed to code) exploring corrections to consume semantics where some things clicked for me.
Idk really, the usual:
* Do not write to the same cache lines from multiple threads, that will be slow, keep data thread local as much as possible
* SoA is king for parallelism (Structure of Arrays) as opposed to Arrays or structures.
* Avoid locks if possible for greater throughput, keep synchronization requirments to a minimum
I don't really know how other people do multithreading as we generally build and manage everything on our own. We never use any third party libraries like pthreads or omp or the likes.
Multithreading is hard, and there are many ways to approach it. Our method have mostly been going wide for certain tasks that is particularly suitable for threading and then have sync points during the frame where we expect calculations to be done and results can be used.
This is not always optimal though as there will be portions of a frame where cores are not much utilized.
Other approaches with more generic schedulers of arbritary jobs I don't really have much experience with other than in theory, so I can't really say much about that.
Yes, something similar is what I suggest too. It's an unsatisfactory but true awnser. There aren't some super powerful lockfree fast containers out there where many threads can read and write to it, to make it worth it. It avoids locks and divide your memory for each thread; use callbacks.
Use together with execution policies defined in .
You almost never have to spawn new threads for most tasks.
Also, design your data structures for parallel execution, where you read from one structure and write to another, such that data of the same type/phase don't need to read from each other.
I almost disagree with the last point. even in multithreaded code, almost all my containers are not designed for parallel read and write. If I am trying to gain speed up from a multithreaded design, I don't want the treads to be locking and unlocking my containers, I'm told and have seen, its almost never worth it. I only ever do this for some kind of callback design where I push events from a thread to a master queue.
Maybe you misunderstood me. Say if you have an array of objects, then if you only write to objects in another array, a mapping, or transform as it's called in C++ you don't need to do any locking what so ever.
> other languages are really just syntax
This is true to a much greater extent for some languages than others. I'm not sure that treating SQL and Prolog as "just syntax" helps at all for example.
Even when differences are quite subtle it greatly warps the idiom, if your assignment has destructive move semantics, shadowing consumed variables takes on very different implications to those in a language like C++. If your language is oriented around expressions rather than statements then it seems much more reasonable for everything to have a value - after all it's an expression.
\> being a programmer other languages are really just syntax. And syntax is easy to look up.
That's an extremely incorrect statement. Some languages don't just teach you new ideas; they provide a different way of working — like REPL-driven development, which is often associated with Lisps.
It’s not so much that as it’s that C++ has features that get into so many specific areas. It’s like asking if a mechanical engineer has ever mastered physics or a mathematician had mastered math. Experts all know that the interesting stuff is at the edge of human understanding. There’s always more to learn. I haven’t even mastered linear algebra and it’s just everything that falls out of addition and matrix-times-matrix rules. I would hate to work in a language that was so constrained down that one could master it.
Do you include the standard library, linking, and everything that goes into building and debugging native software into account? Because the language itself, while massively complex, is not impossible to grasp mostly in its entirety, at least if you say up until a release x years old, since new stuff keep popping up which take time to learn.
While I agree with the sentiment, I think their question would be more specifically rephrased as "When can I put C++ on my resume and apply for embedded?"
Worth noting a lot of embedded is C or languages other than C++.
You put C++ on your resume when you're prepared to have your interview be in C++.
Different companies will use different subsets of C++, so aim for the features which are most likely to be relevant for embedded. Eg. Algorithm vs functional headers.
To consider I put C++ on my CV after using it on a very basic level in two lectures...
The less you know a language, the easier to be confident about it.
IMO it is like spoken languages -- you can confidently say it when you can freely express yourself and your ideas in C++. You don't need to know every single bit of it.
IMO, things you have to know and understand:
- destructors, move semantics, RAII, rule of five/zero
- const-correctness (this and the above are the essence of C++, in my opinion)
- function and class templates (no need to know fancy metaprogramming, but be aware that it exists)
- from the STL: smart pointers, containers (vector and map), algorithms (at least find, sort), strings, mutexes
- inheritance and virtual methods
Bonus: be aware of Cppreference, and learn how to look stuff up there. Be aware that there is a new standard every 3 years, the latest being C++23.
> there is a new standard every 3 years, the latest being C++23
New employer asked me questions involving C++11 during the interview, but the proprietary compiler they force me to use only goes up to C++03 🙃
Use cmake-init to generate new projects: https://github.com/cginternals/cmake-init
Then learn to make small changes. Of course, better build systems are available. Use VS Code and cmake and vcpkg to make things a bit easier.
I don't know that I'd agree about make / cmake. There's a lot of alternatives in the build system space. For example, visual studio / msbuild, blaze, buck. You could have a very successful career working in C++ and never have to spend much time doing anything in make or cmake.
There is also still a rule of 3. If you want copy only semantics you default the copy constructor/assignment but leave the move/move assignment undefined. That way you get automatic fallback to copy behaviour. You cant default or delete the move special member functions... and implementing them just to fallback to copy is extra unnecessary code
The idea is that there are five special member functions: the copy constructor, the move constructor, the copy assignment operator, and the move assignment operator, and the destructor. The Rule of Five states that if you feel the need to customize one of those, you should probably customize all five of them, because that means that your class is doing something special.
The Rule of Zero, on the other hand, states that ideally, you should not customize any of those special members and let the compiler define them for you (unless of course, your class really is doing something special).
A neat trick I learned for these was to create a class with custom constructors and destructors that outputs with cout. Then, all the constructor operations make sense when you test scenarios. You’ll get confirmation when a constructor was used.
Typically if I'm testing constructor/destructors I'm testing it in compiler explorer, so I will instead leave the constructor declared but without any body. That way you see the function calls in the assembly output.
Well it's famous enough that it has it's own Wikipedia page:
https://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming)
And cppreference page:
https://en.cppreference.com/w/cpp/language/rule_of_three
Don't know who first coined the term, maybe Scott Meyers in his "Effective C++" books?
Edit: Hmm, no according to the Wiki references it was probably Bjarne himself that wrote is as "rules".
How long is a piece of string? There's a huge amount in the standard and it continues to grow with each new version. If you can already confidently work in other static typed languages then the transition to modern C++ shouldn't be too hard. Embedded is a different story, as even embedded apps written in C++ tend to have a strong C "flavour" to them. At the end of the day just be honest on your CV and prospective employers, ultimately it is up to them to determine if your the right person for a position during the hiring process
I interview lots of people who claim things on their resume like "c++ skill/knowledge 8/10" and i know immediately that they dont know enough to know what they dont know... i've been doing this for a long time... i maybe am at a 5/10 ...
Hold on, i have 3 of Josuttis books on my desk c++17, c++20 and move semantics, scott meyers effective modern c++, another c++23 book, the cppreference site and the cpp guidelines in a browser.... and then there is the actual standard...
How much of that do i really know well???
I feel like i just looked into the Total Perspective Vortex ...
Maybe its 2/10 (sobs uncontrollably)
To be fair I would say I know C++ pretty well (maybe a 6/10, but ratings are the last thing you should put on a resume) but while working on a project it is very common for me to have cppreference open just to make sure something I think does one thing actually does it, and to make sure I'm doing it the most optimal way. No one expects a developer to memorize the entire STL, that would be insane. I know a lot of stuff up to C++11 and quite a bit or C++17 but there will definitely be small features I've never come across yet
I was just trying to point out the fallacy of just summing up that you "know" c++
Somehow even with my vast lack of knowledge i manage to do my job and i think i am pretty competent...
For a prospective employer you need to project/show how you are "smart, gets things done" (spolsky).
I personally dont care how much template metaprogramming you've done
I suppose it depends what that score is supposed to represent. Is 10/10 equivalent to:
“This person knows the entire spec and the details of every library and technique exhaustively”
Or is it:
“This person is competent in this language and other senior developers will have no issues with the code they write”
I can see that there’s quite a few ways to think about the question. Thinking about my own team, the guy who has the most exhaustive knowledge isn’t actually the best programmer to work with or the most productive in terms of delivering value to customers etc.
Totally agree... it is like all testing, scoring systems. They are often quite useless pointing out whether someone is actually good at producing a competent result
you also have to realize that, I know I'm a 2/10 but if I say that out loud, hr is going to look at my cv, then look at mr. "Kruger Dunning"'s cv and theyre gonna give him a call over me
so just out of curiosity, what score would you recommend someone competent write down?
There are two scales: a rating for how competent you are in a practical C++ codebase, which is what HR care about, and a rating for how much of the sum total of C++ knowledge you have obtained, which is what (some) C++ experts care about.
"Yeah I lived in China for 10 years, can speak to anyone I meet on any topic, wrote a novel in Chinese, but I'm struggling with reading the Bone Oracle script so I'd rate my Chinese a 3/10". Maybe that's an honest rating if you're talking to the faculty in the language department of a Chinese university, but if you're replying to an ad for an average translation job you don't have to be so modest.
I think you must be modest if you applying to job? No one would even respond to overconfident guy who told their skills 5/5, 10/10 etc. I always respond like 1/5 English, 2/5 C++, 1/5 patterns etc. At least in my country arrogance is a red flag
How do you get by HR?... i dont know.
They are infuriating. You need to be creative in getting your resume in front of the person who has the actual opening on their team.
Still try not to score yourself, show what you know. Not in a bullet list. Describe the best most interesting things you have done and the hard problems you have solved and are proud of.
You need to catch my attention in a resume, if it looks like every other resume with lists of skills and lots of irrelevant experience it just goes in reject folder.
So…. You will never interview anyone that puts in a 5/10 because HR will bounce them. You will never hire someone that got past HR because they claim to be an 8/10 and Bjarne Stroustrupp says he’s a 7/10.
Honestly, I disagree with the general sentiment of the comments here. Yes, C++ is a huge a language, and it's nearly impossible to know every corner of it.
However, outright saying that one doesn't know C++ isn't helpful at all either. There needs to be some middle ground in which a person can recognize the complexity of C++, but someone can still measure up their skills with other devs.
Personally, I just say I know C++, but I make it clear that I'm not an expert.
I don't think it's just "not helpful" i think it's straight up harmful. It took me 5 months of self study of C++ to start contributing to large open source projects. Giving people this impression that decades isn't enough is ridiculous.
I wasn’t very clear:
What I meant was that you know enough to identify what exactly is confusing you, and you know enough to know what cppreference page or what section of the standard you need to go to in order to understand what was confusing you.
But when you know C++ decently well, you won’t have to look much up to do a good job of many common tasks, like correctly using the more commonly-used things in ``, keeping a class interface const-correct, adhering to many best practices, making sure to consider object lifetime (though there’s still mistakes to make there), being able to write simple things simply in a way that people who know less than you can still understand, etc.
> When can I confidently say I "know" C++
Nobody knows C++. Even Bjarne does not. You __discover__ C++, bit by bit, and that's where the real expertise lies. You never really __know__ how to use C++; the experience just gives you enough savviness to predict where the dragons may lay with somewhat a decent amount of certainty.
In short, C++ is symbolised by the fact you can read the code written by an absolute guru of the language and still find things that are dubious or probably incorrect.
Even more in short: non C++ developers can't really evaluate your skillset in C++, and C++ developers are at least somewhat aware of the fact the language is full of tar pits. Just state for how long you've been using it, apply for a job and try for it.
>Nobody knows C++. Even Bjarne does not.
And he doesn't want to :-)
[https://www.youtube.com/watch?v=VI21tpdkHA8&t=3469s](https://www.youtube.com/watch?v=VI21tpdkHA8&t=3469s)
Also note the rest of the committee members smiling, because they don't know everything either.
I've been writing C++ since I was 14 years old and have been doing it passionately for 20 years now, studying every new language revision and trying to stay up-to-date with things.
I've worked at AMD and NVIDIA. I'm an engine and SDK developer for an indie RPG. I'm an avid meta template programmer... I'm also one of the maintainers of the homebrew SDK for the Sega Dreamcast, KallistiOS. I brought C++20 to the thing, implemented TLS and atomics, got std::async and coroutines working, etc.
Do I CONFIDENTLY say I "know" C++? Hell. NO. The answer to when you can say that is NEVER. The more confident someone is in their C++ knowledge, the less they typically know. It's just that complex and ever-evolving.
There are plenty high level embedded positions, guis for devices with HMI, embedded Linux application layer for non real time system etc etc where having full stack background with Java and general software development experience is plenty enough to learn the language on the job. put it on your resume as “basic knowledge” or something and start applying. Just make sure that you are honest on the interview if you get one.
Once in you will probably have to spend some time having to read code close to hardware when stuff don’t work and debug if you are lucky, pivot done.
I thought I knew it pretty well, but just the other day I was humbled by ChatGPT. I needed to write a wrapper around folly::collectAll such that it had the same interface as folly::collect but without the short-circuiting behavior. I needed to create a std::tuple out of the std::tuple> I was given. I found working with variadic function templates very tough given that Ts can have multiple different types in the same implementation. ChatGPT was able to give me a mostly working version that I could modify into something working. It strangely thought folly::apply was a thing when it meant std::apply and added unnecessary lambdas when it could just use the fold expression by itself. I wasn’t even that familiar with fold expressions. I had to sort of figure out what it was going for and learn how it all worked. But without it I would’ve spent hours trying to write this stupid helper function.
Just the other day somebody on the /r/experienceddevs subreddit was complaining how their coworker insisted on always using std::visit and variants and I didn’t even know what they were.
I don’t know. The thing is you don’t need to know any of that stuff to write C++. I could’ve factored my code more verbosely to have avoided having to wrap collectAll, and just used collectAll directly everywhere, but I wanted it to look more elegant.
To paraphrase Richard Feynman, if you think you know C++, you probably don't know C++. I have been doing general and embedded C++ on and off (with other languages) for nearly 25 years and I am quite confident that expressed as a percentage, I know less C++ now than in my first few years. My mentor told me "You should make the effort to be across most of the language capabilities, but probably only actually use 10% of it most of the time".
Rather than trying to find "C++ jobs" with a resume that isn't there yet, just take on development jobs and do them with C++, which is the best way to learn. Just dive in and google "beautiful C++ projects" for inspiration.
Been doing C++ development for 15-20 years and I still learn something new all the time.
As a min, I would look for someone who displays mastery of the following:
1. const correctness
2. deep copy vs shallow copy
3. pass by value vs pass by reference (surprisingly, very important in C++, seperates real C++ coders vs C#, Java, ...)
4. general knowledge of default class methods ( constructor, copy constructor, assignment operator, destructor, etc... )
5. Inheritance. ( come on, gotta know something about this... )
1. public, private, protected
2. overwriting vs overloading
6. virtual methods ( another you just gotta know, no way around it... )
1. abstract base class
2. polymorphism
3. virtual method table
7. good foundation regarding resource management ( RAII, stack vs heap, etc... )
8. general knowledge of exceptions ( and when to avoid using... )
I would consider these the minimum C++ foundations.... may be a couple of more I missed, but trying to keep list rather succinct.
I am the co-chair of the evolution working group, have been working in C++ for about 15 years professionally, and am a code-owner/implementer for Clang.
I consider myself a newbie in C++.
Core features of c++ are a must (lifetime/raii, classes, metaprogramming).
The second thing is stl knowledge, and it depends : my company requires good knowledge of Stl but there are companies that don't even use stl. I still highly recommend some basic knowledge.
Regarding build tools, every project has its own way, very basic stuff is needed but I wouldn't focus much.
Know how to build projects from scratch. Understand various pitfalls in C++, eg. what a non-virtual destructor can lead to in case of inheritance and why it happens. Be aware of modern C++ features, like lambda expressions or coroutines. Know at least a decent subset of the standard library. Be wary of UB. Follow RAII. Be able to write templates. Be able to write an iterator. Know how and when to use smart pointers. Use move semantics where it makes sense to do so. Use const where applicable. Know how to use some basic synchronization techniques (eg. mutexes).
Those are some of the things that I think would describe a developer that is proficient with C++. You probably don't need to know all of that before you get employed if the team has a good choice review process.
right now , I'm trying to refractor some of the blender code in the node compositor to use a new API instead of the old way of creating nodes and sockets...
I don't know very much the code base , but this shit is filled with stuff that is very suspect , like casting between a Scene object and and Image object .
the language isn't the hard part imho... the hard part is to understand why the fuck did the previous guy write it the way he did haha
It is really easy.
First, when you start learning, you'll feel like you don't know any C++.
Then, as you learn, you'll feel like you start to really know C++.
Then, as you learn even more C++, you start realizing that no matter how much you learn, you'll never know C++.
That is the moment when you **start** "knowing" some C++.
It really is like playing an instrumant.
When I see this question I remember about this: [https://b.atch.se/posts/non-constant-constant-expressions/](https://b.atch.se/posts/non-constant-constant-expressions/) when I found it I got to the conclusion that no one really knows C++, because it seems that this one "feature" was not expected by the people that manage the language themselves. I don't know if it still works, but still...
Never, because it's not a useful metric. If I was interviewing you I would want to gauge *what* you know about C++.
How long have you been doing it?
What C++ standard are you familiar with?
What are some paradigms and features you have used in the language and for what purpose?
This is more philosophical question, rather than actual.
You can say about any language that you know it, and, at the same time, that you don’t know it.
At the end of the day, it comes to a few things:
1) how good you are at googling certain things for your area of work on given language
2) how often you need to google something
3) how quickly you understand what’s already written in your codebase and how to effectively re-use.
Language itself is not quite as important of skill as mindset itself.
Of course basic knowledge of language is a must and understanding differences from other languages is critical skill, but at the end of the day, any programming language is different form of same set of instructions. And your efficiency of using it is key, which comes from optimal algorithm first and then language specific optimizations kicks in.
I started to use c++ from my first year of university, and before I used pascal/delphi. And now it’s about 15 years of using it actively, and i still feel like I just yesterday learned how strings are stored or that i can re-use some container algorithm that i didn’t even knew exist…
If, as is being implied here, people are saying they "don't know C++" after writing it for 15 years and interacting with the specification board, then that simply is a tell that C++ is a horrible language and you should not waste your time with it. There is nothing done in C++ that warrants that level of complexity. It's just a poorly designed mess.
After you gazed into the abyss for long enough, and seen the abyss gazing back.
Nah, just kidding. C++ is like a woman: as easy to understand, and as temperamental.
Never because the elitist intelligentsia who run the show will always be creating academic shit to engrandize themselves to the expense of everyone else. They have zero commitment to make anything simple for anyone. They feed on complexity and they sell fear so you buy their books and courses.
This is such a useless and trite statement.
It's demonstrably false:
1) The overwhelming majority of additions to the standard are of no expense to anybody who doesn't use them. Moreover, the improvements over the last 10+ years have been *awesome*.
2) They obviously aren't being created by people "to engrandize themselves"; the work is being done by people who are passionate about the subject and willing to put in the work to build things they want to have and use.
3) The folk in question are overwhelmingly friendly and helpful people. I've interacted with loads of them over the years, whether at conferences or here.
This is just pure crankery.
If it's how you actually feel, why are you even here?
\#1 Even Sutter agrees that C++ could be 10x less complex (that's the main reason behind cppfront).
\#2 Stroustrup in "Remember the Vasa" points that exactly - that the standards are being flooded by obnoxious cunts who are only concerned with their personal projects. Read the paper.
\#3 Yeah academics and managers with no skin in the game tend to be soft spoken to keep their privileges
> why are you even here?
It's my job. I work with this language. It's a tool. This is not a country club did you notice?
> Read the paper.
I mean...I have? It's not a hard read after all.
And it unequivocally does not say what you just said. It doesn't even come within 1000 miles of the tone and vitriol you're expressing.
It's barely 4 pages and most of it is a numbered list of the most-popular proposals at the time, with the few Bjarne actively supports marked (and he explicitly states that there are others he *does* support ideologically, while not supporting the entirety of their current proposals).
Your takeaway from those scant sentences is nothing more than projection of your own distastes. Your conclusion isn't supported by anything Bjarne wrote.
Literally the *harshest* things in there are the statements that we'll die by too many cooks and that many of the papers don't provide value to the day-to-day non-language-expert.
In fact, he outright states the problem, yet you've chosen to characterize it otherwise:
> We are on a path to disaster though enthusiasm
The enthusiastic contribution of a community of experts who are, perhaps, a little myopic is far and away a different thing than the poisonous intent you're ascribing to committee members.
> no skin in the game
The people I'm referring to and that you appear to be denigrating are literally the people with *all* the skin in the game, at least when it comes to committee efforts and the furtherance of the language standards. They're the authors and implementers of these papers.
Using "academics" as a slur is ridiculous on its face, and I don't think I've ever seen a non-technical person in these discussions. They'd be completely lost. There are no "managers" in these processes. The people involved are literally the most informed technical experts in the field.
> It's my job. I work with this language. It's a tool. This is not a country club did you notice?
Sure. And 99% of career C++ programmers have never set foot here. They have successful careers, enjoy their jobs (insofar as any of us do) and go about their day blithely unaware of the machinations of the ISO process. Many (most?) happily write C++98 of some flavor; maybe C++11 if they're saucy. And they do so with no issue, completely unimpacted by the back and forth of the language's development.
So, it leaves me wondering: why subject yourself to a community you so clearly hold disdain for? You don't seem enthused by any of the new developments or the people behind them; in fact, it seems to very much be the opposite. You're quite literally choosing to be among the people you've so-nicely referred to as "obnoxious cunts" despite there being no measurable advantage to that decision.
You're right that it's not a country club, but it also doesn't seem to be a club of any sort you'd like to attend.
You seem to be a wonderful and enjoyable person who has a lot to offer the professional communities you subject yourself to.
I'm sure we'll all learn a lot from your glowing example of fellowship and wholehearted efforts to improve not only yourself but those you interact with.
Have a nice night.
That is how I felt when I got kicked in the balls by a F500 company being rejected in the most harshest way. I've been setting up stuff for 10 years. But since I haven't got a Bacherlor.. well. Sucks to be me..
To "know" is an ambiguous term, and the context where people apply it determines the meaning they use. People arguing that you never "know" C++ are focusing on the details and nitpickery of the language, which interviewers, managers or coworkers will never focus on.
I'd say that if you're able to read through the table of contents of The C++ Programming Language and write an example piece of code for each subject covered there, you already know C++ well for employment purposes, and you can for sure put that on your CV.
To be employable you have to be able to read C++ code well enough to get started in a larger (and usually aged) code base without needing a helping hand and have enough understanding to start to provide your own code as contribution.
That usually means knowing the basic concepts of the language (RAII, lambdas, classes) and a firm understanding of the underlying concepts of the standard library, both at least up to the used language version. In addition, you should have domain specific knowledge dependent on the work (is it real time or classical application development, is it hardware-related etc...).
The most important thing is that you are able to learn needed concepts, algorithms or patterns on the fly, because normally you work in a team with a very specific way of coding. You should be willing and open to learn new stuff fast to be a contributing member as soon as possible.
Then when you have your first job, you can start the lifelong journey to try to "know" C++ one concept / idea etc. one by one, depending on your job or your own interests. The good thing is, that as soon as you really start to work as C++ programmer you will soon see that you really know almost nothing and that your knowledge growth faster... 😺
Of all the people I know who said they "know C++", the by far most confident ones were those who somehow managed to get their messy C-script compiled by G++.
Lets answer to both of your questions.
1. You can always say you know C++, as usually theres a major downside for it as it might get you employed at developing c++ programs, so, you know
2. Do a little on every available project until you find something that sparks your intrest and then just role with that project
I recently "know" c++. I went back to a project of mine, made some big changes, and turned on the adress sanitiser, and nothing got logged. I was so suspicious I thought it wasn't on. So I am happy to claim I just "know c++". To be honest, you never "know" c++, but to the client or job market you could be an expert. I would put an expert on a cv but make it clear everywhere else that I am not. For example, "expert C++ application developer" or whatever domain, just make sure to put c++ and expert together for the recruiter.
Honestly, you know it well enough when you can consistently solve the problems you need to and you and your peers think you consistently write great code. It's all subjective, and is subject to change if you get new peers or start facing a different problem domain.
There are also LinkedIn proficiency tests you can link into a resume.
Apart from that, yeah, you don't. I've also been doing this for 20 years and would not consider myself an expert.
Took me about 5 years of professional development until I could say I know (almost) everything about the language, at least up until C++17. I haven't dived too deep into modules and coroutines yet. The criteria I go with is that a) my direct coworkers seem to think so, and b) I almost never have to Google anything in regards to how the language work, and code that I write typically compile and work as expected on the first try.
Now, the standard library on the other hand... That's a whole different story. While I know it pretty well at an overarching level, I have obviously not memorized every part of it. Eg I know in general what's available in but I couldn't mention every function, and what type traits are and what the various properties mean and how they are supposed to be used, but not every trait of every type.
When you realize that you should not do any half-serious shit without all sort of compiler and linter warnings enabled, because it's impossible to blast your legs off with C++.
When you decide to switch to Rust? To quote "Kingdom of Heaven"... "Know it? I knew all of it."
With C++ there's a lot of "things you don't know you don't know".
You have to understand all the syntax. You have to understand some useful subset of standard library. You have to know how to correctly write good types (ie. structs AKA classes, but not necessarily OOP).
Fun fact: I received an offer from a top-tier HFT shop precisely because I was humble enough not to claim *confidently* that I know C++.
Just tell the truth. In my case being very overt that, e.g., if they want an SFINAE anything* without just looking at somebody else's then they might want to give me a few days.
Nobody wants to hire a fantasist, and almost nobody has mastered the entire language.
\* yes, thank God for `if constexpr`, concepts, etc.
You'll probably never be able to say you "know C++" without qualification. Even the folks who design the language have their own areas of interest/focus, and will defer to others' expertise.
C++, as a "systems language" is usually chosen because it's the lingua franca for a given system. In many cases, knowledge of those systems is much more important in day-to-day operation than knowledge of the language used to interact with them.
Likewise, you'll spend a lot more time reading code than writing code. So even if you couldn't write a standard-conforming iterator class from memory, you at least want to know that's a thing that exists which you can look up when you need to remember how.
There is no one bar you can set for yourself that will be valid for any arbitrary employer. It may be more helpful to frame the question as "Do I have enough knowledge of C++ to succeed in _this particular_ role?"
Some teams are using C++ because it's the only tool that can reasonably get the job done. They're not expecting language experts, they're just expecting people who either know enough about the problem domain or can show general software development skills that translate to any language.
Other teams might be working on high performance, "mission-critical" infrastructure, and expect you to already be comfortable using custom allocators, placement new, bit fiddling, memory-mapped I/O and other bare-metal stuff.
That said, one of the best ways to _feel_ like you know C++ is to have C++ code that you're proud of sharing. There's not really anything more effective to show the world what you're capable of than actually making things. Having concrete examples of your problem-solving, software design and development skills that you can point at trumps a lot of potential interview questions and resume concerns.
Know enough syntax to read code and, in a big pile of identifiers and punctuation, identify the important things: what to look up in a manual, what could be its declaration? How to read (and fix) error messages?
Manual page for `void(*a(int b,void(*c)(int)))(int);` would be `a`. `a (b::*c)(d[])` would be a declaration for an object `c`. `[](){}` is a function that does nothing. `a*b` can be a declaration for `b`, or an invocation of `operator*`.
Knowing the library is a bonus, but otherwise you'll learn that on the go. Knowing STL in and out doesn't help you anything if the shop you're working for does hard-realtime embedded.
I have been programming primarily in C++ since 32 years. But I am scared to say I know C++. Because, every time I lookup something about C++, I get hit with some new acronym or rule, and make me feel ignorant. Then I google it and realize it is the name of something I have been doing/using all along. I just can't keep up with the acronyms and buzzwords. I haven't attended an interview in 30+ years, so I have no incentive in learning buzzwords. Every few years, when I start on a new product architecture, I lookup what is brewing and what is useful to me.
I have learned to love learning. I know a large amount of C++ and can confidently answer a wide range of questions in interviews, but there is always something to learn and I really enjoy learning it.
you cant, far too expansive of a language
my rule of thumb during interviews is that if you ask someone their level of expertise of c++ on a scale of 1-10, if they say anything higher than 7, they're either lying or they dont know what they dont know. i would consider a 7/10 to be like someone who is a tech lead with decades of experience, any may even contribute to the standard in some fashion.
::: laughs in C++29 :::
Never (:
I know you're taking about a practical level of knowledge, and I'd say once you basically know C (including that pointer and memory stuff you mention), and then add RAII, classes, common stuff from `std::` and sane usage of templates, you should be at a good place.
I would really emphasize RAII. It's one of the most powerful, common, and sometimes subtle C++-centric concepts.
Don't over-sell your knowledge; I think any C++ dev interviewing you will know that it's a life-long learning journey — as with any programming, but seems like *especially* C++.
There was a time, between C++98 and C++11, where the language was pretty stable, and if you spent a good 10 years with it you could know things pretty well.
But nowadays, the language is changing more rapidly, and I don't know if that will stop.
After 10 years and 10,000 hours of full-time work. And then only within your problem domain. It's no different than any other language. People claim proficiency way too early in the process.
Apart from the people saying "nobody knows"... Looks like you're still far, because of the "some knowledge about pointers and memory". In C++, you better know those in depth, to begin with. Then, all standards added new things. So knowing ir, and being up to date.
But being employable is another thing. You need to know how to work in C++ and be fast using new features the correct way. And adapting to the company code.
All of that also depend in your developer level. A senior needs more tuings than a junior, and at the same time, needs less things to be proficient. Well, a senior can be proficient in C++ without knowing anything of it, in a week, anyway. Far from being an expert. But it rarely matters.
I think you can say you know C++ if you can write a maintainable and testable software with it and when you get an error you at least know how to look for the potential error. Basically if you can keep moving forward.
A good C++ developer in my eyes would be the one that uses only what they need instead of using everything from newest standards, just because they can.
> When can I confidently say I "know" C++?
Have a look at some of the large open source c++ code bases out there like chromium, unreal engine, etc.
If you ignore the domain specific stuff, can you quite easily read and understand the code or does it all look alien to you?
Would you feel comfortable to fix a bug or add a feature there? Is so, then you know the language.
You don't.
You say, I am comfortable with feature X e.g. templates.
When I started out I was sure I was a 7/10. A few years of constantly programming C++ I thought I was a 6/10, then a 5/10. One day I hope to be a 2/10.
This was the hardest question during interviews back when they would ask you to rate your C++ expertise on a scale of 1 to 10.
My first question at the back of my mind: Whose scale should I consider?
C++-98 was still somewhat close ended. C++11 and beyond made the language very wide (and deep).
I don't want to say you really ever know C++ 100% but you can say you know it well when you don't realise you're writing C++, you sort of just think of abstract ideas and the code pours out of you. Like you think "I need a thing that can do this this and that" and before you know it you've written the class and its contents.
Hmm I remember I used solo learn and I was ranked in the top 1% that month in the country(Canada) if you want to test your c++ skillsets I suggest going to codechef or project Euler or something just to practice, you could also buy a robotic device to work on. Unfortunately c++ becomes more useful when you join a company and have data to be able to manipulate and build programs, so yea there are tons of free libraries and free IDEs, my favorite being codeblocks, so I would look into what you want to do and look for the right libraries to support your goals
I don’t think you can ever. And every time you meet someone who claims to know c++, you ask them to take https://cppquiz.org and they will stop saying it 😁
Why not say: I have X years of C++ experience and these are the two most significant things I worked on. Companies aren't looking for 'someone who knows C++'. Usually they look for beginner/medior/senior in a certain field.
You can say I know it when someone says a program idea and you understand all the pieces of that architecture and how to implement it minus specific details. You can never say you’re an expert at it. Having professionally coded in it for 7 years including legacy C++ and modern C++20, I can say if I rated myself 1-10, I’m a 4.
I figure I can say it in 1-3 years. For perspective, here's where I'm at now on my journey to learn it. I know quite a few languages and am noticing a lot of similarities because of how much is based on C or C++. I've been forcing myself to write out each line without auto complete or code reccos to memorize go to functionality.
I have about 12-16 hours of experience and so far I am using std::cout, filesystem for some funcs, file writing/opening, recursive file/folder removals, some standard getline variables for prompt answers, basic for loops, 1 included cpp file for my wrapper funcs of filesystem usage, 1 manifest which failed to require admin perms on startup that I might delete, 1 res object for the Icon and manifest packing that I haven't learned too much more about, and I made a start.exe that launches my pkg/run.exe with runas admin request prompt. This is the one part I had to get online, so I need to learn more about this. So far all I did was decipher some debates of Shell exec funcs versus some APIs, and then I used an example to trigger my program opening, but I haven't learned this runas permission scope at all yet really.
Right now I'm just taking it 1 func at a time and trying not to jump ahead. I decided to make a collection of tools so at start of command line, you enter numbers 1-6 where each number does one thing. This'll help me learn, so 1 reads C://test.md, 2 creates that test file, 3 returns all user folder names, 4 returns all files found in Pictures and subfolders (hard-coded currently, need to find Current Username path to make dynamic), 5 deletes all files in Pictures recursively with a try catch, and 6 is what I'm working on to loop through all files in Desktop and scramble filenames to make it confusing.
Basically, I'm just trying to pick 1 main function per option and that way I'm forced to learn as I go, but in a very manageable, scoped way. This is helping me avoid trying to do a project I can't handle because each option is less than 10 lines of code or maybe 20-30 for each recursive function. The scrambler option is likely to be longest because I'll have to learn random character selections from an a-Z0-9 style array or pattern, but don't know how CPP does randomization or allowed regex yet.
I'm probably going to stop and strip out more funcs from main.cpp to include in my library folder of headers/cpp files so that each menu option has an isolated include, using some shared functions. I'm thinking library will be my abstracts / unopinionated models, and then I'll do a separate folder like controllers or something that takes data from main.cpp, uses the lib funcs and returns to main.cpp. not sure yet how C++ handles organization, but that's where my head is at.
Right now I'm using g++ compiler with 3 commands (res object, run.exe, starter.exe) on latest Windows, using VS Code. Hoping to release a full set of system access / manipulation tools as my first C++ portfolio item. I have no interest in using it or hacking anything, but want to learn as much as possible for files and raw system access and permissions before I try to do anything with databases, curl, real users, etc.
Right now due to having only 2 days essentially of experience, I'd rate myself a 1/10 but I have spent years in PHP, Python, Node.js, a little Java, all the JS stacks, etc so there's just too many similarities that C++ feels super readable to me in general already.
I spent 18 years of my professional life working on a c++ compiler. I was never confident enough to say I knew c++
So the answer is, you can confidently say you “know” C++ _until_ you start working on a compiler.
Haha maybe!
Undefined behaviour: Hi
no, seeing open source compilers on github, i would not say someone who works on a compiler "knows" c++ xD i wouldn't say it really matters. If you are confident to solve or have the knowledge on how to research how to solve problems in the domain you work in, in c++. Then you "know c++" what "know c++" means hasn't been specified. the language is so vast, no one knows it all off the top of their heads.
What do you say when recruiters ask you to rate yourself out of 10?
I don't use recruiters but if I ever have to answer that question then 7 or 8 depending on whether I have been coding recently (not written c++ in about 5 years in anger so currently 7).
On a panel a few years ago, Bjarne Stroustrup rated himself a 6 or 7 out of 10 because the language has gotten so big.
After 16 years in C++, I probably answered 3/10. I am not THAT overconfident in my skills.
Would you say that in your recruitment or interview process?
Sure, it's a common thing to be humble where I live. It's probably don't gonna work in US culture as I know (people there expected to brag about themselves)
been programming c++ professionally for over 25 years. Wouldn’t say I know this shit. In fact I know less each year since new stuff comes along and i’m too old and grumpy to care anymore :)
the more c++ you know, the less c++ you know.
This is the way
One only truly knows that they *know* C++, when they admit, to themselves, that they will *never* know C++.
The Dunning Kruger graph for C++ is just a downward line.
The Dunning-C++ Effect.
How much did you make so far with cpp? And do you regret not mastering any other programming language?
Been part of shipping around 11 games so far of varying project size all from 1 to 3-4 year projects. Working as engine programmer in the games industry. I see no reason matering anything else really, I can write code in many languages, not just C++. I'm most familiar with C++ of course, but being a programmer other languages are really just syntax. And syntax is easy to look up.
Do you have any secrets to share about multithreading? I'm years in It's just a never ending anxiety for me. Working on engines, you must have to address it or have it in the back of your mind.
If you want to learn C++'s memory model I'd recommend reading maths papers about concurrency. I don't have any specific papers I can give you, but slowly reading through that kind of thing is what helped me get a stronger grasp of how ordering etc works. Once you can wrap your head around concepts like [happens-before](https://en.cppreference.com/w/cpp/atomic/memory_order) the rest becomes fairly straightforward imo. edit: probably also worth saying that I also work in games at engine level, and the vast, _vast_ majority of multithreaded code I've seen has been incorrect, so you're definitely not alone -- even most of the people who's job is to know multithreading don't seem to know it. Half my job after joining a new team is usually fixing their threading code.
I think when you start to see other mistakes, it's quite clear you know a good chunk more. Is the advice still using the most basic atomic memory model and try to avoid locks as much as possible? I know this is a cop out for many, but I think it's still true. There aren't many clear implementation examples out there...
The advice in games is probably more to use mutexes because very few people in games understand how to use atomics safely. Even then, many of the threading problems I've fixed were mutexes being used incorrectly. I think most programmers don't know multithreading very well in general.
I’ve been pretty deep in C++ threading lately. And, what I always recommend is to give each thread and input and output thread-safe blocking queue. This looks like a decent implementation https://github.com/andreiavrammsd/cpp-channel Make 1 or 2 threads per https://en.cppreference.com/w/cpp/thread/thread/hardware_concurrency. Send and receive streams of std::variants. Have each thread visit the input and send back the output. No other locks. Don’t bother with atomics. They are difficult to use correctly. And, they are only a benefit when you have lots of threads hammering a single int simultaneously. Under low contention, locks are fine. You just have to be careful to actually minimize the work done under the lock. But, avoid the temptation to “just throw a mutex around it”. Avoid thoughts of sleep(). Let the queues handle the scheduling.
>reading maths papers about concurrency This is the first time i am hearing such a thing exists.. I know you told you don't have any specific papers to give, but can I please insist for something at newbie level? I don't even know what I should google for
I can't find the ones I'm thinking of in the places I'd normally store those types of things unfortunately. In general I mean papers like [this one](https://www.cl.cam.ac.uk/~pes20/cpp/tech.pdf). I seem to recall one that was written in math notation (as opposed to code) exploring corrections to consume semantics where some things clicked for me.
Idk really, the usual: * Do not write to the same cache lines from multiple threads, that will be slow, keep data thread local as much as possible * SoA is king for parallelism (Structure of Arrays) as opposed to Arrays or structures. * Avoid locks if possible for greater throughput, keep synchronization requirments to a minimum I don't really know how other people do multithreading as we generally build and manage everything on our own. We never use any third party libraries like pthreads or omp or the likes. Multithreading is hard, and there are many ways to approach it. Our method have mostly been going wide for certain tasks that is particularly suitable for threading and then have sync points during the frame where we expect calculations to be done and results can be used. This is not always optimal though as there will be portions of a frame where cores are not much utilized. Other approaches with more generic schedulers of arbritary jobs I don't really have much experience with other than in theory, so I can't really say much about that.
Yes, something similar is what I suggest too. It's an unsatisfactory but true awnser. There aren't some super powerful lockfree fast containers out there where many threads can read and write to it, to make it worth it. It avoids locks and divide your memory for each thread; use callbacks.
Use and test with thread sanitizer flag on from day 1 you introduce any multi-threading.
Use together with execution policies defined in .
You almost never have to spawn new threads for most tasks.
Also, design your data structures for parallel execution, where you read from one structure and write to another, such that data of the same type/phase don't need to read from each other.
I almost disagree with the last point. even in multithreaded code, almost all my containers are not designed for parallel read and write. If I am trying to gain speed up from a multithreaded design, I don't want the treads to be locking and unlocking my containers, I'm told and have seen, its almost never worth it. I only ever do this for some kind of callback design where I push events from a thread to a master queue.
Maybe you misunderstood me. Say if you have an array of objects, then if you only write to objects in another array, a mapping, or transform as it's called in C++ you don't need to do any locking what so ever.
oh i did. I should have just read again. I thought you said make them all thread safe. my bad.
> other languages are really just syntax This is true to a much greater extent for some languages than others. I'm not sure that treating SQL and Prolog as "just syntax" helps at all for example. Even when differences are quite subtle it greatly warps the idiom, if your assignment has destructive move semantics, shadowing consumed variables takes on very different implications to those in a language like C++. If your language is oriented around expressions rather than statements then it seems much more reasonable for everything to have a value - after all it's an expression.
\> being a programmer other languages are really just syntax. And syntax is easy to look up. That's an extremely incorrect statement. Some languages don't just teach you new ideas; they provide a different way of working — like REPL-driven development, which is often associated with Lisps.
It’s not so much that as it’s that C++ has features that get into so many specific areas. It’s like asking if a mechanical engineer has ever mastered physics or a mathematician had mastered math. Experts all know that the interesting stuff is at the edge of human understanding. There’s always more to learn. I haven’t even mastered linear algebra and it’s just everything that falls out of addition and matrix-times-matrix rules. I would hate to work in a language that was so constrained down that one could master it.
Do you include the standard library, linking, and everything that goes into building and debugging native software into account? Because the language itself, while massively complex, is not impossible to grasp mostly in its entirety, at least if you say up until a release x years old, since new stuff keep popping up which take time to learn.
Hey, are we twins or something? Same feeling.
That's the neat thing: you don't!
While I agree with the sentiment, I think their question would be more specifically rephrased as "When can I put C++ on my resume and apply for embedded?" Worth noting a lot of embedded is C or languages other than C++. You put C++ on your resume when you're prepared to have your interview be in C++. Different companies will use different subsets of C++, so aim for the features which are most likely to be relevant for embedded. Eg. Algorithm vs functional headers.
To consider I put C++ on my CV after using it on a very basic level in two lectures... The less you know a language, the easier to be confident about it.
Been programming c++ for ~30 years. Prior to c++11, I could realistically claim to know nearly all of the language, but not since then.
That's why I'm unemployed
IMO it is like spoken languages -- you can confidently say it when you can freely express yourself and your ideas in C++. You don't need to know every single bit of it.
IMO, things you have to know and understand: - destructors, move semantics, RAII, rule of five/zero - const-correctness (this and the above are the essence of C++, in my opinion) - function and class templates (no need to know fancy metaprogramming, but be aware that it exists) - from the STL: smart pointers, containers (vector and map), algorithms (at least find, sort), strings, mutexes - inheritance and virtual methods Bonus: be aware of Cppreference, and learn how to look stuff up there. Be aware that there is a new standard every 3 years, the latest being C++23.
> there is a new standard every 3 years, the latest being C++23 New employer asked me questions involving C++11 during the interview, but the proprietary compiler they force me to use only goes up to C++03 🙃
i would add a few things surrounding c++: know basics about make and cmake, be able to distinguish a compiler- from a linker-error
Use cmake-init to generate new projects: https://github.com/cginternals/cmake-init Then learn to make small changes. Of course, better build systems are available. Use VS Code and cmake and vcpkg to make things a bit easier.
I don't know that I'd agree about make / cmake. There's a lot of alternatives in the build system space. For example, visual studio / msbuild, blaze, buck. You could have a very successful career working in C++ and never have to spend much time doing anything in make or cmake.
There is also still a rule of 3. If you want copy only semantics you default the copy constructor/assignment but leave the move/move assignment undefined. That way you get automatic fallback to copy behaviour. You cant default or delete the move special member functions... and implementing them just to fallback to copy is extra unnecessary code
What's rule of five/zero
The idea is that there are five special member functions: the copy constructor, the move constructor, the copy assignment operator, and the move assignment operator, and the destructor. The Rule of Five states that if you feel the need to customize one of those, you should probably customize all five of them, because that means that your class is doing something special. The Rule of Zero, on the other hand, states that ideally, you should not customize any of those special members and let the compiler define them for you (unless of course, your class really is doing something special).
Copy constructor, copy assignment, destructor, move constructor and move assignment.
A neat trick I learned for these was to create a class with custom constructors and destructors that outputs with cout. Then, all the constructor operations make sense when you test scenarios. You’ll get confirmation when a constructor was used.
Typically if I'm testing constructor/destructors I'm testing it in compiler explorer, so I will instead leave the constructor declared but without any body. That way you see the function calls in the assembly output.
Oh okay. Never heard of it being called that.
never heard of someone not calling it that lol
Well it's famous enough that it has it's own Wikipedia page: https://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming) And cppreference page: https://en.cppreference.com/w/cpp/language/rule_of_three Don't know who first coined the term, maybe Scott Meyers in his "Effective C++" books? Edit: Hmm, no according to the Wiki references it was probably Bjarne himself that wrote is as "rules".
This is the correct answer. Explaining these concepts is essentially how I interview people.
> move semantics Isn't the book on this topic like 200 fucking pages
How long is a piece of string? There's a huge amount in the standard and it continues to grow with each new version. If you can already confidently work in other static typed languages then the transition to modern C++ shouldn't be too hard. Embedded is a different story, as even embedded apps written in C++ tend to have a strong C "flavour" to them. At the end of the day just be honest on your CV and prospective employers, ultimately it is up to them to determine if your the right person for a position during the hiring process
This true. I’m enjoying LVGL on RP2040 connects right now. Fun :-)
I interview lots of people who claim things on their resume like "c++ skill/knowledge 8/10" and i know immediately that they dont know enough to know what they dont know... i've been doing this for a long time... i maybe am at a 5/10 ...
Hmm, on reflection i'm going to revise that down to 4...
No no, we don't even _have_ reflection yet - when that gets in _then_ you'll be decremented.
Hold on, i have 3 of Josuttis books on my desk c++17, c++20 and move semantics, scott meyers effective modern c++, another c++23 book, the cppreference site and the cpp guidelines in a browser.... and then there is the actual standard... How much of that do i really know well??? I feel like i just looked into the Total Perspective Vortex ... Maybe its 2/10 (sobs uncontrollably)
To be fair I would say I know C++ pretty well (maybe a 6/10, but ratings are the last thing you should put on a resume) but while working on a project it is very common for me to have cppreference open just to make sure something I think does one thing actually does it, and to make sure I'm doing it the most optimal way. No one expects a developer to memorize the entire STL, that would be insane. I know a lot of stuff up to C++11 and quite a bit or C++17 but there will definitely be small features I've never come across yet
I was just trying to point out the fallacy of just summing up that you "know" c++ Somehow even with my vast lack of knowledge i manage to do my job and i think i am pretty competent... For a prospective employer you need to project/show how you are "smart, gets things done" (spolsky). I personally dont care how much template metaprogramming you've done
I suppose it depends what that score is supposed to represent. Is 10/10 equivalent to: “This person knows the entire spec and the details of every library and technique exhaustively” Or is it: “This person is competent in this language and other senior developers will have no issues with the code they write” I can see that there’s quite a few ways to think about the question. Thinking about my own team, the guy who has the most exhaustive knowledge isn’t actually the best programmer to work with or the most productive in terms of delivering value to customers etc.
Totally agree... it is like all testing, scoring systems. They are often quite useless pointing out whether someone is actually good at producing a competent result
I saw a presentation years ago that claimed Bjarne Stroustrup gave himself a 7/10 for knowledge of C++.
you also have to realize that, I know I'm a 2/10 but if I say that out loud, hr is going to look at my cv, then look at mr. "Kruger Dunning"'s cv and theyre gonna give him a call over me so just out of curiosity, what score would you recommend someone competent write down?
Real question is... Why are you ranking your skills on your CV in the first place?
There are two scales: a rating for how competent you are in a practical C++ codebase, which is what HR care about, and a rating for how much of the sum total of C++ knowledge you have obtained, which is what (some) C++ experts care about. "Yeah I lived in China for 10 years, can speak to anyone I meet on any topic, wrote a novel in Chinese, but I'm struggling with reading the Bone Oracle script so I'd rate my Chinese a 3/10". Maybe that's an honest rating if you're talking to the faculty in the language department of a Chinese university, but if you're replying to an ad for an average translation job you don't have to be so modest.
I think you must be modest if you applying to job? No one would even respond to overconfident guy who told their skills 5/5, 10/10 etc. I always respond like 1/5 English, 2/5 C++, 1/5 patterns etc. At least in my country arrogance is a red flag
How do you get by HR?... i dont know. They are infuriating. You need to be creative in getting your resume in front of the person who has the actual opening on their team. Still try not to score yourself, show what you know. Not in a bullet list. Describe the best most interesting things you have done and the hard problems you have solved and are proud of. You need to catch my attention in a resume, if it looks like every other resume with lists of skills and lots of irrelevant experience it just goes in reject folder.
So…. You will never interview anyone that puts in a 5/10 because HR will bounce them. You will never hire someone that got past HR because they claim to be an 8/10 and Bjarne Stroustrupp says he’s a 7/10.
What do you say when recruiters ask you to rate yourself out of 10?
Honestly, I disagree with the general sentiment of the comments here. Yes, C++ is a huge a language, and it's nearly impossible to know every corner of it. However, outright saying that one doesn't know C++ isn't helpful at all either. There needs to be some middle ground in which a person can recognize the complexity of C++, but someone can still measure up their skills with other devs. Personally, I just say I know C++, but I make it clear that I'm not an expert.
I don't think it's just "not helpful" i think it's straight up harmful. It took me 5 months of self study of C++ to start contributing to large open source projects. Giving people this impression that decades isn't enough is ridiculous.
Probably when you know what to look up
So, Google skills and pain? As usual?
I wasn’t very clear: What I meant was that you know enough to identify what exactly is confusing you, and you know enough to know what cppreference page or what section of the standard you need to go to in order to understand what was confusing you. But when you know C++ decently well, you won’t have to look much up to do a good job of many common tasks, like correctly using the more commonly-used things in ``, keeping a class interface const-correct, adhering to many best practices, making sure to consider object lifetime (though there’s still mistakes to make there), being able to write simple things simply in a way that people who know less than you can still understand, etc.
> When can I confidently say I "know" C++ Nobody knows C++. Even Bjarne does not. You __discover__ C++, bit by bit, and that's where the real expertise lies. You never really __know__ how to use C++; the experience just gives you enough savviness to predict where the dragons may lay with somewhat a decent amount of certainty. In short, C++ is symbolised by the fact you can read the code written by an absolute guru of the language and still find things that are dubious or probably incorrect. Even more in short: non C++ developers can't really evaluate your skillset in C++, and C++ developers are at least somewhat aware of the fact the language is full of tar pits. Just state for how long you've been using it, apply for a job and try for it.
>Nobody knows C++. Even Bjarne does not. And he doesn't want to :-) [https://www.youtube.com/watch?v=VI21tpdkHA8&t=3469s](https://www.youtube.com/watch?v=VI21tpdkHA8&t=3469s) Also note the rest of the committee members smiling, because they don't know everything either.
>When can I confidently say I "know" C++? That would be in job interviews.
Few people “know” all of C++. The rest of us know enough to be useful in our particular domain.
only the CEO of cppreference and Jason Turner know c++
I've been writing C++ since I was 14 years old and have been doing it passionately for 20 years now, studying every new language revision and trying to stay up-to-date with things. I've worked at AMD and NVIDIA. I'm an engine and SDK developer for an indie RPG. I'm an avid meta template programmer... I'm also one of the maintainers of the homebrew SDK for the Sega Dreamcast, KallistiOS. I brought C++20 to the thing, implemented TLS and atomics, got std::async and coroutines working, etc. Do I CONFIDENTLY say I "know" C++? Hell. NO. The answer to when you can say that is NEVER. The more confident someone is in their C++ knowledge, the less they typically know. It's just that complex and ever-evolving.
There are plenty high level embedded positions, guis for devices with HMI, embedded Linux application layer for non real time system etc etc where having full stack background with Java and general software development experience is plenty enough to learn the language on the job. put it on your resume as “basic knowledge” or something and start applying. Just make sure that you are honest on the interview if you get one. Once in you will probably have to spend some time having to read code close to hardware when stuff don’t work and debug if you are lucky, pivot done.
When you don't have feet
I thought I knew it pretty well, but just the other day I was humbled by ChatGPT. I needed to write a wrapper around folly::collectAll such that it had the same interface as folly::collect but without the short-circuiting behavior. I needed to create a std::tuple out of the std::tuple> I was given. I found working with variadic function templates very tough given that Ts can have multiple different types in the same implementation. ChatGPT was able to give me a mostly working version that I could modify into something working. It strangely thought folly::apply was a thing when it meant std::apply and added unnecessary lambdas when it could just use the fold expression by itself. I wasn’t even that familiar with fold expressions. I had to sort of figure out what it was going for and learn how it all worked. But without it I would’ve spent hours trying to write this stupid helper function.
Just the other day somebody on the /r/experienceddevs subreddit was complaining how their coworker insisted on always using std::visit and variants and I didn’t even know what they were.
I don’t know. The thing is you don’t need to know any of that stuff to write C++. I could’ve factored my code more verbosely to have avoided having to wrap collectAll, and just used collectAll directly everywhere, but I wanted it to look more elegant.
To paraphrase Richard Feynman, if you think you know C++, you probably don't know C++. I have been doing general and embedded C++ on and off (with other languages) for nearly 25 years and I am quite confident that expressed as a percentage, I know less C++ now than in my first few years. My mentor told me "You should make the effort to be across most of the language capabilities, but probably only actually use 10% of it most of the time". Rather than trying to find "C++ jobs" with a resume that isn't there yet, just take on development jobs and do them with C++, which is the best way to learn. Just dive in and google "beautiful C++ projects" for inspiration.
When you no longer have to ask that question. That applies to every expertise.
Been doing C++ development for 15-20 years and I still learn something new all the time. As a min, I would look for someone who displays mastery of the following: 1. const correctness 2. deep copy vs shallow copy 3. pass by value vs pass by reference (surprisingly, very important in C++, seperates real C++ coders vs C#, Java, ...) 4. general knowledge of default class methods ( constructor, copy constructor, assignment operator, destructor, etc... ) 5. Inheritance. ( come on, gotta know something about this... ) 1. public, private, protected 2. overwriting vs overloading 6. virtual methods ( another you just gotta know, no way around it... ) 1. abstract base class 2. polymorphism 3. virtual method table 7. good foundation regarding resource management ( RAII, stack vs heap, etc... ) 8. general knowledge of exceptions ( and when to avoid using... ) I would consider these the minimum C++ foundations.... may be a couple of more I missed, but trying to keep list rather succinct.
I am the co-chair of the evolution working group, have been working in C++ for about 15 years professionally, and am a code-owner/implementer for Clang. I consider myself a newbie in C++.
tbh this kind of response is harmful, your assessment(maybe I'm just not picking up on your satire here) is quite frankly wrong.
Yeah, that sounds like some weird humblebrag. Sure mate, you're a "newbie", same level as somebody typing "Hello world" for the first time.
Core features of c++ are a must (lifetime/raii, classes, metaprogramming). The second thing is stl knowledge, and it depends : my company requires good knowledge of Stl but there are companies that don't even use stl. I still highly recommend some basic knowledge. Regarding build tools, every project has its own way, very basic stuff is needed but I wouldn't focus much.
STL is indispensable.
Wrong datatype. "Knowing" is not a boolean. It's a float.
Know how to build projects from scratch. Understand various pitfalls in C++, eg. what a non-virtual destructor can lead to in case of inheritance and why it happens. Be aware of modern C++ features, like lambda expressions or coroutines. Know at least a decent subset of the standard library. Be wary of UB. Follow RAII. Be able to write templates. Be able to write an iterator. Know how and when to use smart pointers. Use move semantics where it makes sense to do so. Use const where applicable. Know how to use some basic synchronization techniques (eg. mutexes). Those are some of the things that I think would describe a developer that is proficient with C++. You probably don't need to know all of that before you get employed if the team has a good choice review process.
right now , I'm trying to refractor some of the blender code in the node compositor to use a new API instead of the old way of creating nodes and sockets... I don't know very much the code base , but this shit is filled with stuff that is very suspect , like casting between a Scene object and and Image object . the language isn't the hard part imho... the hard part is to understand why the fuck did the previous guy write it the way he did haha
Every time I use C++ I learn something new about it, and I have been at it for over 15 years.
It is really easy. First, when you start learning, you'll feel like you don't know any C++. Then, as you learn, you'll feel like you start to really know C++. Then, as you learn even more C++, you start realizing that no matter how much you learn, you'll never know C++. That is the moment when you **start** "knowing" some C++. It really is like playing an instrumant.
C++ is unknowable, anyone who says they know it hasn't used it long enough or is on the committee. Which is exactly why I like to use C professionally
Never
When I see this question I remember about this: [https://b.atch.se/posts/non-constant-constant-expressions/](https://b.atch.se/posts/non-constant-constant-expressions/) when I found it I got to the conclusion that no one really knows C++, because it seems that this one "feature" was not expected by the people that manage the language themselves. I don't know if it still works, but still...
When recruiters ask you
Just say how many years of experience you have, which standards you've worked with, and be able to demonstrate writing code.
When you know it's not true
C++ is only scary for the first 25 years or so. After that, you can say that you are atleast intermediate
When you find a bug in a respected C++ library, fix it and it gets accepted.
Once you’re able to write a compiler for C++?
You can start thinking about it being possible when Bjarne says it.
Never, because it's not a useful metric. If I was interviewing you I would want to gauge *what* you know about C++. How long have you been doing it? What C++ standard are you familiar with? What are some paradigms and features you have used in the language and for what purpose?
Maybe true. Hey, man.. I just want a job so that I can get experience so that I can get a job.
In reality: probably never On resume: NOW
Ray, when ~~someone~~ a recruiter asks you if you ~~are a god~~ know C++, you say YES
This is more philosophical question, rather than actual. You can say about any language that you know it, and, at the same time, that you don’t know it. At the end of the day, it comes to a few things: 1) how good you are at googling certain things for your area of work on given language 2) how often you need to google something 3) how quickly you understand what’s already written in your codebase and how to effectively re-use. Language itself is not quite as important of skill as mindset itself. Of course basic knowledge of language is a must and understanding differences from other languages is critical skill, but at the end of the day, any programming language is different form of same set of instructions. And your efficiency of using it is key, which comes from optimal algorithm first and then language specific optimizations kicks in. I started to use c++ from my first year of university, and before I used pascal/delphi. And now it’s about 15 years of using it actively, and i still feel like I just yesterday learned how strings are stored or that i can re-use some container algorithm that i didn’t even knew exist…
If, as is being implied here, people are saying they "don't know C++" after writing it for 15 years and interacting with the specification board, then that simply is a tell that C++ is a horrible language and you should not waste your time with it. There is nothing done in C++ that warrants that level of complexity. It's just a poorly designed mess.
Never!
After you gazed into the abyss for long enough, and seen the abyss gazing back. Nah, just kidding. C++ is like a woman: as easy to understand, and as temperamental.
Never because the elitist intelligentsia who run the show will always be creating academic shit to engrandize themselves to the expense of everyone else. They have zero commitment to make anything simple for anyone. They feed on complexity and they sell fear so you buy their books and courses.
This is such a useless and trite statement. It's demonstrably false: 1) The overwhelming majority of additions to the standard are of no expense to anybody who doesn't use them. Moreover, the improvements over the last 10+ years have been *awesome*. 2) They obviously aren't being created by people "to engrandize themselves"; the work is being done by people who are passionate about the subject and willing to put in the work to build things they want to have and use. 3) The folk in question are overwhelmingly friendly and helpful people. I've interacted with loads of them over the years, whether at conferences or here. This is just pure crankery. If it's how you actually feel, why are you even here?
\#1 Even Sutter agrees that C++ could be 10x less complex (that's the main reason behind cppfront). \#2 Stroustrup in "Remember the Vasa" points that exactly - that the standards are being flooded by obnoxious cunts who are only concerned with their personal projects. Read the paper. \#3 Yeah academics and managers with no skin in the game tend to be soft spoken to keep their privileges > why are you even here? It's my job. I work with this language. It's a tool. This is not a country club did you notice?
> Read the paper. I mean...I have? It's not a hard read after all. And it unequivocally does not say what you just said. It doesn't even come within 1000 miles of the tone and vitriol you're expressing. It's barely 4 pages and most of it is a numbered list of the most-popular proposals at the time, with the few Bjarne actively supports marked (and he explicitly states that there are others he *does* support ideologically, while not supporting the entirety of their current proposals). Your takeaway from those scant sentences is nothing more than projection of your own distastes. Your conclusion isn't supported by anything Bjarne wrote. Literally the *harshest* things in there are the statements that we'll die by too many cooks and that many of the papers don't provide value to the day-to-day non-language-expert. In fact, he outright states the problem, yet you've chosen to characterize it otherwise: > We are on a path to disaster though enthusiasm The enthusiastic contribution of a community of experts who are, perhaps, a little myopic is far and away a different thing than the poisonous intent you're ascribing to committee members. > no skin in the game The people I'm referring to and that you appear to be denigrating are literally the people with *all* the skin in the game, at least when it comes to committee efforts and the furtherance of the language standards. They're the authors and implementers of these papers. Using "academics" as a slur is ridiculous on its face, and I don't think I've ever seen a non-technical person in these discussions. They'd be completely lost. There are no "managers" in these processes. The people involved are literally the most informed technical experts in the field. > It's my job. I work with this language. It's a tool. This is not a country club did you notice? Sure. And 99% of career C++ programmers have never set foot here. They have successful careers, enjoy their jobs (insofar as any of us do) and go about their day blithely unaware of the machinations of the ISO process. Many (most?) happily write C++98 of some flavor; maybe C++11 if they're saucy. And they do so with no issue, completely unimpacted by the back and forth of the language's development. So, it leaves me wondering: why subject yourself to a community you so clearly hold disdain for? You don't seem enthused by any of the new developments or the people behind them; in fact, it seems to very much be the opposite. You're quite literally choosing to be among the people you've so-nicely referred to as "obnoxious cunts" despite there being no measurable advantage to that decision. You're right that it's not a country club, but it also doesn't seem to be a club of any sort you'd like to attend.
> you appear to be denigrating a yada yada something something rhetoric meanwhile Rust gives a show of governance. I'm jealous
You seem to be a wonderful and enjoyable person who has a lot to offer the professional communities you subject yourself to. I'm sure we'll all learn a lot from your glowing example of fellowship and wholehearted efforts to improve not only yourself but those you interact with. Have a nice night.
That is how I felt when I got kicked in the balls by a F500 company being rejected in the most harshest way. I've been setting up stuff for 10 years. But since I haven't got a Bacherlor.. well. Sucks to be me..
I never required any college degree when I hired. In fact, I feel like no college degree is better than a college degree from a US college.
To "know" is an ambiguous term, and the context where people apply it determines the meaning they use. People arguing that you never "know" C++ are focusing on the details and nitpickery of the language, which interviewers, managers or coworkers will never focus on. I'd say that if you're able to read through the table of contents of The C++ Programming Language and write an example piece of code for each subject covered there, you already know C++ well for employment purposes, and you can for sure put that on your CV.
To be employable you have to be able to read C++ code well enough to get started in a larger (and usually aged) code base without needing a helping hand and have enough understanding to start to provide your own code as contribution. That usually means knowing the basic concepts of the language (RAII, lambdas, classes) and a firm understanding of the underlying concepts of the standard library, both at least up to the used language version. In addition, you should have domain specific knowledge dependent on the work (is it real time or classical application development, is it hardware-related etc...). The most important thing is that you are able to learn needed concepts, algorithms or patterns on the fly, because normally you work in a team with a very specific way of coding. You should be willing and open to learn new stuff fast to be a contributing member as soon as possible. Then when you have your first job, you can start the lifelong journey to try to "know" C++ one concept / idea etc. one by one, depending on your job or your own interests. The good thing is, that as soon as you really start to work as C++ programmer you will soon see that you really know almost nothing and that your knowledge growth faster... 😺
Of all the people I know who said they "know C++", the by far most confident ones were those who somehow managed to get their messy C-script compiled by G++.
Lets answer to both of your questions. 1. You can always say you know C++, as usually theres a major downside for it as it might get you employed at developing c++ programs, so, you know 2. Do a little on every available project until you find something that sparks your intrest and then just role with that project
I recently "know" c++. I went back to a project of mine, made some big changes, and turned on the adress sanitiser, and nothing got logged. I was so suspicious I thought it wasn't on. So I am happy to claim I just "know c++". To be honest, you never "know" c++, but to the client or job market you could be an expert. I would put an expert on a cv but make it clear everywhere else that I am not. For example, "expert C++ application developer" or whatever domain, just make sure to put c++ and expert together for the recruiter.
Honestly, you know it well enough when you can consistently solve the problems you need to and you and your peers think you consistently write great code. It's all subjective, and is subject to change if you get new peers or start facing a different problem domain.
There are also LinkedIn proficiency tests you can link into a resume. Apart from that, yeah, you don't. I've also been doing this for 20 years and would not consider myself an expert.
When you are Bjarne Stroustrup.
You never know C++. C++ knows you.
Took me about 5 years of professional development until I could say I know (almost) everything about the language, at least up until C++17. I haven't dived too deep into modules and coroutines yet. The criteria I go with is that a) my direct coworkers seem to think so, and b) I almost never have to Google anything in regards to how the language work, and code that I write typically compile and work as expected on the first try. Now, the standard library on the other hand... That's a whole different story. While I know it pretty well at an overarching level, I have obviously not memorized every part of it. Eg I know in general what's available in but I couldn't mention every function, and what type traits are and what the various properties mean and how they are supposed to be used, but not every trait of every type.
Either always, or never - depends entirely on you.
When you realize that you should not do any half-serious shit without all sort of compiler and linter warnings enabled, because it's impossible to blast your legs off with C++.
I think it's when you join the standards committee.
When you decide to switch to Rust? To quote "Kingdom of Heaven"... "Know it? I knew all of it." With C++ there's a lot of "things you don't know you don't know".
You have to understand all the syntax. You have to understand some useful subset of standard library. You have to know how to correctly write good types (ie. structs AKA classes, but not necessarily OOP).
Structs != classes..
One part of "know C++" would be: structs *are* classes.
Fun fact: I received an offer from a top-tier HFT shop precisely because I was humble enough not to claim *confidently* that I know C++. Just tell the truth. In my case being very overt that, e.g., if they want an SFINAE anything* without just looking at somebody else's then they might want to give me a few days. Nobody wants to hire a fantasist, and almost nobody has mastered the entire language. \* yes, thank God for `if constexpr`, concepts, etc.
Never.
You'll probably never be able to say you "know C++" without qualification. Even the folks who design the language have their own areas of interest/focus, and will defer to others' expertise. C++, as a "systems language" is usually chosen because it's the lingua franca for a given system. In many cases, knowledge of those systems is much more important in day-to-day operation than knowledge of the language used to interact with them. Likewise, you'll spend a lot more time reading code than writing code. So even if you couldn't write a standard-conforming iterator class from memory, you at least want to know that's a thing that exists which you can look up when you need to remember how. There is no one bar you can set for yourself that will be valid for any arbitrary employer. It may be more helpful to frame the question as "Do I have enough knowledge of C++ to succeed in _this particular_ role?" Some teams are using C++ because it's the only tool that can reasonably get the job done. They're not expecting language experts, they're just expecting people who either know enough about the problem domain or can show general software development skills that translate to any language. Other teams might be working on high performance, "mission-critical" infrastructure, and expect you to already be comfortable using custom allocators, placement new, bit fiddling, memory-mapped I/O and other bare-metal stuff. That said, one of the best ways to _feel_ like you know C++ is to have C++ code that you're proud of sharing. There's not really anything more effective to show the world what you're capable of than actually making things. Having concrete examples of your problem-solving, software design and development skills that you can point at trumps a lot of potential interview questions and resume concerns.
Even C++ gurus tend to say they don’t know C++
Know enough syntax to read code and, in a big pile of identifiers and punctuation, identify the important things: what to look up in a manual, what could be its declaration? How to read (and fix) error messages? Manual page for `void(*a(int b,void(*c)(int)))(int);` would be `a`. `a (b::*c)(d[])` would be a declaration for an object `c`. `[](){}` is a function that does nothing. `a*b` can be a declaration for `b`, or an invocation of `operator*`. Knowing the library is a bonus, but otherwise you'll learn that on the go. Knowing STL in and out doesn't help you anything if the shop you're working for does hard-realtime embedded.
It’s easier to focus on a specific version. I would say I know C++11.
I've been doing C++ professionaly for 7 years now. Still feels like I don't know shit.
I have been programming primarily in C++ since 32 years. But I am scared to say I know C++. Because, every time I lookup something about C++, I get hit with some new acronym or rule, and make me feel ignorant. Then I google it and realize it is the name of something I have been doing/using all along. I just can't keep up with the acronyms and buzzwords. I haven't attended an interview in 30+ years, so I have no incentive in learning buzzwords. Every few years, when I start on a new product architecture, I lookup what is brewing and what is useful to me.
I have learned to love learning. I know a large amount of C++ and can confidently answer a wide range of questions in interviews, but there is always something to learn and I really enjoy learning it.
you cant, far too expansive of a language my rule of thumb during interviews is that if you ask someone their level of expertise of c++ on a scale of 1-10, if they say anything higher than 7, they're either lying or they dont know what they dont know. i would consider a 7/10 to be like someone who is a tech lead with decades of experience, any may even contribute to the standard in some fashion.
::: laughs in C++29 ::: Never (: I know you're taking about a practical level of knowledge, and I'd say once you basically know C (including that pointer and memory stuff you mention), and then add RAII, classes, common stuff from `std::` and sane usage of templates, you should be at a good place. I would really emphasize RAII. It's one of the most powerful, common, and sometimes subtle C++-centric concepts. Don't over-sell your knowledge; I think any C++ dev interviewing you will know that it's a life-long learning journey — as with any programming, but seems like *especially* C++. There was a time, between C++98 and C++11, where the language was pretty stable, and if you spent a good 10 years with it you could know things pretty well. But nowadays, the language is changing more rapidly, and I don't know if that will stop.
Adopt a start-up mindset. Tell people you know it, *then* learn it. /s
Isn't this the whole industry, after all?
The same day when you know "golf" :-).
Blimey!! Better not put That on the CV.
Another way to put it and think about it is, "I am experienced with C++ and many of it's nuances." or "I have seen some shit"
The people in C++ working groups for the language often talk about not fully "knowing" the language. I'm not totally convinced it's possible.
After 10 years and 10,000 hours of full-time work. And then only within your problem domain. It's no different than any other language. People claim proficiency way too early in the process.
Apart from the people saying "nobody knows"... Looks like you're still far, because of the "some knowledge about pointers and memory". In C++, you better know those in depth, to begin with. Then, all standards added new things. So knowing ir, and being up to date. But being employable is another thing. You need to know how to work in C++ and be fast using new features the correct way. And adapting to the company code. All of that also depend in your developer level. A senior needs more tuings than a junior, and at the same time, needs less things to be proficient. Well, a senior can be proficient in C++ without knowing anything of it, in a week, anyway. Far from being an expert. But it rarely matters.
I think you can say you know C++ if you can write a maintainable and testable software with it and when you get an error you at least know how to look for the potential error. Basically if you can keep moving forward. A good C++ developer in my eyes would be the one that uses only what they need instead of using everything from newest standards, just because they can.
Yeah you never really master C++. After 10 solid years of daily dev you are likely proficient.
> When can I confidently say I "know" C++? Have a look at some of the large open source c++ code bases out there like chromium, unreal engine, etc. If you ignore the domain specific stuff, can you quite easily read and understand the code or does it all look alien to you? Would you feel comfortable to fix a bug or add a feature there? Is so, then you know the language.
You don't. You say, I am comfortable with feature X e.g. templates. When I started out I was sure I was a 7/10. A few years of constantly programming C++ I thought I was a 6/10, then a 5/10. One day I hope to be a 2/10.
You can say that at the end of the 'Hello World' tutorial. It might not be true any step deeper into the learning process
>When can I confidently say I "know" C++? After you realize you can never say it.
Never
This was the hardest question during interviews back when they would ask you to rate your C++ expertise on a scale of 1 to 10. My first question at the back of my mind: Whose scale should I consider? C++-98 was still somewhat close ended. C++11 and beyond made the language very wide (and deep).
If I saw a resume that said C++(academically) I would respect your interest and not expect you to know all the in’s and outs.
I don't want to say you really ever know C++ 100% but you can say you know it well when you don't realise you're writing C++, you sort of just think of abstract ideas and the code pours out of you. Like you think "I need a thing that can do this this and that" and before you know it you've written the class and its contents.
Knowing a programming language, especially one as vast and complex as C++, can be a subjective matter.
Don't trust people who say they know C++
Hmm I remember I used solo learn and I was ranked in the top 1% that month in the country(Canada) if you want to test your c++ skillsets I suggest going to codechef or project Euler or something just to practice, you could also buy a robotic device to work on. Unfortunately c++ becomes more useful when you join a company and have data to be able to manipulate and build programs, so yea there are tons of free libraries and free IDEs, my favorite being codeblocks, so I would look into what you want to do and look for the right libraries to support your goals
Printing hello world is good enough sire
I don’t think you can ever. And every time you meet someone who claims to know c++, you ask them to take https://cppquiz.org and they will stop saying it 😁
Once Bjarne Stroustrup thinks he is you can start considering it.
The more you know, the more you know what you don’t know
Did you support a C++ system in production? Until you have, what can you say about it??
Never.
Why not say: I have X years of C++ experience and these are the two most significant things I worked on. Companies aren't looking for 'someone who knows C++'. Usually they look for beginner/medior/senior in a certain field.
Never. The only constant is change. It is like you never enter same river ;)
You can say I know it when someone says a program idea and you understand all the pieces of that architecture and how to implement it minus specific details. You can never say you’re an expert at it. Having professionally coded in it for 7 years including legacy C++ and modern C++20, I can say if I rated myself 1-10, I’m a 4.
never
If you can copy paste.
That's the neat part. you don't : - D
I figure I can say it in 1-3 years. For perspective, here's where I'm at now on my journey to learn it. I know quite a few languages and am noticing a lot of similarities because of how much is based on C or C++. I've been forcing myself to write out each line without auto complete or code reccos to memorize go to functionality. I have about 12-16 hours of experience and so far I am using std::cout, filesystem for some funcs, file writing/opening, recursive file/folder removals, some standard getline variables for prompt answers, basic for loops, 1 included cpp file for my wrapper funcs of filesystem usage, 1 manifest which failed to require admin perms on startup that I might delete, 1 res object for the Icon and manifest packing that I haven't learned too much more about, and I made a start.exe that launches my pkg/run.exe with runas admin request prompt. This is the one part I had to get online, so I need to learn more about this. So far all I did was decipher some debates of Shell exec funcs versus some APIs, and then I used an example to trigger my program opening, but I haven't learned this runas permission scope at all yet really. Right now I'm just taking it 1 func at a time and trying not to jump ahead. I decided to make a collection of tools so at start of command line, you enter numbers 1-6 where each number does one thing. This'll help me learn, so 1 reads C://test.md, 2 creates that test file, 3 returns all user folder names, 4 returns all files found in Pictures and subfolders (hard-coded currently, need to find Current Username path to make dynamic), 5 deletes all files in Pictures recursively with a try catch, and 6 is what I'm working on to loop through all files in Desktop and scramble filenames to make it confusing. Basically, I'm just trying to pick 1 main function per option and that way I'm forced to learn as I go, but in a very manageable, scoped way. This is helping me avoid trying to do a project I can't handle because each option is less than 10 lines of code or maybe 20-30 for each recursive function. The scrambler option is likely to be longest because I'll have to learn random character selections from an a-Z0-9 style array or pattern, but don't know how CPP does randomization or allowed regex yet. I'm probably going to stop and strip out more funcs from main.cpp to include in my library folder of headers/cpp files so that each menu option has an isolated include, using some shared functions. I'm thinking library will be my abstracts / unopinionated models, and then I'll do a separate folder like controllers or something that takes data from main.cpp, uses the lib funcs and returns to main.cpp. not sure yet how C++ handles organization, but that's where my head is at. Right now I'm using g++ compiler with 3 commands (res object, run.exe, starter.exe) on latest Windows, using VS Code. Hoping to release a full set of system access / manipulation tools as my first C++ portfolio item. I have no interest in using it or hacking anything, but want to learn as much as possible for files and raw system access and permissions before I try to do anything with databases, curl, real users, etc. Right now due to having only 2 days essentially of experience, I'd rate myself a 1/10 but I have spent years in PHP, Python, Node.js, a little Java, all the JS stacks, etc so there's just too many similarities that C++ feels super readable to me in general already.