3 ms·

I'm writing this from the experiencing of maintaining large legacy C++ projects as well as developing new ones. I only do this for work, not as a hobby, nor any

I'm writing this from the experiencing of maintaining large legacy C++ projects as well as developing new ones. I only do this for work, not as a hobby, nor anything OS. >Show me how to import library in CMake. And then also show me how to import library that doesn’t have CMakeLists.txt file. I'm not sure how this is a gotcha. I'm not that familiar with Cargo, but I think the equivalent would just be something like: TARGET_LINK_LIBRARIES(myProgramName Eigen3::Eigen) in cmake. Not very hard. Also...why does it matter if there's a cmakelists.txt file? How is that a bad thing? >Good luck explaining to team that they can only use subset of C++ You learn as you go, like literally any other language. You don't need to understand every single line and function call in a program to make changes or add things to it. As you come across something you need to modify, you learn a bit about the features being used. Now, if you have a real go-getter on the team who has covered the entire project in the most advanced features used in the most obscure ways, sure, it's going to suck for anyone just starting. But that's a problem again, in literally any language. And not a fault of C++, frankly.

wiseowise 3y ago
> I'm not sure how this is a gotcha. I'm not that familiar with Cargo, but I think the equivalent would just be something like: > TARGET_LINK_LIBRARIES(myProgramName Eigen3::Eigen) Include how the library gets in your build, not how you link it. > Also...why does it matter if there's a cmakelists.txt file? How is that a bad thing? Maybe because it gets dramatically harder than having `cargo install x`? Or did they solve it recently where any autotools/meson/whatever gets pulled into project without any blood sacrifices to pass all compiler flags properly? > You learn as you go, like literally any other language. You don't need to understand every single line and function call in a program to make changes or add things to it. As you come across something you need to modify, you learn a bit about the features being used. How can you make you changes to something you don't understand and make sure that it still works? Also, this is absolute nightmare from perspective of team and org cohesion. > But that's a problem again, in literally any language. And not a fault of C++, frankly. No, it's not. Aside from maybe Scala, I can't think of any mainstream modern programming language where you have to actively create your own sublanguage to make it bearable.
- Night_Thastus 3y ago
  >Include how the library gets in your build, not how you link it. Kind of depends. If you're in a Linux environment or something like MSYS, you'd just need the relevant Eigen package (in MSYS: mingw-w64-eigen3), which then you can link against. You could build it from source instead I suppose, and it has its own cmakelists which you just add as a subproject if you want to go that route. This isn't rocket science. Could it be easier? Sure. But it's not terrible either. >How can you make you changes to something you don't understand and make sure that it still works? Also, this is absolute nightmare from perspective of team and org cohesion. You learn about how the part you're modifying works. Ask for some assistance from the team members. Read the docs. Look up anything from libraries/stdlib that you don't understand, go into the debugger and watch as the state changes. Build the knowledge gradually. The next thing won't be as difficult. Don't try to take in the entire project at once, that's an overload of information for any non-trivial project. Again, that's true in literally any language.
  - fsloth 3y ago
    It sounds like you are operating in an existing org with a mature codebase. In this context, where the existing product is implemented using C++, continuing to use the language makes perfect sense. I implement and maintain C++ for my day job so sure, it's not that bad ... it's only bad when you compare it to the state of the art in other language ecosystems. "This isn't rocket science. Could it be easier? Sure. But it's not terrible either." I don't know how to measure "terrible". I agree it's not rocket science. And it's much better than two decades ago. But still, compared almost to any other industrial language (which of course have their own set of problems) the default experience setting up and maintaining a cross platform project is abysmal. By "abysmal" I mean that defining the build is not a project goal in itself that requires meticulous design and expertise, and is something that just works out of the box. If you work only in posix land the experience is far less uncomfortable, of course.

wiseowise 3y ago

> I'm not sure how this is a gotcha. I'm not that familiar with Cargo, but I think the equivalent would just be something like: > TARGET_LINK_LIBRARIES(myProgramName Eigen3::Eigen) Include how the library gets in your build, not how you link it. > Also...why does it matter if there's a cmakelists.txt file? How is that a bad thing? Maybe because it gets dramatically harder than having `cargo install x`? Or did they solve it recently where any autotools/meson/whatever gets pulled into project without any blood sacrifices to pass all compiler flags properly? > You learn as you go, like literally any other language. You don't need to understand every single line and function call in a program to make changes or add things to it. As you come across something you need to modify, you learn a bit about the features being used. How can you make you changes to something you don't understand and make sure that it still works? Also, this is absolute nightmare from perspective of team and org cohesion. > But that's a problem again, in literally any language. And not a fault of C++, frankly. No, it's not. Aside from maybe Scala, I can't think of any mainstream modern programming language where you have to actively create your own sublanguage to make it bearable.

Night_Thastus 3y ago
>Include how the library gets in your build, not how you link it. Kind of depends. If you're in a Linux environment or something like MSYS, you'd just need the relevant Eigen package (in MSYS: mingw-w64-eigen3), which then you can link against. You could build it from source instead I suppose, and it has its own cmakelists which you just add as a subproject if you want to go that route. This isn't rocket science. Could it be easier? Sure. But it's not terrible either. >How can you make you changes to something you don't understand and make sure that it still works? Also, this is absolute nightmare from perspective of team and org cohesion. You learn about how the part you're modifying works. Ask for some assistance from the team members. Read the docs. Look up anything from libraries/stdlib that you don't understand, go into the debugger and watch as the state changes. Build the knowledge gradually. The next thing won't be as difficult. Don't try to take in the entire project at once, that's an overload of information for any non-trivial project. Again, that's true in literally any language.
- fsloth 3y ago
  It sounds like you are operating in an existing org with a mature codebase. In this context, where the existing product is implemented using C++, continuing to use the language makes perfect sense. I implement and maintain C++ for my day job so sure, it's not that bad ... it's only bad when you compare it to the state of the art in other language ecosystems. "This isn't rocket science. Could it be easier? Sure. But it's not terrible either." I don't know how to measure "terrible". I agree it's not rocket science. And it's much better than two decades ago. But still, compared almost to any other industrial language (which of course have their own set of problems) the default experience setting up and maintaining a cross platform project is abysmal. By "abysmal" I mean that defining the build is not a project goal in itself that requires meticulous design and expertise, and is something that just works out of the box. If you work only in posix land the experience is far less uncomfortable, of course.