Hi Marc, > > The only benefit that I see is that the typedef name is usually shorter > > to write. But that does not matter when, typically, there will be 1 or > > at most 2 instances of such a struct in a given function. > > The related module string-desc exports the typedefs string_desc_t and > rw_string_desc_t, although the structure is also part of the public > interface in the sense that it is not only accessed through a pointer > by user code. It would at least have the benefit of consistency to > have a typedef for string_buffer as well.
But a typical function can have 5 or 10 variables of type string_desc_t and only 1 of type 'struct string_buffer'. That's why a shorter name matters more for string_desc_t. > As the user is not supposed to touch the structure fields directly, > the struct string_buffer type should be considered opaque in my > opinion; it should not matter for the user whether it is implemented > as a struct, a union, or as a pointer to some heap-allocated data. The difference does matter. If something is merely a pointer, the programmer can pass it down to other functions by value. Whereas passing a 'struct string_buffer' by value would 1) have terrible performance, 2) not achieve the intent that the callee's effects are visible in the caller. So far, you haven't been convincing me. > some > consistency guidelines (if possible) for future developments would be > nice (e.g., when to typedef or not, how to name a struct/typedef, > whether to typedef away a pointer or not, etc.) I have no personal recommendations on this one. Maybe you will like the ones from the prior knowledge summarization engine (attached)? Bruno
typedef-guidelines.odt
Description: application/vnd.oasis.opendocument.text
