Re: OT: getting the protocol family of a file descriptor

Am Freitag, 1. Februar 2008 14:07:48 schrieb Dag-Erling Sm=C3=B8rgrav:
> "Heiko Wundram (Beenic)" <[e-mail]> writes:
> > At the moment, there are two different kinds of connections being
> > handled by front-end plugins (which basically accept on a listening
> > socket, set up a certain initial state and pass it to the backend):
> > AF_INET(6) and AF_BLUETOOTH. The latter won't work with the
> > getaddr*-functions or getnameinfo() to format the address,
>
> so fix getnameinfo() :)
>
> > I personally don't find this especially beautiful
>
> why does it need to be beautiful?

No, it doesn't need to be beautiful, of course. But when you use a language=
=20
that has (slightly) higher type-safety than C, such as C++ (in the form of=
=20
allowing you to cast pretty much anything to anything, but having to cast=20
_explicitly_ for pointers of different types except for conversion to void*=
),=20
you're bound to not understand your code after some time of letting it rest.

And, it makes the code harder to read (at least if you stick to C++'s stand=
ard=20
*_cast<>() templates) and debugging it more painful.

That's what I'd call beautiful (as in "minimize the number of casts you=20
need"), but again, I already said that that it's okay if "it's just me." An=
d=20
the actual "dirty" code is hidden away in a framework, anyway, so I hopeful=
ly=20
won't have to touch that for quite some time. ;-)

=2D-=20
Heiko Wundram
Product & Application Development
_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[e-mail]"