On Thu, Apr 28, 2011 at 10:47 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > On Thu, 28 Apr 2011, Colin McCabe wrote: >> > I pushed a patch to master that adds this. It's now >> > >> > struct ceph_mount_t; >> > >> > which is sort of annoying: the _t suffix really shouldn't be there. But >> > if it's just ceph_mount it conflicts with int ceph_mount()... :/ >> > >> > sage >> > >> > >> >> Well, actually, in C and C++, variables can have the same name as >> types. In other words, the namespaces are separate. Taking advantage >> of this isn't necessarily a good idea, though... parsing in C++ is >> pretty ambiguous already. > > In this case it's the function ceph_mount(). I'll make it > struct ceph_mount_info and typdef ceph_mount_info_t I guess! > > sage > We don't actually need a typedef for this. In C++, you can declare "Foo f;" in any context that you could declare "struct Foo f;" For the part of our code that is C, I think we've been trying to keep to the kernel style guides, which contain a (well-justified) rant against overuse of typedef. I think TV commented on this too :) What do you guys think of changing struct ceph_mount_t to struct ceph_mount_info_t? sincerely, Colin. > >> >> As far as the _t suffix goes, it's used a lot in the Ceph library >> bindings. For example, librados has rados_t, rados_ioctx_t, >> rados_list_ctx_t, and rados_snap_t. librbd has rbd_snap_t and >> rbd_image_t. So although we don't generally use the _t internally, the >> library bindings are generally a _t party (so to speak.) >> >> cheers, >> Colin >> -- >> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >> -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
