Technically you could use smart pointers, or other types too.
But beware the performance impact, and do get numbers before changing.
Ethereal/Wireshark does an enormous amount of small allocations and frees.
One of my primary goals when we added the first emem allocators were
performance.
Make it very cheap, near zero cost for both allocations and free,
especially for a lot of small shortlived allocations.
This is important especially if you have really big captures where
the original malloc()/free() real allocators became impossibly slow.
On Thu, Jun 20, 2013 at 11:08 PM, Dirk Jagdmann <doj@xxxxxxxxx> wrote:
>> C++. It snuck in with Qt. Should we allow C++ in the rest of the code or
>> at least use C++ compilation everywhere?
>
> A tough call. If we go C++ we should have a plan to use the STL classes with our
> concept of memory (allocator scope). I've started a short discussion last year,
> but somebody found out, that using STL objects on the heap with the C++
> allocators doesn't have the same semantics (and really doesn't work) with our
> packet or file lifetime scopes.
>
> However a second approach with C++ objects managed by smart pointers and those
> smart pointers being aware of the packet/file/application lifetime might work.
> We should research this, write guidelines how to use C++ objects in Wireshark
> and then make a decision if we want to allow C++ features everywhere.
>
> Another advantage would be that we can use real C++ exceptions.
>
> --
> ---> Dirk Jagdmann
> ----> http://cubic.org/~doj
> -----> http://llg.cubic.org
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe