Nov 23 2006

예제를 통해 Doxygen 주석 다는 방법 최대한 간단히 익히기

분류: Tip.Tech 태그: ,Heart @ 5:26 오후

Trackback : http://dev.heartsavior.net/archives/126/trackback/

나중에 까먹게 될 까봐 바로 사용할 수 있을 정도로 간략하게 간추려서 올림

* 예제는 실제 사용 중인 소스 코드를 타겟으로 함
* ‘최대한 간단히’ 에 주목
* 설치 및 운용, 자세한 사용법에 대해서는 다루지 않음(아래 사이트들을 참조)

http://parasite.pe.kr/?p=26 / http://parasite.pe.kr/?p=27
http://wiki.kldp.org/wiki.php/Doxygen
http://www.gpgstudy.com/gpgiki/DoxygenTutorial

* 대신, 설정 템플릿 파일은 올려 둠(급할 수도 있으니까)
– 옮기면서 첨부파일을 날림…

아래는 Doxygen 형식의 주석이 적용된 예제 소스이다.

/**
@file PropertiesUtil.h
@brief CPropertiesUtil 클래스 선언 헤더

*/

#if !defined(AFX_PROPERTIESUTIL_H__5B7DF824_3F5A_47F6_9AD3_A287733C8379__INCLUDED_)
#define AFX_PROPERTIESUTIL_H__5B7DF824_3F5A_47F6_9AD3_A287733C8379__INCLUDED_

#if _MSC_VER > 1000
#pragma once
#endif // _MSC_VER > 1000

#include “stdafx.h”

#define PROPERTY_LOAD_SUCCESS 1 /**< 파일 파싱까지 성공함 */
#define PROPERTY_LOAD_FILE_FAILED 0 /**< 파일 로드에 실패함 */
#define PROPERTY_ERROR_LINE_MUL -1 /**< 여기에 * n(에러 행 번호) 해서 리턴하게 됨 */

/**
@brief 설정 파일을 읽어서 보관하는 클래스

설정 파일의 구조는 다음과 같다.
- 첫 글자가 # 이면 그 라인은 주석
- 빈 라인은 대상이 되지 않음
- ‘속성 = 값’ 으로 이루어진다.
*/
class AFX_EXT_CLASS CPropertiesUtil
{
public:
/**
* @brief 생성자\n
* 아무 일도 하지 않는다.
*
*/
CPropertiesUtil();

/**
* @brief 소멸자\n
* 아무 일도 하지 않는다.
*
*/
virtual ~CPropertiesUtil();

/**
@brief 설정 파일을 읽어들여서 파싱하고 각 설정들을 저장

@param szFileName 읽어들일 설정 파일 이름
@return 에러 유무
@see PROPERTY_ERROR_LINE_MUL
@see PROPERTY_LOAD_FILE_FAILED
@see PROPERTY_LOAD_SUCCESS
*/
int LoadFile(const char * szFileName);

/**
@brief 속성에 해당하는 값을 맵에서 찾아서 전달인자에 설정

@param szKey 속성 이름
@param csValue 속성에 해당하는 값
@return 속성의 존재 유무
*/
BOOL GetMatchedValue(const char * szKey, CString & csValue);

private:
CMapStringToString m_mapKeyToVal; /**< 키와 값을 매핑시킨 객체 */

};

#endif // !defined(AFX_PROPERTIESUTIL_H__5B7DF824_3F5A_47F6_9AD3_A287733C8379__INCLUDED_)

JavaDoc 유저라면 보기만 해도 어떻게 하는 건지 짐작이 올 것이고, 아니어도 감이 올 거라 생각한다.

많은 주석 스타일 중에 JavaDoc 스타일을 선택하였고( /** ~ */ ) 속성도 필요한 것만 사용하였다.
속성들은 앞에 @를 붙이고 있다. 물론 다른 스타일은 !도 있는데, 여기서는 그냥 @만 생각하자.

file : 일반적으로 파일 명을 기술
brief : 함수에 대해 간략하게 기술
주의사항 - 상세 기술과 구분하기 위해 한 라인을 비워야 한다.
param : 파라미터에 대해 기술
see : 참조할 함수나 클래스, define값, struct 등을 기술
return : 리턴값에 대해 기술


속성 없이 쓰여진 텍스트는 상세 기술이라고 생각하면 된다.

이제 Doxygen을 구동시키자. 구동시키면 첨부파일과 같은 내용의 html파일들이 쭉 나오고,
첨부파일은 이를 Doxygen이 chm으로 자동으로 컴파일해 준 것이다.
한번 열어서 확인해 보기 바란다.

– 역시 첨부파일을 날림…

이제 C/C++ 유저도 JavaDoc를 부러워하지 말 지어다.


Nov 23 2006

Doxygen & VC++ 6 한 가지 조금 아쉽네…

분류: Dev.Think 태그: ,, Heart @ 1:10 오후

Trackback : http://dev.heartsavior.net/archives/127/trackback/

요점만 먼저 말하자면, 함수 주석 쓰는 부분이 참 아쉬운 것 같다.

혹시 모르시는 분들을 위해 잠깐 설명을 하자면,
Doxygen에서는 주석을 함수 프로토타입에 써도 되고, 함수 정의에 써도 된다.

그런데 VC++ 6에서 마우스로 갖다대면 나오는 힌트(라지만 주석 뿌리기)는 함수 프로토타입에 적힌 주석만 보여주도록 되어 있다.

그럼 해답은 함수 프로토타입에 쓰면 될까?
맞다. 쓰면 된다. Not bad…

하지만, 솔직히 귀찮은 작업임에 틀림이 없다.
설계를 잘 했다면 작업할 때 프로토타입 한번 선언하면 자주 수정하지 않는 게 당연한 것이고, 그에 비해 구현은 수정이 많이 갈 수 있고, 그 수정으로 인해 주석의 변경이 있어야 될 경우도 있기 때문에 함수 정의에 주석을 달아주는 게 좀(많이?) 과장해서 10배는 편하다.

그렇다고 이제 와서 VC++ 6 서팩 7 만들어서 정의에 쓴 주석도 보여달라고 해 봐야 VS 2005가 나온 마당에 해줄 리도 만무하고…

힘없는 자가 참아야지… ㅜ.ㅜ


Nov 12 2006

Google vs Naver?

분류: Dev.Think 태그: ,, , , Heart @ 10:54 오전

Trackback : http://dev.heartsavior.net/archives/128/trackback/

구글이 전 세계 검색 시장을 장악했는데, 유독 한국은 장악하지 못했다.
그리고 그 중심에는 네이버가 있었다.
(어디서 많이 보던 상황인 것 같다… MS 워드와 한글을 보는 것 같지 않은가?)

익히 알고 있겠지만, 구글 검색엔진의 강점은 강력한 페이지 랭킹이고,
네이버의 강점은 지식인, 카페, 블로그, 사전(백과사전 포함), 인물 정보 등의 다양한 수단에서 정보를 얻어낸다는 데 있다.
그리고 그 이면에는 일명 ‘수작업’이 있다.

그래서인지 혹자는 ‘수작업에 의한 승리’, ‘검색 성능으로 승부를 안보고 온갖 잡다한 정보로 이기려 든다’ 고 하여 구글 찬양 네이버 즐~ 하면서 까내리는 사람들이 많다.
하지만, 내 의견은 조금 다르다.

수작업에 의한 승리? 온갖 잡다한 정보? 그게 뭐 잘못된 건가?
법령에 ‘검색은 무조건 봇이 알아서 하도록 만들어야 한다’ 라고 명시되어 있는 것도 아니지 않는가?
웹 페이지 crawling에 의한 데이터만 검색에 반영하라는 법령도 없지 않은가?

이 모든 것은 개발자의 입장에서, 혹은 IT인의 입장에서 이 둘을 비교했기 때문이 아닐까?

나도 개발자이고, 잠시나마 대학교 자연어처리/검색엔진 관련 연구실에도 있어봤고 해서 구글 기술 대단한 건 전 세계 개발자들 전부 동감하고, 나도 동감한다.
기술력이야 구글 검색엔진이 대단하지. 페이지랭킹 기술, 구글 서버들의 연동, OS 개발, 엄청난 웹 페이지 데이터베이스 등…
기업 자체도 곧 MS랑 맞먹을 정도 까지 성장할 것으로 내다보고 있는데…

하지만 그건 단지 개발자 입장에서 본 기술력에 대한 찬양일 뿐, 그 이상도 그 이하도 아니다.

게임이 렌더링 성능 좋고 그래픽 좋고 사운드 좋다고 무조건 뜨는 게 아니다.
어떻게 보면 게임에서 가장 염두에 두어야 할 것은 시나리오와 인터페이스, 전체적인 게임 스피드, 조작감 등이다.

검색도 마찬가지다.
페이지 랭킹, 수작업, 인덱싱, …… 유저 입장에서 알 바 아니다.
나온 결과가 유저가 원하는 결과를 가장 편하고 많이 표현해야 되는 것이 아닌가?

검색된 웹 페이지만 페이지 랭킹에 의해 나열해 주는 구글, 검색어를 또 분류하여 그에 대한 온갖 정보를 모두 끌어와서 보여주는 네이버
일반 유저 입장에서 어느 쪽이 편하게 쓸 수 있을까?

개발자가 쓰라고 검색엔진이 존재하는 게 아니다.
오히려 컴퓨터를 사용하는 인구 중에 개발자만 따지자면 소수의 측에 속한다.

그럼 어느 쪽에 맞춰주는 것이 현명한 것일까?

난 오히려 네이버가 각 나라에 맞게 커스터마이징을 잘 하면 구글 시장을 뚫고 세계로 진출할 수 있다고 생각한다.


뒷 쪽 »