Learning that you can use unions in C for grouping things into namespaces • Hacker News Board

Re: Learning that you can use unions in C for grouping things into namespaces

#31

Post by midjji » Sun, Aug 01, 2021, 7:37 PM UTC

10000truths wrote: post #15

Anonymous nested structs are also quite useful for creating struct fields with explicit offsets: #include #include #define YDUMMY(suffix, size) char dummy##suffix[size] #define XDUMMY(suffix, size) YDUMMY(suffix, size) #define PAD(size) XDUMMY(__COUNTER__, size) struct ExplicitLayoutStruct { union { struct __attribute__((packed)) { PAD(3); uint32_t foo; }; struct __attribute__((packed)) { PAD(5); uint16_t bar; }; str…

There are two kinds of undefined behaviour being invoked in using this. Its a horrible idea and a horrible code smell, get rid of it if you ever see something like this.

Re: Learning that you can use unions in C for grouping things into namespaces

#32

Post by midjji » Sun, Aug 01, 2021, 7:38 PM UTC

gumby wrote: post #18

10000truths wrote: post #15

Anonymous nested structs are also quite useful for creating struct fields with explicit offsets: #include #include #define YDUMMY(suffix, size) char dummy##suffix[size] #define XDUMMY(suffix, size) YDUMMY(suffix, size) #define PAD(size) XDUMMY(__COUNTER__, size) struct ExplicitLayoutStruct { union { struct __attribute__((packed)) { PAD(3); uint32_t foo; }; struct __attribute__((packed)) { PAD(5); uint16_t bar; }; str…

One of the very few things from C that I miss in C++ is anonymous structs and enums. I really don’t understand why they are not allowed. That is, C style enums don’t have to have a name but “type safe” (enum class) ones do. One classic use is to name an otherwise boolean option in a function signature; there’s typically no need to otherwise name it. C++ incompatibly requires a name for all struct and class declaratio…

Use a enum in a namespace, or anonymous namespace

Re: Learning that you can use unions in C for grouping things into namespaces

#33

Post by midjji » Sun, Aug 01, 2021, 7:39 PM UTC

10000truths wrote: post #21

nyanpasu64 wrote: post #19

Earlier quoted context omitted.

Do foo and bar deliberately overlap?

Yes, I was looking to demonstrate the flexibility of the approach by including overlapping fields.

If you write to either, accessing the other, even on the overlap, is undefined behaviour

Re: Learning that you can use unions in C for grouping things into namespaces

#34

Post by WalterBright » Sun, Aug 01, 2021, 7:39 PM UTC

10000truths wrote: post #15

Anonymous nested structs are also quite useful for creating struct fields with explicit offsets: #include #include #define YDUMMY(suffix, size) char dummy##suffix[size] #define XDUMMY(suffix, size) YDUMMY(suffix, size) #define PAD(size) XDUMMY(__COUNTER__, size) struct ExplicitLayoutStruct { union { struct __attribute__((packed)) { PAD(3); uint32_t foo; }; struct __attribute__((packed)) { PAD(5); uint16_t bar; }; str…

Anytime macros are used for metaprogramming, it's time to reach for a more powerful language.

Re: Learning that you can use unions in C for grouping things into namespaces

#35

Post by midjji » Sun, Aug 01, 2021, 7:41 PM UTC

bruce343434 wrote: post #26

Imo this is not “perverse”. In my vector library I alias a vec3 as float x,y,z and float[3] using this technique.

This is also known as the most common invocation of undefined behaviour in game programming. If you do this, write to y, then read from [1]. You are invoking undefined behaviour, and compilers doing different things here between windows, linux mac, and different compiler versions is a common cause of "why isnt my game working right on XXX, it works fine on YYY questions.

Re: Learning that you can use unions in C for grouping things into namespaces

#36

Post by WalterBright » Sun, Aug 01, 2021, 7:42 PM UTC

gumby wrote: post #18

10000truths wrote: post #15

Anonymous nested structs are also quite useful for creating struct fields with explicit offsets: #include #include #define YDUMMY(suffix, size) char dummy##suffix[size] #define XDUMMY(suffix, size) YDUMMY(suffix, size) #define PAD(size) XDUMMY(__COUNTER__, size) struct ExplicitLayoutStruct { union { struct __attribute__((packed)) { PAD(3); uint32_t foo; }; struct __attribute__((packed)) { PAD(5); uint16_t bar; }; str…

One of the very few things from C that I miss in C++ is anonymous structs and enums. I really don’t understand why they are not allowed. That is, C style enums don’t have to have a name but “type safe” (enum class) ones do. One classic use is to name an otherwise boolean option in a function signature; there’s typically no need to otherwise name it. C++ incompatibly requires a name for all struct and class declaratio…

> I really don’t understand why they are not allowed.

I don't, either. Such were in D from 2000 or so.

I also don't understand why `class` in C++ sits in the tag name space. I wrote Bjarne in the 1980s asking him to remove it from the tag name space, as the tag name space is an abomination. He replied that there was too much water under that bridge.

D doesn't have the tag name space, and in 20 years not a single person has asked for it.

This did cause some trouble for me with ImportC to support things like:

    struct S { ... };
    int S;

but I found a way. Although such code is an abomination. I've only seen it in the wild in system .h files.

Re: Learning that you can use unions in C for grouping things into namespaces

#37

Post by midjji » Sun, Aug 01, 2021, 7:42 PM UTC

sesuximo wrote: post #2

Doesn’t matter for C, but in C++ this could make your contexpr functions UB since you can only use one member of a union in constexpr contexts (the “active” member).

Constexpr unions is the sane/safe way to use them. Its great, because accessing a member which isnt the last one written, constexpr will explicitly prevent it compile time. Whereas all other examples here are explicitly undefined behaviour!

Re: Learning that you can use unions in C for grouping things into namespaces

#38

Post by midjji » Sun, Aug 01, 2021, 7:45 PM UTC

rightbyte wrote: post #7

I don't regard this as a "perverse" hack. If I ever do embedded memory mapped stuff in C11 this is way too tempting.

You are practically guaranteed to invoke undefined behaviour if you do. Just use a map on a std::array of e.g. std::byte

Re: Learning that you can use unions in C for grouping things into namespaces

#39

Post by AlotOfReading » Sun, Aug 01, 2021, 7:46 PM UTC

vbezhenar wrote: post #25

Subsentient wrote: post #20

Bleurgh. I have a deep soft spot for C, and I'm known to get twisted pleasure from using obscure language features in new ways to annoy people, but this is a level of abuse that even I can't get behind. If you need namespacing, use C++. As much as I love C, it's terrible for large projects.

Linux kernel is large project and clearly C is sufficient for it, given the fact that migrating to C++ would probably be very easy (not using all C++ features, but just selected ones), yet it did not happen. I think that C++ is better than C, but C is not that bad, even for large projects.

A big issue with introducing C++ into a codebase is that it's incredibly hard to stick to a particular subset or standard. There's always a well-justified argument for the next standard or "just this one additional feature". Eventually you end up with the whole kitchen sink, regardless of where you started.

I've had far more success hard-firewalling C++ into its own box where programmers can use whatever they can get running than trying to limit people to subsets.

Re: Learning that you can use unions in C for grouping things into namespaces

#40

Post by midjji » Sun, Aug 01, 2021, 7:51 PM UTC

adtac wrote: post #27

vbezhenar wrote: post #25

Earlier quoted context omitted.

Linux kernel is large project and clearly C is sufficient for it, given the fact that migrating to C++ would probably be very easy (not using all C++ features, but just selected ones), yet it did not happen. I think that C++ is better than C, but C is not that bad, even for large projects.

the kernel has to live with the choices it made in the 90s, you don't

Yeah they should have upgraded to some restricted subset of C++ or new restrictive language ages ago. I mostly buy the arguments against having exceptions, perhaps even against polymorphism in general, but the argument against destructors, or atomics... hell no.