On Sun, Feb 10, 2013 at 9:06 AM, Ed Beroset <bero...@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-requ...@wireshark.org?subject=unsubscribe