[computer-go] C++: #include vs .h files

[Peter Drake]

We have a winner!

Sorry for the confusion. I grew up in a world where the compiler is  
willing to make more than one pass. :-|

Thanks,

Peter Drake
Assistant Professor of Computer Science
Lewis & Clark College
http://www.lclark.edu/~drake/




On Aug 9, 2006, at 3:34 PM, Weston Markham wrote:

> You can "forward declare" one (or both) of the classes in the header
> for the other:
>
> in BitBoard.h:
>
> class BoardState;
> class BitBoard {
>    BoardState* state_;
> };
>
> ... the catch is that when the forward-declared class is mentioned in
> that header file, the type is not "complete", which basically means
> that the compiler does not know its size.  If the class being defined
> declares storage for the forward-declared one, you will have problems.
> But of course, this sort of relationship could not be circular
> anyway, so you can usually resolve such issues:
>
> struct Foo;
> struct Bar;
> struct Foo {
>    Bar bar;  // not legal, because Bar's size is not known.
> };
> struct Bar {
>    Foo foo; // also not legal, and at this point, each structure must
> recursively contain itself!
> };
>
> Weston
>
> On 8/9/06, Peter Drake <drake at lclark.edu> wrote:
>>
>> That mostly worked, but I have a more subtle problem.
>>
>> I have two classes, BitBoard and BoardState. Each needs to know  
>> about the
>> other because the other appears in field declarations or method  
>> signatures.
>> If I put
>>
>> #include "BoardState.h"
>>
>> in BitBoard.h and vice versa, there is obviously a circularity.  
>> How to get
>> around this?
>>
>>
>>
>> Peter Drake
>> Assistant Professor of Computer Science
>> Lewis & Clark College
>> http://www.lclark.edu/~drake/
>>
>>
>>
>>
>>
>> On Aug 9, 2006, at 3:02 PM, Peter Drake wrote:
>> Okay, I'll try cleansing my .h files of definitions. Stay tuned.
>>
>> (Is it okay to declare object fields in .h files?)
>>
>>
>> Peter Drake
>> Assistant Professor of Computer Science
>> Lewis & Clark College
>> http://www.lclark.edu/~drake/
>>
>>
>>
>>
>>
>> On Aug 9, 2006, at 2:55 PM, Weston Markham wrote:
>>
>> Most likely, you have a definition in a .h file.  This can be legal,
>> but you may need to mark it "inline".  Any chance you can post a
>> concise example?  (what minimal declarations & definitions in which
>> files will demonstrate the problem)
>>
>> Weston
>>
>> On 8/9/06, Peter Drake <drake at lclark.edu> wrote:
>>
>> Thanks for the quick response on the array passing. I think I get  
>> it now.
>>
>> I'm having a devil of a time trying to divide my classes  
>> between .h and .cpp
>> files. Specifically, if I have the same #include in several .cpp  
>> files, I
>> get complaints about redundant definitions from the linker. I can  
>> avoid this
>> by putting everything in the .h files (except for one .cpp file),  
>> but then I
>> can't define classes that depend on each other.
>>
>> Any advice?
>>
>>
>> Peter Drake
>> Assistant Professor of Computer Science
>> Lewis & Clark College
>> http://www.lclark.edu/~drake/
>>
>>
>>
>>
>>
>> _______________________________________________
>> computer-go mailing list
>> computer-go at computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>>
>>
>> _______________________________________________
>> computer-go mailing list
>> computer-go at computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>> _______________________________________________
>> computer-go mailing list
>> computer-go at computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>> _______________________________________________
>> computer-go mailing list
>> computer-go at computer-go.org
>> http://www.computer-go.org/mailman/listinfo/computer-go/
>>
>>
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://computer-go.org/pipermail/computer-go/attachments/20060809/0f75876e/attachment.htm