함수명, 변수명 바꾸기

프로그래머가 가장 힘들어하는 일은 이름 짓기라고 한다.

이름을 짓기가 어려운 만큼, 보다 더 좋은 이름이 떠오르면 바꾸고 싶은 생각도 하기 마련이다.

그것은 클래스, 함수, 변수 이름 또한 마찬가지이다.

그러나 이미 개발이 많이 진행되어서 기존에 작성한 함수명, 변수명이

여기저기서 많이 쓰이고 있는 상황이라면?

아마 모든 이름을 직접 하나씩 변경하려면 어려워서 바꾸는 걸 포기하거나,

모두 바꾸기(Ctrl+Shift+H)를 사용해서 바꾸기를 시도할 것이다.

모두 바꾸기의 경우 바꿔야 할 이름 외에도 바꾸면 안되는 이름까지도 바꿔버릴 수 있는데,

자칫하면 컴파일이 안되거나, 사이드 이펙트(Side Effects)가 발생하는 등의 위험이 따르게 된다.

Visual Studio에서는 이러한 상황을 대비해서 이름 바꾸기 기능을 지원한다.

Visual Studio 이름 바꾸기 기능을 사용해서 쉽고 안전하게 함수명, 변수명을 한 번에 일괄 변경해보자.

Visual Studio 이름 바꾸기 기능

Visual Studio에서 이름 바꾸기 기능을 실행하려면 이름을 바꾸려는 항목(함수명, 변수명)을 캐럿(caret)으로 선택하고
Ctrl+R+R 을 누르거나, 마우스 오른쪽 버튼을 클릭해서 '이름 바꾸기'를 선택하면 된다.

'이름 바꾸기' 기능은 Visual Studio 2015 이상에서 도입된 기능으로 Visual Studio 2017, Visual Studio 2019에서도 동일하게 사용할 수 있다.

(Visual Studio 2013 이하에서는 지원하지 않는다.)

아래에서 소개하는 내용은 편의상 C++ 코드이지만, C#과 같은 다른 언어에서도 동일하게 사용할 수 있다.

함수명, 변수명 일괄 변경하는 방법

1. 바꾸려는 함수명, 변수명을 선택하고 Ctrl+R+R 또는 마우스 오른쪽 버튼 클릭 후 '이름 바꾸기' 선택

여기서는 클래스명 AppleClass를 예시로 들것이다.

2. '이름 바꾸기' 창에서 '새 이름'란에 변경하고자 하는 이름을 입력하고 '미리 보기' 클릭

클래스명 AppleClass를 BananaClass로 일괄 변경해볼 것이다.

검색 범위는 '전체 솔루션'이 기본인데 일반적인 상황에서는 건드리지 않아도 될 것이다.

3. '변경 내용 미리 보기'창에서 변경할 항목을 선택하고 '적용' 클릭

(왼쪽) 이름 변경이 필요한 항목들은 자동으로 체크되는 반면, (오른쪽) 다른 네임스페이스에서의 동일한 클래스명은 확인되지 않은 참조로 분류되어 체크가 해제되어 있는 것을 확인(오른쪽)할 수 있다.

Visual Studio가 일정 수준 자동으로 체크를 선택해주긴 하지만, 그래도 한 번 정도는 불필요한 변경 항목이 있는지 확인이 필요하다.

4. 이름 바꾸기 완료

이로써 BananaClass 클래스명으로 이름 바꾸기가 완료되었다.

만약 이름 바꾸기 후 컴파일 오류가 발생할 경우 Ctrl+Z로 변경 사항을 취소하거나,

문제가 있는 부분을 직접 변경해주면 되겠다.

C 런타임 라이브러리

런타임 라이브러리 링크 옵션인 /MD 및 /MT 컴파일 옵션을 이해하기 위해서는 런타임 라이브러리에 대한 이해가 필요하다.

런타임 라이브러리(Run-Time Libraries)란 여러 프로그램들이 실행 중에 입력과 출력, 메모리 관리, 연산, 예외 처리 등 공통적으로 필요로 하는 기능들을 별도의 라이브러리 형태로 묶어서 제공하는 것을 의미한다.

C/C++에서는 대표적으로 C 런타임 라이브러리(CRT; C Run-Time Libraries)가 있으며, 이는 ISO C99 표준 라이브러리를 통합하는 C++ 표준 라이브러리의 일부이다. 즉 C/C++로 작성된 프로그램이 실행 중에 기본적으로 필요로 하는 기능들을 포함하여 라이브러리 형태로 제공된 것을 의미한다.

/MD vs /MT 컴파일 옵션의 차이점

/MD 및 /MT 컴파일 옵션은 위에서 언급한 C 런타임 라이브러리(CRT)의 연결 방식과 관련된 옵션이다.

MD는 Multi-Threaded DLL, MT는 Multi-Threaded의 약자이며, 두 가지 옵션 모두 다중 스레드 개발을 지원한다는 의미이기도 하다.

참고로 /MDd, /MTd는 /MD 및 /MT의 디버그용 옵션이다.

과거에는 싱글 스레드만 지원하는 /ML, /MLd 옵션도 제공이 되었지만 최근의 멀티 코어, 멀티 스레드 환경에서는 경우에 따라 문제가 발생할 소지가 있어 제거된 것으로 보인다.

/MD 및 /MT 컴파일 옵션의 특징은 다음과 같이 정리할 수 있다.

/MD (Multi-Threaded DLL)

• /MD 옵션은 C 런타임 라이브러리를 별도의 DLL로 동적으로 연결(dynamic link)하는 방식
• MSVCRT.lib가 .obj 파일에 배치되어 빌드된다. (디버그 모드의 경우 MSVCRTD.lib)
• 여러 실행 파일이 라이브러리를 공유하여 사용할 수 있어 실행 파일 크기 및 메모리 사용량 감소
• 실행 파일 배포 시 반드시 재배포 패키지를 함께 배포해야 함

/MT (Multi-Threaded)

• /MT 옵션은 C 런타임 라이브러리를 실행 파일 내에 포함하여 정적으로 연결(static link)하는 방식이다.
• LIBCMT.lib가 .obj 파일에 배치되어 빌드된다. (디버그 모드의 경우 LIBCMTD.lib)
• 대상 시스템에 설치된 DLL에 의존하지 않는다.
• 실행 파일의 크기가 커진다.

런타임 라이브러리 링크 /MD, /MT 설정 방법

• [프로젝트 속성] -> [구성 속성] -> [C/C++] -> [코드 생성] : 런타임 라이브러리 선택

단일 실행 파일을 배포하는 경우라면 /MT 옵션으로 배포하는 것이 간편하겠지만,
다수개의 실행 파일을 배포하는 경우 /MD 옵션을 사용하면 배포 크기 및 메모리 사용량 측면에서 효율적일 수 있다.

만약 /MD 컴파일 옵션 사용 시 재배포 패키지를 함께 배포하지 않으면 다음과 같은 시스템 오류가 발생할 수 있다.

"VCRUNTIME140.dll이(가) 없어 코드 실행을 진행할 수 없습니다. 프로그램을 다시 설치하면 이 문제가 해결될 수 있습니다."

/MD 컴파일 옵션으로 배포 후 문제가 발생할 경우 아래 링크를 참고하여 재배포 패키지를 설치하면 되겠다.

• 2020/11/16 - [Windows] - VCRUNTIME140.dll 시스템 오류, 간단하게 해결해보자!

C/C++의 빌드 모드

C/C++의 Debug 및 Release 빌드 모드의 의미와 차이, 각 모드별 장단점에 대해서 알아보고, 추가로 성능 측정을 통해 실제 환경에서 비교해보자.

보통 C++로 코드 작성 후 결과물을 실행 파일로 만들기 위해서는 빌드 작업을 해야만 한다.

이때 Visual Studio와 같은 IDE에서는 Debug 또는 Release 빌드 모드를 선택할 수 있다.

이는 사실 C/C++ 컴파일러의 최적화 옵션의 차이인데, Visual Studio에서는 편의를 위해 빌드 모드를 분리해놓은 것이다.

현업에 종사하거나 숙련된 개발자는 당연히 이 차이를 알고 있겠지만,

주로 C/C++ 개발을 처음 접하는 분들, 특히 학생들은 Visual Studio 기본값인 'Debug'로 빌드해서 배포를 하는 경우가 종종 있다.

잘못된 빌드 모드로 배포할 경우 성능 저하가 발생하거나 프로그램 실행 불가 등의 문제로 상당히 고생할 수 있다.

그러므로 각 빌드별 특징을 잘 알고있어야 한다.

Debug vs Release 차이점

그럼 Debug 모드와 Release 모드 빌드는 어떤 차이점이 있을까?

일단 이름에서도 알 수 있듯,

Debug 모드는 디버깅에 적합한 빌드이며,

Release 모드는 배포를 적합한 빌드이다.

빌드 구성의 세부 속성에 따라 일부 차이가 있을 순 있겠지만,

대체로 두 빌드에 대한 차이점을 요약하면 다음과 같다.

물론 코드 실행 결과는 동일하다.

각각의 빌드 모드는 언제 사용해야할까?

Debug 빌드는 코드 실행 속도가 느리지만, 디버깅이 용이하고 컴파일 속도도 빠르므로

한창 개발이 진행중인 프로젝트에서 개발자가 디버깅을 할때 사용하는 것을 권장한다.

Release 빌드는 코드 실행 속도가 빠르고 배포하기도 용이하므로 (VC++ 재배포 패키지) 개발이 완료되고,

실제 사용자에게 전달할 때 사용하는 것을 권장한다.

그러나 Release 빌드에서도 Debug 빌드에서 확인되지 않은 문제점이 발견되므로

Release 빌드에서의 테스트도 필수라고 할 수 있다.

Debug vs Release 성능 비교

그럼 Debug 빌드와 Release 빌드에서 성능 차이는 얼마나 발생하는 것일까?

간단한 테스트를 통해 각 빌드의 코드 실행 속도와 메모리 사용량을 비교해보자.

다음 테스트 결과가 모든 케이스를 대표하지는 못하겠지만, 참고용으로 활용할 수는 있겠다.

테스트는 '소수 구하기'이다.

#include <iostream>
#include <vector>
#include <Windows.h>

bool isPrime(int x)
{
    if (x <= 1)
    {
        return false;
    }

    for (int i = 2; i < sqrt(x); ++i)
    {
        if (x % i == 0)
        {
            return false;
        }
    }

    return true;
}

int main()
{
    int n;
    std::vector<int> vec;
    LARGE_INTEGER st, ed, freq;

    std::cout << "소수 개수 : ";
    std::cin >> n;

    QueryPerformanceFrequency(&freq);
    QueryPerformanceCounter(&st); // 측정 시작

    for (int i = 0; vec.size() < n; ++i)
    {
        if (isPrime(i))
        {
            vec.push_back(i);
        }
    }

    QueryPerformanceCounter(&ed); // 측정 완료

    std::cout << "소요 시간 : " << (double)(ed.QuadPart - st.QuadPart) / ((double)freq.QuadPart);
    system("pause");

    return 0;
}

100,000개의 소수를 구하는 방식으로 Debug, Release 빌드 각각 테스트하여 비교해볼 것이다.

빌드 환경

• Windows 10 19H2 x64
• Visual Studio 2019
• Debug x86(/MDd /Od), Release x86(/MD /GL /O2 /Oi)

1. 실행 파일 크기 비교

• Debug  - 71.5KB (73,216 바이트)
• Release - 15.0KB (15,360 바이트)

=> 약 4.7배 차이

2. 실행 속도 비교 (100,000개, 3회 평균)

• Debug  - 3.02014초
• Release - 0.24319초

=> 약 12.4배 차이

3. 메모리 사용량

• Debug  - 1,000KB
• Release - 844KB

=> 약 15%(156KB) 차이

    (단, 실행 파일의 크기가 커질수록 오차가 발생할 것이다.)

Debug 빌드와 Release 빌드 모드의 의미와 차이, 각 모드별 장단점에 대해서 살펴보았다.

각 빌드의 성능 측정 결과, 실행 파일 크기는 4.7배, 실행 속도는 12.4배, 메모리 사용량은 15% 정도 차이가 발생했다.

실제로 성능을 측정하여 비교해본 건 처음인데,

이번 케이스에서는 예상보다도 많은 차이를 보이는 것 같다.

위 내용을 참고해서 Debug와 Release 빌드를 적절히 활용하길 바란다.