I'm sorry to insist on this point but, in general, maybe you should consider having a function that provides the
sizeof() each opaque structure/type of the APR (maybe not all of them, but at least some).
That would let the user play with the opaque types without breaking the interest
I don't think that there is any reason to not have a sizeof()
function, other than any code that does play with the pointers will
be non-portable code. The reason that I originally went with opaque
data structures (I did it before giving the code to the ASF), was that
most of the structures are
Sorry I didn't explain myself very well.
I don't wan't to play with pointers, of course, a single sizeof won't allow me
to do much more then a memcpy().
For example ( innocently :p ) :
struct mystuct {
apr_pool_t p;
...
} myvar;
apr_pool_t p;
apr_pool_create(p, NULL);
Christopher Key wrote:
Yann wrote:
Sorry I didn't explain myself very well.
I don't wan't to play with pointers, of course, a single sizeof won't
allow me to do much more then a memcpy().
For example ( innocently :p ) :
struct mystuct {
apr_pool_t p;
...
} myvar;
apr_pool_t p;
Yann wrote:
Sorry I didn't explain myself very well.
I don't wan't to play with pointers, of course, a single sizeof won't
allow me to do much more then a memcpy().
For example ( innocently :p ) :
struct mystuct {
apr_pool_t p;
...
} myvar;
apr_pool_t p;
apr_pool_create(p, NULL);
On 6/6/08, Ryan Bloom [EMAIL PROTECTED] wrote:
I don't think that there is any reason to not have a sizeof()
function, other than any code that does play with the pointers will
be non-portable code. The reason that I originally went with opaque
data structures (I did it before giving the code
Branko Čibej wrote:
Yann wrote:
Sorry I didn't explain myself very well.
I don't wan't to play with pointers, of course, a single sizeof won't
allow me to do much more then a memcpy().
For example ( innocently :p ) :
struct mystuct {
apr_pool_t p;
...
} myvar;
apr_pool_t p;
Erik Huelsmann wrote:
On 6/6/08, Ryan Bloom [EMAIL PROTECTED] wrote:
I don't think that there is any reason to not have a sizeof()
function, other than any code that does play with the pointers will
be non-portable code. The reason that I originally went with opaque
data structures (I did it
On Fri, Jun 6, 2008 at 9:18 AM, Yann [EMAIL PROTECTED] wrote:
Erik Huelsmann wrote:
On 6/6/08, Ryan Bloom [EMAIL PROTECTED] wrote:
I don't think that there is any reason to not have a sizeof()
function, other than any code that does play with the pointers will
be non-portable code. The
Christopher Key wrote:
Yann Lavictoire wrote:
Big snip
Ok, given your most recent post, I can see what you're doing now. I
also think a mail client somewhere along the way had borken you're
original code slightly, did you mean,
struct {
...
} myvar;
apr_pool_t *p;
This still seems like
Yann wrote:
Sorry I didn't explain myself very well.
I don't wan't to play with pointers, of course, a single sizeof won't
allow me to do much more then a memcpy().
For example ( innocently :p ) :
struct mystuct {
apr_pool_t p;
...
} myvar;
apr_pool_t p;
apr_pool_create(p, NULL);
On Fri, Jun 6, 2008 at 5:10 PM, Yann [EMAIL PROTECTED] wrote:
Christopher Key wrote:
[...]
Ryan Bloom wrote:
If this is what you really want/need, then I would suggest focusing on
a patch that implements this functionality.
Ryan
OK, I can try to do that although I feel some sarcasm in
I agree with Sander, this should be relatively easy to implement using
parent relationships. And, I didn't intend sarcasm. I really meant
that if you have a feature that APR is missing, it is better to
implement it inside APR, rather than implement a wrapper around the
existing concept.
Ryan
Yann wrote:
Branko Čibej wrote:
Yann wrote:
Sorry I didn't explain myself very well.
I don't wan't to play with pointers, of course, a single sizeof
won't allow me to do much more then a memcpy().
For example ( innocently :p ) :
struct mystuct {
apr_pool_t p;
...
} myvar;
14 matches
Mail list logo
