Re: [PATCH] btree: Add custom allocator interface.
David Gibson <[email protected]> Tue, 9 Feb 2016 09:40:57 +1000
| Newsgroups | org.ozlabs.lists.ccan |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Feb 08, 2016 at 02:26:29PM +1000, Stuart Longland wrote:
> On 08/02/16 12:17, David Gibson wrote:
> >> +static void* default_malloc(const struct btree_allocator* alloc, size_t size);
> > Existing style in this function suggests "void *foo" rather than
> > "void* foo".
>
> Ahh, call it habit, I'm used to having the "pointer" bit with the type
> (as to me; "pointer to void" is a distinct type from "void"). Caught
> myself doing it elsewhere but missed it here, I'll fix it.
So, from a language design point of view, I agree with you. However,
I dislike that style in C because it obscures the fact that C
importantly *does not* have that sensible handling of types.
More specifically this style:
int* a, b;
Suggests that a and b have the same type, but of course they don't.
> > [snip]
> >> > +/* Default allocator implementation */
> >> > +const struct btree_allocator BTREE_DEFAULT_ALLOCATOR = {
> > Use of all-caps for a non-macro is a bit unexpected.
> >
>
> Good point. I guess I wanted to visually differentiate a constant from
> other member types.
I applaud the idea, but unfortunately I don't think that use of caps
is common enough to make it really clear.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
_______________________________________________
ccan mailing list
[email protected]
https://lists.ozlabs.org/listinfo/ccan
signature.asc
(application/pgp-signature, 819 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWuSeJAAoJEGw4ysog2bOSF2oQAJ7upI6F4gwVCboYhFjPAC0v MWCDKJESmaFDoZL4NASvDwf2LP96sCL4TW0jn8w4jSYoUcg3Zug9F9LvE7GlNYb1 GsvGGGOEGbRYellGu/utZ3QV/SAlKglFCzxlQReSGlSqy1zZ6Aa2m2DJOqBMCicD 2ASxH/lOnRJVcAFpAQ1vS9JungTDBTW3ox2ezyrW4XwwUEvtBCiGhyaXTLTsEpwh hYNY9r4z7UhGGNz2aXc33MGVNAwUOfHVsAM1kfpSxAi3wj5d/+Q6SYZu1/P8Gu/v U2uwXo5sH+BkERDP2wPOcCx5wze4QyBOC/XOPkCXwkPbVGgX6Ie+dDOLENlF1qkA 0Xs/h6F7Xshqnn9PC9FwZTZF5AP2OQTG5z8eRGT9SUzHDPC1n//Jq07wRZNQr+lo cdE2zWDewO8LJ1BpqCYlGEbzJ0TBXtteqapg196unTnUIIt2YCYUZ3vWhXCAN4TG v9qr7gt9/bzO0+CFK1UGXXPpOZkrj0W/RXlcuWy2xYqERMXD2SQpkXx8NCQR8yRJ UUJOWH61KLRquH/lqOZVfHpgm+KEklHsgT9McRtO+7lyQ/4zT7Qx7aWo6sJ28sqk rqryngtS6vSZN/Xvj7eDocoT7vETbHU6D4nJvV/PEWz1XO14rSxhlQK4nV2W3D77 L1pHKvQZZDpWIAQGaeh4 =vqW7 -----END PGP SIGNATURE-----