프로젝트를 컴파일 할 때 다음 오류가 발생합니다.
./PC.h:15:12: error: unknown type name 'InstructionMemory'
PC *new_pc(InstructionMemory *memoria);
^
./PC.h:17:1: error: unknown type name 'InstructionMemory'
InstructionMemory *get_memory(PC *programCounter);
^
2 errors generated.
In file included from main.c:5:
./InstructionRegister.h:7:36: error: unknown type name 'BankRegister'
int opera(InstructionRegister *IR, BankRegister *bank);
하지만 이건 말이 안 돼요. 파일을 보면 헤더 파일이기 때문에 #include를 헤더 파일에 사용할 수 없다는 것을 알고 있습니다. 그래서 나는 내가 뭘 잘못하고 있는지 모른다.
내 PC.h 파일의 내용이 있습니다.
typedef struct PC PC;
PC *new_pc(InstructionMemory *memoria);
int getpc(PC *programCounter);
InstructionMemory *get_memory(PC *programCounter);
char *fecth(PC *programCounter);
char *linea_actual(PC *programCounter);
다음 메이크 파일을 사용하여 컴파일합니다.
CC = gcc
CFLAGS=-I
DEPS = ALU.h InstructionRegister.h Rebasing.h BankRegister.h MemoryInstruction.h ControlUnit.h PC.h
run: exect
./exect $(EX)
%.o: %.c $(DEPS)
$(CC) -c $< $(CFLAGS)
exect: ALU.c InstructionRegister.c Rebasing.c BankRegister.c MemoryInstruction.c main.c ControlUnit.c PC.c
gcc -o exect InstructionRegister.c Rebasing.c BankRegister.c MemoryInstruction.c main.c ControlUnit.c PC.c -I.
clean:
rm -f *.o
그래서 나는 당신이
#include헤더 파일에 사용할 수 없다는 것을 알고 있습니다.
당신은 착각합니다. 헤더 파일에 몇 가지 include 지시문 을 사용할 수 있으며 자주 사용해야하며 원할 수도 있습니다.
일반적인 작은 C 프로젝트 (예 : 총 10 만 줄 미만의 C 코드)는 종종 하나의 공통 헤더 파일을 가질 것입니다 . 예를 들어 myheader.h일반적으로 include 가드로 시작 하고 여러 시스템이 포함합니다.
#ifndef MYHEADER_INCLUDED
#define MYHEADER_INCLUDED
// some system includes
#include <stdio.h>
#include <stdlib.h>
/// your type declarations
enum foo_en { /* blablabla */ };
struct bar_st { /* blablabla */ };
typedef struct bar_st Bar;
/* etc... */
/// your global functions
extern int myglobfun(int, int);
/* etc...*/
/// your global variables (have only a few of them)
extern Bar*my_bar;
/* etc... */
#endif /*MYHEADER_INCLUDED*/
이것은 프로젝트를 구성 할 수있는 하나의 가능성 일뿐입니다. 어떤 사람들은 #include모든 번역 단위 (예 : C 소스 파일)에서 자신의 일부 헤더 앞에 많은 헤더 파일과 명시 적으로 시스템 헤더 를 갖는 것을 선호합니다 .
단일 공통 헤더를 갖는 이점은는 Makefile코딩이 간단하고 공통 헤더를 미리 컴파일 할 수도 있다는 것 입니다. 단점은 struct헤더의 모든 변경 (예 : 공통 필드 추가 )이 make모든 것을 다시 컴파일 해야한다는 것입니다 (작은 프로젝트의 경우 큰 문제가 아님).
또는 많은 헤더 파일을 가질 수 있습니다. 그런 다음 포함 가드 (단일 공통 헤더의 경우 실제로 쓸모가 없지만 해를 끼치 지 않음)를 사용하고 다중 포함과 관련된 규칙을 정의해야합니다. 종종 헤더 파일 자체에 다른 필요한 헤더 파일이 포함되거나 포함되었는지 확인합니다.
// file "myheaderone.h"
#ifndef MYHEADERONE_INCLUDED
// check that "myotherheader.h" has been included
#ifndef MYOTHERHEADER_INCLUDED
#error myotherheader.h should have been #include-d
#endif
//// etc
또는 #include "myotherheader.h"시작 부분에 코드를 작성할 수 있습니다.myfirstheader.h
여러 헤더가있는 경우, 당신은 복잡한 필요 Makefile참조하면 오히려 종속성을 생성 할 수 있습니다 이 . 그것은 좋아 하고 친구 를 위해 몇 가지 전 처리기 옵션 을 사용합니다 .gcc-M
BTW, 당신 Makefile은 틀 렸습니다. 하드 코딩하지 말고를 cc사용 $(CC)하십시오. 수 있는지 물어 GCC를 모든 경고 및 디버그 정보 (예에 대한 CFLAGS= -Wall -g). GNU 메이크에 대해 알아 규칙의 카탈로그를 실행하여 make -p. 그리고 당신은 CFLAGS= -I정말 잘못된 것입니다, 당신은 할 수 있습니다 CFLAGS= -I. -Wall -g부터 -I해야한다 항상 디렉토리 뒤에는.
추신. 사용 gcc하는 경우 항상-Wall 그것을 전달 하는 습관을 들이십시오. 매우 자주 (그리고 확실히 당신의 경우) 당신은 또한 원합니다 -Wextra(더 많은 경고를 받고 싶습니다 . 컴파일러 경고는 당신의 친구이며 당신이 그들 중 하나도 없을 때까지 코드를 개선해야 함을 기억하십시오) 그리고 아마도 -g( -g디버거 를 사용할 수 있으려면 ) . 벤치마킹을 위해 컴파일러에게 최적화를 요청하십시오 (예 : -O1또는 사용 -O2 -mcpu=native).
-H전 처리기 옵션 에 유의gcc 하십시오. 포함 된 모든 파일을 표시하도록 요청 합니다. 때로는 (예를 들어, 일부 불쾌한 매크로를 디버깅하기 위해) 번역 단위의 전처리 된 형태를보고 싶을 때 사용 gcc -C -E하십시오.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다