31–40 of 88 posts
C++ ABIs are why Win32 settled on things like COM to do cross-module passing of objects. Because nobody could agree on a standard, the COM standard enforced a very specific calling convention, and a very specific vtable layout for COM objects.
Earlier quoted context omitted.
I understand that Move Semantics led to better implementations and that this is why things changed. I know that in this case, problems arose when transitioning from C++98 to what's commonly called Modern C++ (C++11). However, I'm not very familiar with what the specific issues were with COW. If you happen to know of any documents that describe this problem in more detail, I'd appreciate it if you could let me know. I…
The changes to std::string were made because "the [pre-C++11] definition of basic_string allows only very limited concurrent access to strings. Such limited concurrency will inhibit performance in multi-threaded applications." The proposed fix was to make "all iterator and element access operations safely concurrently executable." [0]. This involved limiting the circumstances in which iterators could be invalidated,…
Earlier quoted context omitted.
Isn't this one reason why C is the de facto FFI? OSes happen to use it in their OS ABI and so everything is forced to speak it
One reason. The other is C is easy. Any language can implement it and have confidence it can work. (there are other options that are just as easy, but C won). C++ is much harder because of things like function overloading and exceptions - none of it is difficult, but there is a lot more to do and thus more opportunities for bugs.
Does the C++ standard guarantee binary ABI? Isn't that something that compiler and library contributors handle separately? So I think the arguments you see online are more accurate—vendors are the ones maintaining it. In other words, the ABI we rely on today isn't really part of the C+ standard—it's more like the Itnaium C++ ABI or the MSVC C++ ABI. In the end, I think the ABI stays stable because of community conven…
The C++ standard doesn't say anything about binary ABI (as you say generally either Itanium or MSVC, though there are other options they are rare). However the people who write that standard are very sensitive to the vendors and users of C++ who depend on a stable binary ABI. Thus they take extreme care to ensure that no change to the standard breaks binary ABI. The C++ standard did force gcc to break the ABI of std:…
During the same time the MSVC compiler broke ABI multiple times and the world didn't end.
The fact that breaking ABI was such a shitshow for libstc++ is more related to the way C++/ABI/SOs is/are handled in Linux...
GNU libstdc++ "Dual ABI" issue - https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_a...
I understand that Move Semantics led to better implementations and that this is why things changed. I know that in this case, problems arose when transitioning from C++98 to what's commonly called Modern C++ (C++11). However, I'm not very familiar with what the specific issues were with COW. If you happen to know of any documents that describe this problem in more detail, I'd appreciate it if you could let me know. I…
A nice succinct post by Pavel Khaipov; Copy-on-Write in Modern C++: Why the Standard Dropped It - and Why Qt Still Uses It - https://www.linkedin.com/posts/khaipov_copy-on-write-in-mode...
A detailed post by Andrii Nikishaiev; Why Copy-On-Write (COW) removed in C++? - https://www.linkedin.com/pulse/why-copy-on-write-cow-removed...
The std document on Concurrency Modifications to Basic String - https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n25...
Finally, C++11 tightened the specification for std::string viz. contiguous memory, some methods must have O(1) access time, when references/iterators/pointers can/cannot be invalidated etc. which doomed COW.
Earlier quoted context omitted.
The C++ standard doesn't say anything about binary ABI (as you say generally either Itanium or MSVC, though there are other options they are rare). However the people who write that standard are very sensitive to the vendors and users of C++ who depend on a stable binary ABI. Thus they take extreme care to ensure that no change to the standard breaks binary ABI. The C++ standard did force gcc to break the ABI of std:…
> They then watched the gcc community work through 10 years of pain to make the transition. During the same time the MSVC compiler broke ABI multiple times and the world didn't end. The fact that breaking ABI was such a shitshow for libstc++ is more related to the way C++/ABI/SOs is/are handled in Linux...
Microsoft never said it outright, but I’ve always assumed the major con that made them switch was that people didn’t buy new Visual Studio versions because upgrading VS required also upgrading all of your binary blob closed-source dependencies.
Earlier quoted context omitted.
One reason. The other is C is easy. Any language can implement it and have confidence it can work. (there are other options that are just as easy, but C won). C++ is much harder because of things like function overloading and exceptions - none of it is difficult, but there is a lot more to do and thus more opportunities for bugs.
I would go far as to say that modern C++ is an Eldritch horror of a programming experience
Same applies to C and UNIX/POSIX, OpenGL/Vulkan/OpenCL/NVN/LibGNM(X),...
Thus analysers and language subsetting tools, enforcing language style guides and safer coding practices.
One nice thing to remember is for projects you control, you can dictate the ABI. There isn't a law enforcement bureau that will arrest you for passing parameters in whatever register suits you. You just have to imagine life differently than they did in the 70s when they dreamed up dynamic libraries for reasons that are largely no longer valid.
Program Obfuscation via ABI Debiasing (pdf) - https://www.google.com/goto?url=CAESYgHuR6pNsi8_4x_I2WBy7lmf...
PS: James Coplien in his excellent Advanced C++ Programming Styles and Idioms shows many techniques one of which is actually replacing vtable entries at runtime to mimic features from more dynamical runtime languages (eg. Smalltalk).
C++ ABIs are why Win32 settled on things like COM to do cross-module passing of objects. Because nobody could agree on a standard, the COM standard enforced a very specific calling convention, and a very specific vtable layout for COM objects.
And Delphi came along and used the same layout, so an interfaced Delphi object has beautiful COM interop.
In a tragic way, given the prevalence of COM in Windows, especially since Vista, someone at Microsoft should offer a few Delphi and C++ Builder licenses to the teams responsible for doing COM tooling.
Because MFC/OLE, ATL, WTL, WRL, C++/WinRT all have their sharp edges and could be so much better, if someone actually cared about productivity and framework ergonomics.
C++ ABIs are why Win32 settled on things like COM to do cross-module passing of objects. Because nobody could agree on a standard, the COM standard enforced a very specific calling convention, and a very specific vtable layout for COM objects.
And COM enforces lifecycle rules, transparent remoting, uniform activation (constructors basically), security primitives, marshalling, transparent async calls (yes, you can call any method asynchronously), and a ton of other things. It's actually very good and it's a shame most don't know about it and most of the rest sneer at it.