apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apr/include apr_general.h
Date Tue, 02 Jan 2001 14:51:52 GMT

> > > > > Then write apr_file_get_pool(). Not a cast and an assumption.
> > > > 
> > > > That also means that we have to write apr_socket_get_pool and
> > > > apr_lock_get_pool and apr_mmap_get_pool, etc.
> > > 
> > > Yup.
> > 
> > That is ugly and just plain wrong.
> It is also standard design practice for use of incomplete types.
> You should be following it or not using incomplete types.  I personally
> find it ugly and don't use incomplete types.

And it makes sense for most fields in an incomplete type, and we do
it.  That's fine.  For a field that we have defined as always being there,
and always as the first field, it isn't necessary.  Oh well, I have given
Greg the go ahead to do whatever he wants.

> > If I understand your problem with this, you are afraid that somebody will
> > use this macro on a variable that is either not an APR variable, or is an
> > APR type but is not one of the incomplete types.  Well, this can be fixed
> > multiple ways.  Just require that every APR structure has a pool at the
> > beginning of the structure, whether it is complete or not.  
> I would argue that none of the APR types should have a pool, but I
> don't have that much time on my hands.

You would also have a fight on your hands.  :-)  I have tried to remove
the pools from APR recently, just so that I could abstract out some of the
memory allocation stuff.  It isn't as easy as you might think.  I am still
working through it though.


Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131

View raw message