11–20 of 37 posts
What is the "runtime overhead involved in passing unique_ptr by value"? The reference is a 1h YouTube video.
I wrote up a reddit post for a possible workaround for removing the overhead. It's standard C++, no ABI break is required. It's not without caveats though: https://www.reddit.com/r/cpp/comments/do8l2p/working_around_...
What is the "runtime overhead involved in passing unique_ptr by value"? The reference is a 1h YouTube video.
Short version: it passes a pointer to the pointer forcing a double indirection rather than a single. Simple attempts to fix don't really work. Not even sure an ABI break will be enough, but it would at least be a minimum requirement.
Discussion of whether the next (or any future) c++ release should break abi compatibility.
Does C++ have an ABI?
Discussion of whether the next (or any future) c++ release should break abi compatibility.
Does C++ have an ABI?
Nevertheless, certain language changes can force a breaking change to any existing ABI (or even all of them, and the C++ committee does not work in a vacuum. They work with existing implementations and must agree with implementers before making changes to the standard.
For example, there was a change to the definition of std::string in C++11 that forced a break in all commonly used ABIs (MSVC, Itanium at least). This was deemed necessary, but the cost of it to real-world programs has proven higher than anticipated, and may be a regretted decision (it apparently still causes problems and requires special flags even today).
What is the "runtime overhead involved in passing unique_ptr by value"? The reference is a 1h YouTube video.
Short version: it passes a pointer to the pointer forcing a double indirection rather than a single. Simple attempts to fix don't really work. Not even sure an ABI break will be enough, but it would at least be a minimum requirement.
But unique_ptr in public interfaces feels like code smell. I have done it, but not proudly.
Earlier quoted context omitted.
Does C++ have an ABI?
C++ doesn't but Windows C++ does, to the extent it's implicitly used for things like COM. Any breaking change would have to be managed carefully.
On another platform, libstdc++ is mostly backward compatible, within reason.
The C++ standard is not "officially" concerned by stability, except that in practice people in the committee care a lot (because some major implementations care a lot) so some modifications are rejected because they would break the ABI currently used in practice.
Earlier quoted context omitted.
C++ doesn't but Windows C++ does, to the extent it's implicitly used for things like COM. Any breaking change would have to be managed carefully.
On the contrary one of the reason of COM is to not depend on the C++ ABI, which is not stable at all under Windows (it has been de-facto stable for the three last version of MSVC, but was broken each time before, and the recent stable stride is not an indication this ABI compat will continue - actually it is well known that MS internally maintains an ABI incompat version of the STL that will be very probably used in…
Customers who needed stability were staying on ancient compilers. MS probably would rather have them using new versions, and exercising new features.
a. Having a real binary compatibility story is beneath C++, but
b. The accidental ABI compatibility that exists today is too widely adopted to break.
Earlier quoted context omitted.
C++ doesn't but Windows C++ does, to the extent it's implicitly used for things like COM. Any breaking change would have to be managed carefully.
On the contrary one of the reason of COM is to not depend on the C++ ABI, which is not stable at all under Windows (it has been de-facto stable for the three last version of MSVC, but was broken each time before, and the recent stable stride is not an indication this ABI compat will continue - actually it is well known that MS internally maintains an ABI incompat version of the STL that will be very probably used in…