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?
