[Rcpp-devel] Template instantiation of commonly-used types

[Kevin Ushey]

If we were to have these vectors as part of the shared object rather
than header-only, wouldn't this imply breakage for existing packages
if newer versions of Rcpp changed the Vector template class
implementation (perhaps it inherits new policies, or gains new
methods, or methods change, or becomes templated in a different way)?
This is unlikely but it could happen down the line.

Also, doesn't it imply fewer opportunities for the compiler to inline
code when possible? Part of the reason Rcpp is header only is that it
gives the compiler opportunities to inline all parts when sensible; by
having the Vector class external the compiler can lose the ability to
inline these calls.

Overall I feel fairly uncomfortable moving away from header-only-ness
in Rcpp (although we could be persuaded otherwise) -- reducing compile
time / binary size doesn't seem a convincing enough reason to steer
away from being header only as possible.

On Wed, Oct 15, 2014 at 11:01 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
>
> On 15 October 2014 at 10:28, Kevin Thornton wrote:
> | I should clarify: those git gist are the "git clone" links.  Here are the direct links for viewing:
> |
> | The .h: https://gist.github.com/molpopgen/5180d60689fa8d6cb353
> |
> | The .cpp: https://gist.github.com/molpopgen/c13135659e0b27421a3a
>
> Could you give it a spin and actually try how R CMD check behaves if you do
> that?  And/or check how any of the Rcpp dependents behaves?  Maybe give
> numbers for the gain in compilation you try to achieve?
>
> If it does work we can surely condition via configure on the appropriate
> compiler and version.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
> _______________________________________________
> Rcpp-devel mailing list
> Rcpp-devel at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel