On Mon, Feb 11, 2013 at 12:26 PM, Evan Huus <[email protected]> wrote: > On Mon, Feb 11, 2013 at 11:01 AM, Dirk Jagdmann <[email protected]> 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.
On second thought, and after a little digging into how exactly STL allocators work, they don't really support what we are currently doing with emem/wmem. Specifically, they would only allow us to bulk-free the underlying memory of classes, not bulk-destruct (which is also necessary). This is a fairly strong argument that regardless of what the API ends up doing, dissector internals should be limited to C-style structs. >> 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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
