llvm dev - Jul 2015 - [LLVMdev] [llvm-c] enum conversion approaches

Hi all,

I was looking at the C API (adding some missing Build* methods) and was
wondering about how to move between C++ and C enums. There seem to be multiple
ways of doing this:
* dedicated method: eg LLVMAtomicOrdering->AtomicOrdering in
mapFromLLVMOrdering
* local switch statement: eg. LLVMAtomicRMWBinOp->AtomicRMWInst in
  LLVMBuildAtomicRMW
* static cast: eg. LLVMVisibility->GlobalValue::VisibilityTypes in
  LLVMSetVisibility

Are there specific reasons for these different approaches? At first sight, it
seems like the C enums can be one-on-one mapped to their C++ counterpart, so a
static_cast should suffice. Sanity checking the input enum doesn't seem like
a
reason either, because only some of the manual conversion fragments end with
a fatal error.

What is the preferred way of doing this? Does it make sense to convert the other
approaches?

Best,
Tim

The reason is that we want to keep the C API stable. Sorting the C++ enums
alphabetically or logically shouldn't impact the C API.

On Fri, Jul 17, 2015 at 1:33 AM, Tim Besard <tim.besard at elis.ugent.be>
wrote:
> Hi all,
>
> I was looking at the C API (adding some missing Build* methods) and was
> wondering about how to move between C++ and C enums. There seem to be
> multiple
> ways of doing this:
> * dedicated method: eg LLVMAtomicOrdering->AtomicOrdering in
> mapFromLLVMOrdering
> * local switch statement: eg. LLVMAtomicRMWBinOp->AtomicRMWInst in
>   LLVMBuildAtomicRMW
> * static cast: eg. LLVMVisibility->GlobalValue::VisibilityTypes in
>   LLVMSetVisibility
>
> Are there specific reasons for these different approaches? At first sight,
> it
> seems like the C enums can be one-on-one mapped to their C++ counterpart,
> so a
> static_cast should suffice. Sanity checking the input enum doesn't seem
> like a
> reason either, because only some of the manual conversion fragments end
> with
> a fatal error.
>
> What is the preferred way of doing this? Does it make sense to convert the
> other
> approaches?
>
> Best,
> Tim
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/b5c8d032/attachment.html>