On Sat, 2008-09-20 at 13:31 +0200, Kinkie wrote: > On Fri, Sep 19, 2008 at 9:08 PM, Alex Rousskov > <[EMAIL PROTECTED]> wrote: > > On Fri, 2008-08-22 at 10:24 +0200, Kinkie wrote: > > > >> The wordlist-refactor branch is from my point of view feature-complete. > >> It can be found in Launchpad, at > >> https://code.launchpad.net/~kinkie/squid/wordlist-refactor. > >> I'm not posting a bundle to propose merging into trunk at this time, > >> because despite the patch being quite self-contained, some core > >> developers have expressed concerns about it potentially introducing > >> subtle bugs, and suggested it to be merged after branching 3.1. > >> > >> Here's the branch summary: > >> Purpose of this branch is to migrate wordlist from a C-style interface > >> with some c++ coating into a proper c++ object. It does not aim to > >> increase the performance of the implementation, but to have cleaner > >> semantics for the callers. > >> This branch is an interim step on the way to a proper > >> template-library-based class. Collateral advantages include unit > >> tests, doxygen documentation and naming convention compliance. > >> > >> > >> I appreciate anyone taking a peek at it and posting any comments. > > > > *B1* Should we just use std::list or another standard container instead? > > It seems like a standard container provides everything the new WorldList > > wants to provide. Is this a performance optimization? > > No. This implementation is an intermediate step, migrating to a > standard container is the eventual aim. > The whole concept should probably also be phased out in favour of a SBufList.
Understood. So we have a few options here: 0) Do nothing now. Continue to use C-ish WordList until better String is available. Decide what to do next at that time. 1) Polish and implement new C++ WorldList class that still uses char* words. Convert all user code to use that new class. Later, throw away that class, replace with some String-based list. 2) Use existing std::list<SquidString> or similar (i.e., use a standard list and the existing SquidString class). Convert all user code to use std::list<SquidString>. When proper String is available, replace SquidString with String and, possibly, std::list with StringList. Out of these options, (1) seems to make least sense. Why spend hours on inventing a new class that is going to be replaced with something better, especially if that something better already exists? Thank you, Alex.
