Policies/Binary Compatibility Examples - Revision history

Neverendingo: Text replace - "" to ""

2011-06-29T20:57:27Z

Text replace - "</code>" to "</syntaxhighlight>"

Neverendingo: Text replace - "`" to ""`


2011-06-29T20:31:28Z
Text replace - "<code cppqt>" to "<syntaxhighlight lang="cpp-qt">"
Show changes



Thiago: /* Override a virtual that doesn't come from a primary base */
2009-08-26T14:50:01Z
‎Override a virtual that doesn't come from a primary base

				
				
				
				
			
			← Older revision
			Revision as of 14:50, 26 August 2009
			
Line 591:
Line 591:
    
  '''Reason''': this is a tricky case. When dealing with multiple-inheritance of classes with virtual tables, the compiler must create multiple virtual tables to guarantee polymorphism works (that is, when your MyClass object is stored in a PrimaryBase or SecondaryBase pointer). The virtual table for the primary base is shared with the class's own virtual table, because they have the same layout at the beginning. However, if you override a virtual coming from a non-primary base, it is the same as adding a new virtual, since that primary base did not have the virtual by that name.   '''Reason''': this is a tricky case. When dealing with multiple-inheritance of classes with virtual tables, the compiler must create multiple virtual tables to guarantee polymorphism works (that is, when your MyClass object is stored in a PrimaryBase or SecondaryBase pointer). The virtual table for the primary base is shared with the class's own virtual table, because they have the same layout at the beginning. However, if you override a virtual coming from a non-primary base, it is the same as adding a new virtual, since that primary base did not have the virtual by that name.
  + 
  + '''Note''': this applies to any case of multiple-inheritance, even if it's not a direct base. In the example above, if we had MyOtherClass deriving from MyClass, the same restriction would apply.
    
  == Override a virtual with a covariant return with different top address ==   == Override a virtual with a covariant return with different top address ==



Tampakrap: ~PrimaryBase() -> ~SecondaryBase();
2009-08-13T00:37:00Z
~PrimaryBase() -> ~SecondaryBase();

				
				
				
				
			
			← Older revision
			Revision as of 00:37, 13 August 2009
			
Line 562:
Line 562:
  {   {
  public:   public:
−      virtual ~PrimaryBase(); +      virtual ~SecondaryBase();
       virtual void bar();        virtual void bar();
  };   };



Thiago: Add the example of changing return types with enums
2009-08-04T08:31:26Z
Add the example of changing return types with enums

				
				
				
				
			
			← Older revision
			Revision as of 08:31, 4 August 2009
			
Line 298:
Line 298:
  // MSVC mangling: ?at@QByteArray@@QBADH@Z   // MSVC mangling: ?at@QByteArray@@QBADH@Z
  char QByteArray::at(int) const;   char QByteArray::at(int) const;
  + </code>
  + |-
  + | <code cppqt>
  + // GCC mangling: _ZN6QEvent17registerEventTypeEi
  + // MSVC mangling: ?registerEventType@QEvent@@QAAXH@Z
  + int QEvent::registerEventType(int)
  + </code>
  + | <code cppqt>
  + // GCC mangling: _ZN6QEvent17registerEventTypeEi (unchanged)
  + // MSVC mangling: ?registerEventType@QEvent@@QAAXW4Type@V0@@@Z
  + QEvent::Type QEvent::registerEventType(int)
  </code>   </code>
  |}   |}
Line 306:
Line 317:
    
  In the third example, the return type changed from a simple integer (a POD) to a QString -- in this case, the compiler usually needs to pass a hidden implicit first parameter, which won't be there. In this case, existing code calling the function will more than likely crash, due to trying to dereference the implicit QString* parameter that isn't there.   In the third example, the return type changed from a simple integer (a POD) to a QString -- in this case, the compiler usually needs to pass a hidden implicit first parameter, which won't be there. In this case, existing code calling the function will more than likely crash, due to trying to dereference the implicit QString* parameter that isn't there.
  + 
  + In the fourth example, the return type changed from one POD type (an int) to another (an enum), which is also carried by an int. The calling sequence is most likely the same in all compilers, however the mangling of the symbol name changed, meaning that calls will fail due to an unresolved symbol.
    
  == Change the access rights ==   == Change the access rights ==



Thiago: /* Change the CV-qualifiers of global data */
2009-07-16T08:32:05Z
‎Change the CV-qualifiers of global data

				
				
				
				
			
			← Older revision
			Revision as of 08:32, 16 July 2009
			
Line 454:
Line 454:
    
  '''Reason''': some compilers encode the CV-qualifiers of the global data in its mangled name. Especially note that a static const value declared in the class itself can be considered for "inlining" -- that is, the compiler doesn't need to generate an external symbol for the value since all implementations are guaranteed to know it.   '''Reason''': some compilers encode the CV-qualifiers of the global data in its mangled name. Especially note that a static const value declared in the class itself can be considered for "inlining" -- that is, the compiler doesn't need to generate an external symbol for the value since all implementations are guaranteed to know it.
  + 
  + Even for compilers that don't encode the CV-qualifiers of global data, adding const may make the compiler place the variable in a read-only section of memory. Code that tried to write it will probably crash.
    
  == Add a virtual member function to a class without any ==   == Add a virtual member function to a class without any ==



Thiago: /* Change the return type */
2009-07-16T08:27:17Z
‎Change the return type

				
				
				
				
			
			← Older revision
			Revision as of 08:27, 16 July 2009
			
Line 301:
Line 301:
  |}   |}
    
− '''Reason''': changing the return type changes the mangled name of the function names in some compilers (GCC notably does not encode the return type). However, even if the mangling doesn't change, the convention on how the return types are handled may change. In the first example above, the return type changed from a 64- to a 32-bit integer, which means on some architectures, the upper half of the return register may contain garbage. In the second example, the return type changed from QByteArray to QString, which are two incompatible types, whereas in the third example, the return type changed from a simple integer (a POD) to a QString -- in this case, the compiler usually needs to pass a hidden implicit first parameter, which won't be there. + '''Reason''': changing the return type changes the mangled name of the function names in some compilers (GCC notably does not encode the return type). However, even if the mangling doesn't change, the convention on how the return types are handled may change.  
  +  
  + In the first example above, the return type changed from a 64- to a 32-bit integer, which means on some architectures, the upper half of the return register may contain garbage. In the second example, the return type changed from QByteArray to QString, which are two incompatible types.
  +  
  + In the third example, the return type changed from a simple integer (a POD) to a QString -- in this case, the compiler usually needs to pass a hidden implicit first parameter, which won't be there. In this case, existing code calling the function will more than likely crash, due to trying to dereference the implicit QString* parameter that isn't there.
    
  == Change the access rights ==   == Change the access rights ==



Thiago: /* Change the type of global data */
2009-07-16T08:25:51Z
‎Change the type of global data

				
				
				
				
			
			← Older revision
			Revision as of 08:25, 16 July 2009
			
Line 397:
Line 397:
    
  '''Reason''': some compilers encode the type of the global data in its mangled name. Especially note that some compilers mangle even for simple data types that would be allowed in C, meaning the <tt>extern "C"</tt> qualifier makes a difference too.   '''Reason''': some compilers encode the type of the global data in its mangled name. Especially note that some compilers mangle even for simple data types that would be allowed in C, meaning the <tt>extern "C"</tt> qualifier makes a difference too.
  + 
  + Even if the mangling doesn't change, changing the type often changes the size of the data as well. That means code that was accessing the global data may be access too many or too few bytes.
    
  == Change the CV-qualifiers of global data ==   == Change the CV-qualifiers of global data ==





Thiago: Add the explanation to the function-parameter-changing section
2009-07-15T10:22:05Z
Add the explanation to the function-parameter-changing section

				
				
				
				
			
			← Older revision
			Revision as of 10:22, 15 July 2009
			
Line 234:
Line 234:
  </code>   </code>
  |}   |}
  + 
  + '''Reason''': changing the parameters of a function (adding new or changing existing) changes the mangled name of that function. The reason for that is that the C++ language allows overloading of functions with the same name but slightly different parameters.
  + 
  + I don't have the mangled name for the Sun CC example above, that compiler does enforce the constness of POD types in both declaration and implementation.
    
  == Change the return type ==   == Change the return type ==



Thiago: Add the mangled names and explanations on what goes wrong if you do what this document tells you not to do
2009-07-15T10:02:34Z
Add the mangled names and explanations on what goes wrong if you do what this document tells you not to do
Show changes

← Older revision		Revision as of 14:50, 26 August 2009
Line 591:		Line 591:

	'''Reason''': this is a tricky case. When dealing with multiple-inheritance of classes with virtual tables, the compiler must create multiple virtual tables to guarantee polymorphism works (that is, when your MyClass object is stored in a PrimaryBase or SecondaryBase pointer). The virtual table for the primary base is shared with the class's own virtual table, because they have the same layout at the beginning. However, if you override a virtual coming from a non-primary base, it is the same as adding a new virtual, since that primary base did not have the virtual by that name.		'''Reason''': this is a tricky case. When dealing with multiple-inheritance of classes with virtual tables, the compiler must create multiple virtual tables to guarantee polymorphism works (that is, when your MyClass object is stored in a PrimaryBase or SecondaryBase pointer). The virtual table for the primary base is shared with the class's own virtual table, because they have the same layout at the beginning. However, if you override a virtual coming from a non-primary base, it is the same as adding a new virtual, since that primary base did not have the virtual by that name.
		+
		+	'''Note''': this applies to any case of multiple-inheritance, even if it's not a direct base. In the example above, if we had MyOtherClass deriving from MyClass, the same restriction would apply.

	== Override a virtual with a covariant return with different top address ==		== Override a virtual with a covariant return with different top address ==

← Older revision		Revision as of 08:32, 16 July 2009
Line 454:		Line 454:

	'''Reason''': some compilers encode the CV-qualifiers of the global data in its mangled name. Especially note that a static const value declared in the class itself can be considered for "inlining" -- that is, the compiler doesn't need to generate an external symbol for the value since all implementations are guaranteed to know it.		'''Reason''': some compilers encode the CV-qualifiers of the global data in its mangled name. Especially note that a static const value declared in the class itself can be considered for "inlining" -- that is, the compiler doesn't need to generate an external symbol for the value since all implementations are guaranteed to know it.
		+
		+	Even for compilers that don't encode the CV-qualifiers of global data, adding const may make the compiler place the variable in a read-only section of memory. Code that tried to write it will probably crash.

	== Add a virtual member function to a class without any ==		== Add a virtual member function to a class without any ==

← Older revision		Revision as of 08:25, 16 July 2009
Line 397:		Line 397:

	'''Reason''': some compilers encode the type of the global data in its mangled name. Especially note that some compilers mangle even for simple data types that would be allowed in C, meaning the <tt>extern "C"</tt> qualifier makes a difference too.		'''Reason''': some compilers encode the type of the global data in its mangled name. Especially note that some compilers mangle even for simple data types that would be allowed in C, meaning the <tt>extern "C"</tt> qualifier makes a difference too.
		+
		+	Even if the mangling doesn't change, changing the type often changes the size of the data as well. That means code that was accessing the global data may be access too many or too few bytes.

	== Change the CV-qualifiers of global data ==		== Change the CV-qualifiers of global data ==