Wireshark · Wireshark-dev: Re: [Wireshark-dev] Idle Thought - Compiling with C++

[Guy Harris <guy@xxxxxxxxxxxx>]

On Feb 11, 2013, at 8:01 AM, Dirk Jagdmann <doj@xxxxxxxxx> wrote:

> To me the biggest advantage of transitioning to a C++ compiler is the
> availability of std::string and std::list, std::set, std::map. They are so much
> more convinient to use than equivalents from the glib or the alternatives
> designed for Wireshark.

Yes - one of the biggest annoyances with C is that it doesn't *really* support character strings worthy of the name.

> Since the C++ STL classes allow a custom allocator

Good - that's one of the key requirements, namely a memory allocator that supports reasonably fast allocation of a lot of objects from a pool and fast bulk freeing of everything in the pool.

> I don't advocate to redesign Wireshark into a C++ object/inheritance hell at
> once,

Or ever. :-)  Presumably you *can* do good object-oriented designs rather than rat's-nest-of-classes design with C++.

> Since the QT version is already using C++, I guess that simply building current
> Wireshark with a C++ compiler is a no brainer.

The Qt version is using C++ *in the UI code*; that doesn't make building current Wireshark, in its entirety, with a C++ compiler necessarily easy:

	http://buildbot.wireshark.org/trunk/builders/Ubuntu-12.04-x64/builds/3671/steps/compile/logs/warnings%20%2818752%29

Note all the lines flagged with "[-Wc++-compat]"; those are for code that's valid C but not valid C++ and that would have to be fixed in order to compile with a C++ compiler (unless there's a "let valid C code that *could* be handled as C++ code through" option to all C++ compilers we'd be likely to use).

> The only caveat I can think of: if we build libdissectors with a C++ compiler
> that might force other users of that library to switch to C++ as well (name
> mangling etc).

As long as all APIs exported by libdissectors are C APIs and wrapped in

	extern "C" {

		...

	}

name mangling shouldn't be a problem, right?