Hi all,
thanks for your thoughts so far.
I expect we can maintain a C interface for e.g. FFI (Foreign Function
Interface?).
The VOLK library itself is written in C. However, we provide all the
necessary tools to use VOLK in C++. Unlike other libraries that is not
as straightforward as one m
Hey Nick,
> Yes, that's kind of my fault.
"Dault" is kind of a hard word when it's your achievement that a C API VOLK got as far as
it took us!
> C++20 finally makes C++ a much less Lovecraftian nightmare
We're going to have template metaprogramming! SFinaE fhtagn!
Seriously, though. Operat
On Tue, Dec 21, 2021 at 3:29 AM Marcus Müller wrote:
> Hi Johannes,
>
> I, for one, like it :) Especially since I honestly find void
> volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit
> clunky and would
> rather call a type-safe, overloaded function in a volk namespace called
True, but with Pybind11, we at least get direct python->C++ bindings which *can* allow for
in-place modification of appropriately typed numpy arrays. For other languages, the C
layer should be pretty much a zero-overhead redirection (or so I hope), just like it's
theoretically useful right now.
If nothing else I think there is a lot of value in adding c++ wrappers to
volk. I don't have a strong opinion on an underlying base of c or c++, but
would like for it to be easier to use in c++. A common approach with other
c libraries like zeromq is to make a header only c++ wrapper. This would
ta
I like the idea. It will make it difficult to use volk with other
language's FFI though.
--Albin
On Tue, Dec 21, 2021, 12:27 Marcus Müller wrote:
> Hi Johannes,
>
> I, for one, like it :) Especially since I honestly find void
> volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny b
Hi Johannes,
I, for one, like it :) Especially since I honestly find void
volk_32fc_x2_s32fc_multiply_conjugate_add_32fc to be a teeny tiny bit clunky and would
rather call a type-safe, overloaded function in a volk namespace called
multiply_conjugate_add.
Re: RFC: can we have something like
Hi everyone,
today I'd like to propose an idea for the future of VOLK. Currently,
VOLK is a C library with a C++ interface and tooling that is written in C++.
I propose to make VOLK a C++ library. Similar to e.g. UHD, we can add a
C interface if the need arises.
This email serves as a reque
