[OTR-dev] Self-referencing structure

Twan Fox twanfox at gmail.com
Thu Apr 13 23:38:54 EDT 2006


mike davis wrote:
> this is always a bit of a pain, you run into this a bit with linked 
> list stuff..
>
> im curious though, because i got this code to build with vc 6.0 before:
>
> typedef struct pending_connection{
> char        cookie[SLINK_COOKIE_SIZE];
> int        socka;
> pthread_t       threadid;
> struct pending_connection  *pNext;
> struct pending_connection  *pPrev;
> }pending_connection;
>
> which vc++ 6.0 seems to think is a perfectly valid syntax
>>
>> typedef struct fingerprint {
>>    struct fingerprint *next;          /* The next fingerprint in the 
>> list */
>>    struct fingerprint **tous;         /* A pointer to the pointer to 
>> us */
>>    unsigned char *fingerprint;        /* The fingerprint, or NULL */
>>    struct context *context;           /* The context to which we 
>> belong */
>>    char *trust;                       /* The trust level of the 
>> fingerprint */
>> } Fingerprint;
>>

The issue is not so much with the VS.NET 2003 being incapable or 
unwilling to understand the whole notion of a self-referenced structure. 
The issue relates to the conflict between the 'struct fingerprint' 
structure and the 'unsigned char *fingerprint' line. For a C++ compiler, 
that basic syntax is grounds for a constructor function. As in:

class A {
    A::A;      // This would generate the invalid constructor function
    A::A();   // This is proper syntax for a constructor function
}

ref: http://msdn2.microsoft.com/en-us/library/77e603b6.aspx

What is terribly stupid about this issue is the notion that VS.NET 2003 
seems to believe that a struct is somehow the same as a class, and 
should imply that any member that shares the same name as the structure 
is a constructor function.

Because I wound up having issues rebuilding my plugin from scratch, 
setting out to make use of the Windows Template Library for the UI, this 
problem came up as well as a failure to link in the libotr library I had 
made. Ultimately, and I think this might've taken care of my problem had 
I done it first, doing the following would have allowed me to merge a 
library written in C to a project written in C++

extern "C" {
#include <userstate.h>
#include <proto.h>
}

This would have told VS that the headers are true "C" syntax and should 
be treated as such. This also allowed me to link the library I built for 
libotr v3.0.0 into the resulting .dll from my project.

Seems, as I kind of expected, this is a case of programmer error, with 
the programmer being me.

Thanks for the feedback and assistance.

- Twan



More information about the OTR-dev mailing list