aphadeon":2nvkajng said:
That said, I still think includes and header files are rather unintuitive.
The includes and header files are part of the pre-processor, when you stop thinking about them as part of C++ and think of them as a way to quickly include all the function & class prototypes without having to write the same thing over and over then you kind of start loving header files.
I find that the C++ "gurus" around the world say things like "We still have header files in 2017! How frustrating!" but the people who actually sit down and use the language for production projects don't complain about header files. Personally, I'd be upset if they were removed as the pre-processor system helps out a lot. The language itself is gaining a lot of functionality that the pre-processor provided:
http://en.cppreference.com/w/cpp/language/constexpr so some of the crazy pre-processor stuff is getting made obsolete with a more powerful "pre-processor" that's in the language itself.
aphadeon":2nvkajng said:
But that's a relatively minor nitpick compared to the one thing I find most appalling: the lack of a good build and library system. C++ is basically a mother-language at this point- it's been around forever and a day, is supported on just about anything (I managed to compile OS-free baremetal code with it yesterday while trying to get CMake to work as a build system); yet there's not a build system, even for desktops, that provides decent package management and basic compilation.
Linux systems tend to have a convention where libraries are installed in the same way as applications, so you'd download zlib through your normal package manager for your Linux distribution and that also installs includes and libs to some shared location that you can use in your builds.
I doubt there'd ever be a single library package repo for C/C++. It's something I've never felt like I've needed for the language, personally. I definitely used the one that codeblocks had back in the day, when I was very first starting out in C++, but these days I'd rather compile libraries myself so I can debug them properly and modify them as needed. mruby, libpng, zlib, SDL2 comes to mind.
EDIT: Out of all major operating systems, I still think macOS with XCode is the best environment for C/C++ development. Frameworks is just 1 handy way to share library packages; you can compile multiple library targets into 1 Framework and your project configuration will select the one to use for the build. Assets can go in the Framework too, so if you have mruby as a Framework you can put your debug or release bootstrap bytecode binary into the Framework and have your project select either one depending on the build. It's a programming-oriented version of an archive file with a load of sub-folders and no need to write build rules for each target.
You can still compile and use .a and .dylib as normal if you want traditional style distribution, but there's a good reason why everyone uses Frameworks for XCode.
Clang has the GCC standard library, on macOS the Clang compiler is a frontend to GCC, but these days it's my opinion that people should move away from GCC; LLVM is just "better" at this point and has a more healthy, cross-language oriented ecosystem (I can write code in Swift and run it on the Game Boy Advance!). GCC can do the same, but you need to jump through a forest made up of hoops. At the moment, LLVM produces more performant code than GCC - its C/C++ standard library I've found is also more performant and lighter on resources too. It just doesn't have the early 1980s bloat that GCC has.
Android has also moved to Clang/LLVM and mimics the same behaviour as XCode when it comes to GCC compatibility. I think they're even encouraging GCC's standard library to be avoided because LLVM's is simply better. If you're interested; it is the Android ARM toolchain that I use to compile my Game Boy Advance code, another testament to how good LLVM is. I'm using the Clang libraries that modern Android uses to compile for a tiny, weak (by modern standards) Nintendo handheld console from 2001.
EDIT2: Khronos' intermediate code SPIRV was derived from LLVM's IR, I wish they had stuck with using LLVM directly as then we'd be able to compile Vulkan shaders in any language that LLVM supports - but alas they decided to fork.