Блог

Согласно официальной странице о ruby, расширить Ruby с помощью C проще, чем Perl. Я не сторонник (perl) XS, но я нахожу, что очень просто написать что-то быстрое и незамысловатое с помощью Inline:: C, так почему же это проще на Ruby?

Писать расширения C на Ruby проще, чем на Perl или Python, благодаря очень элегантному API для вызова Ruby из C. Сюда входят вызовы для встраивания Ruby в программное обеспечение, для использования в качестве языка сценариев. Также доступен SWIG-интерфейс.

Любые дальнейшие объяснения от тех, кто использует больше расширений C, были бы полезны.

(Полное раскрытие, я программист на Perl)

Ruby C API, безусловно, выглядит намного приятнее, чем на Perl. Это выглядит как обычная библиотека C с функциями, которые соответствуют коду Ruby. API Perl — это путаница макросов внутри макросов внутри макросов и флагов magic threading. Использование Perl API вне ядра Perl, безусловно, является второстепенной задачей. Ruby определенно выигрывает в том, что не вызывает ужаса, от которого сжимается кишечник.

Хотя Ruby имеет лучший C API, в Perl есть лучшие руководства о том, как с ним что-либо делать. В сгенерированной документации Ruby отсутствует какое-либо связное руководство или часто вообще какой-либо описательный текст. Возможно, я ищу не в том месте, но это все, что было предложено. В отличие от этого, документация Perl API написана от руки в прозе с полезной информацией о том, что делает каждая функция. Кроме того, в core docs есть более десятка документов об использовании Perl и C. Я бы сказал, что Perl выигрывает в docs.

FFI выглядит довольно впечатляюще. Самое близкое, что есть в Perl к FFI, — это Inline:: C, который представляет собой оболочку вокруг беспорядка XS. Его основное назначение — встроить код C в вашу программу на Perl, но вы также можете использовать его для доступа к функциям библиотеки C.

Вот тривиальный пример, похожий на пример getpid Нэша.

 use Inline
  C             => Config       =>
  ENABLE        => "AUTOWRAP";

use Inline C => q{ int getpid(); };

print getpid();
  

Итак, я обманываю, потому что технически getpid возвращает pid_t в моей системе, но это всего лишь целое число. Похоже, что в FFI очень много специального кода для getpid, поэтому я подозреваю, что простота использования напрямую зависит от того, позаботился ли FFI об этом. Тривиальные примеры тривиальны. Было бы интересно посмотреть, что происходит, когда возникают типичные сложности, такие как функции, которые возвращают предварительно выделенную память и имеют нечетные типы и перебрасывают структуры.

Хотя FFI и Inline::C можно использовать для выполнения одного и того же, то, как они это делают, выглядит очень, очень по-разному. Inline::C на самом деле компилирует и кэширует C-код. FFI почему-то не выполняет никакой компиляции. Я не уверен, действительно ли это так, или компиляция выполняется для вас во время установки для обычных библиотек.

Кроме того, FFI сглаживает проблемы переносимости в различных реализациях Ruby и их различных способах вызова собственных API. Это то, что Inline :: C не обязательно делать, и, честно говоря, удивительно, если это действительно работает. Одним из преимуществ является то, что интерфейс FFI намного более плавный, чем Inline ::C. С помощью Inline:: C совершенно ясно, что вы пишете оболочку вокруг компилятора C.

С помощью FFI очень легко расширить Ruby с помощью C. Это пример из github

 require 'rubygems'
require 'ffi'
module Foo
  extend FFI::Library
  ffi_lib FFI::Library::LIBC
  attach_function :getpid, [ ], :int
end
puts "My pid=#{Foo.getpid}"
  

Вам не нужен компилятор, установленный на
ваша система должна иметь возможность запускать FFI
расширения. В Linux вы также не
необходимо установить программу разработки
версии библиотек, только
версии для среды выполнения. Конечно,
библиотеки, на которые вы ссылаетесь, понадобятся
чтобы в какой-то момент он был скомпилирован,
но, скорее всего, вам не пришлось бы делать
это.

https://github.com/ffi/ffi/wiki/why-use-ffi