Stefan Teleman wrote:
>
>
> Garrett D'Amore wrote:
>> Thank you for your instructional description of the C++ language with
>> respect to templates.
>>
>> There are a few significant points, that I think you keep missing, or
>> are glossing over:
>>
>> When I said C++ doesn't separate *binary* interface from
>> implementation, I was *not* talking about the nice separation done
>> for the benefit of the programmer. I was talking about separation
>> done across the boundary created by the linker ... AFAIK, C++ does
>> not recognize that there is such an interface boundary.
>>
>> In C++, if an inline function is expanded by the compiler, but makes
>> use of *private* members of the class, then the *binary
>> implementation* of the resulting code is *tied* to the
>> implementation, and if the implementation changes (e.g. by changing
>> the dynamically linked library) then there can be unfortunate
>> consequences.
>>
>> I'm not a template expert, so I'll demonstrate with a simple inline
>> function using C++ circa 1990.
>>
>> class box {
>> int width;
>> int height;
>> /* put more private details here... */
>>
>> public:
>> void draw(); // private implementation elsewhere
>>
>> public inline int getwidth() { return width; }
>> };
>
> This is a hypothetical example of a very poorly designed C++ class. I
> would expect to see this type of design from a High School Student,
> and not from a professional. Certainly not from an industry leader.
>
> The quality of this implementation aside, this code excerpt is not
> from the Apache Standard C++ Library.
>
> Could you kindly provide an example of ABI breakage -- any kind of
> breakage -- from the source code of the Apache Standard C++ Library,
> currently under discussion ?
>
> Incidentally, the problem you are illustrating in your example has
> been solved about 14 years ago (if not earlier):
>
> http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=sr_1_1?ie=UTF8&s=books&qid=1220661045&sr=1-1
>
>
>
> Published November 10, 1994.
>
> As to which of the Design Patterns addresses this very exact problem
> is left as an exercise for the reader.
Okay, I'm not interested in debating this further ... or even
researching it. I frankly don't have the energy to read the source code
for a significant library written in a language I don't work in on a day
to day basis.
However, if you will assert that there are no binary compatibility
problems of this nature (nor any others of a similar nature arising from
templates) -- i.e. that the header files do not create a problem, then I
don't have a problem.
The litmus test for this problem would be to take an application
compiled against one version the library, and replace the library
underneath it with a different implementation. If the applications
still work, then I'm satisfied. If the applications do not work, then
we have to make some kind of continuity statements or guarantees about
how we manage fixes and upgrades to the library. If Apache's
implementation guarantees that this breakage doesn't occur on minor or
patch upgrades, then that might be acceptable, although we have to
figure out continuity to ensure that the library (or a drop in
compatible replacement) will remain available for quite some time.
(Standard commitment effectively means ~forever, btw.)
That still doesn't address the other major set of concerns I had, about
mixing and matching different implementations of the standard
libraries. I think I'm unhappy with anything above Volatile commitment
without a game plan that ultimately addresses the problem and gets us to
a single "recommended" base library implementation.
-- Garrett
>
> --Stefan
>
