Closed lundmark closed 6 years ago
I like this, I just have one issue. Generating a header like that removes c-support :( one could generate it as uint8 etc as members for c, but that would make it an offer mess :(
But maybe it's ok that it is c++ only if size is specified?
This is a part of the c-standard as of c11; 6.7.2.2 Enumeration specifiers (p: 117-118).
\o/
poke ;)
I'm wondering if how to expose the underlying type of an enum in the typelib as right now the syntax do not have any "place" to put the type =/ As it is now the only way I see this being done is changing tld-format for enums from enums : { "my_enum" : { "v1" : 2, "v2" : 3 } }
to enums : { "my_enum" : { "type" : "uint32", // default to uint32 "values" : { "v1" : 2, "v2" : 3 } } }
However that might be a requirement for issue #61 also.
Any objections?
I think this is the way to go. This unifies the interface of the typelibrary declaration anyway, which per se I think is a good thing. The features that this opens up to is also a very good thing in my eyes. So twice the win, I say yes!
Also... I guess we should open up for signed enum-values as well. Today they are only unsigned.
Yes :)
On Wed, May 16, 2018 at 10:51 AM, Fredrik Kihlander < notifications@github.com> wrote:
Also... I guess we should open up for signed enum-values as well. Today they are only unsigned.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wc-duck/datalibrary/issues/59#issuecomment-389445004, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXOMmYBR3arfLpuALKvf7I6MobcmR_Gks5ty-iagaJpZM4Q3hrO .
I'm having a bit of a problem with the enum-typespecifiers... I have to enable c++11 for it to work in c++ but maybe that is ok? If you do not specify the type it will not emit a ": int8_t" etc and compile on older standards?
i.e. if your compiler is not up for the task you can't use the feature.
One COULD also do a fallback for compilers that do not support enum-storage with
typedef int8_t my_enum;
const my_enum v1 = 1..
But that feels quite "crufty" + more stuff that needs testing... I guess I'll add it if there is any need for it.
Which compiler are you using? You should only have to enable c11.
I think that we can start with having it only implemented the way the standard uses it. If people will start needing it in other situations we can probably look into that then?
Clang warns that it is not valid c++03... But I'll try to just disable that warning in the enum-scope and add some stati_asserts
This is almost done in the branch 'enumwork', the only thing left is how to handle the unitests for older versions of msvc... I don't know if I should just ifdef them or if I should do some backwards compatibility for c and older compilers?
In backwards compat I thought I would generate something like
typedef uint8_t my_enum; static const my_enum my_enum_value1 = 123; static const my_enum my_enum_value2 = 124;
that should work right?
Hey,
Yeah I think that should be fine, right? it's basically the same afaik.
Cheers, Simon
On Tue, Jun 26, 2018 at 8:53 PM, Fredrik Kihlander <notifications@github.com
wrote:
This is almost done in the branch 'enumwork', the only thing left is how to handle the unitests for older versions of msvc... I don't know if I should just ifdef them or if I should do some backwards compatibility for c and older compilers?
In backwards compat I thought I would generate something like
typedef uint8_t my_enum; static const my_enum my_enum_value1 = 123; static const my_enum my_enum_value2 = 124;
that should work right?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/wc-duck/datalibrary/issues/59#issuecomment-400424179, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXOMv14ELu8d4yz4JXZAvFdJAUGvw1Wks5uAoMQgaJpZM4Q3hrO .
Finally merged to master!
such as this:
enum MyTestEnum : uint8_t { MY_TEST_ENUM_VAL = 1, };