3 ms·
> hacks like “we will always have this struct in another one with a pointer preceding A struct embedded within a different struct gives simply a bigger struct,
by jstimpfle 5y ago
> hacks like “we will always have this struct in another one with a pointer preceding
A struct embedded within a different struct gives simply a bigger struct, which is something we have decided is a good idea (as opposed to e.g. attribute lookup in dynamic scripting languages).
The unfortunate thing is that there is no way to check statically that an inner struct that you hold in your hand is indeed embedded within a larger thing. But that is the kind of assertion that is incredibly hard to prove in a simple framework without complicating things, so the better idea seems to not do it. (Also it's the kind of assertions that seldom wrong once you've tested a tiny bit).
> (text based macros are simply the worst thing ever)
Are they?
Consider how many actual bugs were caused by text macros, and then consider how many useful things you can do with them that you simply cannot do with AST based macros.
- kaba0 5y agoWhat about dynamically replacing said inner or outer struct? You get absolutely no insight on the intent of the developer. That’s why actually joining a C project is really hard. C simply sucks at abstraction, and can only manage it through convention, without enforcement. Please show me any IDE that can reliably refactor huge C projects. Compare it to eg. Java. The difference is night and day — what even is the point of text based macros? You have to parse the AST either way, why not manipulate that? And you can say that at the time memory constraint or whatever, but it is simply a terrible idea all around. You are basically running sed through your code.