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

#131

Post by midjji » Mon, Aug 02, 2021, 7:22 PM UTC

genocidicbunny wrote: post #88

midjji wrote: post #35

Earlier quoted context omitted.

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.

Type punning is not undefined, it's implementation defined in C. In practice, every major C compiler will be fine with type punning, though it may disable some optimizations. The story is different in C++, but in practice many compilers support it the same as in C. Especially for games, where VC++ (PC, Xbox) and Clang (PS4/PS5) are the most commonly used compilers, it also works as expected. The trick is to only use…

Something being very common and a very common source of portability issues isn't exactly contradictory. Its a bad idea, and it is outright being taught in modern game programming courses that its a bad idea, but common in older guides, specifically because it caused so many problems. Im pissed at this specific construct because I got it handed to me in a huge game library and had to spent a long time figuring out why it wasn't working in rare, but important cases.

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

#132

Post by midjji » Mon, Aug 02, 2021, 7:24 PM UTC

shultays wrote: post #83

saagarjha wrote: post #74

Earlier quoted context omitted.

I don’t see the undefined behavior here?

Op probably means cpp, where it is indeed undefined behavior. not sure about c. I doubt that if this would cause a "my game does not work on XXX" though. Is there really a compiler out there that will handle such abuse differently?

yes its undefined behaviour in both C and C++. Yes, a number of compilers treat this differently, its also poorly supported on custom hardware using standard compilers like gcc. So compiling for some mobile device with slightly custom ... good luck.

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

#133

Post by midjji » Mon, Aug 02, 2021, 7:26 PM UTC

jjnoakes wrote: post #99

midjji wrote: post #47

Earlier quoted context omitted.

All undefined behaviour is well defined for each compiler, what it really means is implementation defined and subject to change without notice or documentation with every compiler version or host os what flags are enabled or a thousand other things. Why use an approach which strictly relies on specific versions of specific compilers, rather than a completely portable and standard compliant struct with char array and…

> All undefined behaviour is well defined for each compiler This is not true. > what it really means is implementation defined Implementation-defined behavior is a thing in the standard and is separate from undefined behavior.

What is referred to as implementation defined behaviour is a different class, yes, obviously. I guess nasal deamons was too complicated a piece of irony for you.

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

#134

Post by midjji » Mon, Aug 02, 2021, 7:29 PM UTC

fifjdynb wrote: post #60

midjji wrote: post #50

Earlier quoted context omitted.

There is absolutely undefined behaviour there. Undefined behaviour is defined not as nasal daemons but as: The compiler implementer does not guarantee that this behaviour will be hardware, circumstance, compiler version, or os consistent, nor that we will warn if we change this. Packed is technically not a undefined behaviour, but it is certainly a trap. Especially because the compiler macros leads people to make def…

You don't get to decide what UB means. It really does mean nasal demons are a possibility: all bets are off when you run that executable. Use of the term "undefined behaviour" to mean something else may be on the increase, unfortunately ( https://mars.nasa.gov/technology/helicopter/status/298/what-... ), but if we're talking about C, it's meaning is fixed.

I didnt, the deterministic nature of computer programs guarantees that what I wrote is the actual outcome.

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

#135

Post by midjji » Mon, Aug 02, 2021, 7:32 PM UTC

junon wrote: post #59

midjji wrote: post #52

Earlier quoted context omitted.

Pedantic is for the older C++ standard, its not pedantic for the latter e.g c++11, I think this changed.

No, pedantic is for disabling compiler extensions. You still need to explicitly specify a standard.

gcc pedantic ignores the language flag, and clang and intel state they mirror gcc. So pedantic would be not C++11 even if you added that.

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

#136

Post by gumby » Mon, Aug 02, 2021, 10:15 PM UTC

jcelerier wrote: post #105

gumby wrote: post #96

Earlier quoted context omitted.

No, they are forbidden by the standard (take a look at cppreference). Some compilers implement the C behavior as an extension, so tell your compiler to follow the standard strictly. I don’t use extensions, even convenient ones, as I have to be able to run my code on a variety of compilers. If you don’t have to do that, some extensions (like this one) are really handy.

From the standard, the enum-name is marked as optional in the enum grammar: in [dcl.enum]( https://eel.is/c++draft/dcl.enum#11 ) ; it is also referenced e.g. in [dcl.dcl]: > An unnamed enumeration that does not have a typedef name for linkage purposes ([dcl.typedef]) and that has a first enumerator is denoted, for linkage purposes ([basic.link]), by its underlying type and its first enumerator; such an enumeration is…

This is awesome. I referenced cppreference, but that is not authoritative. Unfortunately, in the final draft, [class.pre] grammar makes the name mandatory even though the language you quote remains in the first textual paragraph following the grammar specification!

The part of enums you quoted was C-compatible enums; anonymous scoped enums are explicitly forbidden: "The optional enum-head-name shall not be omitted in the declaration of a scoped enumeration" (dcl.enum 2).

Sigh. I will send in a clarification at least on the class/struct/union side. Ideally the grammar would be fixed rather than that paragraph.

The draft I looked at is https://timsong-cpp.github.io/cppwp/n4868/ (2020-10-18, shortly after the standard was approved).

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

#137

Post by WalterBright » Mon, Aug 02, 2021, 11:35 PM UTC

shaklee3 wrote: post #120

WalterBright wrote: post #109

Earlier quoted context omitted.

Oh man, you sure know how to drive a stake in my heart! What have I done! Some curses should just not be uttered. I'm not sure where it is on my backups. But it was done just like you'd do it in C++. The same thing, just with D syntax.

We're making a numerical computing library that expression templates are used for compile-time evaluation of expressions. It's a very niche hpc library, so it might be one of the few places it's appropriate.

I wish you luck with it. If you send me an email, when I find what I wrote about it I'll pass it along to you.

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

#138

Post by WalterBright » Mon, Aug 02, 2021, 11:35 PM UTC

nextaccountic wrote: post #127

WalterBright wrote: post #123

Earlier quoted context omitted.

I wish you luck with it. If you send me an email, when I find what I wrote about it I'll pass it along to you.

I think you replied the wrong comment

Oops, indeed I did. Replied to the right one!

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

#139

Post by d110af5ccf » Tue, Aug 03, 2021, 12:35 AM UTC

WalterBright wrote: post #122

d110af5ccf wrote: post #116

Earlier quoted context omitted.

> the language is fairly unusable until you write lots of macros This is not (typically) the case. It would be like saying that you need to write lots of templates to get things done in D. Metaprogramming is certainly very nice to have but it's not a requirement for the vast majority of tasks. It's important to note that Lisps are an entire family of languages; some implementations are batteries included while others…

> it's not a requirement for the vast majority of tasks. Right, but the temptation to do it is irresistible. > That's Doing It Wrong™ Of course it's doing it wrong. The point is, that seems to always happen because the temptation is irresistible. > goto I rarely see a goto anymore. It just doesn't have the temptation that macros do. > alias this Has turned out to be a mistake. > integrate it seamlessly into the host…

Fair enough, it seems we have very different philosophies on this particular issue. Without oft maligned features such as alias this and operator overloading I never would have given D a try as an alternative to C++.

I'd like to suggest that I think you might be missing some perspective here. You say that misuse of macros always happens and that you've seen it over and over. Yet if you explore the Scheme ecosystem you might notice that significant parts of any given implementation often take the form of macros. Racket in particular fully embraces the idea of the programmer mixing customized languages together and while examples of bad code certainly exist it seems to work out quite well on the whole.

To be clear, I do appreciate having easy access to tools that are simple and safe. I just also like having seamless access to and interop with a set of powerful ones that don't try to protect me from my own poor decisions. I shouldn't need to do extra work to make use of an alternative more powerful tool for a small part of a project. At that point it becomes very tempting to drop the safer tool altogether in favor of the more powerful one just to avoid the obviously needless and therefore particularly irritating overhead.

I much prefer the approach of providing limited language subsets that can be opted into and out of in a targeted manner. Having the compiler enforce a simple one by default provides a set of guard rails without getting in the way when it matters.

If I could write the majority of my code in something resembling Go and just a small bit of it in an alternative dialect with expressive power comparable to Common Lisp that would be ideal. To that end, I'm a huge fan of features like @system, @safe, and @nogc in D while very much disliking the need to use string mixins to write a DSL, the various restrictions placed on CTFE behavior, and other similar things.

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

#140

Post by d110af5ccf » Tue, Aug 03, 2021, 1:05 AM UTC

nextaccountic wrote: post #124

d110af5ccf wrote: post #119

Earlier quoted context omitted.

> D compile time evaluation. How is it better than macros/templates? CTFE isn't better than templates, it's a completely different tool. CTFE computes a result at compile time as though you had written a literal in the source code. Templates generate blocks of specialized code on the fly based on various parameters (typically types). They solve different problems.

I think that Walter was trying to say that D gets by doing the same things that people use macros for, but without macros. I interpreted this as meaning that D uses CTFE in those same situations. Am I wrong? What does D do, then?

I think he was saying that sufficiently powerful languages provide enough features that you won't need macros in the first place. If you feel that you do for some reason, go find a more powerful language instead.

> What does D do, then?

Most mainstream languages, D included, very intentionally don't provide any features that could potentially be used to extend the language itself on the fly. (At least not in a straightforward manner. Obviously the C preprocessor kind of sort of facilitates a bit of this.)

As a counterexample, Rust does provide some of this in the form of procedural macros but doesn't provide (to the best of my knowledge) an equivalent to Lisp reader macros.