Wireshark-dev: Re: [Wireshark-dev] Idle Thought - Compiling with C++
From: Evan Huus <eapache@xxxxxxxxx>
Date: Mon, 11 Feb 2013 12:36:52 -0500
On Mon, Feb 11, 2013 at 12:18 PM, Richard Stearn
<richard@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> A thought from the sidelines.  I have contributed to Wireshark, once.
> I probably will not contribute again (unless I find another protocol
> itch to scratch).  This is an observation from scratching that itch.
>
> Creating suite of dissectors from the skeletons in the development
> guide was not difficult.  When I did not understand how a particular
> function worked it was a simple matter to find the code and read.
> Often with object oriented languages it is not that simple as you
> may need to follow the inheritance and the advantage of hiding the
> detail rapidly unravels.

That's partly a hint that in general we need better documentation for
our APIs, but it's a valid point regardless. Again, this thread was
started with the thought that using a C++ compiler might be helpful -
I specifically tried to avoid the discussion about re-architecting in
an object-oriented style since that's obviously much more complicated
and less (to me) clear-cut.

> Would moving to C++ discourage or encourage potential contributors?

Moving just to a C++ compiler shouldn't cause problems for anybody.
While C++ isn't technically a superset of C, it is trivial for C
programmers to avoid the few areas of incompatibility (as far as I
know there are simply a few more reserved words like 'new' to avoid in
variable names).

> Can the complexity of the classes be controlled?

As I've already mentioned, moving to C++ as a language and to
object-oriented as a paradigm is a much bigger discussion, and there
isn't a whole lot of point in even having it until we've moved to
writing C on a C++ compiler.

> Is time/effort available to document the class hierarchy?

Documentation is needed regardless of language. You seem to be taking
it as given that C++ inherently needs more documentation than C, but
why that would be isn't immediately apparent to me. Either way, moving
to C++ constructs was really not the original proposal.

> Because I am on the sidelines here I am not (and should not be)
> saying "don't", just saying please consider carefully.

That's what this thread is for :)

Evan