기 작성되어 있던 C++ 컴포넌트에서 한개의 함수에 너무 많은 코드로 인해,
컴파일러 내부 오류를 경험하고 해당 코드에 대해서 리팩토링을 결심!!

관련된 작업은 Extract Method 이며 자동으로 해당 부분을 추출하여 Method를 만들어 주는 툴을 중심으로 알아 보았다.

이것 저것 알아보던 중 2개의 후보가 눈에 띠었다.
대상은 "Refactor! For Visual C++ 2005"와 "Visual Assist X" 에서 지원하는 Refactoring 에 관련된 기능이다.

결론부터 얘기하면 "Refactor! For Visual C++ 2005"의 기능이 쓸만 하였고 Visual Assist X 의 리팩토링 기능은 간단한 기능을 제외하고는 그다지 유용하지 못하였다.


Visual Assist X
Visual Assist X 는 Visual Studio 에서 코딩에 도움을 주는 유용한 기능이 있는 Add-in 툴로서 최신 버전에는 리팩토링 기능까지 추가가 되었다.

예상했던 대로 속도는 무난히 빨랐으며 간단한 목적으로 사용하기에는 문제가 없으나 몇가지 사항에 대해서는 조심히 사용 해야 될듯하다.

1. Extract Method 의 경우 10개 까지의 파라미터 까지 밖에 지원 하지 않는다.
  - Extract Method의 대상 코드의 파라미터의 지원이 10개까지 밖에 지원하지 않는다
  - 나머지에 대해서는 수작업 신공..

2. Extract Method 의 구문 중 return 이 포함되어 있는 구문에 대해서 별 다른 코드를 넣어주지 않는다.
  - 이것도 나머지는 수작업 신공 -_-;

// 원본코드
bool Run()
{
    int a = 0;
    if (a == -1) {
        return false;
    }

    cout << "next process " << endl;

    a = 10;
    return true;
}

// Extrace Method 후의 코드
bool MyMethod( int a )
{
    if (a == -1) {
        return false;
    }

    cout << "next process " << endl;
}



bool Run()
{
    int a = 0;
    return MyMethod(a);

    a = 10;
    return true;
}


3. Rename 의 경우 바꾸지 못하는 경우 발생
  - 특수한 경우에 구문 분석으로 발견하지 못하여 변경을 못해주는 경우 발생

4. VC++6, VC++2005 버전등 여러 버전 사용 가능
  - 단 VC++6 의 경우 코드 "실행 취소"로 되 돌릴 경우 리팩토링 액션 단위가 아닌 한줄 한줄의 단위로 되 돌리기가 된다.
  - 머 이것도 VC++6 을 안쓰면 되지 머..




Refactor! For Visual C++ 2005

1. 모든 기능적인 부분에서 합격점이지만 속도가 많이 느린 경우 발생
  - 특히 많은 코드에 대해서 리팩토링의 경우 IDE가 뻣었나! 라는 생각이 들 정도로 행이 걸려 있는 상태가 지속
  - 아마도 아래와 같은 UI 부분의 지원 때문에 느리지 않나 생각이 들며 IDE를 처음 로딩할때도 DxCore 라는 모듈을 로딩할때 시간이 좀 걸린다.

refactor1.jpg



2. Visual Assist X 에서 문제였던 코드 중간의 return 부분을 별도의 return 여부를 판단하는 파라미터를 이용하여 처리 해주고 있다.

// 원본코드
bool Run()
{
    int a = 0;
    if (a == -1) {
        return false;
    }

    cout << "next process " << endl;

    a = 10;
    return true;
}


bool RunExtracted(int a, bool &pShouldReturn)
{
    pShouldReturn = false;
    if (a == -1) {
        pShouldReturn = true;
        return false;
    }

    cout << "next process " << endl;
    return false;
}

bool Run()
{
    int a = 0;
    bool lShouldReturn;
    bool lResult = RunExtracted(a, lShouldReturn);
    if (lShouldReturn)
        return lResult;

    a = 10;
    return true;
}


3. Rename 등의 작업을 할때 링크 라는 개념의 함수의 정의, 구현, 호출 부분을 연결된 데이터를 관리하며 UI도 비슷하게 동작을 하는것 같다
  - 허나 UI때문인지 속도 부분에서도 약간 더딘 면이 없지 않아 있다.


4. 무엇보다도 장점인 무료.. 허나 현재는 VC++ 2005만 무난히 적용 되는 것으로 보이며, 
추후에는 더 발전 되어있는 모습으로 더욱 쓸만한 툴이 되지 않을까 생각한다.



결론.

위의 두개의 툴은 그 외에도 많은 리팩토링 기법의 도구를 제공을 하며,
C++의 문법 복잡성에 의해 다른 언어에 비해서 많이 더뎠던 리팩토링 자동화 부분에서 어느정도 해소가 되지 않았나 생각이 든다.

아  이제 C++에서도 리팩토링을 툴로 제공을 하는구나... 흐흐..

앞으로 좀 더 발전을 하면 VC++ 에서도 C#처럼 내장 IDE에서 리팩토링을 제공을 하는 날이 있지 않을까 생각을 한다.



이상 허접한 리팩토링 툴 비교기..

'Dev > C++' 카테고리의 다른 글

C++0x Lambda  (0) 2009.05.20
C++0x 지원 컴파일러 목록  (0) 2009.05.20
An Overview of the Coming C++ (C++0x) Standard  (0) 2008.12.29
asio C++ library  (0) 2008.08.22
C++ 0x - Herb Sutter의 블로그 글  (0) 2008.07.29




C++ 0x에 대한 리뷰 동영상인가 보다.

시간있을때 하나씩 정리를 해볼까 하는데.. 움..

'Dev > C++' 카테고리의 다른 글

C++0x 지원 컴파일러 목록  (0) 2009.05.20
C++ Refactoring  (0) 2009.04.14
asio C++ library  (0) 2008.08.22
C++ 0x - Herb Sutter의 블로그 글  (0) 2008.07.29
C++ 0x  (0) 2008.05.09
http://sourceforge.net/projects/asio/

asio is a cross-platform C++ library for network and low-level I/O programming that provides developers with a consistent asynchronous model using a modern C++ approach.


asio 는 클로스 플랫폼은 지원하는 네트워크 라이브러리이다

ACE와는 비교도 안되게 가볍고 C++ 헤더로만 이루어져 있어 별도의 라이브러리 컴파일 과정이 필요없다.
그리고 각 플랫폼에 맞는 동기/비동기 모델을 하나의 인터페이스로 구현을 하여 유연성있는 네트워크 프로그램을 제공을 한다

boost 1.35부터 포함되어 있어 boost 라이브러리를 통해서 사용가능하고 직접 다운받아 stand alone 으로도  사용 가능하다


Download 쪽 항목을 보면 asio-tr2 라고 하는 패키지가 보이는데,
C++ tr2의 네트워크 라이브러리에 대한 제안서로 보인다.

개인적으로 tr2에 정의되어 있는 네트워크 라이브러리의 C++ 구현 인터페이스가 무지 궁금하지만,
asio 를 채택하는것도 그리 나쁜 선택은 아니라고 판단된다.


ps.
tr2의 내용중에 XML, HTML, Networking 같은 경우는 boost와 같이 C++ 계에서 주도적(?)으로
사용되는 것이 없어서 어떤 것들이 채택(혹은 구현)될지 궁금하다.

tr2의 주 내용
Unicode
XML and HTML
Networking
Usability for novices and occasional programmers


'Dev > C++' 카테고리의 다른 글

C++ Refactoring  (0) 2009.04.14
An Overview of the Coming C++ (C++0x) Standard  (0) 2008.12.29
C++ 0x - Herb Sutter의 블로그 글  (0) 2008.07.29
C++ 0x  (0) 2008.05.09
memory pooling - code  (0) 2008.05.01

Herb Sutter 블로그의 C++ 0x 에 대한 리포트 링크 정리
http://herbsutter.wordpress.com/



http://herbsutter.wordpress.com/2007/05/10/trip-report-april-2007-iso-c-standards-meeting/

- 템플릿 별칭(aliase), 가변 템플릿 파라미터, using 용법 확장에 대한 내용들


http://herbsutter.wordpress.com/2007/09/10/trip-report-july-2007-iso-c-standards-meeting/

- 새로 추가되는 기능들에 대한 내용들
- constexpr, decltype  등...


http://herbsutter.wordpress.com/2007/11/01/trip-report-october-2007-iso-c-standards-meeting/

- C++ 0x 의 시기와 주요 컨셉에 관한 글
- nullptr 에 대한 소개
- threading, Concurrency, Atomic 에 관한 내용들


http://herbsutter.wordpress.com/2008/03/29/trip-report-februarymarch-2008-iso-c-standards-meeting/

- Lambda function and closure 에 관한 내용들


http://herbsutter.wordpress.com/2008/07/04/trip-report-june-2008-iso-c-standards-meeting/

- 초기화에 관한 내용들
- STL에서의 배열 초기화나 클래스 멤버의 초기화 문법에서의 초기화에 관한 이야기

'Dev > C++' 카테고리의 다른 글

An Overview of the Coming C++ (C++0x) Standard  (0) 2008.12.29
asio C++ library  (0) 2008.08.22
C++ 0x  (0) 2008.05.09
memory pooling - code  (0) 2008.05.01
Is Derived - code  (0) 2008.05.01

차세대 C++ 표준인 C++ 0x 의 언어적인 추가 사항 정리
(C++ 1x 가 되지 않기를 빈다... ^^;)


- UTF-8, UTF-16 지원

= u8"I'm a UTF-8 string."
= u"This is a UTF-16 string."
= U"This is a UTF-32 string."


- Template Aliases

#include <vector>

template<typename T>
class MyAllocator {
};

template<typename T>
using MyVector = std::vector<T, MyAllocator<T>>;

MyVector<int> vec;


 - Allow sizeof to apply to non-static data members

Currently the C++ Standard does not allow the following:

struct S {
   int m;
};

sizeof(S::m)


- Generalized Constant Expressions - constexpr

아래의 코드처럼 작동하기 위해 추가된것 같다
이미 C 99 표준에서는 배열크기에 대해서 상수가 아닌 지역변수도 허용되는데 그것과는 또 다른 지원방식


constexpr int Number ()
{
    return 5;
}

double array[Number()];


constexpr int square(int x)
{
    return x * x;
}

float array[square(9)];  



- 중첩된 template 선언에서 >> 연산자의 문법오류

#include <vector>

// 현재의 경우 아래의 문법이 에러가 난다
// 이유는 마지막에 >> 부분이 중첩 tempate 문법의 닫는 의미가 아닌 시프트 연산자로 인식
// C++ 0x 버전에서는 문제없이 컴파일 될수 있도록 조치
typedef std::vector<std::vector<bool>> Flags;

// 그래서 아래와 같이 해야 했다
typedef std::vector<std::vector<bool> > Flags;


- auto 키워드 추가

컴파일 타임에 자동으로 타입을 유추하여 타입을 확정해주는 auto 라는 키워드 추가

for (vector<int>::const_iterator itr = myvec.begin(); itr != myvec.end(); ++itr) {} // 타입명시

for (auto itr = myvec.begin(); itr != myvec.end(); ++itr) {} // auto 사용


- stl 컨테이너에 배열 초기화 허용

내 생각에는 {1, 2 } 의 형식을 바로 타입(ex: int p[])으로 인식할수 있게끔 된것이 아닌가 생각이 드는데 확인을 해봐야 할것같다

std::vector<double> v = { 2.3, 1.2, 6.7, 4.5  };


- for each 형식의 문법 지원

네이티브 타입만 지원하는지 컨테이너도 지원 하는지 확인 해봐야 할듯

int my_array[5] = {1, 2, 3, 4, 5};
for(int &x : my_array)     // 참조 주목
{
    x *= 2;
}


- Lambda, Closure 형식 문법 지원

boost::lambda 은 정말 놀랍다.
그런데 이런걸 언어차원에서 지원하다니..

// 기존 for 문
for(vector<Widget>::iterator i = w.begin(); i != w.end(); ++i) {
    cout << *i << " ";
}

// boost::lambda
for_each( w.begin(), w.end(), cout << _1 << " " );

// C++0x lambda
for_each( w.begin(), w.end(), []( const Widget& w ) { cout << w << " "; } );



참고 사이트 :
http://blogs.msdn.com/vcblog/archive/2007/06/04/update-on-the-c-0x-language-standard.aspx
http://www.jong10.com/246

'Dev > C++' 카테고리의 다른 글

asio C++ library  (0) 2008.08.22
C++ 0x - Herb Sutter의 블로그 글  (0) 2008.07.29
memory pooling - code  (0) 2008.05.01
Is Derived - code  (0) 2008.05.01
C++에서 프로퍼티 구현하기  (0) 2008.05.01

MemPooling #

메모리 풀링 클래스

Efficient C++(Dov Bulka , David Mayhew)에서 많은 도움은 얻음
나름대로 좋은 성능을 냄

/**
 * MemPool.h
 *
 * Memory Pooling Class
 *
 * Copyright (c) 2004 by cdecl (byung-kyu kim)
 *
 */

#ifndef __MEM_POOL_H__BY__CDECL
#define __MEM_POOL_H__BY__CDECL


namespace GLASS {

// MemPool Class 
class MemPool
{
public:
    typedef unsigned int size_type;
    enum { DEFAULT_CHUNK_SIZE = 32 };

    struct MemNode { MemNode *next_; };

public:
    MemPool(size_type type_size, size_type chunk_size = DEFAULT_CHUNK_SIZE) :
        pHead_(0), pFree_(0), nUsed_(0),
        TYPESIZE(type_size > sizeof(MemNode*) ? type_size : sizeof(MemNode*)),
        CHUNK_SIZE(chunk_size)
    {
        ExpanseChunk();
    };
    ~MemPool() { Release(); }

public:
    void* malloc()
    {
        if (IsFull()) {
            if (pFree_) return (NodeNext(pFree_));

            ExpanseChunk();
        }

        int nOffSet = sizeof(MemNode*) + (TYPESIZE * nUsed_++);
        return (reinterpret_cast<char*>(pHead_) + nOffSet);
    }

    void free(void *p)
    {
        MemNode *pmn = reinterpret_cast<MemNode*>(p);
        pmn->next_ = pFree_;
        pFree_ = pmn;
    }

    void ExpanseChunk()
    {
        size_type nAllocSize = TYPESIZE * CHUNK_SIZE + sizeof(MemNode*);

        MemNode *pmn =
            reinterpret_cast<MemNode *>(::operator new(nAllocSize));

        nUsed_ = 0;;

        pmn->next_ = pHead_;
        pHead_ = pmn;
    }

    bool IsFull() const
    {
        return nUsed_ >= CHUNK_SIZE;
    }

    void Release()
    {
        while (pHead_ != 0) {
            ::operator delete(NodeNext(pHead_));
        }
    }

private:
    inline MemNode* NodeNext(MemNode *&pmn)
    {
        MemNode *p = pmn;
        pmn = pmn->next_;
        return p;
    }

private:
    // No Copy
    MemPool(const MemPool&);
    MemPool& operator=(const MemPool&);

private:
    MemNode *pHead_;
    MemNode *pFree_;

    size_type nUsed_;

private:
    const size_type TYPESIZE;
    const size_type CHUNK_SIZE;

};


} // namespace GLASS

#endif

'Dev > C++' 카테고리의 다른 글

C++ 0x - Herb Sutter의 블로그 글  (0) 2008.07.29
C++ 0x  (0) 2008.05.09
Is Derived - code  (0) 2008.05.01
C++에서 프로퍼티 구현하기  (0) 2008.05.01
boost::pool 예제  (0) 2008.05.01

Is Derived #


처음에 이 소스에서 template의 가능성을 보고 뒷통수를 맞은 기분 이었습니다.
기본적인 내용은 Base에서 Derived가 상속 되었느냐를 확인 하는 코드 입니다.
이 예제 뿐만 아니라 Modern C++ Design(Andrei Alexandrescu)에는 무궁무진한 template의 향연이 펼쳐집니다.


아래의 예제는 More Exceptional C++(Herb Sutter)에 나오는 내용입니다.
원본은 Andrei Alexandrescu에 의해 작성된 글이라고 More Exceptional C++에서 명시 하고 있습니다.
제가 컴파일러에서 테스트하고 수정한 소스입니다.
//////////////////////////////////////////////////////// 
#include <iostream>
using namespace std;


template <class Derived, class Base>
class IsDerived
{
private:
    class YES { char c[2]; };
    class NO {};

    static YES Test(Base *p);
    static NO Test(...);

public:
    // VC++, g++ 문제 없음 
    static bool Is()
    {
        return (sizeof(Test(static_cast<Derived *>(0))) == sizeof(YES));
    }

    // VC++ 문제없음 
    // g++ 3.2 컴파일 안됨 
    // g++ 3.4.1 에서는 문제 없음
    // enum { Is = (sizeof(Test(static_cast<Derived *>(0))) == sizeof(YES)) }; 

};


class B {};

class C : public B
{};


int main()
{
    cout << IsDerived<C, B>::Is() << endl;
}

'Dev > C++' 카테고리의 다른 글

C++ 0x  (0) 2008.05.09
memory pooling - code  (0) 2008.05.01
C++에서 프로퍼티 구현하기  (0) 2008.05.01
boost::pool 예제  (0) 2008.05.01
STLport 초간단 설치  (1) 2008.05.01

C++에서 프로퍼티 구현하기 #


C++에서 템플릿을 이용한 프로퍼티를 구현한 소스입니다.
VC++에서는 프로퍼티를 컴파일러 차원에서 지원하지만 이건 ANSI 코드입니다.

출처는 BorlandForum 이고 보다 안정적이게 소스를 수정했습니다.

#ifndef __PROP_H__BY_CDECL__ 
#define __PROP_H__BY_CDECL__ 

namespace Glass {

class IYES {};
class YES : public IYES {};
class NO {};

template <class T, class Parent, class ReadWrite = YES>
    class Prop
{
public:
    typedef Prop<T, Parent> this_type;
    typedef T (Parent::*get_fun)();
    typedef void (Parent::*set_fun)(const T&);

    Prop() : getf_(NULL), setf_(NULL), parent_(NULL) {}

    void SetParent(Parent *p) {
        parent_ = p;
    }

    void Set(set_fun f) {
        ReadWrite yn;
        IYES *p = &yn; // 읽기전용일때 이함수를 사용하면 컴파일 에러 !! 

        setf_ = f;
    }

    void Get(get_fun f) {
        getf_ = f;
    }

    T operator=(const T &value) {
        ReadWrite yn;
        IYES *p = &yn; // 읽기전용일때 이함수를 사용하면 컴파일 에러 !! 

        if (!setf_) {
            throw exception();
        }

        (parent_->*setf_)(value);
        return value;
    }

    T operator=(this_type &type) {
        return operator=(static_cast<T>(type));
    }

    operator T() {
        if (!getf_) {
            throw exception();
        }

        return (parent_->*getf_)();
    }

private:
    Parent *parent_;
    get_fun getf_;
    set_fun setf_;

};


} // namespace Glass 

#endif // __PROP_H__BY_CDECL__ 



#include <iostream>
#include <string>
using namespace std;


class AA
{
public:
    AA() {
        Str.SetParent(this);
        Str.Set(&AA::setStr);
        Str.Get(&AA::getStr);
    }

    void setStr(const string &str)
    {
        cout << "setStr" << endl;
        str_ = str;
    }

    string getStr()
    {
        cout << "getStr" << endl;
        return str_;
    }

    Glass::Prop<string, AA> Str;
    string str_;
};


int main()
{
    AA a;
    a.Str = "cdecl ";

}

'Dev > C++' 카테고리의 다른 글

memory pooling - code  (0) 2008.05.01
Is Derived - code  (0) 2008.05.01
boost::pool 예제  (0) 2008.05.01
STLport 초간단 설치  (1) 2008.05.01
Stroustrup - The real interview  (0) 2008.05.01

boost::pool 예제 #

boost::pool을 사용한 메모리 풀링.
빈번한 메모리를 사용할때에 유용하다고 판단.

#include <iostream>
#include <string>
using namespace std;

#include <windows.h>
#include <boost/pool/pool.hpp>

class VM
{
public:
    void* operator new(size_t s)
    {
        return bpool.malloc();
    }

    void operator delete(void *p)
    {
        bpool.free(p);
    }

private:
    char sz[100];

private:
    static boost::pool<> bpool;
};

boost::pool<> VM::bpool(sizeof(VM));


class NVM
{
private:
    char sz[100];
};


template <class Ty>
DWORD PoolingTest()
{
    enum { COUNT = 1000, LOOP = 500 };

    DWORD dw = GetTickCount();
    Ty *pArr[LOOP];

    int i, j;
    for (i = 0; i < COUNT; ++i) {
        for (j = 0; j < LOOP; ++j) {
            pArr[j] = new Ty();
        }
        for (j = 0; j < LOOP; ++j) {
            delete pArr[j];
        }
    }

    return GetTickCount() - dw;
}


int main()
{
    cout << "pooling: " << PoolingTest<VM>() << endl;
    cout << "normal: " << PoolingTest<NVM>() << endl;

    cout << "END" << endl;
    cin.get();
    return 0;
}



컴파일 환경
CPU: P3 600 (notebook)
RAM: 320

gcc version 3.4.1 (mingw special)

결과
pooling: 100
normal: 581
END

'Dev > C++' 카테고리의 다른 글

Is Derived - code  (0) 2008.05.01
C++에서 프로퍼티 구현하기  (0) 2008.05.01
STLport 초간단 설치  (1) 2008.05.01
Stroustrup - The real interview  (0) 2008.05.01
qsort vs sort  (0) 2008.05.01

STLport의 사용이유 #

  • VC++ 6.0의 내장된 STL 구현이 비표준인것들이 많아 사용상 어려움
  • 부분적으로 내장된 STL보다 성능이 뛰어남
  • VC++ 7.0 이후 버전은 개인적으로 자체 STL사용 권장


STLport 초간단 설치 #

STLport의 설치방법중 커맨드명령(IDE 없이)을 통해 설치하는 방법을 이용한다.
(개인적으로 이방법이 가장 편하고 쉬움)

VC++ 6.0을 사용할때 서비스팩은 항상 설치 권장
  • sp5 or sp6


STLport 받기 #

아래의 사이트에서 Current release version파일을 받음
받은 압축된(gz이나 zip파일) 파일을 아무데나 풀기


컴파일하기 #

압축을 푼 디렉토리에서 src디렉토리로 이동하여 컴파일 한다.
nmake -f vc6.mak 

컴파일후 lib 디렉토리가 생성되며 lib디렉토리에는 컴파일된 결과물인 Object파일과 lib, dll 파일들이 생성된다.


설치하기 #

nmake -f vc6.mak install

VC++의 환경변수를 세팅 안했다면 아래와같은 메세지가 나올것이다
Microsoft (R) Program Maintenance Utility   Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

하위 디렉터리 또는 파일 ..\\lib이(가) 이미 있습니다.
하위 디렉터리 또는 파일 ..\\lib\\obj이(가) 이미 있습니다.
하위 디렉터리 또는 파일 ..\\lib\\obj\\VC6이(가) 이미 있습니다.
"Please set up MSVCDir environment variable. Did you run vcvars32.bat ?"
지정된 파일을 찾을 수 없습니다.
NMAKE : fatal error U1077: 'if' : return code '0x1'
Stop.

VC++의 환경변수를 세팅한다
vcvars32.bat

그리고 다시 install
nmake -f vc6.mak install
Setting environment for using Microsoft Visual C++ tools.
E:\Library\공개라이브러리\STLport-4.6\src>nmake -f vc6.mak install

Microsoft (R) Program Maintenance Utility   Version 6.00.9782.0
Copyright (C) Microsoft Corp 1988-1998. All rights reserved.

하위 디렉터리 또는 파일 ..\\lib이(가) 이미 있습니다.
하위 디렉터리 또는 파일 ..\\lib\\obj이(가) 이미 있습니다.
하위 디렉터리 또는 파일 ..\\lib\\obj\\VC6이(가) 이미 있습니다.
Copying STLport .lib files to VC lib directory : E:\PROGRA~1\MICROS~1\VC98\lib..
.
..\\lib\stlport_vc6.lib
..\\lib\stlport_vc6_static.lib
..\\lib\stlport_vc6_stldebug.lib
..\\lib\stlport_vc6_stldebug_static.lib
        4개 파일이 복사되었습니다.
Done copying .lib files.
Copying STLport DLLs to Windows system directory...
..\\lib\stlport_vc646.dll
..\\lib\stlport_vc6_stldebug46.dll
        2개 파일이 복사되었습니다.
STLport DLL libraries are installed on your system.
Copying STLport headers files to VC include directory : E:\PROGRA~1\MICROS~1\VC9
8\include\stlport...
414개 파일이 복사되었습니다.
Done copying STLport headers.
STLport installation complete.
Please find STLport headers in E:\PROGRA~1\MICROS~1\VC98\include\stlport.
Please find STLport .lib files in E:\PROGRA~1\MICROS~1\VC98\lib.
Please find STLport DLLs in Windows system directory.


설치내용 #

설치(install)의 경우 다음과 같은 내용이 실행된다.
  1. 윈도우의 System디렉토리에 다음 2개의 dll을 복사한다.
    • stlport_vc646.dll (릴리즈용)
    • stlport_vc6_stldebug46.dll (디버그용)

  2. VC 6.0 의 lib 디렉토리에 lib파일 4개를 복사한다.
    • stlport_vc6.lib (릴리즈용 DLL)
    • stlport_vc6_static.lib (릴리즈용 static)
    • stlport_vc6_stldebug.lib (디버그용 DLL)
    • stlport_vc6_stldebug_static.lib (디버그용 static)

  3. VC 6.0 include 디렉토리 밑에 stlport 디렉토리를 복사한다.


사용하기 #

VC++ 6.0 IDE의 include 경로를 잡아준다. (한번만 해주면됨)
  • Tools -> Options 메뉴에서 include 디렉토리를 VC++ 6.0의 include디렉토리 밑의 stlport디렉토리를 새로만들어 맨위로 올려준다
    • ex) E:\PROGRAM FILES\MICROSOFT VISUAL STUDIO\VC98\INCLUDE\STLPORT

  • STLport를 사용하지 않을때는 stlport 디렉토리는 맨밑으로 내린다.

Use run-time library 를 지정한다.
  • 프로젝트마다 지정한다.
  • Project -> Settings -> C/C++ (탭) -> Category를 Code Generation -> Use run-time library:
  • 아래의 4개중 하나를 지정한다.
    • Multithreaded
    • Multithreaded DLL
    • Debug Multithreaded
    • Debug Multithreaded DLL

  • Single-Threaded 나 Debug Single-Threaded는 링크시 심볼 출동로 링크에러가 남.


배포하기 #

static (Multithreaded or Debug Multithreaded)으로 컴파일을 했을 경우는 코드가 포함되므로 따로 배포 할것이 없다 - 대신 실행파일(혹은 DLL)의 바이너리 크기가 커진다.

DLL 버전 (Multithreaded DLL or Debug Multithreaded DLL)으로 컴파일 했을경우 아래의 파일을 같이 배포해야한다.

(버전 4.6 기준)
Use run-time library 필요한 DLL
Multithreaded DLL stlport_vc646.dll
Debug Multithreaded DLL stlport_vc6_stldebug46.dll

'Dev > C++' 카테고리의 다른 글

C++에서 프로퍼티 구현하기  (0) 2008.05.01
boost::pool 예제  (0) 2008.05.01
Stroustrup - The real interview  (0) 2008.05.01
qsort vs sort  (0) 2008.05.01
최소 완전한 클래스를 만들어라  (0) 2008.05.01

실제 Stroustrup 인터뷰(The real interview) #


원문: B. Stroustrup, "The real Stroustrup interview," IEEE Computer, vol. 31, no. 6, pp. 110-114, June 1998.
번역문: 서진택의 C++ complete guide중에서 발췌

'The Design and Evolution of C++'(Addison Wesley, 1994)에서, Bjarne Stroustrup은 아래와 같이 논의했다.
"프로그래밍 언어는 실제로 세계(world)의 극히 작은 부분입니다. 그러므로 그것은 너무 심각하게 간주되어서는 안 됩니다. 일부분(proportion)의 감각(역자주: '프로그래밍 언어는 전 세계에 비하면, 매우 작은 부분이다'는 감각)을 유지하면서, 그리고 더욱 중요하게 유모어(humor) 감각을 유지해야 합니다. 중요한 프로그래밍 언어 중에서, C++는 익살과 농담의 풍부한 자원입니다. 그것은 우연이 아닙니다."
지난 몇 달 동안, Stroustrup과 IEEE Computer 잡지와의 가짜(hoax) 인터뷰가 사이버스페이스에서 회자(make round)되었다. 우리는 그 사건에 대해 유감스럽게 (regret) 생각한다. 하지만, 그것이 우리로 하여금 C++의 대부와, 표준 C++과 일반적인 소프트웨어 개발에 대한 그의 통찰력(insight)을 나눌 좋은 기회를 허락하였다. 우리는 또한 그의 지속적인 부분(proportion)과 유머(humor)에 대한 감각을 증명할 수 있었다(그는 그 우스꽝스러운 인터뷰를 만약 그 자신이 썼다면, 더 재미있는 개작(parody)이 되었을 거라고 제안했다).

- Scott Hamilton, Computer

표준 C++(STANDARD C++)

Computer: ISO(그리스어 isos의 파생어, International Organization for Standardization)는 표준 C++을 1997년 11월 승인하였습니다. 그리고 당신은 당신의 책 'The C++ Programming Language'(Addison Wesley, 1997)의 3번째 판을 출판하였습니다. 지난 몇 년간 C++가 어떻게 발전하였으며, ISO 표준이 C++ 공동체(community)에 무슨 의미를 갖는지 이야기해 주시겠습니까?

Stroustrup: 마침내 완벽하고(complete), 상세하며(detailed), 견고한(stable) C++의 정의를 내렸다는 것은 위대한 일입니다. 이것은 C++ 공동체에 직접적이고 간접적으로 무수한 도움이 될 것입니다. 컴파일러 제공자들은, 표준위원회의 내용들을 따라가는 것(catching up with the standards committee)에서 이제는 구현의 질에 관한 논쟁으로 쟁점을 이동시키기 시작함에 따라서, 분명히 우리는 더 좋은 개발 환경을 접하게 될 것입니다. 이것은 이미 진행중입니다.

표준을 수용하는 구현은 툴의 혜택과 큰 공통 플랫폼을 제공하는 라이브러리 제공자의 혜택을 경험하게 할 것입니다.

표준은 프로그래머에게 새로운 기술과 함께 더 도전적인 기회를 제공할 것 입니다. 제품의 코드에서 비실제적인 코드를 사용했던 프로그래밍 양식은 실제적인 계획(proposition)이 되어가고 있습니다. 이처럼, 더 유연하고(flexible), 일반적이고(general), 빠른(faster), 그리고 더 유지하기 쉬운 코드를 사용할 수 있습니다.

일반적으로, 우리는 냉정을 유지해야 하고, "개선된" 기교의 주연(orgy)에 탐닉(indulge)해서는 안 됩니다(역자주: 개선된 C++의 기교를 사용하는 것은 중요한 일이 아니라는 주장). 기적은 여전히 없습니다. 그리고 좋은 코드는 여전히 탄탄한 디자인과 대부분 직접적으로 매치되는 코드입니다. 그러나, 바로 지금은, 어떤 기교가 특정한 사람, 조직, 혹은 프로젝트에 적당한지, 실험하고 살펴볼 시간입니다. 'The C++ Programming Language'의 많은 부분은 이러한 기교와 그것들이 제공하는 흥정관계(trade-offs)를 기술하고 있습니다.

이러한 진보를 가능하게 하는, 우리가 눈으로 볼 수 있는 부분은, 언어의 새로운 큰 기능 - 템플릿(template), 예외처리(exception), 실행시 형 정보 (runtime type information), 이름공간(namespace) - 과 표준 라이브러리입니 다. 언어의 자세한 부분의 작은 개선 또한 중요합니다. 우리는 이제 여러 해 동안 사용 가능했던 유용한 것들을 대부분 가지게 되었습니다. 하지만, 호환성과 제품의 품질이 필요로 하는 곳에 대해서는 그것들에 크게 의존할 수 없었 습니다. 이것은 우리로 하여금, 우리의 라이브러리와 응용프로그램을 설계하는 데 있어서 최적이 아닌 차선(suboptimal)을 선택하도록 하였습니다. 그러나, 곧(올 해 1998년) 모든 큰 구현이 표준 C++를 탄탄하게 지원하게 될 것입니다.

언어와 프로그래밍 기교의 관점에서 C++에 가해진 가장 중요한 변화는, 정적으로 검사 가능한 형 안정성(staticaly verifiable type safety)에 대한 강조의 계속적인 증가와 템플릿의 증가된 유연성입니다. 유연한 템플릿은 우아함 (elegance)(역자주: 명시적인 형 변환이 필요없는 C++ 프로그램은 읽기 쉽다. 이것을 우아하다고 표현한 것 같다)과 효율성(efficiency)에 주목하는 형 안정성을 강조하기 위해서 필요합니다.

새로운 기술의 실행가능성(Feasibility of new techniques)

Computer: 당신은 말하기를 "숙련된 C++ 프로그래머조차도 지난 몇 년 동안 인지하지 못한 것은 그러한 새로운 기능이 아니라, 기본적인 새로운 프로그래밍 기교를 가능하게 하는 기능들간의 관계의 변화이다." 라고 하였습니다. 어떻게 이것이 표준 C++에 적용 가능한 지 몇 가지 예를 들어주시겠습니까?

Stroustrup: 오버로딩이나 템플릿이 함께 사용되어 우아하고 효과적인 형 안정 컨테이너의 중요한 역할을 한다는 것을 모르고도, 오버로딩과 템플릿은 규칙들을 각각 공부하는 것은 쉽습니다. 이러한 연결(역자주: 오버로딩과 템플 릿의 연결)은 컨테이너에서 공통적으로 많이 사용되는 근본적인 알고리즘을 자세하게 살펴볼 때에만 명확해 집니다. 다음의 프로그램 조각(segment)을 고려해 봅시다. count()의 첫 번째 호출은 정수 벡터에서 7의 횟수를 헤아립니 다. count()의 두 번째 호출은 스트링 리스트에서 "seven"의 횟수를 헤아립니다.

void f(vector<int>& vi, list<string>* ls)
{
int n1 = count(vi.begin(), vi.end(), 7);
int n2 = count(ls.begin(), ls.end(), "seven");
// ...
}

template<class Iter, class T>
int count(Iter first, Iter last, T value)
{
int c = 0;
while (first != last)
{
if (*first == value) c++;
++first;
}
return c;
}

오버로딩을 지원하는 각각의 언어에서 이것을 구현하는 방법은 다양합니다. 템플릿이 주어지면, 둘 모두의 호출을 다루는 하나의 함수를 만들 수 있습니다. 이 템플릿은 둘의 호출에 대해 최적으로 확장(역자주: 실제로 템플릿 함수는 호출되는 것이 아니라, 컴파일 시간에 템플릿을 호출한 문법에 따라 각각의 경우로 만들어진다. 그리고 실제로 만들어진 이 함수가 호출된다. 이것을 확장(expansion)이라 한다)될 것입니다. 이 count()는 표준 라이브러리의 count()와 거의 유사합니다. 그러므로 사용자가 count()를 직접 작성할 필요는 없습니다. count()함수는 그 자체가 오버로딩에 의존하고 있습니다: 명확히 등호 연산자 ==는 정수와 스트링에 대해 오버로딩되어 있습니다. 게다가 * 와 ++는 각각 벡터와 리스트를 위한 반복형(iterator type)을 위하여 "역참조 (dereference)"와 "다음 요소 참조"로 오버로딩되어 있습니다. 다시말하면, *와 ++는 포인터를 위해 그것들이 가지는 의미가 주어졌습니다.

count()의 이러한 정의는 C++ 표준 라이브러리의 컨테이너와 알고리즘에서 사용된 중요 기교의 결합을 설명합니다. 이러한 기교는 유용합니다. 그리고 그것은 오로지 기본적인 언어의 규칙으로는 간단하게 기술할 수 없습니다.

template<class Iter, class Predicatte>
int count_if(Iter first, Iter last, Predicate pred)
{
int c = 0;
while (first != last)
{
if (pred(*first)) c++;
++first;
}
return c;
}

bool less_than_7(int i) { return I < 7; }

void f2(vector<int>& vi, list<int>& li)
{
int n1 = count_if(vi.begin(), vi.end(), less_than_7);
int n2 = count_if(li.begin(), li.end(), less_than_7);
// ...
}

위에 제시된 좀 더 진보된 예를 참조해 봅시다. 값의 횟수를 헤아리는 대신에, count_if()는 predicate를 만족시키는 요소의 개수를 헤아립니다. 예를 들면, 위에서처럼 7보다 작은 값을 가지는 요소의 개수를 헤아릴 수 있습니다.

이러한 기교를 일반화하여, 어떠한 형의 어떠한 값도 비교하는 것을 다루기 위해서는 함수 객체(function object) - 아래처럼 객체가 함수처럼 불러 내어질(invoke) 수 있는 클래스 - 를 선언하는 것이 필요합니다. 아래처럼 생성자 비교를 원하는 값의 참조를 저장합니다. 그리고 () 연산자는 비교를 수행합니다. 바꾸어 말하면, vi에 있는 요소중에 7보다 작은 요소의 수를 헤아리고, ls에 있는 요소중에 "seven"보다 작은 요소의 수를 헤아립니다.

template<class T> class Less_than
{
const T v;
public:
Less_than(const T& vv) : v(vv) {} // constructor
bool operator() (const T& e) { return e < v; }
};

void f3(vector<int>& vi, list<string>& ls)
{
int n1 = count_if(vi.begin(), vi.end(), Less_than<int>(7));
int n2 = count_if(ls.begin(), ls.end(), Less_than<string>("seven"));
// ...
}

생성된 코드는 매우 효율적이며, 특별히 비교를 수행하고, 다음 요소를 가져 오는 등의 작업을 하는데, 함수 호출 - 혹은 비슷한 늦은 연산자 - 을 사용하지 않는다는 것(역자주: 자세한 사항은 '함수 객체'를 참고하라)은 언급할 만 합니다.

의심할 여지도 없이, 이 코드는 C++ 프로그래머가 아닌 사람에게, 혹은 템플릿과 오버로딩의 개념을 익히지 못한 C++ 프로그램머에게 조차도 이상하게 보일 것입니다. 물론 이것은 이 예제를 여기서 제시한 이유중의 일부입니다. 그러나, 진짜 의도(bottom line)는 이 기교가 당신에게 효율적이고, 형 안정적 이고, 일반적인 코드를 작성하게 한다는 것입니다. 함수형 언어(functional language)(역자주: LISP(list processing: 1959년 John McCarthy가 개발)같은 언어가 한 예이다)에 익숙한 사람들은 이러한 기교가 그러한 언어에서 선구적으로 개척된 기교와 유사하다는 것을 알아차렸을 것입니다.

언어의 모습은 분리되었을 때 근본적으로 지루합니다. 그리고 그것은 좋은 시스템 설계로부터 흩뜨릴 수 있습니다(오직 언어가 살아남아야 할 프로그래밍 기교의 측면에서).

표준 라이브러리(The Standard Library)

Computer: 표준 라이브러리는 어떻습니까? 또한 그것이 C++ 공동체에 무슨 영향을 끼칠까요?

Stroustrup: 표준 라이브러리의 가장 새롭고 흥미로운 부분은 컨테이너와 알고리즘의 일반적이고 확장 가능한 골격(framework)입니다. 그것은 종종 STL(Standard Template Library)이라고 불리는데, 근본적으로 Alex Stepanov의 작품입니다(그 당시 Hewlett-Packard에서 지금은 Silicon Graphics에 있다).

Alex는 확고하게(uncompromisingly) 일반적이면서 효율적인 근본적인 알고리즘을 제공하기 위해 일을 했습니다. 예를 들면, 자료 구조에서 요소를 찾는 것, 컨테이너를 정렬하는 것, 자료 구조에서 값의 횟수를 헤아리는 것 등입니 다. 그러한 알고리즘은 많은 계산에서 근본적인 것입니다.

Alex는 많은 종류의 언어를 가지고 연구했습니다. 그리고 몇 년간 공동 연구자들이 있었습니다. 주목할만한 이들은 David Musser(Rensselaer Polytechnic Institute), Meng Lee(HP Labs), Andrew Koenig(AT&T Labs) 등 입니다. 제가 STL에 공헌한 부분은 매우 작지만 중요하다고 생각합니다: 저는 어댑터(adapter)라고 불리는 mem_fun()을 디자인했습니다. 그것은 다형 객체(polymorphic object)의 컨테이너를 위해서 표준 알고리즘이 사용되는 것 을 제공합니다(역자주: 어댑터는 크기가 동적인 가변 객체를 컨테이너 연산의 대상으로 하기 위한 메모리 할당 및 처리 루틴을 말하는 것 같다). 이처럼, 객체 지향 기술을 시도하는 것이 깔끔하게 표준 라이브러리의 일반적인 프로그래밍 골격에 포함되었습니다.

다소 놀랍게도, STL은 제가 몇 년 전에 개발한 C++을 위한 표준 컨테이너의 좋은 집합을 결정하는 판단기준과 일치되었습니다. 1년 후, STL에 대해 의논하고 마무리한 후, ISO C++ 위원회는 STL을 C++를 위한 표준 라이브러리의 중요한 부분으로 받아들였습니다. 저의 판단기준도 포함되었습니다.

간단한 기본 연산의 확고한 효율성(예를 들면, 배열의 인덱싱 (subscripting)이 함수 호출의 비용을 유발해서는 안 된다);

형 안정성(type-safety)(컨테이너로부터의 객체는 명시적인(explicit) 혹은 함축적인(implicit) 형 변환 없이 사용 가능해야 한다);

일반성(라이브러리는 벡터, 리스트, 맵 같은 몇 개의 컨테이터를 제공해야 한다);

확장성(내가 필요로하는 컨테이너를 라이브러리가 제공하지 못하는 경우, 내가 컨테이터를 만들어 표준 컨테이너처럼 사용할 수 있어야 한다).

약간의 수정과 추가를 거친 STL을 채택함으로써, 위원회에서 해야 할 끔찍한 디자인을 피할 수 있었습니다. 명확히, C++ 표준 위원회의 시간제 근무자의 그룹이 프로그래머가 유용하다고 판단하는 모든 라이브러리의 기능을 제공할 수 없습니다. 결과적으로 중요한 쟁점은 무엇이 표준 라이브러리에 포함되어야 하고, 무엇이 기업과 개인이 제공하는 것으로 남겨져야 하는 것을 결정하는 것이었습니다.

우리는 무엇이 포함되어야 하는가의 길잡이로 "독립적으로 개발된 라이브러리 사이의 통신 역할을 하는데 필요한 것"을 사용하기로 하였습니다. 이처럼, I/O, 스트링, 컨테이너가 큰 촛점이 되었습니다. 우리는 표준 C 라이브러리와 수 계산을 위한 몇 기능을 역사적인 이유 때문에 포함시켰습니다. 하지만, 잠재적으로 유용한 많은 기능들 - 날짜와 통화, 정규 표현 매칭, 그래픽 - 을 남겨두었습니다. 다행히도, 이러한 기능들은 공개 혹은 상업적으로 이용 가능합니다.

표준 라이브러리는 프로그래머가 바퀴를 다시 발명하는 것을 구해냅니다. 특별히, 표준 컨테이너는 초보자나 숙련자 모두에게 높은 수준의 프로그램 (high level programming)을 허락합니다. 쉬운 일을 간단히 처리하는, 아래의 간단한 프로그램을 고려해 봅시다.

int main()
{
cout << "Please enter your first name:\n";
string name;
cin >> name; // read into name
cout << "Hello" << name << "!\n";
}

매크로도 이용하지 않고, 명시적인 메모리 관리나 다른 고수준 언어의 기능을 이용하지 않으며, 리소스의 제한도 받지 않습니다. 특별히, 만약 어떤 익살꾼(joker)이 자신의 첫 번째 이름으로 30,000자를 적는다고 하더라도, 에러나 오버플로우 없이 프로그램은 충실히 이름을 출력할 것입니다.

표준 라이브러리를 이용하는 것은 C++가 배워지던 방법의 혁명을 일으킬 수 있고 일으켜야 합니다. 이제 C++을 고수준 언어로써 배우는 것이 가능합니다. 학생들은 이제 필요할 때만 낮은 수준의 프로그래밍 기능들을 다루면 됩니다. 혹은 낮은 수준의 프로그래밍 기능들을 언급할 적절한 실력들이 쌓이고 나서 보아도 됩니다. 이처럼, 표준 라이브러리는 도구와 교사로서의 역할을 할 것입니다.

복잡성, C++와 객체지향프로그래밍(COMPLEXITY, C++, AND OOP)

Computer: 'The C++ Programming Language'에서 당신은 말하기를 "정상적인 실용적인(practical) 프로그래머들은 생산성, 유지보수, 유연성과 어떠한 종 류와 스케일의 프로젝트에 대한 품질에 대해서도 놀랄만한 향상을 달성했다." 고 했습니다. 그러나 아직 몇몇 비평가들은 C++과 일반적인 OO는 여전히 너무 복잡하고, 교정 유지보수(corrective-maintenance)문제를 일으키며, 큰 시스템에서의 유지 문제가 있다고 합니다. 어쨌던 이러한 비평이, 당신 자신의 경험으로 볼 때, C++로 설계하는 큰 시스템의 개발에 적용되는 것이라 생각합 니까?

Stroustrup: 저의 개인적인 경험으로, OO 설계와 OO 프로그래밍은 전통적인 절차적인 방법을 통해서 당신이 얻을 수 있는 것보다 좋은 코드를 제공할 것 입니다. 그러한 코드는 더욱 유연하고(flexible), 더욱 확장 가능하며 (extensible), 심각한 수행상의 부하(overhead)없이 유지 보수 가능한 (maintainable) 코드입니다. 위의 개인적인 의견에 반대되는 제가 좋아할 만한 강한 증거는 없습니다. 하지만, AT&T 내부에서의 몇몇 연구와 다른 연구들은 이러한 의견을 지지합니다.

두 요소가 쟁점을 난처하게 합니다: "객체 지향적"인 것이 정말로 무엇인지에 대한 일반적인 동의가 없습니다. 또한 토론은 좀체 경험을 충분히 설명하지 못합니다. "OO의 문제"의 많은 부분은 정말로 OO가 무엇인지 모르는 부분적인 이해를 가진 사람들이 야망찬 프로젝트를 진행하는데서 비롯합니다.

그렇다면 OO는 무엇입니까? 확실히 좋은 프로그램 모두가 객체 지향적인 것은 아니며, 객체 지향적인 모든 프로그램이 좋은 것도 아닙니다. 만약 그렇다면 "객체 지향적"인 것이 단순히 "좋은 것"을 의미합니다. 그리고 이것은 당신이 실제적인 결정을 내려야 할 때 개념을 혼동하게 하는 하나의 추가된 전공용어(buzzword)에 불과합니다. 저는 OOP를 클래스의 상속과 가상함수(어떤 언어에서는 메서드(method)라고 하는)를 많이 사용한 프로그램과 동일시하곤 합니다. 이 정의는 역사적으로는 정확합니다. 왜냐하면, 클래스 계층과 가상 함수는 그 당시 시뮬라(Simula)와 다른 언어를 구분짓는 철학이었기 때문 입니다. 사실, Smalltalk가 가장 중요하게 강조된 것은 시뮬라 유산의 이러한 관점 때문입니다.

클래스 계층과 가상 함수에 기초하여 OO를 정의하는 것은 OO가 성공할 것 같은 곳으로의 몇 지침을 제공하기 때문에 실용적입니다. 당신은, 정확하게 같은 형이 아니지만 공통의 인터페이스로 조작될 수 있는 객체를 위한, 구현을 공유할 수 있는 개념들의 변체(variant)를 위한 계층적인 순서를 가진 개념들을 찾습니다. 몇 예제와 약간의 경험을 한다면, 이것이 디자인을 위한 매우 강 력한 접근의 기초가 되는 것을 알것입니다.

그러나, 모든 개념이 자연스럽고 유용하게 계층(hierarchy)과 적합한 것은 아닙니다. 개념들간의 모든 관계가 계층적인 것도 아니고, 모든 문제에 대해 객체에 중심한 접근이 최선인 것도 아닙니다. 예를 들면, 몇 문제들은 근본적으로 알고리즘적(algorithmic)입니다. 결론적으로, 일반 목적의 프로그래밍 언어는 다양한 사고와 다양한 프로그래밍 스타일을 지원해야 합니다. 이러한 다양성은 풀이해야 할 문제의 다양성과 문제 풀이의 다양성에 기인합니다. C++ 은 다양한 프로그래밍 스타일을 지원합니다. 그러므로, 객체 지향 언어라기 보다는 멀티패러다임(multiparadigm) - 이름을 꼭 붙여야 한다면 - 언어라고 불 리는 것이 더 적당합니다.

"좋은 것" - 이해하기 쉽고, 유연하고, 효율적인 - 의 기준을 대부분 만족시키는 디자인의 예로 전통적인 절차 코드를 사용한 재귀 경향 파서(recursive descent parser)가(역자주: 실행 가능한 코드를 생성하는 번역기를 파서 (parser)라 하는데, 재귀 호출을 사용하며, 주로 수식을 번역하기 위해 사용한다) 있다. 다른 예로 STL이 있습니다. 이것은 전통적인 절차적인 코드와 파라미터적인 다형성(역자주: 이름에 의한 다형성이 아닌)에 전적으로 의존하는 컨테이너와 알고리즘을 포함한 일반 라이브러리입니다.

저는 단 하나의 프로그래밍 패러다임만 지원하는 언어는 제한적이라는 것을 발견했습니다. 그것은 간단함(simplicity)을 사는 대신, 프로그래머에게 구속복(straitjacket)을 입히거나, 언어의 복잡함을 응용 프로그램의 복잡함으로 전가 시킵니다. 이것은 특정 목적 언어(special-purpose language)에는 적합하지만, 범용 언어(general-purpose language)에는 적합하지 않습니다. 저는 종종 C++를 시스템 프로그래밍으로 편향된 범용 언어라고 특징 지웁니다. 다음을 지원하는 "더 나은 C"로 생각하는 것이죠.

데이터 추상화

객체 지향 프로그래밍

일반적인 프로그래밍(generic programming).

자연히, 이것은 하나의 접근법만을 허용하는 언어에 비해 복잡함을 증가시킵니다. 저는 이러한 관점 - 문제 영역마다 최선인 각각의 디자인과 프로그래밍 접근법이 있다 - 이 어떤 이들을 화나게 한다는 것을 주목했습니다. 확실히, 모든 사람에게 혹은 모든 문제에 올바른 한가지 방법이 있다는 관점은 거절합니다. 세계는 근본적으로 간단하다는 사실을 열정적으로 믿고 싶어하는 사람들은 제가 이것을 단지 프로그래밍 언어에 대해서만 적용한다는 사실과는 상관없이 격노(fury)합니다. 결국, 프로그래밍 언어는 시스템을 설계하기 위한 많은 도구들 중의 하나입니다.

이러한 두 관점을 모두 해결하는 이상적인 방법은 모든 프로그래밍 스타일을 효율적으로 지원하는 간단한 프리미티브(primitive)의 집합을 지원하는 언어를 가지는 것입니다. 이것이 반복적으로 계속 시도되기는 했지만, 달성되지는 - 저의 의견에 - 못했습니다.

자바와 C++(JAVA AND C++)

Computer: 위에서와 같은 논쟁이 납득할만하게 자바(Java)로 확장 가능하다고 봅니다. Sun이 주장하기를 700,000명의 자바 프로그래머가 있다고 합니다 (비교해서 C++ 프로그래머는 1,500,000명 정도). 당신은 C++가 C와 호환될 필요도 없으며, 자바가 당신이 고안한 언어가 아니라는 주장을 고집합니다. 이러한 질문을 1000번 이상 받았다면 당신은 무슨 말을 할 것입니까?


Stroustrup: 오늘날, 저는 항상 자바에 대해서 질문 받습니다. 그리고 항상 대답하기는 어렵습니다. 제가 만약 약간 부정적인 것을 말한다면, 무례한 것으로 느껴집니다. 제가 만약 약간 긍정적인 것을 말한다면, 자바를 둘러싼 상업적인 공간(commercial hype)에 뛰어드는 것 같고, 자바 공동체의 부분으로부터 흘러나오는 불운한 반 C++ 선전(the unfortunate anti-C++ propaganda)에 뛰어드는 느낌이 들기 때문입니다.

저는 사람들에게 상업적인 라이벌 상태가 아닌, 자신이 개발해야 하는 디자인 기준에 따라 두 개의 언어 중 적절한 것을 선택하라고 권장합니다. 저는 C++을 위한 디자인 표준(cirteria)을 'The Design and Evolution of C++'에서 개괄해 놓았습니다. 그리고 자바는 이러한 기준을 만족시키는 시작조차 못하고 있습니다. 자바를 만병통치약으로 생각하지 않고 프로그래밍 언어의 하나로 생각하는 것은 좋습니다. 결국, C++는 자바의 디자인 목표와 완벽하게 일치하지 않습니다. 그러나, 자바가 유일한 프로그래밍 언어로써 진급된다면, 자바의 결함과 제한은 심각하게 될 것입니다. C++을 개발하는데 적용된 기준이 자바에는 적용되지 않는 몇 가지 예가 아래에 있습니다.

서로 다른 언어로부터 쓰여진 프로그램 부분들을 효과적으로 조합하는 능력

다양한 디자인 스타일과 프로그램 스타일

기정의 타입(built-in type)과 맞먹는 효율을 가진 사용자 정의 타입

기정의 타입과 사용자 정의 타입의 일관된 처리(treatment)

STL처럼 실행시 부담없는 일반 컨테이터(generic container)를 사용하는 능력

프로그래머들이 우아하고 효율적인 코드를 작성할 수 있도록 제가 C++을 디자인했습니다. 많은 응용프로그램을 위해서, 우아함과 효율성을 타협하기를 원하지 않을 때 C++은 여전히 최상의 선택입니다.

저는 어떻게 사람들이 "프로그래머"를 세는지 의문입니다. 학생이 프로그래머입니까? PC에 컴파일러를 가진 사람은 모두 프로그래머입니까? 저는 C++ 을 위해서 인용된 숫자를 이해합니다. 그것은 보수적이고 그럴듯합니다. 그것은 지난 해 실제 팔린 금액을 위한 C++ 프로그램의 수를 적절히 근사화한 것 입니다. 저는 Sun에서 주장하는 자바 프로그래머의 수가 같은 근거인지 의문입니다. 부수적으로, 컴파일러 판매, 책 판매, C++ 수강생 수 등의 확실한 수에 근거해서, 제가 추측하기로 C++ 프로그래머는 매년 10%∼20%증가하고 있습니다.

그리고 저는 자바 팬(fan)이 아닙니다. 저는 과대 선전(hype)을 싫어합니다. 저는 프로그래머가 아닌 사람에게 프로그래밍 툴을 판매하는 시장 전략을 싫어합니다. 저는 독점적인 언어를 싫어합니다. 그리고 저는 많은 프로그래밍 언어를 좋아합니다. 기술적인 측면에서, 자바는 저에게 다른 언어에서 받았던 것처럼, "와 깔끔한데!"란 인상을 주지 못했습니다. 자바는 제가 생각하기에 제 한적인 형태로 다른 유명한 언어의 기능들을 제공합니다.

자바는 많은 것을 C++로부터 빌려 왔습니다. 하지만 그렇게 많이는 아니며, 원하는 만큼의 이해와 맛(taste)도 빌려오지 못했습니다. 자바를 위한 중요한 약속들을 지키기 위해선, 자바는 성장해야 합니다. 이러한 전개는 'C++보다 간단하게'라는 자바의 주장과 타협할지도 모릅니다. 그러나 저의 추측에 그러한 노력은 현재의 것보다 더 좋은 자바 언어를 만들 것입니다. 현재, 자바는 언어의 특징들과 "표준" 라이브러리를 꽤(quite a pace) 축적하고 있는 것처럼 보입니다. 저는 자바 버전의 템플릿이 나타날 것을 기대하고 있습니다.

자바와 그의 공동체가 성숙해가면서, 활기있고 활기있게 하는 철학 (live-and-let-live philosophy)을 희망적으로 채택할 것입니다. 이것은 자바가 프로 프로그래머들의 소중한 도구(tool chest)중의 한 언어로 자리잡게 할 것 입니다.

도구(TOOLS)

Computer: 지난 몇 년간 어떤 방법으로 시스템이 변화했습니까? 그리고 C++의 활동범위(arena)와 일반적인 시스템 디자인에 무엇이 더 필요합니까? C++가 비교적 성장한 이 시점에서, 사용할 수 있는 C++ 툴(tool)들을 어떻게 평가하겠습니까? 그리고 여전히 개선되어야 하는 것은 어떤 것들입니까?


Stroustrup: 먼저, 컴파일러, 디버거, 프로파일러(profiler)(역주: 프로그램의 성능 분석을 위한 도구), 데이터베이스 인터페이스, GUI(Graphical User Interface) 빌더, CAD(Computer Aided Design) 툴과 ISO 표준을 지원하는 기타 기본 툴들을 살펴보고자 합니다. 예를 들면, 저는 데이터베이스 질의의 결과를 STL 컨테이너 혹은 적절한 객체형의 istream으로 얻고 싶습니다. 툴 벤더(vendor)는 좋은 출발을 하였습니다. 하지만, 컴파일러나 다른 소스 코드 분석기에 의존적인 작업을 너무 많이 하였습니다.

제가 리스트한 기본 도구들은 무엇이 바뀐지에 대한 부분적인 대답에 불과합니다. 과거 몇 년 동안, 많은 수의 프로그래머들이 훌륭한 도구와 시스템 기능을 제공하는 인터페이스 코드에 의존해 왔습니다. 이러한 도구들은 지루하고, 에러 발생이 쉬운 작업으로부터 프로그래머들을 구제하는데 필수적입니다. 하지만, 프로그래머가(혹은 고용인이) 툴 제공자의 포로가 되는 위험에 처해 있습니다.

종종 이러한 도구들은 전통적인 프로그래밍 언어에 비해 더욱 복잡하며, 표준은 거의 없습니다. 저는 독점성이(nonproprietary) 없는 도구와 라이브러리를 추천하고 싶습니다. 짧은 안목으로 보면, 예를 들면 10년 정도, 많은 그러한 표준은 형식적인 ISO 나 IEEE의 표준보다 산업계의 표준역할을 합니다. 하지만, 건강한 소프트웨어 산업을 위해, 중요 인터페이스는 잘 정의되고 대중이 사용할 수 있는 것이 필수입니다.

COM(Component Object Model)이나 CORBA(Common Object Request Broker Architecture)같은 시스템 레벨 객체를 위한 표준의 중요성이 증가하는 가운데, C++가 그러한 것들과 깨끗하고(clean), 잘 문서화되어, 사용하기 쉽게 결합될 수 있는 것은 특별히 중요합니다. 불행하게도, 그러한 "표준 작업" - 모두에게 이로운 - 은 누구에게도 짧은 안목의 이점을 제공하지 않기 때문에 소흘히 됩니다.

저는 사용 가능한 C++ 툴들을 평가하지 않겠습니다. 그것들은 매우 훌륭하며, 다른 언어의 어떤 툴보다 더 좋습니다. 그러나, 프로그래머로서, 저는 당연히 더 좋은 품질의 툴들을 바랍니다. 개인적으로, C++ 소스코드를 분석하는 더 좋은 툴들을 기대하고 있습니다. 저는 또한 C++ 컴파일러 벤더들이 신제품을 개발하는 것보다, 자사 컴파일러의 품질과 수행 능력을 향상시키는데 예산을 조금 더 투자하기를 기대합니다. 컴파일러의 실제적인 성능향상은 새로운 버전의 완전한 C++ 컴파일러를 위한 시간보다 다소 저렴합니다. 그러나, 중요한 사용자들이 적응 테스팅(conformance testing)이나 벤치마킹 (benchmarking)을 요구하는 것을 시작하지 않는다면, 벤더들이 광고상 좋게 보이는 것을 위해 자원을 사용할 것을 느낍니다.

미래(THE FUTURE)

Computer: 저는 당신이 C++표준화 작업에 많이 참여한 것으로 알고있습니 다. 하지만, 현재 당신이 참여한 다른 프로젝트에는 어떤 것이 있으며, C++을 발전시키기 위해 어떤 작업을 계속할 것입니까?


Stroustrup: 나는 매우 큰 프로젝트를 성공적으로 완성하고 나서 고통받고 있습니다. ISO C++ 표준이 완성되었습니다. 'The C++ Programming Language'의 제 3판에는 표준 C++이 무엇을 제공하는지 어떻게 가장 잘 사용하는지 진지한 프로그래머들에게 알리고 있습니다. 그리고 'The Design and Evolution of C++'은 C++에 장착된(shaped) 디자인 결정들을 문서화하고 있습니다. 해야할 것들이 아직 많습니다. 그러나 전시간 언어 디자이너를 필요로 하는 것은 아무것도 없습니다. 이제 가능한 변화들에 집중하기 보다는, 코드를 작성함 으로써 C++의 힘과 유연성을 즐길 시간입니다.

그것과는 별도로, 저는 몇 가지 사실들을 배울 기회를 얻었습니다. 몇 새로운 언어와 큰 사업에서 소프트웨어가 어떻게 사용되는지에 관한 것이 그것입니다. 그리고 분산 컴퓨팅에서 몇 실험들을 계획중입니다.

'Dev > C++' 카테고리의 다른 글

boost::pool 예제  (0) 2008.05.01
STLport 초간단 설치  (1) 2008.05.01
qsort vs sort  (0) 2008.05.01
최소 완전한 클래스를 만들어라  (0) 2008.05.01
RAII (Resource Acquisition Is Initialization)  (1) 2008.05.01

std::sort 는 qsort 보다 빠르다 #


  1. 비교 함수의 리턴값
    • <qsort>
      qsort의 비교함수 리턴 값은 int type 입니다.
      그러므로 결과는 3가지 종류이죠

      a < b -> -1
      a > b -> 1
      a = b -> 0

      그러므로 적어두 2번을 비교 해야 합니다.


    • <sort>
      sort의 비교함수 리턴 값은 bool type이입니다.
      그러므로 1번만 비교 하면 되는것이져

         template <typename T>
         bool comp(const T &a, const T &b) {
             return a < b  // a가 b보다 작으면 참 아니면 거짓 
         }
      


  2. 비교함수의 inlining
    • <qsort>
      비교자를 함수로 밖에 못넘기기때문에 함수호출로 인한 오버헤드는 불가피 합니다.
      만약 비교함수를 inline으로 선언해도 함수 포인터를 사용 하므로 무시됩니다.
      (inline및 register는 힌트이기 때문에 컴파일러의 사정에 따라 무시될수 있습니다. 야속하게도 ...)

    • <sort>
      비교함수및 sort함수가 template으로 구성되어서 함수및 함수객체(functor)를 비교자로서 넣을수 있습니다.
      함수로 넣으면 qsort와 같은 오버헤드가 발생 하겠지만 함수객체로 만들면 inlining이 가능하게 만듭니다.



  3. swap 함수의 대입
    • <qsort>
      qsort의 swap함수는 void*로 인수를 받기 때문에 실제 데이터의 크기과 정보를 알수가 없습니다
      그래서 qsort함수의 3번째 인자(데이터의 크기)를 기준으로 객체의 혹은 타입의 크기만큼 전체 복사를
      하게 구현 됩니다.


    • <sort>
      sort함수의 경우는 복사입니다 (template 때문에 가능하져)

         template <typename T>
         void swap(T &a, T &b) {
             T t = a;
             a = b;
             b = a'
         }
      

      그러기 때문에 프로그래머의 데이터 객체의 대입연산자 구현에 따라
      성능은 많이 나아질 여지가 충분한것이져

      거기다가 데이터 자체가 Reference Counting이 된는 객체라면
      그 성능은 월등할것 입니다.

'Dev > C++' 카테고리의 다른 글

STLport 초간단 설치  (1) 2008.05.01
Stroustrup - The real interview  (0) 2008.05.01
최소 완전한 클래스를 만들어라  (0) 2008.05.01
RAII (Resource Acquisition Is Initialization)  (1) 2008.05.01
상속되지 않는것  (0) 2008.05.01

+ Recent posts