4 ms·
They are adding more syntax to reduce syntax. Have you seen the spaceship operator? C++ has jumped the shark. I just want an ABI. Can we get an ABI already?
by snarfy 8y ago
They are adding more syntax to reduce syntax. Have you seen the spaceship operator? C++ has jumped the shark. I just want an ABI. Can we get an ABI already?
- maxxxxx 8y agoYes, an ABI would be great. I am always amazed how easy it is to use libraries in C# or Java whereas C++ is just a PITA.
- pjmlp 8y agoIt is easy as well, when you use a compiler that generates bytecode like C++/CLI.
- aaaaaaaaaab 8y agoUmmmm... Try running java 8 bytecode on an older JVM.
- gpderetta 8y agoThat's possible because all C# and Java compilers only really target a single platform (their respective VM).
- pjmlp 8y agoIt is called COM/UWP on Windows. A C++ ABI requires an OS written in C++, likewise there is no such thing as C ABI per se, rather UNIX ABI, Win32 ABI and so forth.
- eridius 8y agoA C++ ABI does not require an OS written in C++. It just requires all compiler implementations to agree to standardize on a single ABI and enshrine it in a spec that any future implementations must abide by.
- pjmlp 8y agoA C++ compiler that needs to support multiple distinct ABIs? One per each platform, plus an additional one, agreed by all these guys? And the list is not 100% compliant, e.g. TI is missing. https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compilers https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compil... Not even C has managed to do it, what people conventionally refer as C ABI is actually the OS ABI. I still remember having to deal with multiple C ABI on MS-DOS and Windows static libraries.
- gpderetta 8y agoI'm really interested to know how a standard ABI would cover both little endian 32 bit x86 and big endian 64 bit POWER.
- eridius 8y agoCompilers already have ABIs, they're just compiler-specific and not documented. If they didn't have an ABI, then you couldn't link 2 C++ libraries together. In terms of having one spec that handles arbitrary architectures, maybe it could be defined relative to the C ABI? I don't actually know how what the internal ABIs used by the current crop of C++ compilers looks like, so I don't know if they could be expressed relative to the C ABI or not. Alternatively, one could come up with a set of configurable values that define what makes one architecture different from another (such as word size, long/pointer size (if different than word size), endianness, etc). You know, the stuff that the compiler already has to know about in order to compile for an architecture (and I'm pretty sure clang at the least already has a way to even define new target triples in terms of a set of configurable values for this sort of thing). I assume existing compilers don't invent entirely brand new ABIs for each new architecture but instead just adapt an internal standard C++ ABI to the new architecture using a similar process already. The same could be done for a public standard C++ ABI.
- deleted 8y ago[deleted]
- hfdgiutdryg 8y agoPardon the dumb question, but is the term ABI new (or experiencing a recent increase in usage)? I've seen it twice in the last 24 hours, and never before in my life. And that's despite being entirely too familiar with COM.
- Retra 8y agoNo, it is an old term.
- Elv13 8y ago> but is the term ABI new No, it is age old. The thing is that it is only "a thing" to embedded native developers and library authors. The general concept is that the programming language "API" doesn't define how the dll/o/a/la/lib/so/dylib "loader" look for "symbols" in the file. If you example, I do: enum {FOO, BAR}; and next month I change it to enum {BAZ, FOO, BAR}; then everything will still compile, but if I execute an older program with my library, it still thinks FOO is 0 and BAR is 1 while it's no longer the case. It gets worst for function and type definition. Then when you get into C++, it gets an order of magnitude more complex because almost every code change will somewhat break one or many symbols. This is why there is often "proxies" called PIMPL or d_ptr between the library symbols and the actual implementation code. C++ has no officially standardized way to serialize the object to their symbol names. This is often a pain point and Apple wants to fix this for a decade for has so far failed to get everybody to agree on something. For embedded devs, more problem arise from the fact that the instruction set and C library themselves are not the same for all devices and this also break pre-compilled code. Many platform will often favor "static binaries" over dynamic ones to avoid the consequences of breaking the ABI.
- Gibbon1 8y agoI think you see it because there has be a resurgence in interest in C/C++. probably because people are giving up on the idea that all new languages will run on the JVM. ABI is ancient since it defines the underlying structure that allows you to link compiled object files and liberals together (the latter both statically and dynamically). Allowing code generated in one module to successfully call functions in another.