On Mon, Feb 11, 2013 at 1:47 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Feb 11, 2013, at 8: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.
>
> Yes - one of the biggest annoyances with C is that it doesn't *really* support character strings worthy of the name.
>
>> Since the C++ STL classes allow a custom allocator
>
> Good - that's one of the key requirements, namely a memory allocator that supports reasonably fast allocation of a lot of objects from a pool and fast bulk freeing of everything in the pool.
>
>> I don't advocate to redesign Wireshark into a C++ object/inheritance hell at
>> once,
>
> Or ever. :-) Presumably you *can* do good object-oriented designs rather than rat's-nest-of-classes design with C++.
>
>> Since the QT version is already using C++, I guess that simply building current
>> Wireshark with a C++ compiler is a no brainer.
>
> The Qt version is using C++ *in the UI code*; that doesn't make building current Wireshark, in its entirety, with a C++ compiler necessarily easy:
>
> http://buildbot.wireshark.org/trunk/builders/Ubuntu-12.04-x64/builds/3671/steps/compile/logs/warnings%20%2818752%29
>
> Note all the lines flagged with "[-Wc++-compat]"; those are for code that's valid C but not valid C++ and that would have to be fixed in order to compile with a C++ compiler (unless there's a "let valid C code that *could* be handled as C++ code through" option to all C++ compilers we'd be likely to use).
As per Jakub, we have about 7k of those at the moment. The vast
majority appear to be missing casts from void pointers, which are at
least not difficult to fix (especially since I think many are in
generated code).
And some code (e.g. our copy of lemon) doesn't need to be converted
anyways, so any c++-compat warnings in it can be ignored completely.
>> 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).
>
> As long as all APIs exported by libdissectors are C APIs and wrapped in
>
> extern "C" {
>
> ...
>
> }
>
> name mangling shouldn't be a problem, right?
> ___________________________________________________________________________
> 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