2014-02-06 4 views
-3

하나의 파일에 클래스를 만들고 많은 파일에서 해당 클래스를 사용하려고합니다. 나는 매우 혼란 스럽다 ... 나는 을하지 않는다.은 반 파일을 하나의 파일로, 반을 다른 파일로 갖는 지저분한 코드를 원한다.하나의 파일에서 많은 클래스를 사용하십시오

app_core.cpp : (여기에 우리는 클래스가)

class s1 
{ 
    private: 
     int gx; 

    public: 
     int gx(int x,int y) 
     { 
      gx = x; 
     } 
}; 

app1.cpp : (여기에 우리는 클래스를 사용)

#include "app_core.cpp" 
class s1; 

int show() 
{ 
    s1 new_s; 
    cout << new_s.gx(8, 7); 
} 

app2.cpp : (여기에 우리는 클래스를 사용)

#include "app_core.cpp" 
class s1; 

int show() 
{ 
    s1 new_s; 
    cout << new_s.gx(18, 17); 
} 

위와 같은 것을 보관하는 방법 은요?

+4

왜 헤더를 사용하지 않습니까? – JBL

+0

이것은 좋은 습관이지만 내 문제를 해결하지는 못합니다. – JoeFrom

+0

'include <>'명령으로 .cpp 파일을 절대 포함하지 마십시오 – deW1

답변

2

C++에서 #include를 사용하면 포함 된 파일은 해당 지시문 대신 "붙여 넣기"됩니다.

번역 단위이라는 개념이 있습니다.이 단위는 컴파일되고 향후 링크 시간에 다른 단위에서 참조 될 수있는 코드 단위를 나타냅니다.

원하는 것은 번역 단위를 작성하고 다른 번역 단위에 해당 데이터에 액세스하는 방법에 대한 정보를 제공하는 것입니다. 그것이 헤더 파일의 목적입니다.

은 .H 파일 (.H 규칙에 따라, 당신은 당신이 원하는대로를 호출 할 수 있습니다)

파일

class s1 
{ 
    private: 
     int gxd; 

    public: 
     int gx(int x,int y) 
     { 
      gxd = x; 
      return x; 
     } 
}; 

s1class.h 및

APP1 같은 선언의 집합입니다. CPP :

#include"s1class.h" 

//... use s1 class 

app2.cpp :

#include"s1class.h" 

//... use s1 class 

그냥 한 가지주의 사항 : 결코 당신이 (그들은 일관 선언있어 한 바와 같이) 무언가를 원하는대로 One Definition Rule, 당신은 몇 번을 선언 할 수 있습니다 위반해야하지만 한 번 상징 이상 정의 할 수 없습니다 (예를 들어, 함수). (작은 메모 : #pragma 지시어와 유사한 항목을 사용하면 기호를 두 번 이상 다시 선언하지 않아도되고 여러 위치에 머리글을 여러 번 포함 할 때 더 쉽게 사용할 수 있습니다.)

위의 코드에서 "gx"함수는 헤더 파일에 정의되어 있습니다.이 함수는 사용되는 변환 단위당 한 번만 존재해야합니다.

이 경우에는 app1.cpp 및 app2.cpp에 대한 번역 단위를 만드는 데 사용됩니다. ODR을 위반해야합니다. 맞습니까? 클래스의 멤버 함수가 암시 적으로 인라인 인데, 이는 호출자의 본문에 "꿰매어 져"따라서 호출자의 ID의 일부로 통합됨을 의미합니다.

s1class을 :

대안은 헤더 파일 물건을 선언하고 는 관련 CPP 파일에 그들에게를 구현하는 것입니다.시간

#pragma once 

class s1 
{ 
private: 
    int gxd; 

public: 
    int gx(int x,int y); 
}; 

s1class.cpp

#include "s1class.h" 

int s1::gx(int x,int y) 
{ 
    gxd = x; 
    return x; 
} 

위와 같이 진행 : 단지 (기호가 해결 될 때) 연결시에 사용하기 위해 헤더 파일을 포함하여.

+0

첫 번째 예제를 사용하여 어떤 단점이 있습니까? – JoeFrom

+0

"인라인"할 때 항상 이점과 단점이 있습니다 : http://stackoverflow.com/a/145841/1938163. 요약하면 함수를 인라이닝하지는 않지만 컴파일러는 최종 결정을 내릴 것입니다. 그냥 "인라인 가능"으로 표시하는 것입니다. 인라인되면 코드가 더 빨라질 것입니다 (함수를 호출 할 필요가 없으므로 즉시 실행합니다).하지만 크기가 커집니다 (한 곳에서 함수 대신 중복 코드가 더 많음). 성능에 중요하지 않은 작은 메서드가있을 때 일반적으로 인라인 함수를 이와 같이 표시합니다. –

+0

마지막 질문 : 예제 1을 사용할 수있는 경우 예제 2를 사용하는 이유는 파일 크기가 문제가되지 않는다는 것입니다. 예 2는 더 복잡하고 작업에 많은 시간을 필요로합니까? – JoeFrom

1

헤더를 사용할 수 있습니다. app1.h :

class s1 
{ 
    private: 
     int gx; 

    public: 
     int gx(int x,int y) 
     { 
      gx = x; 
     } 
}; 

app2.cpp :

#include"app1.h" 
//... 

또한 파일 app1.h이 컴파일 된 파일을해야
또는 다른 추가 주소와 같은

#include "D:\app1.h" 
//... 

경우 app1.h 파일은 D : 드라이브에 있습니다.

0

Firs t, 그것은 입니다. cpp 파일을 포함하는 나쁜 스타일입니다. 이론적으로 app_core.cpp의 모든 코드를 app_core.h와 같은 헤더에 쓸 수 있습니다. 이 방법이 대부분의 경우에 효과적이지만 컴파일 시간이 불필요하게 길어질 수 있습니다. 정말로 수행하고 싶다면 두 .cpp 파일에서 class s1;을 제외해야합니다.

헤더와 소스 사이의 구분이 "지저분한 코드"의 의미라면 미안하지만 그렇지 않습니다. 일반적인 방법은 없습니다.

+0

느린 컴파일 이외에 어떤 단점'이론 상으로는 app_core.cpp의 모든 코드를 app_core.h와 같은 헤더에 쓸 수 있습니까? – JoeFrom

+0

이것은 기본적으로 주요 단점입니다. 또한 클래스 본문 내에 정의 된 모든 함수는'inline'으로 암시 적으로 선언되지만 그다지 문제가되지는 않습니다. 이것은 컴파일러에 대한 힌트 일뿐입니다. 그러나 컴파일러와 링커가 해당 변수의 단일 인스턴스가 정의 된 위치를 알 수 있도록 기본적으로 .cpp 파일에서 선언되어야하므로 정적 멤버 변수를 정의하는 데 문제가 발생합니다. – anderas

0

헤더 파일을 작성하십시오.

app1.h

class s1 
{ 
    private: 
     int gx; 

    public: 
     int gx(int x,int y) 
}; 

app1.cpp

#include "app1.h" 

int s1::gx(int x,int y) 
{ 
    gx = x; 
} 

app2.cpp 나는 이것이 당신의 "문제"를 해결할 수 있다고 생각

#include "app1.h" 
// your code that calls s1 methods 
0

: 헤더에 클래스를 넣어 헤더에 을 구현합니다 (예 : 라이브러리의 경우 "헤더 전용"이라고 함).

#ifndef CLASS1_H #define CLASS1_H class s1 { private: int gx; public: int gx(int x,int y) { gx = x; } }; #endif //CLASS1_H 

그런 다음 모든 단지 #include "Class1.h".cpp이 필요했습니다.

하나의 파일에 하나의 클래스가 있습니다 (선언과 구현이 분리되어 있지 않음).다만주의 할 때로는 편리하고, "헤더 전용"코드를 사용하는 단점을 가지고있는 동안 :

  • 구현은 이제 구현에 어떤 변화가 당신이 재해야 함을 의미한다는 것을 의미 선언에 연결되어 이 헤더를 포함하는 코드를 컴파일하십시오.

  • 컴파일 단위가 인터페이스가 아니라 번역 단위의 모든 구현을보아야하기 때문에 컴파일에 더 많은 시간이 걸립니다.

당신의 믿음과는 달리, 하나의 헤더와 하나의 구현 파일을 갖는 것이 지저분하지는 않습니다. 그것의 장점을 가지고 널리 사용되는 연습입니다. 하지만 네, 단점 중 하나는 두 개의 파일을 관리해야한다는 것입니다.

관련 문제