apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko Čibej <br...@xbc.nu>
Subject Re: apr_dbd: a generic SQL wrapper
Date Fri, 10 Dec 2004 05:48:13 GMT
Nick Kew wrote:

>On Fri, 10 Dec 2004, Branko �^Libej wrote:
>
>  
>
>>Nick Kew wrote:
>>
>>    
>>
>>>/* These are opaque structs.  Instantiation is up to each backend */
>>>#ifndef APR_DBD_INTERNAL
>>>typedef struct apr_dbd_t apr_dbd_t;
>>>typedef struct apr_dbd_transaction apr_dbd_transaction;
>>>typedef struct apr_dbd_results apr_dbd_results;
>>>typedef struct apr_dbd_row apr_dbd_row;
>>>typedef struct apr_dbd_prepared apr_dbd_prepared;
>>>#endif
>>>
>>>
>>>      
>>>
>>If these are truly internal, they shouldn't be declared in the public
>>header, even #ifdefed out. That's a small nit, but I thought I'd mention
>>ti since it leaped out at me.
>>    
>>
>
>They're not internal.  Applications need to know them all to pass to
>functions in the API.  It's the instantiations that are internal.
>
>The #ifndef is because *drivers* have to declare them before
>#including apr_dbd.h.
>  
>
They don't have to declare them before including the header. This 
sequence is completely valid:

    typedef struct foo foo;

    struct foo {
       int bar;
    };

IOW, the typedef serves as a forward declaration of the structure. So 
that #ifdef can go away.

-- Brane



Mime
View raw message