int -> string 변환이 필요한 경우에는 stringstream을 쓰는 것이 ‘간단하’다.
반대의 변환이 필요한 경우에는 stringstream을 써 봐야 코드가 간단해 지지 않는다.
두 가지 경우 모두, C API를 쓰는 것에 비해서는 성능이 굉장히 떨어진다.
성능이 걱정되신다면 뭐니뭐니 해도 C API쪽이 낫겠어요.
출처: stringstream
stl을 배우고 난 뒤론 stringstream을 쓰는 일이 부쩍 늘었다. 성능에 민감해서 stl보단 C 함수를 선호하는 사람도 있지만, 어지간하면 편리한 쪽을 택한다. 자주 쓰지도 않는 기능을 최적화하느라 머리 쓰기 귀찮고, 무엇보다 나중에 프로필러 돌려서 결과를 확인해보면 엉뚱한 데서 병목이 발생하기 일쑤다.
C API를 쓰면 위에서 지적한 것 말고 다른 문제도 있다. 문자열을 숫자로 바꿀 때 오류가 발생했는지 알 방법이 없다. atoi 같은 함수는 예외 상황에서 0을 반환하고, errno에 아무런 오류 값을 저장하지 않는 경우가 많다. "안녕?"이란 rn문자열을 숫자로 변환시켜보면 안다. 굳이 이런 문제를 회피하고 싶다면 isdigit 같은 함수를 쓰면 되지만, 그만큼 귀찮다. 그에 비해 stringstream 방식은 오류값이 분명하게 반환하는 걸 확인했다.
다시 성능 이야기를 잠깐 더 하자면, 최근엔 서버 관리용 도구를 하나 만드는 중이다. 그런데 이 애플리케이션은 사용자가 명령을 입력했을 때만 움직이기 때문에 성능이 전혀 중요하지 않다. 또 C++/CLI로 개발했기 때문에 C나 C++이 아닌 닷넷의 Int.ToString()이나 Int.Parse()를 썼다. 문제가 생겼을 때 친절하게 예외 메시지를 던져주니까, stringstream보다 편리하다. 성능이 중요하지 않으면 이런 방법도 있다.
strtol() family 함수를 쓰면 에러체킹도 가능하긴 합니다만, 말씀대로 편하지는 않지요. ^^
네. 이런저런 방법을 찾아봤지만 C++ 세계에선 stringstream이 제일 편하더라구요.
저…errno 가 thread local 한 값인지요. 기억에는 이곳저곳 C함수에서 다 쓰는 걸로 기억해서요. 멀티쓰레드에서 쓰기가…(리눅스에서는 thread local하게 컴파일해주는 옵션이 있었던거 같기도 하고요..)
리눅스는 잘 모르겠습니다. 윈도우도 처음엔 ThreadLocal 값이 아니었지만, 재작성했다고 들었습니다.