typedef 로 선언한걸 갑자기 인식을 못하네요...T.T

프리프로세싱만 한 결과를 보시면 도움이 될듯..

소스는 변함이 없더라도 환경이 바뀌면 뭔가 상수들이 붙는게
안붙을 수 있거든요.

프리프로세싱만 한 결과에서 저 정의문 전후로 보심이..

#ifndef ___somthing___
#define ___somthing___

typedef ...

struct ...
{..};

#endif

이런것 때문은 아닌가요?

parse error라면 아니겠지만 혹시나 해서요
양쪽파일에서 서로 include하고있다면 그런일이 없을것같기도하네요

aaa.h

#ifndef __AAA_H__
#define __AAA_H__
                                                                                
typedef struct _aaa   Aaa;
                                                                                
#include "bbb.h"
                                                                                
                                                                                
struct _aaa
{
        Bbb *    b;
};
                                                                                
#endif

bbb.h

#ifndef __BBB_H__
#define __BBB_H__
                                                                                
typedef struct _bbb   Bbb;
                                                                                
#include "aaa.h"
                                                                                
                                                                                
struct _bbb
{
        Aaa *     a;
};
                                                                                
#endif                                                                            

이렇게 해서 다른곳에서 aaa.h를 include한다면 preprocessor에 의해 다음과 같은 알맞은 코드가 생겨나겠죠?

typedef struct _aaa   Aaa;
typedef struct _bbb   Bbb;

struct _bbb
{
        Aaa *     a;
};

struct _aaa
{
        Bbb *    b;
};

그러고 보니 preprocessor에 의해 생겨난 코드는 씨언어를 처음에 배울때 봤던 코드와 비슷한거 같네요..

두개의 함수가 서로를 재귀적으로 호출하며 정의하는... 선언문과 정의문을 구별하여 정의하면서 그 위에 선언문만 써주면 된다고...

이 해결은 아주 간단합니다. 선언부에서는 typedef 심볼을 안쓰면 되죠.

struct _aaa 
{ 
        struct _bbb *    b; 
};
struct _bbb 
{ 
        struct _aaa *     a; 
}; 

typedef struct _aaa   Aaa; 
typedef struct _bbb   Bbb; 

이렇게 하면 인클루드에 전혀 문제를 겪지 않습니다. 단지 struct 이름과 typedef 이름이 서로 대응되는 일관된 규칙만 가지면 되죠.

원래 만들지 않는다는 말씀에는 문제가 있습니다. 3차원 입체를 컴퓨터상에서 구현하는 솔리드 모델 자료 구조중 매우 유명한 Half-edge 자료 구조 및 Radial edge 자료 구조는 cross reference 를 매우 빈번히 사용합니다.

typedef struct blah { 
  ... // 
}tagBlah,*ptr_tagBlah,**pptr_tagBlah;

이렇게 하면 좀 편하게 보입니다.

//template < class ST  > // template and typedef is not collateral in applying 
typedef struct blah { 
  int	a; 
  template < class ST > 

     ST*	  wrapped_Instance() { 
	
                ST* p_ST = new p_ST ;
	return   p_ST; 
  }
  virtual test(){
	  cout << " haha" <<endl; 
  }
}tagBlah,*ptr_tagBlah,**pptr_tagBlah, aTen_tagBlah[10];

<주의: template function 맞는지. 저런식으로 되는 게 gcc 3.2 에서

가능할지 모르겠습니다. 저는 않되는데 .

저런식이라면 어차게 되지않을런지요. 저건 :oops:

class 와 namespace 를 가지고 구역을 나눠주시면 코드가 날려있어도

어느정도 헤더 충돌이나 뭐나 괜찮을것 같군용..

class CA; // forward declaration

typdef struct tag; // 이렇게 하는거도 좋지만,...

위의 경우는 크로스 레퍼런스의 예가 아닌듯 하군요. 크로스 레퍼런스는 header include에서 발생하는 문제(컴파일타임)이지 런타임시에 고려되는 것은 아닙니다. 탐색하고 그런것과도 전혀 다른 이유죠. 위의 것은 그냥 어떤 데이터구조체(혹은 클래스)에 탐색을 피하기 위해서 tail pointer나 key mark 를 달아주는 것에 대한 예이군요.

그리고 어쩔 수 없는 경우에는 사용해야 하는 것에는 이의가 없습니다. 어쩔 수 없다는데 당연히 사용해야겠죠. 되도록이면 필수적이지 않으면 피하는게 좋을 뿐이죠. 정 안되면 하나의 헤더파일로 만들어서 서로가 서로를 include하는 것을 막아주면 되겠죠. 위에 말씀하신대로요.

자료구조상에서 역참조탐색을 피하기 위해서 사용하는 부분이군요.

halfedge는 모르겠지만, graph이론에서 주로 사용하는 코딩스타일이군요. CAD에서 사용한다니까, 아마도 면적이나 그런것들과 관계가 있나보군요..

그러고 보니 정말 원 쓰레드와 많이 벗어나는것 같군요. 8)

원래의 쓰레드와는 다소 어긋난 얘기지만, 몇가지 사항에 대해 지적하고자 합니다.

cross-refference가 정확히 무슨 뜻인지는 모르겠지만, 헤더 파일끼리의 상호 참조만을 뜻하는 것이라면 맞는 말입니다. 그러나 상호 참조 구조체를 뜻하는 것이라면 틀린 말입니다. 또한 상호 참조 구조체는 여러 곳에서 상당히 빈번하게 사용되고 있습니다.

struct foo { int data1; struct bar *next1; };
struct bar { int data2; struct foo *next2; };

위의 코드는 분명히 적법한 코드입니다. (C언어 펀더멘탈 p.608 인용)

하지만 그런 것이 표준(C90+AMD1을 기준으로)에 위배되는 코드는 아닙니다. 다음의 코드는 분명히 적법한 코드입니다. (C언어 펀더멘탈 p.605 인용)

typedef struct foo user_type;    /* incomplete type */
/* ... */
struct foo {
/* 맴버 선언 생략 */
};    /* completed */

만약 위의 코드가 제대로 컴파일이 안된다면, 해당 컴파일러의 버그이거나 ANSI C(혹은 ISO C) 표준을 제대로 지원하지 못하는 오래된 컴파일러일 가능성이 큽니다.

_와 그 뒤의 대문자로 시작하는 명칭 또는 __로 시작하는 명칭은 모두 구현체에 예약되어 있는 명칭입니다. (C99 7.1.3p1) 따라서 충돌 가능성이 있으며, 사용자는 일반적으로 사용하지 않는 것이 원칙입니다. 저같은 경우 macro guard용 매크로 상수 이름으로는 plsj_AAA_h와 같은 형식을 사용합니다. Visual C++에서 자동으로 생성한 코드에는 macro guard로 __AAA_H__와 같은 이름을 사용하는 것 같은데, 별로 바람직한 방식은 아닙니다.