On Tue, Feb 12, 2013 at 12:01 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
> On Mon, Feb 11, 2013 at 12:26 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>> 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.
>
> 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.
... on the heap, of course. Classes on the stack are just fine since
the compiler scopes them for us.
