Reply to thread

Message: [QUOTE="James Kanze, post: 3973878"] [...] That generally doesn't work, regardless. After all, it doesn't work for int; how could it work for a struct which contains an int? [...] That's not true. I've used DLL's without any C linkage on at least three platforms: Solaris, Linux and Windows. The only time name mangling is relevant is when the user explicitly loads a DLL and requests the function name (dlsym under Unix). In such cases, the usual solution is to have a single factory function as entry point, and declare that (and only that) as extern "C". Of course, you can only load DLL's which are binary compatible. Which means a lot of different things, on different platforms. If you're talking about the standard, you have to consider all possible cases. I explicitly stated elsewhere that this isn't a problem in practice. Of course, if you're calling LoadLibrary, then you're 100% Windows anyway, so you can count on the guarantees Microsoft gives as well as those in the standard. The weakness is that for a C++ compiler to compile something which can be called from C, it needs a C compiler and some collaboration on the part of the C compiler. And the C++ standard has no influence over C compilers. And extern "C" and layout are pretty orthogonal; depending on what you're doing, you might need both extern "C" and some sort of layout compatibility, however. It depends on the platform, but for at least Posix and Windows, there has to be, since the system ABI is defined in terms of C. In practice, given the simplicity of C, most of the layout issues depend directly on the hardware---I don't need to read the compiler specifications for an IBM mainframe, for example, to know the layout, since a compiler isn't going to introduce unnecessary padding (it can, but it won't), and the hardware determines where the padding, etc., is necessary. C++ is more complicated, since you have to consider things like how vtables are layed out. And for both C and C++, the calling conventions can vary. I don't know the situation on modern mainframes, but a long time ago, I know that different C compilers for the Siemens BS2000 used different calling conventions. The language specification cannot specify a standard ABI. That has to be hardware specific. Historically, C++ became significant after most hardware architectures had been specified, and there were several different C++ compilers around before C++ became important enough. The Itanium is the rare exception of an architecture which was defined after C++ was important, but before any compilers existed for it. History is keeping C alive. Yes. Generally speaking, this newsgroup is about programming in C++; there is a separate group, comp.std.c++ for discussions of the standard. And while the separation isn't absolute, you can't program in C++0x today, so most discussion of it probably would be more appropriate in csc++. That is, of course, completely impossible, since the standard still hasn't been approved, and in fact, we still don't know exactly what will be in it. Generally, it takes a few years after the finalization of a standard for implementations to catch up; for that matter, most compilers today don't implement all of C++03. That it's real. It exists. It's not just an abstract specification. Yes. (I suppose that technically, it's several implementations, since you can control some of the aspects, like the signedness of a plain char, from the command line.) If all you're targetting is Windows, then all you need to know is Visual C++. [/QUOTE]

Verification