I should have specified C is definitely much better as an interface
than C++. The lack of name mangling and function overloading allows for a much more stable ABI which can be compatible between different versions of the same compiler or, more specifically, different versions of the standard (a program compiled with C++11 can call c functions in a library compiled with C++20). Once you start using C++ things in the interface you've basically locked yourself in to that compiler version, and it's why you hear stories of companies sticking to C++11 while C++20 is out: they use libraries which they can't recompile. I worked at a place where we didn't switch off of C++14 because no one wanted to recompile boost.
> isn't having that kind of circular dependency terrible form?
It's terrible form in the sense that it isn't sanctioned OOP design, but strict adherence to a paradigm is for academics. Sometimes the pragmatic solution to a problem won't jibe with the language at hand, and you can either spend hundreds of hours re-architecting a system or just go with what works. In this case, the forward declare could be avoided if you use a void*, but then you'd need to cast it back anytime you want to use it.
>This is something that I've wondered for some time. How much of the jargon and complex language functionalities does the average C++ programmer understand and use daily? Am I the only one that thinks the language has gotten absurdly complex? For example, would an average C++ programmer already know what
>means? When you read what it does it's reasonable, but I had never come across propagate_const before, and this is just the first thing you see on the linked page, I find that cppreference continually pulls std jargon out the ass and I have no idea how there can always be more!
It really depends on what you mean by average. If you're writing, reading, and reviewing C++ for 8 hours a day, you start to pick up a lot of the esoteric things pertaining to what you're doing. I'd say most of my peers know what templates are and can write simple ones (maybe even a little SFINAE); know about vector, map, set, sort, pair/tuple, string, iostreams, smart pointers, lambdas, iterators, numeric_limits, and maybe filesystem; are capable of looking up most of the language they'd find out in the wild (advanced templates being the thing most would have trouble with); and know some of the surface level jargon of the standard (declare, define, undefined behavior, etc.). Beyond that, you need to have an interest in the language itself to start picking up more stuff. As for if average C++ programmers would already know
I'd say they could look at it and understand what it meant. Most people have probably never used anything in experimental save for filesystem when it was in there, so I'd doubt that anyone could say they've used it out in the wild, but my first intuition is that it would make the pointed to object const if its containing object was const which, from my understanding of cppreference, is the case.
The fact that cppreference likes to stick new and strange things into their examples is why I like it so much. You can click on most things that come from the library right from the examples, and their usually simple enough to understand without having to look up everything new. I might be biased, but I like learning about the new and strange stuff, so I don't mind their inclusion.
If you really want to get into the jargon, all the papers from the standards committee are posted online at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/
and the working draft itself is posted at https://github.com/cplusplus/draft.
I mostly watch the papers for future features and the read the draft if I come across some questionable code.