5 ms·

> I think it is fair to say there are two different versions of modern C++ you can learn: one for library designers and one for everyone else. I get what you'r

by foofie 3y ago

> I think it is fair to say there are two different versions of modern C++ you can learn: one for library designers and one for everyone else. I get what you're trying to say, but this assumption that only a subset of developers need to know how to write code intended to be consumed by third parties is the reason why stuff needlessly breaks all the time for no good reason. We can't have modularity without having code consumable by other components, and knowing how to write reusable components and reusable interfaces is a core competency in software development.

pavlov 3y ago
My possibly Luddite opinion is that using the most amazing and surprising new C++ features is not the best way to build code consumed by others. It’s good for internal APIs if you have a library team and active quality control, but if you involve third party users, more conservative is often better for everyone. For a lot of use cases, a plain C API wrapper is still very useful because it’s so easy to call from practically any other language. It can be better for maintenance to have a very narrow C API than to expose all the bells and whistles from C++ wonderland.
- Night_Thastus 3y ago
  I agree fully, and this is what I do personally. (Though we have to use a C wrapper API for cross-platform compatibility and name mangling reasons) But honestly, people seem to get all hung up on C++ having weird features. No-one is being forced to use a feature just because it exists. I use the sub-set of C++ that I'm familiar with and grow it when it looks like it'll save a lot of effort relative to cost of learning it.
- jujube3 3y ago
  "Building code to be consumed by others" is literally all programming languages are about though. So... time to move to Rust then?
  - foofie 3y ago
    You Rust fanboys get very tiring. No one can sneeze in a discussion on <INSERT_PROGRAMMING_LANGUAGE> without one of your types jumping in with a clueless and gratuituous "So... time to move to Rust then? "
    - vpastore 3y ago
      [dead]
- foofie 3y ago
  > My possibly Luddite opinion is that using the most amazing and surprising new C++ features is not the best way to build code consumed by others. It's ok if you opt to not jump onto the latest and greatest, specially at the interface level. What is counterproductive is to not learn new features, and know when and when not to use them. It makes absolutely no sense to stay stuck in C++11 when there's a heap of basic features that were since made available throughout the last decade. It's even more critical the fact that the C++ standardization effort placed a great deal of effort on vocabulary types, which by its own definition mean types excpliticly designed to be used in interfaces. It's perfectly ok to make a call to not use exceptions, template metaprogramming, multi threaded support, etc. What's counterproductive is staying stuck way back in 2011 because you do not know what's out there.
jandrewrogers 3y ago
I think knowing how to write modular code is somewhat separate from the advanced "library writer" features in C++. Anyone can write clean and modular code without them, just as you could before they existed. You don't lose expressiveness per se but from a library user perspective it requires a great many more things to be explicit, writing a lot more boilerplate, and a larger API surface area that you have to learn. The new C++ features give the library writer the option of investing in more elegant, flexible, and concise expressions of modular code with little additional work but requiring stronger C++ skills to elevate the modularity in this way. It is an ease-of-use improvement as much as a modularity improvement and provides some evolutionary pressure to design better interfaces to modular code.
- angiosperm 3y ago
  When you are designing an interface, and a new feature could make it better -- safer, faster, less convoluted -- but you fail to use it, you have produced a worse interface.
- foofie 3y ago
  > Anyone can write clean and modular code without them, just as you could before they existed. I don't think so. There are multiple books dedicated to the topic of writing modular code, including books specialized in C++. Projects such as Qt are renowned for having adopted architectural traits that ensure they do not break compatibility even following a major version upgrade. I still see projects not respecting contracts and what not to put in the interface. I think that this belief that "anyone can write clean and modular code" contrasts with reality, and suggests a certain obliviousness regarding the problem domain.

by foofie 3y ago

pavlov 3y ago

My possibly Luddite opinion is that using the most amazing and surprising new C++ features is not the best way to build code consumed by others. It’s good for internal APIs if you have a library team and active quality control, but if you involve third party users, more conservative is often better for everyone. For a lot of use cases, a plain C API wrapper is still very useful because it’s so easy to call from practically any other language. It can be better for maintenance to have a very narrow C API than to expose all the bells and whistles from C++ wonderland.

Night_Thastus 3y ago
I agree fully, and this is what I do personally. (Though we have to use a C wrapper API for cross-platform compatibility and name mangling reasons) But honestly, people seem to get all hung up on C++ having weird features. No-one is being forced to use a feature just because it exists. I use the sub-set of C++ that I'm familiar with and grow it when it looks like it'll save a lot of effort relative to cost of learning it.
jujube3 3y ago
"Building code to be consumed by others" is literally all programming languages are about though. So... time to move to Rust then?
- foofie 3y ago
  You Rust fanboys get very tiring. No one can sneeze in a discussion on <INSERT_PROGRAMMING_LANGUAGE> without one of your types jumping in with a clueless and gratuituous "So... time to move to Rust then? "
  - vpastore 3y ago
    [dead]
foofie 3y ago
> My possibly Luddite opinion is that using the most amazing and surprising new C++ features is not the best way to build code consumed by others. It's ok if you opt to not jump onto the latest and greatest, specially at the interface level. What is counterproductive is to not learn new features, and know when and when not to use them. It makes absolutely no sense to stay stuck in C++11 when there's a heap of basic features that were since made available throughout the last decade. It's even more critical the fact that the C++ standardization effort placed a great deal of effort on vocabulary types, which by its own definition mean types excpliticly designed to be used in interfaces. It's perfectly ok to make a call to not use exceptions, template metaprogramming, multi threaded support, etc. What's counterproductive is staying stuck way back in 2011 because you do not know what's out there.

jandrewrogers 3y ago

I think knowing how to write modular code is somewhat separate from the advanced "library writer" features in C++. Anyone can write clean and modular code without them, just as you could before they existed. You don't lose expressiveness per se but from a library user perspective it requires a great many more things to be explicit, writing a lot more boilerplate, and a larger API surface area that you have to learn. The new C++ features give the library writer the option of investing in more elegant, flexible, and concise expressions of modular code with little additional work but requiring stronger C++ skills to elevate the modularity in this way. It is an ease-of-use improvement as much as a modularity improvement and provides some evolutionary pressure to design better interfaces to modular code.

angiosperm 3y ago
When you are designing an interface, and a new feature could make it better -- safer, faster, less convoluted -- but you fail to use it, you have produced a worse interface.
foofie 3y ago
> Anyone can write clean and modular code without them, just as you could before they existed. I don't think so. There are multiple books dedicated to the topic of writing modular code, including books specialized in C++. Projects such as Qt are renowned for having adopted architectural traits that ensure they do not break compatibility even following a major version upgrade. I still see projects not respecting contracts and what not to put in the interface. I think that this belief that "anyone can write clean and modular code" contrasts with reality, and suggests a certain obliviousness regarding the problem domain.