> thing_t * thing
This makes my head hurt!
I'd prefer thing_t *thing.
But it's a nice concept
Resume in C
41–50 of 115 posts
Re: Resume in C
#42Great idea, but oops... the data structure thing_t is hideous. It is a "god object" for anything where differently purposed members are union'd. Also, putting char*'s into a union is a terrible idea.
Re: Resume in C
#43Wow, I didn't know this was valid C code, it's pretty convenient. school_t uiuc = { .school = "University of Illinois at Urbana-Champaign", .location = "Urbana, IL", .program = "BS Computer Science", .started = 1251158400, .left = 1336608000, .accomplishments = { "Minor in International Studies in Engineering, Japan", "Focused on systems software courses", NULL } };
It's a C99 feature (I think?) -- designated literals. They're absolutely wonderful.
Although GP didn't remark on it, TFA uses an other cool feature which is actually C11: anonymous unions. Although not as wonderful as designated literals, they're really quite convenient.
Re: Resume in C
#44Great idea, but oops... the data structure thing_t is hideous. It is a "god object" for anything where differently purposed members are union'd. Also, putting char*'s into a union is a terrible idea.
> It is a "god object" for anything where differently purposed members are union'd. Also, putting char*'s into a union is a terrible idea.
They're not differently purposed, the union is just used to define more contextual labels for equivalent fields, and thus make initialisation more readable within each domain.
Re: Resume in C
#45Great idea, but oops... the data structure thing_t is hideous. It is a "god object" for anything where differently purposed members are union'd. Also, putting char*'s into a union is a terrible idea.
Why is putting char* into a union a bad idea?
Re: Resume in C
#46> thing_t * thing This makes my head hurt! I'd prefer thing_t *thing. But it's a nice concept
Surely it should be `thing_t* thing`!
Re: Resume in C
#47Great idea, but oops... the data structure thing_t is hideous. It is a "god object" for anything where differently purposed members are union'd. Also, putting char*'s into a union is a terrible idea.
> It is a "god object" for anything where differently purposed members are union'd. Also, putting char*'s into a union is a terrible idea. They're not differently purposed, the union is just used to define more contextual labels for equivalent fields, and thus make initialisation more readable within each domain.
There are three data structures unsystematically blended into one (that is, one cannot unambiguously tell which fields go into which "virtual" type, and cannot formally check the correctness). The name thing_t is indicative that you indeed cannot really tell what that entity is. This kind of data structure design begs for errors, while being conceptually wrong.
Re: Resume in C
#48Great idea, but oops... the data structure thing_t is hideous. It is a "god object" for anything where differently purposed members are union'd. Also, putting char*'s into a union is a terrible idea.
Why is putting char* into a union a bad idea?
char* points to some mutable buffer of char's that is supposed to be allocated somewhere. In this particular case they are assigned string literals, but in general it would be quite easy for someone to break consistency of allocations/deallocations in such code.
Re: Resume in C
#49> thing_t * thing This makes my head hurt! I'd prefer thing_t *thing. But it's a nice concept
Surely it should be `thing_t* thing`!
thing_t* thing_ptr, thing
imo, the star should be with the variable name. because, in this case, a reader could think that both thing_ptr and thing are pointer to a thing_t
"thing_t thing_ptr, thing, other_thing_ptr" is imo more readable
Re: Resume in C
#50Earlier quoted context omitted.
> It is a "god object" for anything where differently purposed members are union'd. Also, putting char*'s into a union is a terrible idea. They're not differently purposed, the union is just used to define more contextual labels for equivalent fields, and thus make initialisation more readable within each domain.
There are three data structures unsystematically blended into one (that is, one cannot unambiguously tell which fields go into which "virtual" type, and cannot formally check the correctness). The name thing_t is indicative that you indeed cannot really tell what that entity is. This kind of data structure design begs for errors, while being conceptually wrong.
> There are three data structures unsystematically blended into one
The point is that they're not three completely separate data structures, they're a single data structure with context-dependent field labelling.