Re: Idle Thought - Compiling with C++

[Evan Huus <eapache () gmail com>]

On Mon, Feb 11, 2013 at 12:26 PM, Evan Huus <eapache () gmail com> wrote:
> On Mon, Feb 11, 2013 at 11:01 AM, Dirk Jagdmann <doj () cubic org> 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 <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe