On May 19, 2009, at 10:42 PM, Zach Welch wrote:
On Tue, 2009-05-19 at 22:14 -0700, David Brownell wrote:On Tuesday 19 May 2009, Dean Glazeski wrote:changed all 'struct target_s' to 'target_t' to keep things consistent.I'd rather do away with all typedefs myself, except maybe for "int" variants. Ditto that "*_t" convention. Anyone feel strongly pro-typedef?I think typedefs have their place, but I agree they are BAD when used inheader file declarations.
It all depends. I've seen really horrible uses of typedefs and I've seen really good use of typedefs. For example, an opaque handle that is provided to callers of an API to track a resource is really nice as a typedef. Sure, you can use the socket approach and hand back an int or you could hand back a pointer to a forward-declared struct, but that makes the API unnecessarily ugly or confusing. Instead, a typedef clarifies that the argument is a handle as opposed to an arbitrary int and allows an easy change in the backing type assuming everyone recompiles.
I'm not a fan of things like 'typedef uint32_t UInt32'. That is redundant and only serves as a bad hack instead of a search and replace.
Why? Because 'struct foo' can be forward-declared safely if it will beused only for pointers.
If a header includes a 'typedef struct foo foo_t', you can safely write foo_t * if you want to include the header or 'struct foo *' if you don't. The typedef just gets rid of the C oddities of putting structs and enums in their own namespaces.
In turn, this allows header files to be decoupled from one another. Go back and look at the changes that Istarted to decouple the headers and you will see me _removing_ typedefsto accomplish that mission.
Technically, the typedefs didn't need to be removed to accomplish that. In fact, the removal of the typedefs can easily cause more confusion. For simple structs, this isn't necessarily a problem, but more complex types easily show the benefits of typedefs. Consider the following:
int list_item_next(struct item * head, struct item * cur, struct item ** next);
versus
typedef enum {
...
} list_error_t;
typedef struct item * list_item_t;
typedef struct item * list_t;
list_error_t list_item_next(list_t head, list_item_t cur, list_item_t
* next);
Technically both have the same behavior, but the second makes the expected arguments clearer (don't pass an arbitrary element as the head of the list, next is a value-return param, etc). It also allows the API to change the underlying representations of the types without the caller changing (but a recompile might be necessary).
As a result, the changes in this patch result in the system being moretightly coupled than it really needs to be (and takes it in the oppositedirection that it should be headed), so I am fairly strongly against applying it without first seeing the typedef changes removed.
typedefs do not introduce strong coupling in any way. There is still an option to use the forward declaration via the struct when necessary. Of course, the use of the struct should only be reserved for those cases where it needs to be a forward declaration to avoid include loops.
Other than that, it looks great, and I am really appreciating the work!Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
