1. 특정 명칭(클래스, 함수, 변수 등등)의 선언지로 곧바로 찾아가기.
(1) 소스 코드에서 cursor나 마우스 포인터가 가리키고 있는 명칭에 대해서는 현재 소속되어 있는 클래스나 namespace 문맥을 감지하여 동작해야 하며, (2) 그냥 임의의 심벌을 타이핑하여 조회하는 기능도 있어야 한다. 둘 다 필요하다.

2. 디렉터리를 불문하고 프로젝트에 있는 특정 파일 이름을 곧바로 타이핑으로 조회하여 파일 열기. 시작하는 단어와 중간에 있는 단어가 모두 지원되어야 한다.

3. 그리고 명칭이 아닌 임의의 문자열을 검색하는 Find in files인데, 다음과 같은 범위에서 모두 가능할 것.
(a) 소스(=번역 단위)든 헤더든 프로젝트에 정식으로 등록돼 있는 파일
(b) 프로젝트에 정식으로 등록은 안 돼 있지만, 등록된 파일로부터 인클루드에 의해 한 번이라도 엮이는 파일들
(c) 프로젝트 파일이 하나라도 존재하는 디렉터리에 덩달아 있는 모든 소스 파일들

즉, 3은 파일 내부의 문자열 검색이고 2는 파일 이름 자체의 검색이다. 2의 경우 일단은 검색 도메인이 (a)만으로 한정이지만, 2도 (b)나 (c)가 옵션에 따라 지원된다면 금상첨화다.

Visual Studio IDE의 경우, 1은 진작부터 인텔리센스 엔진을 통해 지원되어 왔다. 그러나 2는 2012에 와서야 가능해졌으며, 3은 (a)만 가능하다. (c)를 하려면 결국 프로젝트 경로를 수동으로 직접 입력해야만 가능하여 매우 불편함. 프로젝트에 존재하지는 않지만 같은 디렉터리에 있는 파일들을 덩달아 찾아야 할 때도 있는데도 말이다.

물론 (b)는 소스 코드를 컴파일까지는 아니어도 전처리기 수준의 파싱은 해야 구현 가능하기 때문에, 좀 어려울지 모른다. #include를 제대로 처리하려면 프로젝트 차원의 인클루드 디렉터리 관리자가 있어야 하며, 조건부 컴파일뿐만 아니라 인클루드 대상 자체에 대해서도 매크로 상수 전개가 필요할 때가 있으니 말이다.

c/cpp 같은 소스 코드가 그 자체로 온전한 번역 단위를 구성하는 게 아니라, 다른 소스 코드에 또 인클루드되어 쓰이는 경우가 있다. 물론 프로젝트에 등록되지 않은 채로 말이다.
이런 파일은 (a) 형태의 문자열이나 파일명 검색이 되지도 않아 대단히 불편하며, IDE가 구문 분석을 하는 것도 굉장히 복잡하고 어렵게 만든다. C/C++에서 인클루드는 정말 양날 달린 검인 게 실감이 간다.

끝으로 (b)와 관련된 여담 하나 좀 남기겠다.
과거 비주얼 C++ 6 시절엔 프로젝트 파일 리스트에 External dependencies라고 해서, 정식으로 프로젝트에 포함돼 있지는 않지만 프로젝트 파일에 의해 인클루드되는 파일을 대충, 얼추 계산해서 표시해 주는 기능이 있었다. '대충, 얼추'라는 말은 그 동작이 100% 정확하지는 않았다는 뜻이다. 그러던 것이 닷넷으로 넘어가면서 이 얼렁뚱땅 불완전한 기능은 삭제되었다.

그 뒤, 버전이 201x으로 넘어가면서 이 기능은 부활했다. 온전한 컴파일러가 소스 코드를 머리부터 발끝까지 다 분석하면서, MFC와 플랫폼 SDK가 중첩 인클루드하는 수십, 수백 개의 헤더 파일들을 하나도 빠짐없이 정확하게 나열해 주는 무시무시한 기능으로 다시 태어난 것이다. 비주얼 C++ IDE는 변화가 없는 것 같아도 내부적으로 이렇게 변모하고 있다.
모든 파일들의 의존도 정보를 파악하고 있다는 소리이니, 이를 바탕으로 함수 호출 tree처럼 파일들의 include 계층 다이어그램(includes / included by)을 그려 주는 기능은 IDE에 혹시 없나 궁금하다.

Posted by 사무엘

2014/04/21 08:28 2014/04/21 08:28
, ,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/954

Trackback URL : http://moogi.new21.org/tc/trackback/954

Comments List

  1. 김재주 2014/04/28 19:58 # M/D Reply Permalink

    최상위 제품에서는 분산 빌드를 지원하는 것 같던데요. 분산 빌드를 효율적으로 하려면 헤더 파일 의존성을 알고 있어야 하죠. 오픈 소스 분산 빌드 시스템인 distcc도 정적 분석을 통해 의존관계를 분석하고요. 이왕 구현하는 거 기능으로 집어넣은 모양입니다.

    1. 사무엘 2014/04/29 11:03 # M/D Permalink

      예. 핵심은 2010부터는 IDE의 인텔리센스용 컴파일러도 야메 가짜(NCB)가 아니라 정확한 full-scale로 바뀌었다는 점이죠.
      아, 그러고 보니 VC6 시절에는 MFC 클래스 위저드 전용 파서와 그 파서 전용 주석도 있었지요. //{AFX_ 뭐 이런 거... 그 주석을 지워 버리면 클래스 위저드도 바보가 됐고..
      그랬는데 닷넷 200x에서는 전용 주석이 없어도 함수의 선언과 정의 위치 정도는 알아서 감지하는 NCB 컴파일러 기반으로 바뀌었더랬습니다.

      구조 분석이 어려운 언어를 상대로 full-scale 컴파일러를 돌리기 곤란하던 옛날엔 이런 저런 꼼수가 많았었습니다.

Leave a comment
« Previous : 1 : ... 1370 : 1371 : 1372 : 1373 : 1374 : 1375 : 1376 : 1377 : 1378 : ... 2205 : Next »

블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Site Stats

Total hits:
3064879
Today:
190
Yesterday:
3190