21–30 of 74 posts
Conan + (any build system) = problem solved Conan has a learning curve, but it’s totally worth it. Anyone making their own build system should get some experience with a state of the art package manager before writing a single line of code, because chances are that it already solves whatever problem is motivating you.
vcpkg/NuGET + (any build system) = problem solved
I wish we had a culture that expected every new C/C++ build system to handle a non-trivial project like Boost or Qt (and their dependencies, like ICU and OpenSSL) before it being pitched as the new best thing. It's trivial to make a build system that elegantly handles your own toy projects that follow your preferred style and structure. But the real world of C/C++ is a harsh place with a lot of variability.
Conan + (any build system) = problem solved Conan has a learning curve, but it’s totally worth it. Anyone making their own build system should get some experience with a state of the art package manager before writing a single line of code, because chances are that it already solves whatever problem is motivating you.
I prefer the equation, :) vcpkg/NuGET + (any build system) = problem solved
This is sort of unrelated, but that reminds me that one of my biggest issues with learning C++ was how I was expected to deal with libraries (particularly on Linux, where conventions will even differ between distros) and building the project. Most guides or what have you sort of teach you how to compile a file or two, but you quickly run into issues that are difficult to solve for a complete beginner without a direct…
I end up "Randomly" stabbing at things until it works just well enough to get that particular thing done then dropping it all because it was such a painful experience.
Compared to something like cargo which works really well, C++ and it's build tools just feel flaky.
It may be that I'm just missing a mental model to get to grips with it, but no other major programming language is like that from my experience.
Earlier quoted context omitted.
For Go, mixing languages is uncommon because its FFI suffers an impedance mismatch with its task scheduler. For Rust, mixing languages is extremely common. Rust's entire original reason for existing was to rewrite small parts of a large C++ project.
So much common that Google had to create their own integrations for Android and Fuchsia. I bet the announced Chrome efforts will again, require another adaptation.
One .cc/.h pair, one object Not always the case; I have a project with default.o: default.yaml $(LD) -r -b binary -o default.o default.yaml and a default.h containing extern const char _binary_default_yaml_start[]; extern const char _binary_default_yaml_end[]; #define PARAM_YAML _binary_default_yaml_start #define PARAM_YAML_LEN (_binary_default_yaml_end - _binary_default_yaml_start) this used in the main code as fwri…
> “If you want something like this to work, you have to commit to a certain amount of consistency in your code base. You might have to throw out a few really nasty hacks that you've done in the past. It's entirely likely that most people are fully unwilling or unable to do this, and so they will continue to suffer. That's on them.”
Earlier quoted context omitted.
Delphi made an awful lot of things incredibly easy. Com automation for example. It is just too bad Borland had fucked up.
It boggles my mind that for how hardline the WinDev is about using COM, they still fail to match Borland, nowadays Embarcadero tooling for COM. For a brief moment they almost had it with .NET Native and C++/CX, and then, first they killed C++/CX in name of C++/WinRT (with VS tooling just like in the good old ATL days), and with UWP's deprecation, CsWinRT also fails quite short of the .NET Native experience in regards…
I've been in the industry for 30 years just in Canada. Have come to conclusion that software developers in their majority rarely prefer most efficient, elegant (whatever that means) ways of accomplishing things. I have a theory that being "software developer" is sort of self servant. Because of that they enjoy unneeded complexity, tooling etc. etc.
I personally have never indulged into coding for the sake of it. To me software development was always just a tool to build amazing products people / businesses would use. So I always think about product, how it will be used and how to get there with the least financial "damage" either for my own company or for a client.
One .cc/.h pair, one object Not always the case; I have a project with default.o: default.yaml $(LD) -r -b binary -o default.o default.yaml and a default.h containing extern const char _binary_default_yaml_start[]; extern const char _binary_default_yaml_end[]; #define PARAM_YAML _binary_default_yaml_start #define PARAM_YAML_LEN (_binary_default_yaml_end - _binary_default_yaml_start) this used in the main code as fwri…
Your use case would be served by C23's #embed [1]. The same thing has been proposed for C++ but repeatedly kicked down the road because the standardisation committee wanted to make it more general even though no one had any demand for that so they didn't know what it would look like. (C++ standardisation in a nutshell.)
This sounds like it would be fine for code that you write yourself. But if you're only compiling code you wrote then C++ build systems are pretty trivial. The hard bit is dependencies.
One big lesson that newer languages like go and rust seemed to have learned is that the tooling, building and dependency management need to be dictated as part of the language ecosystem. Dealing with tons of other C++ projects written by other people (even in the same company) - how to specify dependencies, where their build artifacts can be found, etc - is a HUGE pain in the ass and consumer of my time.
I'm not sure why C and C++ have such a bad story here. Some combination of greater intrinsic complexity (separate headers, underspecified source-object relationships, architecture dependency, zillions of build flags, etc), a longer history of idiosyncratic libraries which people still need to use, the oppressive presence of distro package managers, and C programmers just being gluttons for punishment, probably.
Earlier quoted context omitted.
So much common that Google had to create their own integrations for Android and Fuchsia. I bet the announced Chrome efforts will again, require another adaptation.
I'm unsure what this is trying to say. You appear to be in begrudging agreement that Rust is commonly mixed with other languages?