It is crazy to go to all of the extra trouble of dealing with an additional pointer for the email_t type, when it is just a struct that is a simple wrapper around a char * that could be passed around directly; a lot of the code in this example is just for dealing with having to manage the lifetime of the extra email_t allocation, which seems like an unnecessary hoop to jump through.
Isn’t that sort of just the cost of doing business in C? It’s a sparse language, so it falls to the programmer to cobble together more.
I do also think the concrete example of emails should be taken as a stand-in. Errors like swapping a parameter for an email application is likely not very harmful and detected early given the volume of email that exists. But in other, less fault-tolerant applications it becomes a lot more valuable.
It is crazy to go to all of the extra trouble of dealing with an additional pointer for the
email_t
type, when it is just astruct
that is a simple wrapper around achar *
that could be passed around directly; a lot of the code in this example is just for dealing with having to manage the lifetime of the extraemail_t
allocation, which seems like an unnecessary hoop to jump through.Isn’t that sort of just the cost of doing business in C? It’s a sparse language, so it falls to the programmer to cobble together more.
I do also think the concrete example of emails should be taken as a stand-in. Errors like swapping a parameter for an email application is likely not very harmful and detected early given the volume of email that exists. But in other, less fault-tolerant applications it becomes a lot more valuable.
C supports passing
struct
s around by value, so there was no need to allocate memory for it on the heap.