News for hackers. Stuff that matters.
Re:C++20 Idioms for Parameter Packs by pavlov on Tuesday February 27, 2024 @01:05PM (#39527290)
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.

Re:C++20 Idioms for Parameter Packs by Night_Thastus on Tuesday February 27, 2024 @01:30PM (#39527654)
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.

Re:C++20 Idioms for Parameter Packs by jujube3 on Tuesday February 27, 2024 @07:29PM (#39532277)
"Building code to be consumed by others" is literally all programming languages are about though.

So... time to move to Rust then?

Re:C++20 Idioms for Parameter Packs by foofie on Wednesday February 28, 2024 @01:30AM (#39534739)
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? "
Re:C++20 Idioms for Parameter Packs by foofie on Wednesday February 28, 2024 @01:28AM (#39534725)
> 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.