C++ (again) / Squid 3

Right, I think it's time for a straw poll...

IIRC we essentially agreed that squid 3 will be C++.

Who here wants to rewrite squid from scratch in C++ for V3?

Who wants to migrate squid in-place to C++ for V3?

IF 'we' are generally in favour of an in-place migration, then the
sensible things to discuss are:
* when do we start and finish it
* How do we structure it (do we structure it)?
* What should the end result look like?

I'm in favour of an in-place migration over the next month (with no
functionality or design changes, just C->C++ syntax). Whilst we could
adopt a structured approach (hit the core files first/hit the
extremities first ...) I believe that is only useful if we adopt a long
transitioning plan. (I.e. we might say start now, convert core files
first, take as long as needed, and have a year or so to do the
transition.) We have 219 .c files in the source tree including all the
helpers (which don't need to migrate IMO). In the /src tree we have 127
.c files. I can commit to migrating 3 a day (thats about an hour of
coding and testing) indefinately. So we could chew through this VERY
quickly if a couple of us do that.

As far as the end result goes, I think that a few coding styles set out
at the beginning and a couple of API goals are all we need. Anything
else will emerge as a result of the C->C++ conversion AND the future
refactoring that that will enable.

By API goals I mean that we should provide C and C++ bindings for
external API's where we expect other development groups to plug in code.
(I.e. the auth helper parameter decoding logic, or eventual generic
helper message passing API).

For coding styles, I'm simply saying we document a half-dozen rules
about class naming/method naming and that's it. Anything more will
change this from a C->C++ exercise to a C->C++ AND 'convert procedural
design to objects' refactoring all in one hit - which is a bigger job
and will take a lot of resources to do quickly. IMO the refactoring can
occur naturally, as long as we refactor as we go post the inital code
conversion.

Finally, for reference a few notes about some prior objections to
allowing C++ in the source tree now:
Memory allocation: I've done some experimentation. It's *trivial* to
make C++ new and delete use MemPools. So there will be *no* extra way of
memory allocation. You can even make cbdata into a class sensibly.
Coding Style: The bulk of the squid code these days *is* C-based-OOP. It
will easily refactor into classes once we allow the process to start.
Unless we plan to make V3 a full rewrite (see above) we HAVE to
transition at some point. It can be a slow or quick transition, but we
have to make it.

So, please all speak up. I'm really keen to know *how* we are going to
get to a V3 squid that is C++.

Rob