일단 namespace는 중대형 프로젝트에서 타사 라이브러리를 자주 가져다 쓰는 경우 곧잘 발생하는 이름 충돌 문제를 해결하기 위해 도입됐습니다. 도입되기 전까지만해도 쓰자파와 쓰지말자파간에 입씨름이 대단했었으나, 결국 표준 라이브러리에 이름공간이 적용됨으로써 일단락 됐죠. 이후 개발되는 모든 언어에는 아예 이름 공간을 안쓰면 프로그램이 안되는 것들도 있습니다. 왜 그럴까요? 정말 윗분들 처럼 쓸데 없는것이라면.. 그냥 없애버리는게 나을텐데..?
namespace가 쓸데없다라고 말하는 사람들의 대부분은 대형 프로젝트를 경험해보지 못한 사람입니다. 대형 프로젝트를 경험했더라도, namespace 분할을 적절하게 하지 않았기 때문에 거추장스럽게만 느껴지는 경우겠죠.
-----------------
현대의 프로그램 세계는 모든것을 자체 개발하기엔 너무 덩치가 커졌습니다. 따라서 몇몇 라이브러리들은 구입해 사용하게 되는 경우가 많이 있는데요. namespace가 없는 A사와 B사의 라이브러리에 Tree라는 이름이 다음과 같이 나와있다고 해봅시다.
A사의 라이브러리중에
struct Tree {};
B사의 라이브러리중에
int Tree;
두개의 라이브러리는 호환되지 않는 이름의 충돌로 인해 컴파일이 안됩니다. 쉽게 말하자면, A사의 라이브러리와 B사의 라이브러리는 절대! 같이 쓸수 없는 라이브러리가 되는 것입니다.
이전에는 대개 라이브러리 함수 이름 앞에 특정한 패턴을 붙여서 이런 문제를 해결했죠 예를들어 acorpTree (A사의 Tree라는 뜻) 뭐 이런식으로요.. 그렇지만, 이런 경우 거의 대부분 읽기 어렵고 지저분한 소스를 만들어 내게 됩니다. 정리가 안되죠.
만약 A사와 B사가 namespace를 잘 정의해서 라이브러리를 구현했다면, 이런 문제를 깨끗하게 해결해 줍니다.
------------------
그럼 어떻게 namespace를 구현하느냐..
구현은 간단합니다. namespace로 정의할 것들을 블럭으로 묶으면 됩니다.
namespace A
{
struct Tree {};
}
namespace B
{ int Tree; }
-------------------
사용하는 측에서는 다음중 하나를 선택해 쓰면 됩니다.
1. using namespace A;
(의미 : 현재 소스 코드에 A사 라이브러리만 쓰이는경우, 이름충돌이 예상되지 않으므로, A에 있는 모든 이름들을 현재 소스의 범위내에 가져온다)
2. using A::Tree;
(의미 : 현재 소?코드에 A사와 B사의 라이브러리가 동시에 쓰이는데, 현재 블럭에서 사용할 Tree는 A사의 Tree 구조체이다)
3. B::Tree = 10;
(의미 : 현재 소스 코드에 A사와 B사의 라이브러리가 동시에 쓰이는데, 현재 블럭에서 두 회사의 라이브러리가 모두 섞여 쓰이므로 명시적으로 이름을 정해준다)
--------------------
이외에도, 이름공간에는 몇가지 까다로운 주의사항 및 고급 사용기법들이 있지만, 현 레벨에서는 이 정도로 충분하다고 봅니다.
윗분들의 답변을 보고.. 한심하다는 생각이 들어서 잔소리 좀 하고 가겠습니다. 우선 남들이 안쓰니깐 쓰지말라는건 말이 되지 않습니다. 전 오히려 namespace를 (적절히 잘) 쓰는 소스코드를 더 많이 봐왔는데요????
또, 어려운 소스를 쓰는 사람은 무조건 잘난척 하는 사람입니까? 천만에요. 그 소스를 만든 사람이 정말 잘난척을 하고 싶었는지의 여부는 물어보면 압니다. 잘난척 하기 위해 소스를 어렵게 만든 사람들은 그 용도를 정확히 알지 못합니다. 꼭 써야할 곳에 써야 하는데, 그러질 못하죠.
그런 잘난척(?) 하기위해 무조건 가져다 쓰는것도 문제가 됩니다. 불필요한 코딩 오버헤드가 발생하는데다, 오작동 할 우려가 크기 때문에요..
----------------------------
namespace가 어떻게 쓰일때 어떤 장/단점을 가지는지 명확히 판단하시고 쓰세요. 비단 namespace 뿐만 아니라, 다른 어떤 기술들도 마찬가지입니다.
** 우선 코어 엔진이나 라이브러리 개발자라면 namespace를 사용해 프로그래밍 하는 습관을 들이십시요. 물론 우리나라엔 게임 엔진을 파는 경우가 거의 없으니 해당사항은 없겠지만요.
** 반대로 그런 경우가 아니라고 하더라도, namespace의 사용법은 정확히 알고 있어야 합니다. 우리보다 뛰어난 프로그래머가 만들어 공개한 좋은 소스를 namespace를 몰라서 못쓴다면 좀 억울할테니까요..
잘쓰면 약이되고 잘못쓰면 독이 된다는 말씀 아시죠? namespace도 마찬가지입니다. 어떨때 왜 써야 하는지, 어떨때 왜 쓰지 말아야 하는지, 자꾸 생각하는 프로그래머가 되어야 합니다.
한 몇년 그만그만한 프로그래머로 지내다 결국 포기하는 사람들을 수도 없이 보아 왔습니다. 반대로, 정말 뛰어난 분들도 수없이 보아왔구요.. 그둘의 차이는, 편견없이, 솔직하게, 지적인 호기심을 가지고 사는 사람이냐 아니냐의 차이입니다. 부디 분발하셔서 좋은 프로그래머가 되시길 바랄께요.. 그럼..
namespace가 쓸데없다라고 말하는 사람들의 대부분은 대형 프로젝트를 경험해보지 못한 사람입니다. 대형 프로젝트를 경험했더라도, namespace 분할을 적절하게 하지 않았기 때문에 거추장스럽게만 느껴지는 경우겠죠.
-----------------
현대의 프로그램 세계는 모든것을 자체 개발하기엔 너무 덩치가 커졌습니다. 따라서 몇몇 라이브러리들은 구입해 사용하게 되는 경우가 많이 있는데요. namespace가 없는 A사와 B사의 라이브러리에 Tree라는 이름이 다음과 같이 나와있다고 해봅시다.
A사의 라이브러리중에
struct Tree {};
B사의 라이브러리중에
int Tree;
두개의 라이브러리는 호환되지 않는 이름의 충돌로 인해 컴파일이 안됩니다. 쉽게 말하자면, A사의 라이브러리와 B사의 라이브러리는 절대! 같이 쓸수 없는 라이브러리가 되는 것입니다.
이전에는 대개 라이브러리 함수 이름 앞에 특정한 패턴을 붙여서 이런 문제를 해결했죠 예를들어 acorpTree (A사의 Tree라는 뜻) 뭐 이런식으로요.. 그렇지만, 이런 경우 거의 대부분 읽기 어렵고 지저분한 소스를 만들어 내게 됩니다. 정리가 안되죠.
만약 A사와 B사가 namespace를 잘 정의해서 라이브러리를 구현했다면, 이런 문제를 깨끗하게 해결해 줍니다.
------------------
그럼 어떻게 namespace를 구현하느냐..
구현은 간단합니다. namespace로 정의할 것들을 블럭으로 묶으면 됩니다.
namespace A
{
struct Tree {};
}
namespace B
{ int Tree; }
-------------------
사용하는 측에서는 다음중 하나를 선택해 쓰면 됩니다.
1. using namespace A;
(의미 : 현재 소스 코드에 A사 라이브러리만 쓰이는경우, 이름충돌이 예상되지 않으므로, A에 있는 모든 이름들을 현재 소스의 범위내에 가져온다)
2. using A::Tree;
(의미 : 현재 소?코드에 A사와 B사의 라이브러리가 동시에 쓰이는데, 현재 블럭에서 사용할 Tree는 A사의 Tree 구조체이다)
3. B::Tree = 10;
(의미 : 현재 소스 코드에 A사와 B사의 라이브러리가 동시에 쓰이는데, 현재 블럭에서 두 회사의 라이브러리가 모두 섞여 쓰이므로 명시적으로 이름을 정해준다)
--------------------
이외에도, 이름공간에는 몇가지 까다로운 주의사항 및 고급 사용기법들이 있지만, 현 레벨에서는 이 정도로 충분하다고 봅니다.
윗분들의 답변을 보고.. 한심하다는 생각이 들어서 잔소리 좀 하고 가겠습니다. 우선 남들이 안쓰니깐 쓰지말라는건 말이 되지 않습니다. 전 오히려 namespace를 (적절히 잘) 쓰는 소스코드를 더 많이 봐왔는데요????
또, 어려운 소스를 쓰는 사람은 무조건 잘난척 하는 사람입니까? 천만에요. 그 소스를 만든 사람이 정말 잘난척을 하고 싶었는지의 여부는 물어보면 압니다. 잘난척 하기 위해 소스를 어렵게 만든 사람들은 그 용도를 정확히 알지 못합니다. 꼭 써야할 곳에 써야 하는데, 그러질 못하죠.
그런 잘난척(?) 하기위해 무조건 가져다 쓰는것도 문제가 됩니다. 불필요한 코딩 오버헤드가 발생하는데다, 오작동 할 우려가 크기 때문에요..
----------------------------
namespace가 어떻게 쓰일때 어떤 장/단점을 가지는지 명확히 판단하시고 쓰세요. 비단 namespace 뿐만 아니라, 다른 어떤 기술들도 마찬가지입니다.
** 우선 코어 엔진이나 라이브러리 개발자라면 namespace를 사용해 프로그래밍 하는 습관을 들이십시요. 물론 우리나라엔 게임 엔진을 파는 경우가 거의 없으니 해당사항은 없겠지만요.
** 반대로 그런 경우가 아니라고 하더라도, namespace의 사용법은 정확히 알고 있어야 합니다. 우리보다 뛰어난 프로그래머가 만들어 공개한 좋은 소스를 namespace를 몰라서 못쓴다면 좀 억울할테니까요..
잘쓰면 약이되고 잘못쓰면 독이 된다는 말씀 아시죠? namespace도 마찬가지입니다. 어떨때 왜 써야 하는지, 어떨때 왜 쓰지 말아야 하는지, 자꾸 생각하는 프로그래머가 되어야 합니다.
한 몇년 그만그만한 프로그래머로 지내다 결국 포기하는 사람들을 수도 없이 보아 왔습니다. 반대로, 정말 뛰어난 분들도 수없이 보아왔구요.. 그둘의 차이는, 편견없이, 솔직하게, 지적인 호기심을 가지고 사는 사람이냐 아니냐의 차이입니다. 부디 분발하셔서 좋은 프로그래머가 되시길 바랄께요.. 그럼..
요다할아범