Re: Idle Thought - Compiling with C++

[Evan Huus <eapache () gmail com>]

On Sun, Feb 10, 2013 at 9:06 AM, Ed Beroset <beroset () mindspring com> wrote:
> Donald White wrote:
> > That said, I have some experience with C to C++ transitions.  Twice in
> > my career, the team I was with was given the job of maintaining legacy
> > products written in C (several 100K lines of code) to maintain and
> > enhance.  In both cases, our first step was to recompile with a C++
> > compiler.  This was done as a quick and intense effort without
> > introducing any C++ language features.  We would just get the code to
> > compile, link and pass its regression tests.  Only later did we replace
> > #defines with consts, macros with inline functions and such.  I judged
> > these efforts as being very beneficial in improving code quality.
>
>
> This is a reasonable approach for improving code quality.  In an open source
> project like Wireshark, I think the challenge would be in specifying which
> C++ features/constructs would NOT be used. Having extensive experience with
> both C++ and C, I'd say that some of the most useful features in C++ didn't
> even exist in 1991 when that "Old dogs, new tricks" article was written.
> Specifically, I mean templates and the Standard Template Library (STL).

That's a good point, actually.

> That said, however and at the risk of stating the obvious, code written in
> C++ looks a lot different than C written in C++.
>
> For example, to me, the tvbuff.c and value_string.c files cry out for
> reimplementation as C++ classes, but to actually do such a reimplementation
> would very literally be a change to the core of Wireshark. If we were to use
> a C++ compiler as simply an enhanced C compiler, we'd have to figure out how
> to prevent submissions from including C++ constructs no "approved" by
> Wireshark coding guidelines.

I think the way to do this would be to start very small and slowly
build up a white-list of C++ features and their accepted usages. Start
with just things that are also part of later C standards (like
variadic macros), and reject anything else C++. Only once we're
comfortable with one thing would we start discussing what else we
could safely add to the white-list.

Wireshark has been doing just fine for nearly 15 years in pure C. I
agree that parts of it cry out for classes and inheritance when I look
at it with my C++ hat on, but they're not necessary, just useful. The
way to do this (if we decide to) is definitely in a conservative
manner.

Evan

P.S. Another thing to consider is that it's much easier (in general)
for C++ to interface with C than vice versa. If we transition the core
to use C++ constructs we're making it somewhat more difficult for
people who know C but not C++ to write dissectors and plugins.
___________________________________________________________________________
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