C++ 공용 멤버를 다음과 같이 정의한다면 어떨까요?

HDNua의 이미지

Cocos2D-X를 이용해 게임 프로그래밍을 하던 도중에 재미있는 생각이 들었습니다.
C++의 정적 필드, 즉 공용 필드를 만드는 새로운 방법에 관한 것인데 아래 코드를 봐주세요.

-----
Entity.h

#ifndef __ENTITY_H__
#define __ENTITY_H__
 
#include <string>
class Entity {
	int value;
public:
	const std::string toString() const;
};
 
#endif

-----
Entity.cpp

#include "Entity.h"
#include <sstream>
 
static struct EntityField {
	friend class Object;
	int commonValue;
public:
	EntityField() : commonValue(0) {}
} Field;
 
const std::string Entity::toString() const {
	std::stringstream ss;
	ss << "Object common: " << Field.commonValue << ", instance: " << value;
	return ss.str();
}

-----
main.cpp

#include <iostream>
#include "Entity.h"
 
int main(void) {
	Entity *entity = new Entity();
	std::cout << entity->toString().c_str() << std::endl;
	return 0;
}

-----

파일 안에서만 접근 가능한 구조체 변수를 만들고 이 변수에 접근하는 식입니다.
싱글톤 객체같이 단 하나만 인스턴스가 생성되는 객체라면 필드로 사용할 수도 있어서 헤더 파일과 소스 파일을 왕복할 필요가 없습니다.

이런 형태의 정의가 문제가 될 수 있을까요? KLDP 여러분의 의견이 궁금합니다.

klyx의 이미지

특별한 점이 없어 보이는데 어떤 의도의 질문인지 잘 모르겠습니다.
굳이 하나 지적하면 struct는 기본 접근 제한이 public이기 때문에 여기서 friend class Object;는 쓸모없는 구문이라는 것과,
어차피 .cpp안에서 공유하는 객체에 대해서는 접근 제한을 두는 것 자체가 의미가 없을 수도 있다는 것 정도입니다.

HDNua의 이미지

Cocos2D-X로 개발을 할 때 필드를 변경할 때마다 헤더 파일과 소스 파일을 왔다갔다하는 게 귀찮아서, 소스 파일에 넣어보면 어떨까 해서 올려봤습니다.
질문으로 올리는 건 성격이 다른 것 같아, 일단 토의 게시판에 올려서 이 아이디어가 어떤지 의견을 들어보고 싶었습니다.
혹 C++에서 전역에 구조체를 생성하면 특별한 상황에서 오류가 발생할 수 있다거나..

근데 다시 생각해보니 별 소득이 없을 질문이었던 것 같네요.
답변 감사합니다.

저는 이렇게 생각했습니다.

klyx의 이미지

'필드를 변경하다'라는 것이 어떤 것인지 잘 모르겠지만, 함수의 구현이 변경될때 해더를 건드리고 싶지 않다는 뜻이라면 pimpl idiom을 찾아보시는게 좋을 듯합니다.

HDNua의 이미지

찾아보겠습니다. 감사합니다.

저는 이렇게 생각했습니다.