Fix invalid C++ identifiers

[klmr]

Rcpp uses __ as a prefix for identifiers in auto-generated code (e.g. here and here). This is problematic, since __ is not not valid in C++ identifiers (it’s reserved for use by the compiler).

Such identifiers are for instance used by standard library implementations. And although most modern implementations try to avoid aggravating users, and so use more explicit conventions in their macro names, a simple grep through the libc++ implementation shows a few macros with names such as __need_size_t (and more in libstdc++), so it’s not unthinkable that there might be conflicts with future versions of some compilers.

It would be better to replace these instances with a legal identifier token, e.g. Rcpp_.

[eddelbuettel]

Thanks for the note, Konrad.

That is attributes.cpp only and hence well localised. I would encourage you (as the one with an itch to scratch) to work on a pull request if you want to see change "soon" as we all are a tad too busy to write code on demand for what I'd call non-bugs.

We effectively live in a g++/clang++ world only even though the occasional user may edploy the Intel compiler or work on some non-standard OS besides Windoof, OS X and Linux. And in that world this just doesn't seem to have bitten so shrugs ...

[jjallaire]

We used those prefixes specifically because they are reserved for the
compiler (and thus extremely unlikely to conflict with user variable
names). Point well taken though that we might end up conflicting with the
compiler as a result! You can in some ways view compileAttributes
pre-processing as effectively part of the (extended) compilation and thus
not at all an inappropriate place to use __ prefixes.

On Fri, Oct 30, 2015 at 12:09 PM, Dirk Eddelbuettel <
notifications@github.com> wrote:

Thanks for the note, Konrad.

That is attributes.cpp only and hence well localised. I would encourage
you (as the one with an itch to scratch) to work on a pull request if you
want to see change "soon" as we all aer atad to budy to write code on
demand for what I'd call non-bugs.

We effectively live in a g++/clang++ world only even though the occasional
user may edploy the Intel compiler or work on some non-standard OS besides
Windoof, OS X and Linux. And in that world this just doesn't seem to have
bitten so shrugs ...

—
Reply to this email directly or view it on GitHub
#387 (comment).

[klmr]

@jjallaire I agree that a prefix is entirely appropriate (and arguably even necessary) here.

I can try my hand at a PR.

[eddelbuettel]

I read the comment differently from you, @klmr :

You can [...] view compileAttributes pre-processing as [...] part of the [...] compilation and thus
not at all an inappropriate place to use __ prefixes.

Looks like we're not yet convinced we need it but heck, if you submit something we will look at it.

[klmr]

@eddelbuettel I got that part, but the “compilation” done by Rcpp isn’t part of the C++ standard compilation workflow so its use of __ isn’t covered by the respective section in the standard (the section explicitly covers only the “C++ implementations and standard libraries”). As far as the C++ standard is concerned, Rcpp is just any old user.

[jjallaire]

Understood, but with C++11 attributes are often used as code generators
that are called during the compilation phase and are thus seen as "compiler
add-ons". So I don't think it's a huge stretch for these compiler add-ons
to use symbols reserved for the compiler (but I agree you are correct in
saying it's not technically standards compliant).

On Fri, Oct 30, 2015 at 1:55 PM, Konrad Rudolph notifications@github.com
wrote:

@eddelbuettel https://github.com/eddelbuettel I got that part, but the
“compilation” done by Rcpp isn’t part of the C++ standard compilation
workflow so its use of __ isn’t covered by the respective section in the
standard. As far as the C++ standard is concerned, Rcpp is just any old
user.

—
Reply to this email directly or view it on GitHub
#387 (comment).

[kevinushey]

We could also hide the implementation in a separate namespace, e.g.

CharacterVector fun(RObject data);
namespace Rcpp {
namespace generated {
inline SEXP pkg_fun(SEXP dataSEXP) {
    // impl
}
}
}

RcppExport SEXP pkg_fun(SEXP dataSEXP) {
    return Rcpp::generated::pkg_fun(dataSEXP);
}

Or, just consider using e.g. an rcpp_ prefix (and maybe even a _gen_ postfix)

[klmr]

In this particular case I think none of these options are technically necessary since it’s an isolated compilation unit and scope (except that it needs to avoid clashing with function parameters, of course). In general, though, the idea of using a prefix is to avoid name clashes with global macros — even if that shouldn’t happen here it’s probably a good policy.

[coatless]

@eddelbuettel

While I'm in the Attributes.cpp file for #526, would it be okay to change the __ prefix to rcpp_ and attach a suffix _gen_ per @kevinushey 's suggestion?

(Tagging #506)

[dcdillon]

Yes. And change every include guard to single underscores while you're at it.

[dcdillon]

Or better yet #pragma once

[jjallaire]

I don't know #pragma once is going to work on every compiler we end up
getting built with. It's also not actually part of the standard (not sure
if CRAN will have a problem with that or not). There are also some
subtleties you need to be aware of related to how files are uniquely
identified (https://en.wikipedia.org/wiki/Pragma_once). I'd suggest erring
on the side of conservatism and leaving the include guards alone.

On Mon, Aug 1, 2016 at 8:15 PM, Daniel C. Dillon notifications@github.com
wrote:

Or better yet #pragma once

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#387 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAGXx40Id6Idgl4mwc6RZxb5dUpLOCNbks5qbowjgaJpZM4GZGlo
.

[coatless]

@jjallaire took the words from my mouth as I was transcribing them.

I'm planning on also modifying:

std::string CppPackageIncludeGenerator::getHeaderGuard() const {
     return "__" + packageCpp() + "_h__";
}

[dcdillon]

Heh. Well single underscores and an RCPP prefix would be best

[dcdillon]

At any rate a good rule of thumb I have found for include guards is PACKAGE_NAMESPACE_NAMESPACE_NAMESPACE_FILE_H