7 ms·

Pre-C++11 was. Modern C++ not so much. Things have drastically improved and dare I say, it's more appropriate to call C++11 and greater C++ v2. That said the to

• baby 7y ago
  Do you still need to write makefiles manually?
  • dwaite 7y ago
    If you are using makefiles, you either write them manually or use a generator like Cmake or the autotools. Tools or scripts to automate build are required in all languages once you hit a certain level of heterogeneity/complexity.
  • umanwizard 7y ago
    What does the build system have to do with the language? The current trend of combining the two concerns by having language-specific build systems (like Cargo) was a mistake, IMO.
    • adrianN 7y ago
      It has a lot to do with the language because the ease of adding external libraries has an enormous impact on the design choices made when writing code. Also, the need for header files and disgusting hacks like unity builds just adds unnecessary friction.
      • signa11 7y ago
        > ... language because the ease of adding external libraries has an enormous impact on the design choices... even if you could incorporate external libraries with zero impedance mismatch, you still have to _use_ the said libraries. while there might be _marginal_ element of truth to that statement, however ease of stitching external libraries into your application has no bearing on either the programming language or the act of programming the application itself.
        • adrianN 7y ago
          I don't understand what you're trying to say. Of course the effort to include the library in the project and keep it up to date has an impact on the decision whether I use it or whether I just roll my own. There is a reason that my Rust projects have dozens of dependencies whereas in C++ I basically restrict myself to boost or other header-only libraries.
          • signa11 7y ago
            > I don't understand what you're trying to say. simple, ease of integrating external libraries into a project has _nothing_ to do with the programming language. they are at best two orthogonal topics.
            • baby 7y ago
              50% of the popularity of modern languages like golang and rust comes from the fact that building and dependency management is light years ahead of older languages.
              • signa11 7y ago
                remind me again on what that has to do with either the syntax or the semantics of the underlying programming language.
                • mrpf1ster 7y ago
                  Your original argument was that the ease of dependency management doesn't change programming or the act of programming. I feel it encourages a compartmentalized approach to writing programs, pulling in dependencies as needed rather than relying on a giant library like Boost. Thus it does actually change the "act of programming", which is a vague term that can mean anything. This is not mentioning all the upsides of having a easy build system from easy learning and community standpoints.
    • baby 7y ago
      Ah. So some people like writing makefiles. Interesting.
    • Too 7y ago
      Common grounds and uniformity - if every library were using it's own build system it becomes very hard to combine libraries. See c++ for example, when including a library you always have to either wrap the build, rewrite it to your build system or find a a way to prebuild. And every library is unique. Contrast this with other systems where you just add a line to your package.json file. Big red flag is that people come up with those header-only libraries or single .c-file only libraries, just to get around the problem of package management. Language rules define dependency rules, that the build system is not aware of. For example transitive #include chains, requiring stuff like gcc -MMD to generate makefiles. This also improves IDE experience with suggestions on where to find imports instead of elementary error messages like "header file not found".