stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: [RFC] stdcxx release process, second draft
Date Wed, 28 Nov 2007 19:55:57 GMT
 

>Travis Vitek wrote
>
>Martin Sebor wrote:
>> 
>> I've incorporated everyone's feedback and committed an updated
>> version with a number of enhancements of my own. Among the most
>> important are the new Goals section with suggested frequencies of
>> releases, and the integration of the Version Policy (I plan to delete
>> versions.html). Let me know what you think.
>> 
>>     http://incubator.apache.org/stdcxx/releases.html
>> 
>
>Martin,
>
>I found this page that documents a few do's and dont's of binary
>compatibility. I realize that most of the tricky issues involve inline
>functions or templates, but this gives a list of the common pitfalls.
>
>  http://tinyurl.com/2gf38p
>
>Travis

Here are some examples that I came up with. Each case is written in a
pseudo diff format.

Travis

 // neither source nor binary compatible. not source compatible
 // if user might take address of member function A::f.
 struct A
 {
-    int f() const { return 1; }
+    int f(int i = 1) const { return i; }
 };

 // alternative is source and binary compatible. can be changed
 // to a default argument in next source incompatible release.
 struct A
 {
    int f() const { return 1; }
+   int f(int i) const { return i; }
 };

 // is binary compatible, but not be source compatible because
 // the compiler has no way to handle A().f(1)
 struct A
 {
    int f(long i) const { return 2; }
+   int f(unsigned i) const { return 2; }
 };

 // not binary compatible, changing access specifier on windows is a
no-no. if the
 // new access modifier is more restricted, this may be source
incompatible, but
 // only if the user code calls or takes the address of the function.
 class A
 {
-private:
+public:
     int f() const { return 1; }
 };

 // source and binary compatible, not functionally compatible. f() will
square v
 // in user code, and ctor will square v in library code. if an instance
is
 // created in library and passed to user code, it will be squared
twice. if the
 // other way, it will not be squared at all.
 //
 // if the definitions were outlined, this would be compatible.
 class A
 {
 public:
-    A(float f) : v(f) { }
-    float f() const { return v*v; }
+    A(float f) : v(f*f) { }
+    float f() const { return v; }
 private:
     float v;
 };


 // binary and source compatible, but not functionally compatible
 // because call to g() is inlined.
 //
 // this would be compatible if f() were outlined, or g() behaved
 // the same for input values 2 and 3.
 struct A
 {
-    void f() { g(2); }
+    void f() { g(3); }
     void g(int i);
 };


 // it appears that this could be fully compatible in some cases.
 // it might not be source/functionally compatible if the user is
 // exposed to this type. a switch on an E instance might cause a
 // default block to be hit, which could trigger a failure in user
 // code.
 //
 // if A::Z is used as a `last enum' marker, this might introduce
 // a binary compatibility issue if a global or member array is
 // declared to have A::Z elements.
 //
 // this might also be binary incompatible if the enum is persisted.
 struct A
 {
-    enum E { W, X, Z };
+    enum E { W, X, Y, Z };
 };

Mime
View raw message