Создание пакета R с Rcpp, который содержит исходный код C и заголовок с ограничительным ограничителем?
У меня есть сторонний исходный файл и соответствующий заголовок (содержащий объявления и директивы include для GSL и т. Д.), Написанные на C. Я пытаюсь собрать пакет R вокруг этих исходных файлов, в основном создавая оболочки для функций, использующих Rcpp. Проблема заключается в том, что эти файлы содержат ограничительный ограничитель, который не является частью стандарта C ++, поэтому R CMD INSTALL не может скомпилировать пакет. Он использует компилятор C для файла .c, но хочу скомпилировать файл .h с компилятором C ++, и это не удается. это терпит неудачу, когда это находит ограничение в заголовочном файле (который включен в файл .cpp).
Я не настолько знаком с C и компилятором, Rcpp и т. Д., Поэтому я не уверен, что будет лучшим подходом здесь?
Проще всего было бы удалить ключевое слово restrict. Это то, что я сейчас сделал (я удивлен, что R CMD INSTALL работает, когда я удаляю restrict из заголовочного файла, но оставляю их в .c файле). Но я скорее не изменяю файлы .c и .h, так как они также используются в не-R среде другими (исполняемыми и в Python), и было бы неплохо иметь одинаковые файлы для всех проектов.
Я также попытался определить пустое ключевое слово restrict, чтобы оно просто «удаляло» ограничение из определений функций, если компиляция была выполнена в компиляторе C ++, но я не смог получить эту работу. Я где-то читал о подобном подходе, но, видимо, так не работает.
Сработало бы, если бы я мог как-то сказать компилятору (через Makevars или что-то в этом роде?), Что конкретный файл .h должен быть скомпилирован с помощью компилятора C? Или будут проблемы с функцией C ++, вызывающей эти функции?
Или же ключевое слово будет иметь значение для производительности, если эти функции вызываются из R через оболочку C ++?
Одна вещь состоит в том, чтобы просто отказаться от Rcpp и использовать .C вместо .Call из R, но, поскольку производительность является ключевым моментом, это не является хорошим вариантом, так как я понимаю, что .Call быстрее (и более надежен). ).
Обратите внимание, что в конечном итоге этот пакет может найти путь к CRAN, поэтому решение должно быть достаточно переносимым. Кажется, есть некоторые специфические для C ++ ключевые слова для ограничения, но я думаю, что это не вариант из-за переносимости.
Решение
Похоже, вы делаете файл .cpp, который делает #include <x.h> где x.h — заголовок C, который использует restrict, Если это правда, я думаю, что вы можете изменить ваш .cpp файл, чтобы сделать это:
#define restrict // nothing
extern "C"{
#include <x.h>
}
Тогда компиляция вашего кода C ++ не увидит restrict ключевое слово, а также я завернул заголовок в extern "C" потому что, если сам заголовок не делает этого внутренне, вам нужно, чтобы ваш компилятор C ++ не применял «манипулирование именами» C ++ к функциям, объявленным внутри.
Другие решения