[Rcpp-commits] r4031 - in pkg/Rcpp/inst/doc: . Rcpp-attributes
noreply at r-forge.r-project.org
noreply at r-forge.r-project.org
Sat Nov 24 15:53:14 CET 2012
Author: jjallaire
Date: 2012-11-24 15:53:14 +0100 (Sat, 24 Nov 2012)
New Revision: 4031
Modified:
pkg/Rcpp/inst/doc/Rcpp-attributes/Rcpp-attributes.Rnw
pkg/Rcpp/inst/doc/Rcpp.bib
Log:
expand discussion of binary compatibility in attributes vignette
Modified: pkg/Rcpp/inst/doc/Rcpp-attributes/Rcpp-attributes.Rnw
===================================================================
--- pkg/Rcpp/inst/doc/Rcpp-attributes/Rcpp-attributes.Rnw 2012-11-24 08:01:15 UTC (rev 4030)
+++ pkg/Rcpp/inst/doc/Rcpp-attributes/Rcpp-attributes.Rnw 2012-11-24 14:53:14 UTC (rev 4031)
@@ -824,13 +824,28 @@
\subsubsection{Binary Compatibility}
-An additional consideration related to exposing \proglang{C++} functions from a package
-is binary compatibility. If a user of your package compiles against
-one version of your package and then runs against another version the binary
+An additional consideration related to exposing \proglang{C++} types from a
+package is binary compatibility. If a user of your package compiles against
+one version of the package and then runs against another version the binary
layout of \proglang{C++} types used must remain stable in order for things to work
-correctly. The recommended way to minimize binary compatibility problems is to
-only use built-in \proglang{C++} types and \pkg{Rcpp} wrapper types in your interfaces.
+correctly. Note that this is an issue that affects all \proglang{C++} interfaces
+exposed by shared libraries and is not specific to \proglang{R} packages or
+\pkg{Rcpp}. A summary of the issues presented can be found in
+`\textsl{Binary Compatibility Issues with C++}' \citep{KDE-TechBase:2012}.
+Note that if your package is used within a \proglang{C++} source file compiled with
+\texttt{sourceCpp} then binary compatability is not a concern (because the
+compilation is always synchronized with the currently installed version of your
+package). Also, packages published on \texttt{CRAN} are automatically rebuilt when a
+package they depend on via \texttt{LinkingTo} is updated, so users with updated
+versions of all packages will similarly not have binary compatibility problems.
+
+However, even when installing from \texttt{CRAN} it's possible for users to
+have the latest version of one package but not of another. If you want to
+minimize binary compatibility problems even in the face of out-of-sync package
+versions then it's strongly recommended that you use only use built-in
+\proglang{C++} types and \pkg{Rcpp} wrapper types in your interfaces.
+
\bibliographystyle{plainnat}
\bibliography{Rcpp}
Modified: pkg/Rcpp/inst/doc/Rcpp.bib
===================================================================
--- pkg/Rcpp/inst/doc/Rcpp.bib 2012-11-24 08:01:15 UTC (rev 4030)
+++ pkg/Rcpp/inst/doc/Rcpp.bib 2012-11-24 14:53:14 UTC (rev 4031)
@@ -506,3 +506,11 @@
publisher = {Springer-Verlag},
address = {London},
}
+
+ at misc{KDE-TechBase:2012,
+ author = {KDE-TechBase},
+ title = {Binary Compatibility Issues With {C++}},
+ howpublished = "\url{http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++}",
+ year = {2012},
+ note = "[Online; accessed 24-November-2012]"
+}
More information about the Rcpp-commits
mailing list