Re: c++0x pods and constructors
On Nov 7, 6:18 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Oct 31, 4:12 am, "dragan" <spambus...@prodigy.net> wrote:
James Kanze wrote:
On Oct 29, 11:40 pm, "dragan" <spambus...@prodigy.net> wrote:
[...]
What about cross-platform interoperability? Write a struct
here, read it there?
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?
[...]
"extern C" fiasco? News to me that it was a fiasco (you
must be an implementor/insider, I bet)! I thought it was
more like "thank god we can still use DLLs in C++".
Fiasco may be too strong a word, but formally, the standard
guarantees much less than it seems to. (I certainly doesn't
guarantee anything with regards to DLLs, for example.)
I does indirectly. "C-linkage" (is that the right
terminology?) is all that can be exported from DLLs ("sorry"
to be so Windows-ish).
That's not true. I've used DLL's without any C linkage on at
least three platforms: Solaris, Linux and Windows.
I guess you probably could get all that name-mangled stuff to
come out of a DLL on a single machine. You won't be selling
that app to other people though, that's for sure.
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.
All that it says (with regards to C) is ``Every
implementation shall provide for linkage to functions
written in the C programming language, "C", and linkage to C
+ + functions, "C++".'' Except that it doesn't specify how
these "functions written in the C programming language" are
to be compiled or linked; an implementation may require you
to compile them using a special C compiler, which generates
code incompatible with the system API, for example. And it
doesn't address the issue of what to do if there is no C
compiler for the system.
Are you being too hypothetical? I don't give it a second
thought: I KNOW that I'll always be able to call "extern C"
functions in a DLL (after LoadLibrary(), blah, blah.)
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.
At least some of the people involved with the
standardization proceedure are aware of this weakness,
although the committee doesn't seem to have wanted to
address it. I think the general intent is more along the
lines that IF there is at least one C implementation
available on the platform, then the compiler must support
linkage with one of them, and document which one, and what
is necessary to make it work.
I seem to have missed "the weakness". I'm sure there is one if
you say so. Anyway, I feel like "extern C" and "layout" are
separate. It's all good information though.
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.
The probable reason the committee didn't address the problem
is that it isn't one in practice.
YES! Thanks for letting me know I'm not "out of it" (a bit
insecure maybe, "out of it", no way!).
Practically all platforms that support C++ have a standard C
ABI,
I didn't know that. Well maybe I sorta did because I rely on
it ("extern C", "POD"). So there is a formality like the C++
ABI for Itanium for C?
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.
which is adhered to by all C compilers, and practically all
C++ compilers come with a C compiler, and require no special
steps to link C and C++. So the standard may not say
exactly what was wanted, but in practice, everything works
as was desired.
Interesting. Big kudos for C. But it is much easier in C to
make a std ABI than in C++. C++ should have specified one from
the beginning, but too late for that now. Live and learn.
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.
Until the day someone decides that C is dead enough that
they don't need a C compiler for their platform.
C/Std ABI: 1 point. C++/No Std ABI: -1 point. C++ is keeping C
alive!
History is keeping C alive.
[...]
Unless I explicitly state otherwise, I'm talking about the
current standard.
Well, and again, the thread is specifically about C++0x. Did
you miss that key aspect?
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++.
There are no implementations of the next standard (can't be,
since it doesn't exist yet), and the way things are going,
I'm beginning to wonder if there will be any in my lifetime.
Now THAT is an interesting tangent. I was thinking that C++0x
features (at least a few stocking-stuffers) would be in my
favorite compiler for Xmas!
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.
With regards to Visual C++, it's a concrete implementation;
concrete implementations always give you a lot more
guarantees than the standard gives.
What do you mean by "concrete implementation"?
That it's real. It exists. It's not just an abstract
specification.
Did you just mean one specific implementation?
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.)
As opposed to worrying about all compilers or the majority or
average of them across all platforms and domains? I just have
some Windows apps to write.
If all you're targetting is Windows, then all you need to know
is Visual C++.
--
James Kanze