On Mon, Feb 11, 2013 at 11: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. Since the C++ STL classes allow a custom allocator we
> can write C++ allocators for our ep_ and se_ (or the new wmem_) paradigms and
> typedef Wireshark versions of the STL objects with these allocators. This would
> be my biggest immediate benefit.
That would be very nice, it's true.
> I don't advocate to redesign Wireshark into a C++ object/inheritance hell at
> once, although with those "features" available new developments can/might/will
> use them and over time we may have better code.
>
> Since the QT version is already using C++, I guess that simply building current
> Wireshark with a C++ compiler is a no brainer. If we agree that this route is
> worthwhile we could simply start building with C++ and develop some guidelines
> how to proceed with new code, restructuring old code and maintaining/bugfixing
> old code.
>
> 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).
I think, at least to start, it would make sense to keep all of our
library interfaces in C (so basically extern-C everything that's
exposed). This prevents us from making use of a number of C++
constructs, but we don't want to go massively changing API/ABI until
we have a broad consensus that the benefits outweigh the costs.
Evan
