11–20 of 74 posts
That goes for almost everything, in developing ship code.
Today, I am in the initial stages of rewriting an app with a codebase that has “accreted” over two years.
It’s kind of a mess (my mess, to be clear).
I’ll be adding a great deal of rigor to the new code.
I think it will come out great, but I have my work cut out for me.
One of the nice things that Visual C++ has is #pragma comment(lib, "xxx.lib") You can specify it in a header file for the library. That way if you include the header file, the library mentioned will automatically get linked as long as it is somewhere in the library search path. I have found myself wishing that GCC would also get something like this.
I remember back when I was programming in Delphi I could link directly against a .dll, just take a function prototype from the .h file and translate it into a function declaration like this one: function I2C_GetNumChannels(out numChannels: Longword): FT_Result; stdcall; external 'libmpsse.dll'; and that was it; but to do this in MSVC you needed not only the .h header and the .dll itself, you also needed that stupid .…
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.
Earlier quoted context omitted.
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.
They all get the tooling wrong though because none can stand the idea that you might want to mix languages, or add their new language to an existing project with existing tooling.
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…
What on earth.
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.
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.
Conan obviously has promise, I haven't spent much time with it, most of my experience with C++ package managers is with nuget and vcpkg. However, my attitude toward package managers is changing.
I increasingly like _not_ using package managers because it makes me (and my company) way way way less likely to bloat our software with unnecessary third party dependencies.
I wrote this in another thread: I never believed you should write something yourself if you can find a package for it. My boss told me I should write it all myself, I could probably write it to be faster. I encountered a case where I needed to compare version numbers in python. For the heck of it I wrote the simplest, quickest, most naive solution I could come up with and then timed it against the most recommended version comparison package in python. I blew it away by 20x throughput.
I don't believe in package managers anymore. Obviously I'll keep using pip and sqlalchemy in Python, but I'll happily spend the 20-30 minutes it takes adding something like nlohmann-json or md4c to my project over worrying about maintaining a package manager for c++ these days. Precisely because it makes me think twice about adding another dependency.
Earlier quoted context omitted.
I remember back when I was programming in Delphi I could link directly against a .dll, just take a function prototype from the .h file and translate it into a function declaration like this one: function I2C_GetNumChannels(out numChannels: Longword): FT_Result; stdcall; external 'libmpsse.dll'; and that was it; but to do this in MSVC you needed not only the .h header and the .dll itself, you also needed that stupid .…
Delphi made an awful lot of things incredibly easy. Com automation for example. It is just too bad Borland had fucked up.
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 to COM.
How a OS development team that is so invested into COM APIs, fails to produce tooling better than the competition for 25 years escapes me.
Earlier quoted context omitted.
They all get the tooling wrong though because none can stand the idea that you might want to mix languages, or add their new language to an existing project with existing tooling.
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.
I bet the announced Chrome efforts will again, require another adaptation.