중요하면서도 좋은 것입니다.
Warning treated as error & STL 에서 트랙백
바로 밑의 글도 읽고나서 읽으시면 됩니다. :$
1. Warning을 무시해도 된다는 얘긴 아닙니다. 원글에서 중점을 두고 얘기한건 배열 길이 계산에 관한 문제 — 지극히 C 적인 코드 — 인데 그걸 C++ 차원에서 컴파일하고 / 해석하는건 좀 심하다고 생각해서 글을 썼을 뿐입니다.
그리고 왜 Joel 블로그를 링크해 주셨는지는 이해가 안가는군요. 전 C/C++의 포인터 형 변환에 관한 설명을 한거 뿐입니다.
OS 커널 같이 binary interface가 중요한게 아니면 C++은 충분히 이식성 있는(portable)한 언어이고, 굳이 C 수준 라이브러리에 얽혀있는 글을 쓸 필요는 없다는 의미에서 아랫 글을 작성했습니다.
2. boost::assignment 라는 아주 훌륭한 대안이 존재합니다. vector를 쓴다면 이런 식의 코드가 가능합니다.
vector<int> v;
v += 1,2,3,4,5,6,7,8,9;
<array>를 쓴다면 좀 더 복잡하지만,
array<int, 3> x;
x = list_of( 1 )( 2)( 3).to_array(x);
같이 인간이 읽기 쉬운 형태로 초기화하는 것을 지원합니다 :)
그런 의미에서 C++의 vector나 array는 기존 C 형식의 배열이 같은 거의 모든 장점을 가지면서도 C++ 특유의 추상화를 적절히 포함한 툴이라고 생각됩니다.
내가 생각하기에 C와 C++이라는 비슷하면서도 타입 시스템이나 추상화 방식에서 차이를 보이는 언어를 배웠다면, 그 차이를 살려야 혹은 살릴 수 있어야 합니다.
C에서 암시적인 형변환을 이용해서 사용자가 제어할 수 있는게 많은 추상화를 쓸 수 있다면 ((예를 들어 linux 파일 시스템 코드라거나 네트웍 드라이버 모듈 같은걸 까보면 사실 상의 virtual function을 쓰는걸 볼 수 있다.)) , C++ 특유의 연산자 오버로딩 등을 이용해서 더 쉽게 C++을 살리는 법도 배워야 한다고 혹은 배울줄도 알아야 한다고 생각합니다.
다시금 올리신 트랙백에 감사드립니다.
1. “굳이 C 수준 라이브러리에 얽혀있는 글을 쓸 필요는 없다는 의미” 라고 하셨는데, 그것이 조엘아저씨 블로그 글을 링크한 이유입니다. C++, 혹은 더 추상화 레벨이 좋은 언어를 쓰더라도 여전히 C 는 공부할만 하다는 의미를 전달하기 위함이었습니다.
2. boost 에 저런 기능이 있었군요. (이쪽은 몰랐네요 :D 곧 되기는 하겠지만 아직은 표준이 아니라 그냥 팀원이 좋아라하는 auto_ptr 만 쓰고 있습니다.) 그런데 vector, list 를 const 로 설정하려고 했을때도 initialize 할 수 있는 방법이 있나요?
그러니까… const int array[]={1,2,3,4} 와 동일한 기능을 하도록 생성자에서 데이터를 세팅할수 있는지요? (몰라서 여쭈어봅니다)
1. C 코드로는 (적어도 해당 범위 내에선) 유효한걸 C++ 코드로는 유효하지 않음을 설명하시고 나서 저런 말을 하는건 저는 잘 이해가 안가는군요.
2. 해당 코드 역시 이런 코드로 바꿔 쓸 수 있습니다.
는 유효한 C++ 코드입니다.
1. C 코드로 Compile이 됨을 유효하다고 표현하시는지요? 저는 compile 이 되어도 error 에 준하는 warning 이 나타난 경우에는 제대로 돌아가지 않을것이 뻔하기 때문에 유효하지 않다고 표현하고 있는데, 그로 인해 서로 다른 부분을 지적하고 있는듯 합니다.
2. 저런게 있었군요! 감사합니다.
1. 배열 길이 얻는 코드에서 그걸 따지는건 좀 무의미하다고 생각한다고 적어놨습니다.
2. The C++ Programming Language에 보면
저런 배열을 초기화 할 때 다음과 같은 방법을 추천하고 있습니다.
std::vector vInt;
const int array[]={1,2,3,4};
copy(array, array +4, back_inserter(vInt));
효율이나 중복을 따지자면 좋지 않을 수 있습니다만,
초기화가 필요한 동적 컨테이너를 이용하고 싶을 때,
초기화하기 간편한 코드이지요.
Boost가 나오면 위와 같은 코드가 가능하겠지만,
아직은 TR1의 시대이니..
TR1의 시대라곤 해도 boost 자체가 상당한 수준의 — major platform(OS+compiler chain) 에 대한 — 이식성을 보장하기 때문에 boost를 쓰는 것도 나쁘지 않은 선택이다.
+= 을 사용하는 copy semantics나 std::copy를 사용하는 copy semantics나 거의 같으면서도 / 구독성은 앞쪽이 낫다는 느낌.