31–37 of 37 posts
Am I wrong in thinking that this mild form of schizophrenia ( no official ABI but dont break the ABI) is part of the reason why we now live in a world where all applications talk to each-other through sockets, incurring huge overheads?
You can use shmem instead of sockets, which is pretty fast. Not as fast as a direct call, but pretty good; good enough for most purposes.
Am I wrong in thinking that this mild form of schizophrenia ( no official ABI but dont break the ABI) is part of the reason why we now live in a world where all applications talk to each-other through sockets, incurring huge overheads?
You can use shmem instead of sockets, which is pretty fast. Not as fast as a direct call, but pretty good; good enough for most purposes.
Earlier quoted context omitted.
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…
In regards to COM I was specially thinking about how virtual functions and methods are layed out. This cannot change without breaking a lot of code. Already this causes issues in non-C++ languages (e.g. the difference with thiscall in C++).
Earlier quoted context omitted.
You can use shmem instead of sockets, which is pretty fast. Not as fast as a direct call, but pretty good; good enough for most purposes.
Have you actually measured? The overhead isn't the socket, but the marshaling and unmarshaling, and you need these things for sockets, shared memory, or any other IPC.
Earlier quoted context omitted.
Makes me wonder why anybody takes them by value, and not by rvalue-reference. But unique_ptr in public interfaces feels like code smell. I have done it, but not proudly.
Quite a few times, I've made C++ library APIs like this: struct iface { virtual ~iface(){ } virtual void doSomething() = 0; static std::unique_ptr create(); } I don't know good ways to replace unique_ptr here. Requiring library users to #include the concrete implementation is not good: inflates compilation time, pollutes namespaces, pollutes IDE's autocompletion DB. Can go C-style i.e. pass double pointer argument to…
But it would often be better to make a move-only value type, and return that instead.
Earlier quoted context omitted.
In regards to COM I was specially thinking about how virtual functions and methods are layed out. This cannot change without breaking a lot of code. Already this causes issues in non-C++ languages (e.g. the difference with thiscall in C++).
The vtable layout is much smaller and much more stable than C++ as a whole. COM has a ton of value.