From: Stuart Longland <stuartl@longlandclan.id.au>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: ccan@lists.ozlabs.org
Subject: Re: [PATCH] btree: Add custom allocator interface.
Date: Tue, 9 Feb 2016 12:14:59 +1000 [thread overview]
Message-ID: <56B94BA3.4060405@longlandclan.id.au> (raw)
In-Reply-To: <20160208234057.GC29288@voom.bne.redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 2155 bytes --]
On 09/02/16 09:40, David Gibson wrote:
> 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.
Yeah, for that reason I tend to write:
int* a;
int* b;
thus being explicit about it. In fact I do that for non-pointers too as
it's just clearer. (I'd make lousy submissions to the IOCCC.)
It also lets me document what each variable is doing with a comment.
However, we digress, the style is definitely the 'void *foo' style
already, and so in the interests of code consistency, that shall be the
style used. ;-)
>>> [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.
Yeah, I did it without thinking, elsewhere like in Python, that's the
convention; ALL_CAPS → constant. I know C has a convention for macros
being capitalised, but none really for const members, my fingers just
went on autopilot.
I shall fix this though when I get to everything else. :-)
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
ccan mailing list
ccan@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/ccan
prev parent reply other threads:[~2016-02-09 2:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-07 0:10 [PATCH] btree: Add custom allocator interface stuartl
2016-02-08 0:45 ` Rusty Russell
2016-02-08 2:37 ` Stuart Longland
2016-02-08 3:41 ` Rusty Russell
2016-02-08 4:24 ` Stuart Longland
2016-02-08 2:17 ` David Gibson
2016-02-08 4:26 ` Stuart Longland
2016-02-08 23:40 ` David Gibson
2016-02-09 2:14 ` Stuart Longland [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B94BA3.4060405@longlandclan.id.au \
--to=stuartl@longlandclan.id.au \
--cc=ccan@lists.ozlabs.org \
--cc=david@gibson.dropbear.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).