Re: retrieve size of array
Andrei Polushin wrote:
kanze wrote:
Andrei Polushin wrote:
When the "independence" is the issue, then we might look
deeper and further, and notice that many public interfaces
avoid dependence on std::vector, but prefer C-style arrays,
because of their predictable binary representation.
Most such public interfaces avoid dependence on C++ completely,
and use a public interface defined in C. In practice, if
std::vector changes its layout, there's a pretty good chance
that vtable layout will change as well, as will name mangling,
and who knows what all else. Either the compiler guarantees
binary compatibility (which includes the layout of all of the
standard classes), or it doesn't.
The reality is not black and white ("either guarantees or not"),
It depends. Whether something is "garanteed or not" is a yes or
no question. But I take note of your point that an
implementation may guarantee certain aspects of the language
API, and not others. And that some guarantees are more or less
indirect---you can count on the vtable layout not changing
because COM is guaranteed, even if MS doesn't mention C++
directly in the guarantee.
but we can talk about the measure of stability in each case.
On my system (Windows) the vtable layout remains stable for
the past 15 years (due to COM requirements), so it is more
stable than the binary representation of STL classes, which
stability is not controlled by some binary standard or
community conventions.
I think you have a point there. Do C++ API's also specify the
layout of objects in the standard library? If not, they're
pretty useless. (And it's a tricky question, since at least
with one of the compilers I use, the layout depends on whether I
specify debug options or not. And I've had core dumps because I
accidentally linked with a version of a library compiled without
debug options, whereas my own code used them.)
And so on: when we want an interface to be more or less
stable, we should depend on more or less stable things.
Currently, C++ doesn't mandate the binary representation of
many so standard types, class layouts, struct alignments, so
it is less (not more) usable in public APIs than C.
I don't think that C++ itself can mandate much here (although I
think the next version of the standard will mandate that the
representation of a complex be compatible with that of an array
of two objects).
That's a pity, because C++ is neither an interpreted language,
nor a virtual-machine language (like Java) and binary
compatibility is a very important thing here.
Quite agreed. The problem is that, of course, you need a
different standard for each platform; by its very nature, binary
compatibility between a Sun Sparc and an Intel isn't possible.
And that pretty much leaves it up to the platform to establish
the standard. At present, the only platform I know of which has
formally done so is the Itanium (although one might consider
whatever VC++ does to be a de facto standard for Windows).
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]