C++26: Deprecating or removing library features
44 comments
·March 20, 2025kstrauser
alecco
> While the old API expected that the shared object is not used directly, the API made it possible which led to undefined behaviour, typically producing a data race.
- C++ is insecure, don't use it
[C++ fixes a hole]
- C++ always deprecates the easy APIs
[Stanley face]kstrauser
I get what they were trying to say, but the exact phrasing amused me. It read like: "This feature was too easy and convenient, so we yanked it."
indigoabstract
I think he meant an easy to misuse API.
optimalsolver
Accidentally correct is the best kind of correct.
zabzonk
> easy-to-use API
A lot of C (not so much C++) programmers thought it was easy to use correctly. Mostly, they were wrong.
zabzonk
I'm amazed it has taken so long to get rid of strtok(). This is one of the worst designed and most misused functions I have ever seen - just about every use of it I have ever come across has been wrong. Write your own mini-parser rather than use it.
johnisgood
I'm amazed people who are skilled in C find it difficult to use, considering everything you have to know about it is available in man-pages (and pretty much everywhere online).
If it is misused, that is a skill issue (yeah, sorry). I could misuse virtually anything in other languages, too...
So, all in all, I don't understand what you are trying to say. There are cases where I would rather use strtok than to roll my own. Sometimes all you need is already available, e.g. strtok, or strsep, or strstr, or what have you.
Consider that I misuse this and that in your favourite language. Is it a reflection of the programming language, or my limited "skills"?
https://wiki.sei.cmu.edu/confluence/display/c/STR06-C.+Do+no... is worth a read, too.
IshKebab
> If it is misused, that is a skill issue (yeah, sorry).
No it isn't. It's very easy to misuse so even skilled people misuse it.
> Consider that I misuse this and that in your favourite language. Is it a reflection of the programming language, or my limited "skills"?
Depends on what this and that are. If they are things that are easy to misuse and many people do, then it's a reflection of the programming language. If they're well-designed and it's only you getting it wrong, then it's your limited skills.
xedrac
The trick is to just make everything hard to use, then it's not easy to misuse.
johnisgood
If what you need is strtok, use it as documented. If you do not use it as documented, that is a skill issue. Do you even need strtok? If you do, RTFM.
> If they are things that are easy to misuse and many people do, then it's a reflection of the programming language. If they're well-designed and it's only you getting it wrong, then it's your limited skills.
Whatever "well-designed" means. At any rate, wonder where you got the "many people" from, who actually have read the manual.
For some of my use-cases, strtok is designed well enough. If I need something else, then I will use something else, and so should you. No need to re-implement strtok (or any other functions) readily available.
Plus, do you really think people who cannot use strtok properly can roll their own?
zabzonk
I don't know why you are going on about "skills" - I never mentioned such things in my comment - something you have introduced, I think. I do agree though that however "skilled" you are strtok() (and other C strXXX functions) is difficult to use correctly.
johnisgood
Because of another commenter who did, BUT I do not think that this is true, not after having read the manual pages. Do you think people who misuse strtok can implement their own alternative? The Internet is full of proper uses of strtok, and I bet LLMs know it too, and would help you through the process if you so want. This applies to most functions e.g. strcpy vs. strncpy vs. strlcpy, just to name one.
Honestly, if someone cannot use strtok (if they should really use it) after having read all the manual pages there is, I doubt they would be able to come up with their own, better version of it.
johnisgood
strtok was removed from C, too? Damn. I guess I am sticking to C99 regardless.
lifthrasiir
Don't use strtok, it was already painful to use in C99. It is not even that hard to emulate using strstr if you do need one.
GuB-42
If your use case is covered by strtok(), why not? Like all functions, you have to use it properly, and the use case for strtok() is narrow, but sometimes, it is just what you need.
I rarely use it myself, but emulating it is silly. Also strstr() is probably not the most appropriate, maybe you mean strpbrk()?
As far as I know, the only function from the libc that you should never use is gets(). It is even written in the manual: "Never use this function". As expected, it is removed from recent standards.
johnisgood
Exactly. There is also "strsep"[1].
johnisgood
man -a strtok
Been happily using it for a long time (unless other functions are not more ideal for the specific use-case).
There are some things to pay attention to, but the manual pages pretty much tell you everything you need to know.
[1] https://archlinux.org/packages/core/any/man-pages/ on Arch Linux, perhaps it is "man-pages" for other distros, too. As per Arch wiki: "man-pages provides both the Linux and the POSIX.1 man pages".
You may also do:
curl -sL 'https://man.archlinux.org/man/strtok.raw' | man -l -
curl -sL 'https://man.archlinux.org/man/getaddrinfo_a.raw' | man -l -
nesarkvechnep
The OC is the type of person to tell you the problems of C are all skill issues.
Lanolderen
Always have been (⌐■_■)
null
ape4
Use strtok_r()
lifthrasiir
That also works, but strtok is of so limited use that it's probably better to roll your own anyway. For example you can't handle arbitrary whitespace with strtok.
LegionMammal978
It wasn't removed, it was just taken off the list of freestanding functions.
superkuh
Luckily most C++ developers don't immediately jump on and begin using backwards incompatible features. The C++ community is still only recently generally requiring C++11. And that's great. Introduce new features but don't immediately use them in practice. Some other languages and their communities could really learn from this.
kstrauser
I feel exactly the opposite. If a language adds a new feature that's useful to me, and it helps me write better code, I'm going to use it. Perhaps not on the first day it comes out, but definitely the next time I need its functionality. And why not? That's why the feature was added in the first place.
There's the chance that its newness means it's not thoroughly tested yet. In any language with a reasonable development process, I'd open a bug report and then figure out a workaround until it's fixed. But I'd expect the interval between "feature is released" and "feature works as documented, modulo the usual long tail of edge cases" to be on the order of weeks or months, not decades.
Like, I can't imagine only now upgrading to Python 2.7 (which was current in 2011). I wouldn't expect every shop to be on 3.13 already, but neither would I scowl at a dev who wanted to use something new from a 2-year-old version.
superkuh
I agree with you from the developer point of view. But you should consider the point of view that other people might want to compile your software.
Python is a great example of a software community that has enormous trouble due to always changing the languae and using new features. It's pretty much infeasible to run a python program on your system python these days. Every single python program requires it's entire own custom python in a container.
jcelerier
> But you should consider the point of view that other people might want to compile your software.
Every platform provides a very easy way to install the latest version of clang.
> It's pretty much infeasible to run a python program on your system python these days.
System python shouldn't be a thing in the first place. If you want to run some python program in 2025 you just
uv venv --python 3.whateverkstrauser
I'm only sympathetic to a point. If I distributed C++ code to paying customers who wanted to compile it locally, I'd surely take their needs into account. For anything I was releasing as FOSS, deal with it. For instance, my nearby server is running Debian 12/Bookworm with GCC 12. According to https://gcc.gnu.org/projects/cxx-status.html, that supports nearly all of C++20. If you can't be bothered to upgrade to your system every few years, I'm not going to make more than 0 effort to cater to your ancient compilers.
In Python terms, today I wouldn't break a sweat to manage unsupported Python versions (https://devguide.python.org/versions/). If my stuff runs on an old Python 3.8 system, right on! I wouldn't deliberately break it or anything. But if something came along in 3.9 that makes my life more pleasant, I wouldn't hesitate to use it.
I also vehemently disagree with your Python characterization. There are any number of common, well-supported ways to easily install arbitrary versions on your system, including pyenv and uv. I have multiple versions installed on the laptop I'm typing this on. I do zero development inside containers: all my work runs directly on the host. And yet, none of them conflict with each other at all.
jcelerier
> The C++ community is still only recently generally requiring C++11.
this doesn't match what I see. The Jetbrains 2023 survey reported that 80% of C++ in use was >= C++17. Qt, one of the most common C++ UI framework, has been requiring C++17 for five years and support C++20 types in its API.
superkuh
Ah, Jetbrains must be touching a different part of the elephant. My related experience is with compiling C++ programs meant for human people to run on their own home computers. I imagine internal company dev projects like Jetbrains would cover don't care nearly so much about compatibility.
Also I note that 25%+ of the Jetbrains 2023 survey use C++11 or older. And 50% of Jetbrains survey devs say "No, I don't plan to move to another C++ standard" from C++11. So it's likely that 25% will stay high.
IshKebab
Nah it's not just Jetbrains. C++17 is the bare minimum at this point. It's even the default in GCC.
devnullbrain
C++14 minimum is the standard
null
juliangmp
C++ has many ugly parts to it, but I wouldn't call sticking with a 14 year old language "great". There's plenty of things that are really damn good, for example - std::span - std::string_view - std::source_location - if constexpr ...
Jyaif
> It was an easy-to-use API so it was deprecated by C++20, along with the introduction of its type-safe replacement std::atomic<shared_ptr<T>>.
Is this humor?
nit: the contrast between the font and the background is too low
flqn
I think the author misspoke and meant to say "easy-to-misuse" instead, which it definitely was.
> It was an easy-to-use API so it was deprecated by C++20,
That tracks with my experiences with C++.