[nanomsg] Re: On the use of small integers instead of pointers to identify "sockets"
- From: Nico Williams <nico@xxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 3 Sep 2013 18:03:37 -0500
I should add that I don't see any need for context handles in nanomsg,
so there not being any is a good thing!
The only way I could see context handles being needed would be if
applications could provide their own implementations of
transports/socktypes. And even, then only if there's a chance of
conflicts between nanomsg-using libraries in the same processes (DLL
hell), which seems unlikely.
I found the blog post that caused me to post here, which turns out to
not have been a blog post, just the 0.1-alpha release announcement.
The 0.1-alpha release announcement mentions the use of ints instead of
void *s. I wonder if you were aware of incomplete struct pointer
types in C... Incomplete struct pointer types give you a way to have
opaque values with strong type safety -- completely unlike int
(neither opaque nor really statically type safe) or void * (opaque but
not statically type safe).
I strongly recommend the use of incomplete struct pointer types,
specifically with a user-friendly typedef name. I can point out some
examples of common APIs that use incomplete struct pointer types
(e.g., PAM, GSS, SASL, some RPCs, ...). The main benefit over using
int is the additional type safety and not having to maintain a lookup
table.
The exported nanomsg API would basically have s/\<int s\>/nn_socket
s/g applied to it, and the nn_socket typedef added. Sentinel values
like -1 would be replaced with NULL; if multiple sentinels are needed
then there is a complication, actually: the need to reserve special
pointer values other than 0 (NULL), but it's a minor complication, not
unlike how POSIX allocates special values of signal handlers (SIG_IGN,
SIG_DFL).
Nico
--
Other related posts:
