On 09/17/2013 03:05 PM, Jiří Zárevúcky wrote: > On 17 September 2013 09:52, Jakub Jermar <[email protected] > <mailto:[email protected]>> wrote: > > On 17.9.2013 1:06, Jiří Zárevúcky wrote: > > Because list_t feels too obscure to me. To me it's much easier to > write > > linked list manipulation in-line, and I think the resulting code is > > clearer as well. Note that I did use list_t and list_foreach() until a > > few days back, but after recent addition of two more magical arguments > > to list_foreach() macro, I just didn't have the energy to go > figure out > > how it works. > > > > That being said, I would not oppose changing this back to > list_t... but > > for this one thing, I am not going to be the one doing the change. > > Why wouldn't you? > > > Two specific reasons why: > 1) It's macro magic. You use as "arguments" arbitrary words you generate > code with. Such stuff IMHO should not be done, unless you really have no > other alternative. > 2) The library types obscure what kind of list it is. You could just as > well replace all pointer types in the code base with "void *". > > You could do better. For example, mandate that a real "next" pointer is > used in the list entry, and let the library check its offset and operate > on these pointers. You wouldn't need list_t or link_t, you would instead > use what they really mean. Instead of using magical macro to retrieve > entry from a link, you can have the library function return void pointer > to the entry, which in C casts to any pointer implicitly. Easier to use, > easier to understand, cleaner interface.
Let me remind you that we are not solving the linked list implementation problem, but the problem of merging your file system related changes. Just reuse the common library code, do not invent your own. If you feel like improving the generic linked list implementation afterwards, you are welcome. But please, no separate linked list implementations. I will only limit myself to commenting on your point 2), because point 1), as you put it, is by definition subject to personal taste. The implementation actually makes sure (in compile time) whether the combination of 'type' and 'member' form a pointer to 'link_t'. You could still get a false negative, but far from accepting any pointer. Perhaps the implementation can be improved to also check whether 'link' is of type 'type'. Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
