[C++] 이름과 스코프

-

C++에서는 많은 것들이 이름을 가질 수 있다. 변수는 모두 이름을 가지고, 객체는 변수를 통해서 이름을 가질 수 있다. 타입도 이름이 있고, 함수도 이름이 있다. 람다 함수는 익명 함수라는 번역 그대로 이름이 없지만, 변수에 할당하여 이름을 통해 접근할 수도 있다. 이 이름을 어디서부터 어디까지 사용할 수 있는가를 그 이름의 스코프라고 하는데, C++은 상황에 따라 다른 스코프를 사용한다. 이번 글에서는 C++의 이름이 가지는 스코프에 관해서 설명하도록 하겠다.

block scope

block scope는 선언된 문장부터 선언된 block이 끝날 때까지 사용할 수 있다. 블록 밖에서 선언된 같은 이름이 있으면 이름이 선언되기 전까지는 블록 밖에서 선언된 이름을 그대로 가지고, 선언된 문장부터 새로 선언한 의미를 가진다.

예를 들어 위와 같은 코드가 있을 때 4번째 줄까지 a는 2번째 줄에서 선언된 a이지만, 4번째 줄부터 block이 끝나는 10번째 줄까지는 4번째 줄에서 선언된 a이다. 또한, block scope를 가지는 이름은 같은 block 안에서 다른 의미를 가지기 위해 다시 사용될 수 없다. 즉, 위에서 5번째 줄에서 10번째 줄까지 사이에서는 a를 다른 의미로 사용할 수 없다.

스코프를 가지는 이름의 대표적인 예제로는 함수 안에서 선언된 변수인 지역 변수(local variable)가 있다. 이때 지역 변수와 automatic storage에 저장되는 지역 객체를 혼동하면 안 된다. 스코프는 어디까지나 컴파일 시 그 이름을 어디까지 사용할 수 있는가 하는 것이지 객체의 라이프타임과는 상관없다. 지역 변수 중에서도 static이나 thread_local 같은 storage를 지정해주는 specifier가 붙은 경우 이 객체들은 automatic storage에 저장되지 않는다.

지역 변수 외에도 typedef나 using으로 선언되는 type alias, 함수 안에서 선언되는 class와 enum 같은 경우도 함수 안에서 선언됐다면 block scope를 가진다. 함수의 인자, for 문에서 선언된 변수, catch 된 exception, C++17이라면 if control 문에서 선언된 변수도 block scope를 가지는데, 이들은 해당 문장이 있는 block이 아닌, 문장 다음에 있는 block에 종속된다.

namespace scope

block scope보다 약간 큰 범위를 가지는 것은 namespace scope다. namespace scope는 이름 그대로 namespace에 선언된 모든 이름을 의미한다. 당연히 이 namespace에는 global namespace도 포함되므로 outermost namespace 밖에 선언된 이름도 namespace scope를 가진다. namespace scope를 가지는 이름은 block scope를 가지는 이름과 마찬가지로 선언된 문장부터 접근할 수 있다. 하지만 block scope와는 다르게 선언된 namespace가 끝나더라도 접근 불가능하지 않다. 아래와 같이 ::(scope resolution operator)를 통해서 접근할 수 있다.

enumeration scope

enumeration scope는 C++11에 처음 들어간 기능으로 enum class가 들어가면서 같이 들어갔다. C++11의 enum class는 scoped enum이라고 부르기도 하는데, 이는 enumerator의 이름이 enumeration에 한정되기 때문이다.

같은 스코프 내에서 선언된 이름을 다시 선언할 수 없다는 규칙은 enumeration scope도 마찬가지므로 enumerator의 이름을 중복해서 사용할 수 없다. 하지만 enum class가 선언된 block scope나 namespace scope의 이름을 더럽히지 않기 때문에 해당 스코프에는 중복되는 이름이 있어도 괜찮다. enumerator를 사용할 때는 enumeration의 이름과 합쳐서 scope resolution operator를 사용한다.

function scope

function hoisting이란 선언된 이름이 마치 함수의 시작 부분으로 옮겨진 것처럼 해석되는 경우를 말한다. JavaScript에서는 모든 변수가 function hoisting 되므로 JavaScript를 써본 사람이라면 익숙한 개념일 것이다. 하지만 마치 JavaScript의 특이한 기능인 것처럼 알려졌기 때문에 C++에서도 function scope에는 function hoisting이 사용된다. 사실 function scope를 사용하는 이름은 label 딱 한 경우뿐이고, 대부분의 경우 goto를 사용하는 것을 피하므로 사용할 일이 거의 없다. 어찌 됐든 이 라벨은 같은 함수 안에서 선언됐다면, 그 선언된 위치와 상관없이 어디서나 라벨을 사용할 수 있다.

class scope

class scope는 클래스 정의 안에서 선언된 모든 이름이 가지는 스코프다. 같은 클래스 안에서 선언됐다면, 클래스의 멤버 변수나 멤버 함수는 물론이고, static 멤버, static 함수, nested class나 class 안에서 정의된 enumeration과 타입들도 모두 같은 class scope로 묶인다. 이때 function scope처럼 모든 이름이 hoisting 된 것으로 해석된다. 예를 들어 아래와 같은 함수가 있을 때, S::f 함수 안에서 i를 사용할 때, 아직 S::i는 선언되지 않았기에 func 함수에 지역 변수로 선언된 i를 의미하는 것 같지만, 실제로는 S 클래스의 모든 변수 선언이 hoisting 됐기 때문에 클래스 S 안에서 사용되는 i는 모두 S::i를 의미한다.

function prototype scope

위에서 이미 함수의 인자는 block scope를 가진다고 말했기 때문에 function prototype scope가 따로 존재한다는 것이 이상할 수 있다. 하지만 이 이름을 잘 보면 답을 알 수 있다. function prototype scope는 function declarator에 한정되는 scope이다. function prototype scope에 해당하는 이름. 즉, 함수의 파라미터는 선언된 순간부터 function declarator가 끝나는 순간까지 사용할 수 있다.

따라서 위와 같은 코드가 있을 때 f 함수의 인자로 선언된 a와 b는 f의 선언이 끝날 때까지 function prototype scope를 가지고, function body에서는 block scope로 사용된다. 이때 선언된 순간부터 사용할 수 있으므로, a의 기본값으로 사용된 b는 첫 번째 줄에서 선언된 constexpr int인 b이다.

하지만 위와 같은 코드에서는 b의 기본값으로 a를 사용하기 전에 이미 a를 인자로 선언했기 때문에 첫 번째 줄에서 선언한 a가 아닌 첫 번째 인자인 a가 된다. 이때 a가 무엇인지 컴파일 타임에 알 수 없으므로 이는 컴파일 에러를 발생시킨다.

하지만 위처럼 컴파일 타임에 값을 알 수 있는 경우에는 사용할 수 있다. 이때 sizeof에 사용된 a는 첫 번째 줄에서 사용된 int32_t가 아닌, 첫 번째 인자인 int8_t 이므로 기본값은 1이 된다.

template parameter scope

마지막으로 설명할 스코프는 template parameter scope다. 이름 그대로 template parameter의 스코프를 정해주기 위한 것으로 선언된 순간부터 접근 가능하며, 선언을 포함한 가장 작은 template의 구현이 끝나는 시점까지다. template parameter scope인 이름은 해당하는 스코프가 끝날 때까지 다른 이름으로 사용할 수 없다. 즉, template 함수나 template 클래스 안에서 template parameter의 이름을 다른 이름으로 사용할 수 없다. 하지만 template parameter scope 안에 다른 template parameter scope가 있을 때, 바깥 스코프에서 선언된 이름을, 안쪽 스코프에서 다시 선언하여 사용할 수는 있다.

지금까지 C++이 가지는 스코프의 종류에 관해서 설명하였다. 요약하자면 C++은 block scope, namespace scope, enumeration scope, function scope, class scope, function prototype scope, template parameter scope의 7가지 스코프를 가지고 있으며, 이 중 class scope와 function scope는 선언한 위치에 상관없이 스코프 내에서 모든 언제나 의미를 가지지만, 나머지 5개 스코프는 이름이 선언된 순간부터 의미를 가진다. 또한, namespace scope, enumeration scope, class scope의 경우 스코프 밖에서도 ::(scope resolution operator)를 통해서 접근할 수 있다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

USB 2.0 케이블의 내부 구조

-
아이폰도 USB-C를 사용하면서 온 세상이 USB 로 통일됐지만 실제로는 너무 다양한 USB가 존재한다. 기본 형태인 USB-A나 최근 많이 사용되는 USB-C 뿐 아니라, 보통 5핀이라고 불리는 micro-B를 포함한 다양한 USB-B 컨넥터들이 존재한다. 그래도 컨넥터는 모양이 다르기 때문에 쉽게 구분할 수 있는데 케이블은 답이 없다. 겉으로는 똑같아 보이는 케이블이라도 어떤 케이블은 데이터 통신이 안 되고 어떤 케이블은 데이터 통신이 가능하다. 이런 차이는 케이블 내부 구성에 따라 발생한다. 이번 글에서는 USB 2.0 케이블의 내부를 통해 USB 케이블에 대해 자세히 알아보겠다. Micro-B 케이블의 편조 차폐와 호일 차폐 위 사진은 집에서 돌아다니던 A - Micro-B USB 2.0 케이블의 피복을 벗겨낸 것이다. 절연체 아래로 금속 선이 있는 것을 알 수 있다. 이 선들은 금속 선이지만 전선은 아니다. 이 선은 전자기 차폐를 목적으로 들어간 금속 선이다. 실제 전선은 이 금속 선을 벗겨야 나온다. 이번에 자른 케이블에는 두 종류의 차폐가 사용됐다. 하나는 얇은 금속 호일이고, 다른 하나는 얇은 도체의 가닥으로 이루어져 있다. 전자는 보통 호일 차폐(Foil Shielding)라고 부르고 후자는 편조 차폐(Braided Shielding)라고 부른다. 이 둘은 다 외부 전자기장으로부터 전선을 보호하기 위해 사용되지만, 특성이 약간 다르다. 보통 편조 차폐가 저주파수 전자기파를 차단하는 것에 효과적이고, 호일 차폐가 고주파수 전자기파를 차단하는 데 효과적이다. USB 3.0의 고속 전송 케이블은 이 두 차폐를 사용하는 것이 필수적이고, 그 외의 경우에는 필수는 아니고 권장 사항이다. 하지만 어지간한 싸구려 케이블을 쓰지 않는 한 요즘은 USB 2.0 케이블에도 이 두 가지를 같이 사용한다. 차폐 선이 쉴드와 연결되지 않았다 하지만 고속 전송을 지원하는 케이블이 ...
Read more »

[C++] enum class - 안전하고 쓰기 쉬운 enum

-
C++ 03 까지의 enum 은 여러 가지 문제를 가지고 있었다. 그래서 그 문제들을 해결하기 위해 C++ 11은 enum class 라는 것을 새로 만들었다. 이제부터 기존의 enum 에 어떤 문제가 있었고, 이것을 enum class 에서 어떻게 해결하였는지 살펴볼 것이다. 우선 기존의 enum 은 전방 선언할 수 없었다. 그 이유는 enumerator에 어떤 값이 들어있을지 알 수 없으면 그 크기를 정할 수 없기 때문 이다. 하지만 enum class 는 underlying type을 명시하지 않으면 int 타입과 같은 크기의 변수로 선언되고, int 값 안에 들어가지 못할 값을 지정하면 컴파일 에러를 발생시킨다. 만약 int 를 벗어난 범위의 값을 사용하고 싶다면, underlying type을 명시해주어야 한다. 기존 enum 의 또 다른 문제는 enumerator의 이름의 범위가 한정되지 않는다는 것이다. 예를 들어 아래와 같은 코드를 보자. IO 함수의 결과와 Parse 함수의 결과를 enum 으로 표현해 보았다. 하지만 이 코드는 컴파일되지 않는다. IOResult 의 Error , Ok 가 ParseResult 의 Error , Ok 와 겹치기 때문이다. 이를 해결하기 위해서는 다음과 같이 enumerator의 이름을 다르게 하거나 아래와 같이 namespace 를 이용해야 했다. 하지만 enum class 는 enumerator의 이름이 enum class 안으로 한정되기 때문에 이런 복잡한 과정이 필요 없이 그저 enum class 를 선언하여 사용하면 된다. 무엇보다 기존 enum 의 가장 큰 문제는 정수형 변수로 암시적으로 변환되는 약 타입(weak type) 변수라는 것이다. 하지만 enum class 는 정수형 변수로 암시적 변환이 되지 않는다. enum class 를 정수형 변수처럼 사용하려고 하면 컴파일 에러를 발생시킨다. 만약 정수형 변수로 사용하고 싶으면 static_cast 를 이용해...
Read more »

Log Aggregator 비교 - Scribe, Flume, Fluentd, logstash

-
https://docs.google.com/presentation/d/12A5RlMCVDN6tA_zUnLrZ0TN5v08gz2GhlRdzxy3T3mU/edit?usp=sharing 회사에서 최근에 Log aggregator system으로 무엇을 사용해야 할지 조사해본 자료다. 우선 log aggregator가 무엇인지 한 문장으로 설명하면, 여러 머신에서 쌓인 로그들을 한 번에 분석할 수 있도록 수집하여 주는 시스템을 말한다. 요새는 특히나 클라우드 시스템이 유행하면서 같은 일을 하는 시스템임에도 다른 머신에서 돌아가는 일이 많아지면서 필요성이 크게 증가하였다. 이번 조사로 알게 된 것들을 적어보도록 하겠다. Scribe 우선 scribe 는 Facebook에서 제작하고 사용하던 log aggregator system이다. scribe: https://www.cnblogs.com/brucewoo/archive/2011/12/13/2285482.html 다른 로그 수집 시스템들을 보면 알겠지만, Scribe는 다른 시스템보다 간단한 구조로 되어 있다. Scribe는 일종의 message queue와 message queue에 쌓인 message를 DB에 저장해 주거나, DB가 실패하였으면 local에 저장하였다가 DB가 복구되었을 때 다시 DB에 저장해 주는 것만을 책임진다. 다시 말하면, message queue에 실제로 메시지를 보내는 부분은 사용자가 직접 작성하여야 한다는 것이다. 흔히들 말하는 scribe의 장점은 성능이다. C++로 만든 만큼 다른 시스템들의 3~5배 정도의 성능을 보여준다는 것이다. 하지만 실제 scribe 사용자들은 무엇보다도 Facebook이 실제로 사용하였던 솔루션인 만큼 성능과 안정성에서 신뢰도가 있다는 것을 장점으로 뽑는다. 하지만 나는 scribe를 사용하는 것을 추천하지는 않는다. 일단 가장 큰 문제는 더이상 Facebook이 Scribe를 사용하지 않는다는 것이다. Facebook은 이미 Ja...
Read more »

[Web] SpeechSynthesis - TTS API

-
SpeechSynthesis 는 Web Speech API의 하나로 주어진 텍스트를 소리로 바꿔주는 TTS API이다. SpeechSynthesis 이전에도 TTS 서비스가 있었지만, 이들은 유료이거나 웹에서 사용하기 불편한 경우가 대부분이었는데 SpeechSynthesis 의 경우 브라우저에 내장되는 API이므로 무료로 쉽게 사용할 수 있다는 장점이 있다. 물론 Web Speech API 자체가 아직 draft 에 해당하기 때문에 브라우저가 지원해야만 사용 가능하다는 문제는 있지만, 2016년 8월 15일 현재 데스크탑에서는 크롬과 사파리, 안드로이드 기본 브라우저인 크롬, 아이폰의 기본 브라우저인 사파리에 지원하고, 파이어폭스는 9월에 지원할 예정이므로 대부분의 모던 브라우저에서는 사용할 수 있다. speechSynthesis 는 5개의 함수를 가지고 있다. 그중 4개는 speak , cancel , pause , resume 이다. 이를 이용해서 재생할 음성을 추가하거나 취소하거나 일시 정지할 수 있다. 이 중 speak 함수는 SpeechSynthesisUtterance 를 인자로 받는다. speak 함수를 호출했을 때, 이미 재생 중인 utterance 가 없고 speechSynthesis 가 pause 되어 있지 않으면, 요청된 utterance 는 즉시 재생된다. 하지만 이미 재생 중인 utterance 가 있거나 speechSynthesis 가 pause 되어 있다면, utterance 는 바로 재생되지 않고 queue에 저장되었다가 후에 재생된다. 따라서 실제로 언제 재생되는지는 utterance 의 콜백을 통해서만 알 수 있다. 이벤트의 종류에 따라서 onstart , onend , onerror , onpause , onresume 등의 콜백을 등록할 수 있다. 또한, SpeechSynthesisUtterance 는 6개의 속성을 가지고 있다. 첫 번째 속성은 text 로 읽을 텍스트를 지정한다. 객체를 생성할 ...
Read more »

[Python] cache 데코레이터로 최적화하기

-
최적화는 귀찮다. 눈에 띄는 실수를 한 게 아니면 어떻게 고쳐야 할지 감이 오지도 않고, 대부분의 최적화는 가독성을 떨어뜨리기 때문에 버그가 발생할 확률이 늘어난다. 하지만 어떤 최적화 테크닉은 코드를 크게 수정하지 않고 큰 성능 향상을 가져온다. 메모이제이션 이 그 대표적인 예제다. 계산이 무겁거나, 디스크의 값을 읽거나, 네트워크 통신처럼 근본적으로 시간이 오래 걸리는 일은 그 실행 결과를 저장했다 재사용하는 것만으로 큰 성능향상을 가지고 온다. 파이썬은 메모이제이션을 쉽게 적용할 수 있는 데코레이터 를 제공한다. functools 모듈의 lru_cache 데코레이터 가 이것이다. 이 데코레이터를 붙이면 함수의 실행 결과를 캐싱해준다. 캐시의 크기는 maxsize 로 지정할 수 있다. 저장할 실행 값이 이 개수를 넘어가는 경우 LRU 알고리즘 에 따라 가장 오래전에 사용한 결과를 지우고 새 값을 캐싱한다. lru_cache 를 사용하면 쉽게 최적화할 수 있지만 아무 함수에나 사용할 수 있는 건 아니다. 함수의 인자를 캐시키로 사용하기 때문에 함수의 실행 결과가 함수의 인자 이외에 다른 요소에 의존적인 함수에는 사용하지 못한다. 즉, 랜덤 요소가 들어가거나 시간에 따라 결괏값이 변하는 함수에는 사용하면 안 된다. 결정성이 보장되는 함수에만 사용할 수 있다는 것은 모든 캐시의 공통적인 특성이다. 여기에 더해 파이썬이 제공하는 lru_cache 는 그 구현상의 문제로 한 가지 제약이 더 있다. 이 데코레이터는 값을 저장하기 위해 인자를 키로 가지는 dictionary 를 사용한다. 따라서 모든 인자가 hashable 타입이어야 한다. 다시 말해 mutable 하지 않은 dictionary, set, list 등을 인자로 받는 함수는 이 데코레이터를 사용해 캐싱할 수 없다. 이런 타입을 인자로 받던 함수는 그 인자를 frozenset 이나 tuple 같은 immutable 타입으로 변환해야 한다. 게다가 keyword argument 를...
Read more »