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.
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). -- ---> Dirk Jagdmann ----> http://cubic.org/~doj -----> http://llg.cubic.org ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
