I consider myself lucky that I practically do not have to deal with C++, but if I were a C++ kind of person, right now I would deeply appreciate how much hard work goes into a tool like this. [1]
In order to be any good, it has to be even more clever than the compiler, at least in a few ways.
And I have a hunch that in the field of programming languages that are used these days, C++ is probably not the easiest one to write such an analyzer for. ;-)
TL;DR - Respect! I can only - but vividly - imagine how hard it must be to create a tool like this.
[1] I have mixed feelings regarding C++, because I have only used it in tiny doses. I treat the language the same way I would treat a bear, if one suddenly appeared: Keep my distance, avoid any sudden motions, but also, under no circumstances, dare I turn my back on it because of the slight chance that it might come after me eventually. I do not actively dislike C++, I just have not found the time to learn it, and I get the impression that if I really want to learn it, it will take much more time than I can currently afford to invest. Maybe some day it will come to pass (that will be a good day also to finally read Moby Dick all the way through from end to end.)
Some advice if you do decide to learn C++: there has been a steady stream of improvements in standard C++ the past 8 years (C++11-17), and some (Bjarne Stroustroup, Herb Sutter, others) promote it as a better starting point for beginners under the name 'Modern C++'.
"[...] Over the years, features have been added to the language, together with highly-tested standard libraries of data structures and algorithms. It's these additions that have made the modern C++ style possible.
Modern C++ emphasizes:
Stack-based scope instead of heap or static global scope.
Auto type inference instead of explicit type names.
Smart pointers instead of raw pointers.
std::string and std::wstring types (see <string>) instead of raw char[] arrays.
Standard template library (STL) containers like vector, list, and map instead of raw arrays or custom containers. See <vector>, <list>, and <map>.
STL algorithms instead of manually coded ones.
Exceptions, to report and handle error conditions.
Lock-free inter-thread communication using STL
std::atomic<> (see <atomic>) instead of other inter-thread communication mechanisms.
Inline lambda functions instead of small functions implemented separately.
C++ as a language has certainly modernized, but its tools are still stuck in the 90's. Contrary to the increasingly bizarre rationalizations offered up by its proponents, CMake and friends are not acceptable package managers or build tools, at least to those of us who have used newer languages. I don't need a build tool assumes all projects are unique snowflakes in need of their own hand-crafted build system; I just want to get up and running quickly without sticking a bunch of maintenance into my build system.
I don't mean to dump on C++; I like the language and I take this post as a sign that things are beginning to improve, and I hope this pace of improvement accelerates. However, I have been disappointed by the head-in-the-sand attitude of some proponents.
The funny thing about cmake is though that simple things are indeed simple, you can describe an executable made of several compile units in a single line of cmake script. The problem is that it doesn't enforce any standardization beyond that of how to structure complex projects, especially if external dependencies are involved.
PS: I don't think you will find a single "fan" of cmake who would say it's the best thing since sliced bread. Most people know it sucks, but grudgingly admit that its better to have one bad standard than a dozen competing solutions.
> I don't think you will find a single "fan" of cmake who would say it's the best thing since sliced bread.
This happens in all the time. At one point here on HN I lamented that C++ didn't have a build system like Rust's Cargo, and lots of C++ folks came out of the woodwork to argue that Cargo is a shitty tool because it can't support certain byzantine projects. Similar arguments were made in a thread about a new C++ package manager that attempts to modernize C++ package management. Almost all of the pro-CMake arguments focus on how capable it is to handle bizarre projects, without realizing that most such projects are bizarre only because they each had to implement their own build system instead of using one that encouraged them toward some standard structure. I can't recall anyone making an argument that resembled "it's better to have one bad standard than a dozen competing standards", even in response to something like "CMake is the best of all C++ tools, but still a far cry from other languages' tooling." Some people would allude to C++ projects being uniquely difficult to build, and so it would be impossible to emulate another language's tools; however, this too seemed to be confusing "C++ projects lack a standard structure" with "C++ projects can't have a standard structure". I could go on and on.
QtCreator and Visual C++ (with UWP), are only now allowing what was already quite comfortable with C++ Builder in the 90's.
As I posted in another thread, Lucid and IBM had quite advanced environments based on Lisp and Smalltalk environments, that failed on the market due to hardware requirements and heavy price tags.
Other than that, I feel your pain.
C++ is no longer my daily tool, but I still enjoy using it, and would also like to have better tooling available for when I do.
The anti-modules discussion post-CppCon is a good example of what you are stating.
Like I said, I am not turning my back on it. I have noticed that C++'s evolution has been gaining momentum over last ten years. I have even read Bjarne's book on the design and evolution of C++ - it was fascinating, and I think it is worth reading even to people who never have used C++.
The thing is that from all I have heard and read I get the impression that learning C++ - really learning it, not just C-with-classes - is a long-term commitment. That is why, as I said, I am keeping a safe distance between me and C++. ;-)
When the day comes, I will not be entirely unprepared.
Although C++ has lots of warts, I still really like the language mainly thanks to the tooling around it. It has had very good IDEs for years and when I see some of the advancements in debuggers and profilers for more modern languages I feel that they are still quite behind.
Note that this server is based on libclang. This is good because having a good language support means that you have to practically write a compiler for it, using an actual compiler is the best way.
However, it is true that I have always used a full fledged IDE – mostly Qt Creator. I never had courage to configure Vim for it and now I will not invest in that. But if a good and fast language server for it existed a few years back I would definitely jump on it.
I think I mentioned that before, Lucid as a company has never done anything with Lisp Machines. Their target market was Unix and various UNIX platforms. What they were famous for was Lucid CL as a very high quality implementation/compiler/runtime of Common Lisp for UNIX. They sold licenses to various companies (like IBM, DEC, SUN, ...), which sold it under their brand with their enhancements. Lucid CL was used for application delivery by commercial customers, because the compiler and runtime were fairly good.
The Lucid CL IDE wasn't THAT advanced. Fairly standard CL stuff.
Example: SUN sold Lucid CL as Sun Common Lisp and the IDE was called Symbolic Programming Environment:
That's nice, but not too advanced and with a basic look&feel.
Lucid as a company failed, because the C++/Energize product failed in the market and it consumed all the money they had earned from milking their Lisp business, which itself was in a shrinking market.
Still if such products had been successful earlier, most likely our C++ IDEs would be much joyful to use even without plugging into clang.
It always feels so many products have been a market failure just because people weren't yet ready for them. Only to have others 10, 20 years later to conquer exactly the same market.
Single user: $5425
Five users: $2975 each
Ten users: $3250 each
A single Energize C++ compiler was slightly more than $1000.
On top of that Energize was a relatively complex piece of software. Probably it would also have been a good idea to have a capable UNIX desktop machine, which even in 1992 wasn't that cheap.
The whole thing was aimed at professional C++ programmers in a relatively limited market of 'mission critical applications'.
I consider myself lucky that I practically do not have to deal with C++, but if I were a C++ kind of person, right now I would deeply appreciate how much hard work goes into a tool like this. [1]
In order to be any good, it has to be even more clever than the compiler, at least in a few ways.
And I have a hunch that in the field of programming languages that are used these days, C++ is probably not the easiest one to write such an analyzer for. ;-)
TL;DR - Respect! I can only - but vividly - imagine how hard it must be to create a tool like this.
[1] I have mixed feelings regarding C++, because I have only used it in tiny doses. I treat the language the same way I would treat a bear, if one suddenly appeared: Keep my distance, avoid any sudden motions, but also, under no circumstances, dare I turn my back on it because of the slight chance that it might come after me eventually. I do not actively dislike C++, I just have not found the time to learn it, and I get the impression that if I really want to learn it, it will take much more time than I can currently afford to invest. Maybe some day it will come to pass (that will be a good day also to finally read Moby Dick all the way through from end to end.)