인프런 커뮤니티 질문&답변

안녕하세요 선생님. 답변해주신 내용 잘 읽었습니다.

Github 쪽을 검색해보니, 작업 시 C-style을 사용하지 말고 C++ style을 사용해라고 권고하는 Issue들이 적지 않게 있더라구요. C++ style이 명확하고 안정성이 좋은건 사실이지만, C-style을 그대로 편하게 사용하는 사람들이 많은 것도 사실인 것 같습니다. Stackoverflow에는 'Don't use them, ever.' 이라거나 'never use'라고 좀 강경하게 C-style을 반대하는 사람도 있더라구요.

개인적으로는 이런 보다 좋은 품질의 프로그램 작성을 다 같이 권장하는 분위기가 나쁘지는 않은 것 같습니다. 사실 제가 아직 실무에 있어본 적이 없어서 프로그램 작성 시 어떠한 무조건적인 규칙을 따르는 것이 일터에 주는 영향 같은 것은 생각을 잘 못하겠지만, C-style이라는 오래 사용되던 방식을 갑자기 모든 사람이 사용하지 못하게 하는 것도 말이 안되긴 하네요.

제가 너무 강의에서 벗어난 부분에 대해 시시비비를 가리려는 느낌이 좀 없지않아 있었던 것 같네요. 실제 사용을 잘하는 것이 더 의미있는 거겠죠.

그와 별개로 저는 이런식으로 생각해보고 질문글 달고 하는게 재밌더라구요. 배우는 입장에서 여러 자료를 찾아보니 공부도 많이 되구요. 말씀 감사합니다.

코딩 스타일이야 말로 자동화가 가능합니다. 대기업은 내부적으로 커밋하려고 하면 자동으로 고쳐주는 시스템이 있습니다. 아예 그런 기능만 담당하는 팀도 있습니다. 'Don't use them'이라고 사람이 조언해주는 것이 아니라 누군가가 하면 안되는 일을할 때 그걸 자동으로 경고해주거나 수정해주는 시스템을 만드는 것입니다. 간단하게는 포매터 생각하시면 됩니다. 극단적인 사례를 들면, 코딩하면서 줄바꿈을 잘 하면 코드 품질을 높이는 데에 도움이 되던 시대도 있었습니다. (비용 산정에 줄 수 반영) 이걸 매번 하지마라 주의해라 경고를 했어야 하는 시대에 일하던 분들에게는 프로그래밍 교육이라고 하면 변수명 잘 짓고 줄바꿈 잘하는 거였습니다. 지금은 합의된 규칙에 따라 포매터를 설정해놓고 파일 저장하면 자동으로 정리를 해줍니다. 참고로 저는 스택오버플로우를 볼 때 언제 쓰여진 글인지 날짜도 꼭 확인합니다.

제가 학생들에게 계속 강조하는 것은 새로운 비즈니스 모델을 찾아내는 것이 중요하다는 것입니다. 예를 들면 인스타그램이 나올 때 비슷한 비즈니스 모델을 시도하는 벤쳐들이 여러개 있었는데 결국 하나만 남았습니다. 어떤 아이디어가 시장에 나오면 초기에는 여러 회사들이 경쟁하다가 하나만 남습니다. 그러면 나머지는 합병되어서 같이 가든가 아니면 다른 아이디어를 시도하러 갑니다. 최근에 틱톡도 비슷한 과정을 거쳐서 자리를 잡았습니다. 학습능력이 좋은 학생들일수록 창업자 마인드로 접근을 하셨으면 좋겠습니다.

그렇군요... 감사합니다 선생님. 넓게넓게 보겠습니다 ㅎㅎ

답변 감사합니다. 본 질문글은 제가 강의를 완강하고 다시 노트를 정리하며 복습하는 과정에서 생긴 의문을 여쭤본 것이라 언급해주신 내용에 대해 알고 있습니다.

functional-style cast는 문법적으로 함수 호출에 가까운 형태를 지니며, 실제로 형변환 연산자를 오버로딩하여 사용하는 것이 가능하다는 점에서 객체지향이라는 C++의 성격을 활용하기에 C++ 스타일이라고 말할 수 있다고 말해 주셨습니다. 내용이 이해도 잘 되었습니다.

그런데 제 생각에는 functional-style은 일반적으로 권장되는 방법들인 static_cast를 포함한 다른 C++ 스타일 캐스팅과는 그 의미가 다른 것 같습니다. static_cast, const_cast 등은 변환의 의도를 명확히 표시하여 알 수 있게끔 하며 안정성도 높은 것이 특징인데 function-style cast는 내부적으로 그 중 하나를 수행할 뿐 그 자체를 C++ 스타일로 보기에는 어렵다고 생각합니다.

그래서 '무엇을 C++ 스타일 캐스팅으로 보아야 하나?'가 관건이긴 합니다.

Bjarne Stroustrup이 아래와 같이 말한 내용이 있습니다.

The "new-style casts" were introduced to give programmers a chance to state their intentions more clearly and for the compiler to catch more errors.

https://www.stroustrup.com/bs_faq2.html#static-cast

C++ 스타일 캐스팅이란 캐스팅의 목적을 명확히 표시하고 컴파일러가 에러를 더욱 잘 잡아내도록 하는 것이 목적이라고 되어 있습니다. 이외의 검색결과에서도 functional-style cast는 C-style과 동일하게 동작하는 것이며, C++ style cast 네 가지를 목적에 맞게 사용하는 것을 권장하고 있습니다.

또한, 첨부해주신 cppreference 링크에서 함수형 스타일 캐스팅의 내부 작동 방식이 C-style 캐스팅 방식과 동일하게 작동한다는 것을 굳이 비교하며 추가적인 설명을 한 것 또한, 함수형 스타일 캐스팅이 C-style 캐스팅 방식이 아니기 때문에 그 작동 방식에 대해서 비교하며 설명한 것으로 이해하시면 좋을 것 같습니다.

위 부분은 어떤 의미인지 잘 이해가 되지 않습니다. 강의에서 설명되는 사례인 int(4.0) 같은 경우의 functional-style cast는 C-style cast가 완전히 동일합니다.

안녕하세요? 질문&답변 도우미 Soobak 입니다.

말씀해주신 내용 잘 이해되었습니다.

교수님께서 답변해주신 내용 또한 확인한 후, 좀 더 넓은 생각으로 토론을 이어나가는 것도 저에게 좋은 경험이 될 것 같아 즐거운 마음으로 답변을 이어 드립니다.

마지막, 제가 질문자님을 납득시켜드리지 못한 내용에 대하여 좀 더 풀어 설명드리면 다음과 같습니다.

• c++ 에는 4가지의 형변환 연산자가 존재

  • static_cast, const_cast, reinterpret_cast, dynamic_cast

• 이 때, 형변환 방식에 대하여 비교 기준을 '명시의 유무' 로 삼아 구분해본다면, '명시적 형변환' 과 '암시적 형변환' 두 가지로 나눌 수 있을 것

• 이 때, '명시적 형변환' 에 대해서 비교 기준을 '언어적 특성' 으로 삼아 구분해본다면, 'C언어 스타일 형변환' 과 'C++언어 스타일 형변환' 으로 나눌 수 있을 것

  • (int)4.0 과 같은 방법은 C언어에서의 형변환과 문법적인 형태가 동일하기 때문에 'C언어 스타일'

  • static_cast<int>(4.0) 과 같은 방법은 C++언어에서의 문법적인 형태이기 때문에 'C++언어 스타일'

  • int(4.0) 과 같은 방법은 C++ 언어에서의 문법적인 형태이기 때문에 'C++언어 스타일' (C언어에서는 위와 같은 문법으로 형변환을 진행할 수 없음)

• 위 3가지의 명시적 형변환 방식에 대하여, '내부 작동 방식' 을 기준으로 삼아 범위를 나눠본다면 (int)4.0 과 int(4.0) 은 내부적인 형변환 연산자 선택에 있어서 작동방식이 동등함.(개인적으로는 그냥 '같다' 라고 표현하고 싶습니다.), 반면 static_cast<int>(4.0) 과 같이 연산자까지 명시하는 명시적 형변환은 이와 구분됨.

• 이 때, cppreference 의 글은 함수형 스타일의 형변환 방식을 C언어 스타일의 형변환 방식과 '작동 기능' 측면에서 비교하여 언급하고 있음.

  • 어떠한 대상 둘을 '비교' 한다는 것은, 그 둘을 구분하는 '기준' 이 있다는 것이므로,
    '굳이' 함수형 스타일 형변환 방식을 C언어 스타일 형변환 방식과 비교하고 있다는 것은 그 둘이 다르기 때문이라고 생각.

• 여기서 제 생각은, 함수형 스타일 형변환 방식은 '문법적으로' C++언어 스타일 이기 때문에, C언어 스타일 형변환 방식과 구분되는 것이며, 다만 이 둘을 '내부 작동 방식' 을 기준으로 살펴보았을 때 함수형 스타일 형변환 방식의 작동 방식은 C언어 스타일 형변환 방식의 작동 방식과 동등하다는 것 입니다.

작성하신 답변 잘 읽었습니다. 저도 마지막에 결론 내리신 것과 같은 생각입니다. 사실 이 주제는 그렇게 중요한 것이 아닐지도 모르겠네요.

강의 내용과는 크게 상관이 없는 내용이지만, 복습을 이어서 하다 열거형 부분에서 왜 enum class와 struct 그리고 class는 전방 선언이 되지만 enum은 되지 않는지 궁금해서 검색했는데 명확한 답을 못 찾겠더라구요. 그런데 스택오버플로우의 한 댓글이 아래와 같이 달려 있더라구요.

It was not allowed in C++ back then because it is not allowed in C. It is not allowed in C because there was no pressing need for such things back in 1980. It is not allowed in C++ now because no one cares. People should not be using old-style enums in new development anyway, why revise rules that govern them?

사실 이것은 C 언어의 제약이 초기 C++에 준 영향이 그대로 이어진 것일지도 모르며, 더군다나 새로운 개발에서는 기존의 열거형이 필요한 경우 enum 대신 enum class를 사용할 것이 권장되므로, 이러한 논쟁에 대해 생각할 이유가 없을지도 모른다... 라는 내용이었습니다.

비슷한 관점에서 생각했을 때, C-style과 C++ style의 정확한 정의에 대해 생각하는 것이 크게 의미있는 활동은 아닌 것 같다는 생각이 뒤늦게 드네요. 물론 여러 자료를 찾아보는 과정에서 여러 형 변환 방법이 생겨난 이유와 그 목적에 대해서 명확히 알게 되었다는 점에서 그 시간 자체는 의미있었던 것 같습니다. 적극적으로 의견교환 해주셔서 감사합니다.