Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

utcc.utoronto.ca

Post reply on HN
Print view View original

121–130 of 150 posts

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

#121

Post by jjnoakes »

WalterBright wrote: post #110
jjnoakes wrote: post #98

Earlier quoted context omitted.

> Conditional compilation is an optimization, not a semantic intent. Why can't it have semantic intent? I frequently use it for cross-platform adjustments, and those don't usually compile on the defined-away platform.

> those don't usually compile on the defined-away platform Then you're doing it wrong :-/ All these can be made to work. P.S. compiling successfully is not the same thing as linking successfully. Think stubs and deciding which files to link together.

They can be made to work by introducing stubs for every os/arch/compiler/dependency I support, but that's way more work for dubious gain.

And who is to say I'm doing it wrong? Just because conditional compilation CAN lead to a rat nest doesn't mean it MUST. And if it happens to be well-organized and works as is, there is no problem.

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

#122

Post by WalterBright »

d110af5ccf wrote: post #116
WalterBright wrote: post #108

Earlier quoted context omitted.

I'm a noob when it comes to Lithp. But I'm told what happens with their macros is the language is fairly unusable until you write lots of macros. The macros then become your personal undocumented wacky language, which nobody else is able to use. I've seen this happen with assembler macro languages, too. > most powerful It's like putting a 1000 hp motor in a car. It's main use is to wreck the car and kill the driver.…

> 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 language is a good thing

Supporting the creation of embedded DSLs is a good thing. Hijacking the syntax of the language to create your own language is a bad thing. I've seen it over and over, it never works out very well. It's one of those things you just have to experience to realize it.

D's support for DSLs comes from its ability to manipulate string literals at compile time, generate new strings, and mixin those strings into the code. This is clearly distinguishable in the source code from ASTs.

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

#123

Post by WalterBright »

d110af5ccf wrote: post #119
nextaccountic wrote: post #118

Earlier quoted context omitted.

> BTW, D is the first language of its type (curly brace static compilation) to be able to execute arbitrary code at compile time. It started as kind of "let's see what happens if I implement this", and it spawned an explosion of creativity. It has since been adopted by other languages. I don't know much about D compile time evaluation. How is it better than macros/templates? Also, what do you think about Haskell's an…

> 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 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

#124

Post by nextaccountic »

d110af5ccf wrote: post #119
nextaccountic wrote: post #118

Earlier quoted context omitted.

> BTW, D is the first language of its type (curly brace static compilation) to be able to execute arbitrary code at compile time. It started as kind of "let's see what happens if I implement this", and it spawned an explosion of creativity. It has since been adopted by other languages. I don't know much about D compile time evaluation. How is it better than macros/templates? Also, what do you think about Haskell's an…

> 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?

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

#125

Post by WalterBright »

jjnoakes wrote: post #121
WalterBright wrote: post #110

Earlier quoted context omitted.

> those don't usually compile on the defined-away platform Then you're doing it wrong :-/ All these can be made to work. P.S. compiling successfully is not the same thing as linking successfully. Think stubs and deciding which files to link together.

They can be made to work by introducing stubs for every os/arch/compiler/dependency I support, but that's way more work for dubious gain. And who is to say I'm doing it wrong? Just because conditional compilation CAN lead to a rat nest doesn't mean it MUST. And if it happens to be well-organized and works as is, there is no problem.

> that's way more work for dubious gain

Oh, have I heard that before. Here's what happens, over the years, to such code:

1. #ifdef's on the wrong feature. For example, #ifdef on operating system for a CPU feature.

2. Overly complex #if expressions, that steadily get worse.

3. Fixing support for X that subtlety breaks F and Q support. It goes unnoticed because your build/test machines are not F and Q.

4. People having no idea what #defines to set on the command line, nor what the ones that are set are doing (if anything).

4. People having no idea how to fold in support for new configurations.

5. Code will #ifdef on predefined macros that have little or no documentation on what they're for or under exactly what circumstances they are set. If the writer even bothered to research that. gcc predefines what, 400 macros?

> Just because conditional compilation CAN lead to a rat nest doesn't mean it MUST.

Jyust yew wite, 'enry 'iggins, jyust yew wite!

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

#126

Post by WalterBright »

shultays wrote: post #115
WalterBright wrote: post #93

Earlier quoted context omitted.

> the compiler won't delete it and complain if bar is not defined extern void bar(); will define it to the satisfaction of the compiler. The linker won't complain if the compiler removes the call to it.

And then you have the issue of not having types. consider this void my_bar_class_type::bar(my_bar_type ::my_bar_inside_type paramater); and you are calling something like myObject->bar(mySecondObject.getWhatever()); You have to mock up like everything

Or go up an abstraction layer so the type details are not needed.

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

#127

Post by nextaccountic »

WalterBright wrote: post #123
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 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

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

#128

Post by jjnoakes »

WalterBright wrote: post #125
jjnoakes wrote: post #121

Earlier quoted context omitted.

They can be made to work by introducing stubs for every os/arch/compiler/dependency I support, but that's way more work for dubious gain. And who is to say I'm doing it wrong? Just because conditional compilation CAN lead to a rat nest doesn't mean it MUST. And if it happens to be well-organized and works as is, there is no problem.

> that's way more work for dubious gain Oh, have I heard that before. Here's what happens, over the years, to such code: 1. #ifdef's on the wrong feature. For example, #ifdef on operating system for a CPU feature. 2. Overly complex #if expressions, that steadily get worse. 3. Fixing support for X that subtlety breaks F and Q support. It goes unnoticed because your build/test machines are not F and Q. 4. People having…

> Here's what happens, over the years, to such code:

Over how many years? Some of my projects are 30+ years old and support a few dozen combinations of OSes, compilers, and architectures, and the method I described hasn't led to a rat's nest yet.

> #ifdef's on the wrong feature. For example, #ifdef on operating system for a CPU feature

Sure, same thing happens when you decide whether to compile in your stubs or not. But if I make a mistake, the code usually won't compile on the configuration in question; if you make a similar mistake, it'll compile with your stub, it might even link, but you'll get odd runtime behavior. Sounds worse.

> Overly complex #if expressions, that steadily get worse

All code gets worse over time and bit rots if you don't maintain it, I don't see things necessarily worse in this area.

> Fixing support for X that subtlety breaks F and Q support. It goes unnoticed because your build/test machines are not F and Q

If you aren't testing on tier one configurations, they shouldn't be tier one. And if a tier three configuration breaks when you do finally get around to testing it, it's tier three, so it gets fixed when it can be and there's no problem. Similar to normal code, I'd say.

> People having no idea what #defines to set on the command line, nor what the ones that are set are doing (if anything) > People having no idea how to fold in support for new configurations

These problems exist for normal code as well. Someone has to own the build configurations, and they have to be maintained, like anything else.

> Code will #ifdef on predefined macros that have little or no documentation on what they're for or under exactly what circumstances they are set. If the writer even bothered to research that. gcc predefines what, 400 macros?

We only use a handful, and they are fairly well documented. But even if they weren't, since the code works on all tier one platforms, we'd know if something was changed out from underneath us because it was underspecified or accidentally relied upon.

But again the same can happen with normal code and system headers, compiler extensions, etc - I don't see why pre-processor macros have to be singled out here.

> Jyust yew wite, 'enry 'iggins, jyust yew wite!

How long?

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

#129

Post by tialaramex »

pjmlp wrote: post #102
tialaramex wrote: post #17

Earlier quoted context omitted.

First of all, C++ 11 may feel like thirty years ago, and certainly some of its proponents look thirty years older than they did at the time, but it was only ten years ago. C++ namespaces date to standardisation work (so after the 1985 C++ but before the 1995 standard C++) but they don't get this job done. Inline namespaces are a newer feature. Secondly this technique does something different. The C hack doesn't touch…

Ah, another of those threads, ok lets set the years straight. Yes, inline namespaces were only introduced in C++11, about 10 years ago, now lets dive into article. "Learning that you can use unions in C for grouping things into namespaces" Grouping into namespaces , so when did C++ get said feature? ANSI/ISO C++89 released to the world in September 1998, which makes around 23 years, or 24 years if we consider the rel…

> This C hack definitly does touch old code

Nope. C considers that a.field2 is still a perfectly reasonable name for well... a.field2, even though a.sub.field2 is now also a name for that same field. The old code that cares about a.field2 works, no changes. You can recompile it, or not, either way, still a.field2

New code (or, sure, rewritten code if you have the budget to go around rewriting all your code) gets to talk about the new-fangled a.sub and it all works together.

Whereas with the C++ namespace hack that doesn't work.

Which is fine -- no reason your C++ namespace hack isn't great for whatever you wanted that for, and this hack is great for what it wanted to do. But where we end up with this thread is your claim that since Bjarne was pestered into adding the namespace feature to C++ in about 1990 this C hack isn't necessary for C++ even though the two are orthogonal.

Yes C++ has namespaces. Yes that's a good feature. No it doesn't help you solve this problem even with the later "inline namespace" feature.

> Grouping into namespaces, so when did C++ get said feature?

What you've done there, and perhaps in this whole thread, is assume that your context is the only context. There is some irony in the fact that this is the sort of problem namespace features in programming languages often aim to prevent. std::cmp::Ordering is very different from std::sync::atomic::Ordering

In your context "namespace" means the C++ feature. But in the author's context, as a C programmer, it just meant the plain fact that C considers a.foo to be a field in a, while a.b.foo is a field in b, which is in turn a field in a, and these names are separate, they don't shadow, they don't clash. The same way member names from different classes are in separate namespaces.

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

#130

Post by midjji »

humanrebar wrote: post #69
midjji wrote: post #40

Earlier quoted context omitted.

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.

> ...against polymorphism... C has polymorphism. Inheritance-based virtual dispatch is just one kind of polymorphism. It's common to wire up polymorphism in C with bespoke data structures using tagged unions it function pointers. Changing an implementation at link time is even a form of polymorphism.

yes, and that is generally worse
Post reply on HN