
On Thu, Jul 31, 2025 at 3:48 PM Дмитрий Архипов <grisumbras@gmail.com> wrote:
чт, 31 июл. 2025 г. в 09:53, Artyom Beilis via Boost <boost@lists.boost.org>:
So quick google (and their gemeni) leads to examples exactly what I need: bp::child, wait, terminate, wait_for etc. Lots of tutorials fine.
This thread is actually amazing. We shouldn't change our APIs, because LLMs can get confused and hallucinate wrong snippets of code.
Agree! But it wasn't about LLM :-) I actually can care less about LLM. The point is If I used Boost.Process when I started my project 2 years ago or if I used the Boost.Process that Ihave with my distro it would become broken. But I used fork/exec code in the first place. And only when I tried to port it to windows I discovered that API was removed when 1.87 to 1.88. When v2 was introduced less than a year ago! (And requiring special definition - or touching the code is breaking) But this only a part of it (see below)
Another point I also liked a lot is this:
No grace time, no deprecation, no keeping old API for a while The "no grace time, no deprecation" was immediately contradicted by the next email.
Please notice that if v1 is hidden and requires special definition and version of 1.88 does not even mention how to enable v1 Quoting docs in 1.88
Version 2 is now the defauled. In order to discourage usage of the deprecated v1, it’s documentation has been removed.
This is now how you do stuff. Sorry! And this is only an example of how boost libraries tend to remove stuff (not first time!)
The "including Asio dependency" looked very strange to me, as I vaguely remembered that Asio was always a dependency of Process. Luckily, we have Boost dependency reports online: https://pdimov.github.io/boostdep-report/boost-1.66.0/process.html.
I stand corrected. My mistake.
The key takeaway for me is that when asked for "concrete projects where that has been a problem" you came up with a *hypothetical* that you didn't even think through very well.
It is a _real_ problem, not a _hypothetical one_. - If I introduce new code I shouldn't use a deprecated API. I may use some older API but not removed (hidden API) Because latest boost removed v1 and I don't know for how long it will stay - I need users to be able to build the project on normal Linux distro (like Ubuntu 2024 or 2020 that is still running) and that means I can't use Boost.Process on Linux. So Boost.Process is just not an option because I need to target more than a single system. So how did I solve it? Instead of moving from fork/exec/kill/wait on Linux to Boost.Process on Linux and Windows had to just use win32 API on Windows because Boost.Process API isn't useful! But what is important isn't Boost.Process itself. It is an issue across the entire boost code base. I hadn't been using boost in my projects for a while and when I finally needed a small library to do a simple task I discovered that nothing changed since I first started using Boost 1.33. It is all the same old story all over again. So I bring this back (not a first time) that Boost breaking APIs all the time should be addressed. Artyom