I now have a simple patch for the bitfields issue. It turned out astyle
misread bitfield definitions as labels..
The "block" issue is not yet identified, but is not as irritating
either.
Regards
Henrik
s�n 2003-02-23 klockan 00.33 skrev Robert Collins:
> On Sun, 2003-02-23 at 02:12, Henrik Nordstrom wrote:
> > Robert Collins wrote:
>
>
> > > I don't think this is a biggy: as we get more OOP, anonymous structs
> > > will dissappear almost completely.
> >
> >
> > Not completely I think. Using anonymous structs is quite handy for
> > grouping related members.
>
> mmmm, in C style coding yes. I'm pretty sure that over time they will
> all go away - and in a sensible fashion.
>
> > Here is a example of a quite recently OOP class:
>
> Please note that this is only 'partly' OOP. It's been factored out from
> the global ACL class, and somewhat refactorded, but there is more that
> can be done:
>
> > class ACLUserData : public ACLData<char const *>
> > {
> > [...]
> > SplayNode<char *> *names;
> >
> > struct
> > {
> >
> > unsigned int case_insensitive:
> > 1;
>
> This flag should go away. Instead the Splay class should be a true
> container that we simply insert, remove and find within. The container
> will be parameterised for case sensitivity, and thus ACLUserData class
> won't know whether it is case sensitive or not. For dumping the config
> I'd like a utility class to store parse-once, forget forever options and
> reduce the duplicated wordlist manipulation - and that class will know
> about the -i.
>
> > unsigned int required:
> > 1;
>
> This option should go away completely. Instead we should replace the
> ACLUserData instance with another that is also derived from ACLData, and
> that implements the behaviour of REQUIRED. That will remove a bunch of
> 'if' clauses in the ACLUserData class.
>
> > }
> >
> > flags;
> >
> > private:
> > static MemPool *Pool;
> > };
> >
> >
> > We could rewrite this to drop any internal grouping of members within
> > classes, but I prefer not.
>
> IMO it's not about dropping the grouping, its that the specific members
> actually control behaviour - and that is almost always a perfect
> scenario for the user of a strategy or state (the insensitive flag), and
> for polymorphism (i.e. ACLRequiredDATA).
>
> Rob
--
Henrik Nordstrom <[EMAIL PROTECTED]>
MARA Systems AB, Sweden
