Register functions?

[okeyes-r7]

It could be good to register some of the functions as callable so that other libraries can use them. In particular I'm thinking of the random value/hash generation code.

[jeroen]

What's the use case? I think it's usually better to expose the interface via R.

[okeyes-r7]

Well, trying to access code via C/C++ ;p. (the specific case is hash generation which would be faster-running code if it could be done compile-side, because it would mean one could simply return the 'finished' object from the C++ rather than needing to allocate it bit by bit, return those bits, and then get hashes and then turn it into a df and return it to the user).

I agree exposing the interface via R is good, but, well, the interface is exposed via R. One can do both!

[jeroen]

allocate it bit by bit, return those bits, and then get hashes and then turn it into a df and return it to the user)

I think it's kind of ugly to expose the same interface via C++. I'm afraid going down this path will introduce a lot of additional maintenance work and potential conflicts with marginal benefit.

Note that you can easily call the R function from Rcpp with little performance overhead

Rcpp::Function md5 = Rcpp::Environment::namespace_env("openssl")["md5"];
md5(Rcpp::CharacterVector("test vec"));

If you really think you need C, I think you'r better of linking against actual libssl directly...

[okeyes-r7]

Aye, that'd be a better way of doing it - just not sure how to guarantee libssl's presence without replicating this package's setup and install code and the rest (unless, since libssl is guaranteed if one has this package, making this package a dependency would work? shrug)

[jeroen]

Yeah i'm afraid you'll either have to replicate the configure foo to find openssl (which is tricky) or work via the R interface :-)

[jeroen]

I still think it's better to either call the R api or directly link to libssl, rather than duplicating the libssl C API in this R package...