Lyn
조회 수 4050 추천 수 0 댓글 0
Atachment
첨부 '1'
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

3월 28일 업데이트 된 364.72 버전 Geforce 드라이버에서는 Vulkan 이 공식 지원됩니다.

또한 vulkan 지원 정보를 간략히 볼 수 있는 SW인 vulkaninfo 가 같이 설치됩니다

 

vul.PNG

 

?

Lyn
조회 수 2364 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

add compile option flag /d2Zi+

 

맨날 까먹어서 저장용으로

?

Lyn
조회 수 24984 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

DLLMain은 WinMain 이나 main 과는 다르게 제약이 많다.

나도 이걸로 크래시 낸 적이 많이몇번 있고 ... 


DLLMain은 일종의 "객체의생성자" 라고 보면 비슷하다.

"로딩중" 인 것이지 로딩이 끝난것이 아니다 라는것이다.


아래에는 Attach 시 기준으로 적었지만, Detach 에도 별 다를건 없다. kerner32.dll 이외의 dll은 이미 언로딩 되어있을 수도 있다.


이제 하지 말아야할것을 슬~슬 나열 해 보자. 


1. kernel32.dll 이외의 dll에 있는 함수 대부분.

kernel32.dll 이외의 dll이 로딩되어 있다는 보장은 전혀없다


2. 동기화코드

락, 언락 등의 코드


3. LoadLibrary, CreateProcess

다른 DLL 쓰지말라는말과 일맥상통. 


4. 전역객체 초기화, 메모리할당 등

메모리메니저가 로딩되었다는 보장이 없다


5. COM관련 코드

역시 보장없다


6. 예외 throw

C++ 객체 생성자에서 throw 하는것과 비슷한 대략므흣한 (...) 상황이 발생한다.


결론. 

DLLMain은 걍 비워 둬라. 그리고 Initialize 함수를 제공해라.
상당수의 라이브러리가 라이브러리 초기화 함수를 제공하는것은 다 이유가 있다!

(당장 GDI+와 Winsock2를 생각해봐라!) 

?

Lyn
조회 수 2306 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

윈도 10을 쓰고 있다가 어느날 게임을 하려는데 그래픽드라이버에 문제가 있는것을 발견했습니다.

그래서 드라이버를 다운그레이드 했는데... 이 빌어먹을 윈도 업데이트가 자동으로 드라이버를 올려버리는겁니다 (...)

그래서 방법을 찾다보니, 아래와 같은 툴을 MS가 제공 하고 있습니다.

드라이버 업데이트를 선택적으로 끌 수 있게 되어 있네요.

 

.. 다행입니다.

 

https://support.microsoft.com/en-us/kb/3073930

TAG •
?

Lyn
조회 수 38818 추천 수 0 댓글 1
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

Delphi 2009(Win32) 에서 추가된 Generics 에 관해서 간략하게 써 보겠습니다.

 

Generic 이란 임의의 타입에 대해 동작하는 매소드(클래스) 를 만드는 방법으로, C++에서는 Template이라 불리며 C#, Java 등에서는 Generics 라 불리는 기능이며, 일반화 프로그래밍을 가능하게 해주는 방법입니다.

 

간단한 예제를 하나 만들어 보겠습니다

변수의 크기를 출력하는 간단한 예제입니다.

 

 

program Project1;

 

{$APPTYPE CONSOLE}

 

uses

  SysUtils, VarUtils;

 

type

  TempClass = Class

  public

    procedure GetSize<T>(Item : T);

  end;

 

  TempRecord = packed Record

    A : Integer;

    B : Double;

    C : Double;

  End;

 

procedure TempClass.GetSize<T>(Item : T);

begin

  WriteLn('Size : ', Sizeof(Item));

End;

 

var

  A : TempClass;

  B : Integer;

  C : TempRecord;

begin

  A.GetSize(3000);

  A.GetSize(4.0);

 

  B := 30;

  A.GetSize(B);

 

  A.GetSize(C);

  ReadLn;

end.

 

 

결과는 각각

2, 10, 4, 20 이 나옵니다.

 

여기서 즉 T 이라는 임의의 Type 에 관해서 크기를 알아 올 수 있는겁니다.

 

여기서 어떻게 Type 이 지정 되냐를 알 수 있는데.

3000을 넘었을 경우는 2byte 정수형 으로 인정한 것을 알 수 있습니다.

 

정수형의 경우는 입력한 숫자의 크기에 따라 1~8 byte 정수형으로 함수가 생성 됩니다.

4.0을 넣었을 경우는 크기가 10이 나왔는데, 모든 실수형은 Extended 형으로 생성합니다.

 

Integer형의 변수 B를 넣었을 경우는 이미 타입이 Integer  라는 것을 명시적으로 선언 하였으므로 크기는 4Byte 가 됩니다.

 

TempRecord 형의 변수는 당연히 20Byte가 나옵니다(Integer + Double + Double)

 

이처럼 하나의 함수로 다양한 Type 에 대한 계산이 가능해 집니다.

 

이것은 컴파일 시점에 GetSize 라는 함수를 프로그래머가 사용한 Type 에 따라 여러벌 만들기에 가능한 것입니다.

 

디스어셈블한 코드를 구경 해보도록 하겠습니다

Project1.dpr.22: WriteLn('Size : ', Sizeof(Item));

0040E1BB A1980A4100       mov eax,[$00410a98]

0040E1C0 BAF0E14000       mov edx,$0040e1f0

0040E1C5 E86A73FFFF       call @Write0UString

0040E1CA BA0A000000       mov edx,$0000000a

0040E1CF E89856FFFF       call @Write0Long

0040E1D4 E8BF56FFFF       call @WriteLn

0040E1D9 E8724DFFFF       call @_IOTest
Project1.dpr.22: WriteLn('Size : ', Sizeof(Item));

0040E200 A1980A4100       mov eax,[$00410a98]

0040E205 BA30E24000       mov edx,$0040e230

0040E20A E82573FFFF       call @Write0UString

0040E20F BA04000000       mov edx,$00000004

0040E214 E85356FFFF       call @Write0Long

0040E219 E87A56FFFF       call @WriteLn

0040E21E E82D4DFFFF       call @_IOTest

Project1.dpr.22: WriteLn('Size : ', Sizeof(Item));

0040E240 A1980A4100       mov eax,[$00410a98]

0040E245 BA70E24000       mov edx,$0040e270

0040E24A E8E572FFFF       call @Write0UString

0040E24F BA14000000       mov edx,$00000014

0040E254 E81356FFFF       call @Write0Long

0040E259 E83A56FFFF       call @WriteLn

0040E25E E8ED4CFFFF       call @_IOTest

 

 

이와 같이 같은 이름의 함수가 비슷비슷한 코드로 여러벌 생성 되어 메모리에 들어있는 것을 확인 할 수 잇습니다.

 

 

이번엔 Type 을 명시적으로 알려주는 코드를 보도록 하겠습니다.

A.GetSize(3); 의 호출 결과는 1이었습니다.

숫자가 작기떄문에 최대한 작은 크기의 메모리를 소모 하기 위하여 Byte 형으로 선언 된 결과입니다.

 

그런데 간혹 정해진 Type 이 필요 할 수도 있습니다.

이럴경우 Type 을 명시적으로 지정해서 호출 해 보겠습니다.

 

A.GetSize<Integer>(3);

로 코드를 변경 한 후 호출하면 4가 출력 되는 것을 알 수 있습니다.

 

무조건 Integer 형의 함수를 호출 하라는 일종의 협박(?) 비슷한 코드를 만들어 낸 셈이 되는겁니다.

 

 

 

다음으로 알아 볼 것은 모든 알고리즘이 임의의 타입에 대해 동작 될 수 없는 경우에 관한 해결책입니다.

 

위의 코드에서 Integer, Double, Record 형의 크기는 아무 문제 없이 구할 수 있었지만, String 형의 크기는 sizeof() 연산자로 구할 수 없습니다.

 

이럴경우 String에 관해서만 특별한 처리를 해 주어야 하는데이는 익히 잘 아시는 오버로딩을 응용하면 됩니다.

 

예제코드를 보겠습니다.

program Project1;

 

{$APPTYPE CONSOLE}

 

uses

  SysUtils, VarUtils;

 

type

  TempClass = Class

  public

    procedure GetSize(Item : String); overload;

    procedure GetSize<T>(Item : T); overload;

  end;

 

  TempRecord = packed Record

    A : Integer;

    B : Double;

    C : Double;

  End;

 

procedure TempClass.GetSize<T>(Item : T);

begin

  WriteLn('Size : ', Sizeof(Item));

End;

 

procedure TempClass.GetSize(Item : String);

begin

  WriteLn('Size : ', Length(Item));

End;

 

var

  A : TempClass;

  B : Integer;

  C : TempRecord;

begin

  A.GetSize<Integer>(3);

  A.GetSize(4.0);

 

  B := 30;

  A.GetSize(B);

 

  A.GetSize(C);

  A.GetSize('Hello Delphi!');

  ReadLn;

end.

 

GetSize 매소드를 T 형과 String 형에 관해 각각 오버로딩 하엿습니다.

String 형으로 GetSize 를 호출하면 Length 를 호출해서 계산하는 함수가, 다른 형으로 GetSize를 호출하면 Sizeof 를 사용하는 함수가 호출 됩니다.

 

이처럼 특정한 Type 에 관해 매소드를 다른 형태로 사용 할 수 있습니다.

 

 

지금까지는 함수의 Generic 을 살펴 보았습니다. 이제 클래스에 관한 Generic 을 살펴 보도록 하겠습니다.

 

program Project1;

 

{$APPTYPE CONSOLE}

 

uses

  SysUtils, VarUtils;

 

type

  TempClass<T> = Class

  public

    Item : T;

  end;

 

  TempRecord = packed Record

    A : Integer;

    B : Double;

    C : Double;

  End;

 

var

  A : TempClass<String>;

  B : TempClass<Integer>;

  C : TempClass<TempRecord>;

begin

  A := TempClass<String>.Create;

  A.Item := 'Hello RAD Studio!';

 

  B := TempClass<Integer>.Create;

  B.Item := 512;

 

  C := TempClass<TempRecord>.Create;

  C.Item.A := 55805096;

  C.Item.B := 3.14159;

  C.Item.C := 0.0;

  ReadLn;

end.

 

위 코드에서는 T 라는 임의의 타입을 가지는 클래스 TempClass<T> 를 선언하엿습니다.

그리고 각각 : String, Integer, TempRecord 형을 가지는 클래스 TempClass<String>. TempClass<Integer>, TempClass<TempRecord> 를 선언 하엿습니다 (TempClass<타입명> 까지가 클래스 이름이라고 생각하시면 편합니다)

 

그리고 각각의 클래스를 생성하고 Item 변수에 접근하여 값을 넣었습니다.

선언한 형태에 따라 TempClass 는 여러 타입의 Item 을 가지는 클래스로 탄생합니다.

 

TIntegerList, TDoubleList 등등을 따로 제작 할 필요 없이 임의의 타입을 가지는 콜렉션을 만들어 쓸 수 있습니다. 사실 이게 Generic을 쓰는 가장 큰 이유라고도 할 수 있습니다. Generic 으로 콜렉션을 만들면 캐스팅이 필요 없고, 타입이 명확하기 때문에 편리하게 사용 할 수 있습니다.

(.net Dictionary<> , STL Vactor<>, List<>, MFC CArray<,> 등이 그에 해당합니다)

마지막으로 한가지만 더 보도록 하겠습니다.

program Project1;

 

{$APPTYPE CONSOLE}

 

uses

  SysUtils, VarUtils;

 

type

  TempClass<T1, T2> = Class

  public

    Item1 : T1;

    Item2 : T2

  end;

 

var

  A : TempClass<String, Integer>;

begin

  A := TempClass<String, Integer>.Create;

  A.Item1 := 'Hello RAD Studio!';

  A.Item2 := 3;

 

  ReadLn;

end.

 

임의의 Type 은 반드시 한 개여야 한다는 제약은 없습니다.

여러 개의 임의의 Type 을 가지는 클래스도 얼마든지 선언 가능합니다.

 

위 코드는 2개의 임의의 Type을 가지는 TempClass<,> 를 선언, 사용 한 모습입니다.

 

 

PS. 간단한 함수도 매소드로 만들어서 예제를 구성했는데... 제가 잘 못해서 그런건진 모르겠는데, 델파이의 제네릭은 전역함수의 제네릭화를 허용 하지 않는 것 같습니다.

 

----

?
  • ?
    GomSun2 2010.06.17 19:54

    와우 좋은 강좌 잘봣음. :)


Lyn
조회 수 40782 추천 수 0 댓글 1
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

- 2010.1.3 지금 이걸 계속 써야 하나 말아야하나 고민중이다. 단돈 몇만원이 아까운게 아니라면 Beyond Compare 사서 써라. 진리다. 비교할 의미자체를 모르겠다(단. 3Way Marge 는 내가 쓰지 않아 잘 모른다)

  2011.11.22 2년사이에 많이 바뀌어서 내용을 추가


[파일비교]

Araxis Merge :

  달라진 부분을 보여주는 가이드라인이 너무 작아서 눈에 띄지 않음.

  단 선으로 바뀐 부분을 보여주기에 매우 많은 길이의 코드가 연속적으로 달라졋을 경우 직관적.

 

Beyond Compare :

  바뀐 부분을 영역색, 글씨색으로 나누어 보여주어서 보기 편함.

  달라진 부분을 보여주는 가이드라인의 길이가 화면크기와 별도로 나타나 직관적이지 않음.

  바뀐 부분이 한 줄의 일부, 아니면 몇줄 이하일 경우 직관적으로 보이나, 바뀐 부분의 길이가 길 경우, 특히 한페이지가 넘어 갈 경우는 보기가 상당히 불편하다.

 

Ultra Compare : 

  돈내고 쓸 가치가 없다. 알고리즘이 개판이다.


Kdiff

  한글 지원이 쓰레기 of 쓰레기라 배제


WinMerge

  제작자는 이 UI로 정말 코드 비교를 할수 있는지 한번 묻고싶다


[폴더비교]

Araxis Merge :

  폴더 비교 창이 매우 난잡하여 보기힘들다.

  필터가 매우 단순

  최신버전에서 필터 기능이 강력해졋다

Beyond Compare :

  알아보기 쉽게 색으로 잘 표시되어 있다.

  필터링 기능이 매우 막강하다. 특히 프로그래머가 jpg, bmp 파일을 Compare 툴로 보는것은 의미가 없는데 필터 옵션에서 아주 간단하게 걸러낼 수 있다.


[기타기능]

Araxis Merge:

  소스비교, 바이너리 비교. 그 이상의 잡기능은 없다

Beyond Compare:

  Mp3비교, 이미지 비교 등등 굉장히 다양한 포맷을 비교하는 기능을 제공한다.


[가격]

Araxis Merge :

  비싼 값에 비해, 밥값을 못한다.

  이제 밥값정돈 한다. 그래도 비싸다

Beyond Compare :

  유료이긴 하지만 비싸지 않고, 이 가격대에 이정도 툴이면 매우 훌륭하다.

 

KDiff, WinMerge : 

  싼게 비지떡이다. 정말 돈이 없다면 그때나 고민해 보자


 

PS. DiffMerge, AcroDiff 등 비교 예정

?

Lyn
조회 수 27951 추천 수 0 댓글 3
Atachment
첨부 '8'
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

C++11 표준이 완성 되면서 상당히 많은 기능이 표준 라이브러리에 추가 되었습니다.

이들중 상당수는 완전히 새로운 클래스로 제공되는 것이 많지만 기존 기능을 보안하는 식으로 추가된것도 많습니다.

그중 가장 많이 쓰인다고 볼 수 있는 string 관련으로도 여러가지가 추가 되었습니다.


아래 코드는 최신의 Visual Studio 2012 에서 작성되었습니다.


첫번째로 Native언어 답게 메모리를 직접 관리 할 수 있는 함수가 추가 되었습니다.


1.png


원래 대부분의 stl 객체가 그렇든 한번 할당 한 메모리는 데이터 사이즈가 줄어든다 해도 줄이지 않았습니다.
하지만 C++11에서는 shrink_to_fit 매소드를 제공하여 메모리를 줄일 수 있도록 하고 있습니다.



2.png


그 다음으론 front, back, pop_back 함수의 추가입니다.
이름답게 front, back 은 각각 첫글자, 마지막 글자를 리턴하며 pop_back은 맨뒤에서 한글자를 잘라냅니다.



사실 이 다음부터가 가장 쓸만한 부분입니다.
C++의 string 은 숫자 관련 함수를 제공하지 않아 C의 atoi, itoa 처럼 배열을 기반으로 하는 함수를 사용하거나 stringstream 을 사용하여 문자열을 조립하는 과정을 필요로 하였습니다. C++11에서는 그것과 관련된 함수를 추가 하였습니다.


3.png


가장 기본적인 활용법입니다 stoi 함수는 문자열을 숫자로 변환합니다. type 에 따라 stoi, stol, stoll, stoul, stoull, stof, stod, stold로 바꿔쓸 수 있습니다.
각각 int, long, long long, unsigned long, unsigned long long, float, double, long double 로 변환하는 함수입니다.


4.png

뒤에 변환할 수 없는 문자열이 있을경우, 변환 가능한 부분 까지만 변환 후 몇글자가 변환되었는지 얻어올 수 있습니다.


5.png

진법 변환도 가능합니다.
16진수 100은 256으로 8진수 100은 64로 정상적으로 변환 되었습니다.

16진수 8진수만이 아니라 7진수 9진수 등 중간단계에 있는 진법으로도 정상적으로 변환이 가능합니다.


6.png


문자열을 언제나 숫자로 바꿀 수 있는것은 아니기 때문에 2 종류의 예외를 던질 가능성이 있습니다.
각각 숫자로 변환 불가능한 문자열과 너무 길어서 숫자의 범위를 넘어서는 문자열을 변환 시도 할 경우의 예외입니다.


7.png

기본적으로 0x를 앞에 붙일경우 0만 인식하여 0으로 변환 되지만 16진법으로 변화할 경우에 한정해서 0x를 인식하여 정상적인 문자열로 판단합니다.
8진법 변환의 경우 앞의 0 한자리만 인식하여 0으로 변환된것을 볼 수 있습니다.



지금까진 문자열을 숫자로 변환 하였지만 반대의 기능도 있습니다.


8.png


반대의 기능으로 to_string 함수를 제공합니다.
모든 정수/실수 타입에 대해 오버로딩 되어 있기때문에 단순히 호출만 하면 됩니다.


단 실수의 경우 무조건 소수점 7번째 자리에서 반올림하여 6자리로 표기하게 되어 있습니다.
자리수 조절이 필요 할 경우 format 기능이 있는 boost:format, stringstream, sprintf 등의 기존 함수를 사용하여야 합니다

?
  • ?
    노땅개발자 2012.09.25 01:15
    정리 참 잘해주셨네요.
    제 블로그에 출처 명시하고 퍼갑니다. ^^
  • ?
    최고의프로그래머 2012.09.26 01:35
    좋은 글 감사합니다. 출처명시하에 스크랩합니다
  • ?
    노력왕 2013.09.17 04:21
    와우 좋은 정보 입니다.
    제 블로그에도 퍼갈게요 좋은 하루 되세요 ^^

Lyn
조회 수 34425 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

역시 이번에도 아무도 관심가져주지 않는 (...) 불쌍한 주제를 하나 가지고 나와봤습니다


C++의 표준 라이브러리인 stl 의 특징이라고 하면 반복자(iterator)의 존재하고 할 수 있는데요...

이 반복자들은 여러가지 종류가 있습니다. 

정방향 or 역방향, 임의접근 or 순차접근, 상수 or 비상수 등 여러가지 조합의 반복자를 생성 할 수 있는데요 ...


이중 방향은 애초에 별도의 함수로 제공되고 (begin vs rbegin), 임의접근이냐 순차접근이냐는 컨테이너의 특성에 달린 문제었습니다.
그러나 상수 반복자(const_iterator)는 별도의 함수가 제공되지 않았는데요, C++특성상 비상수 -> 상수 의 변환은 자유롭기 때문입니다.

그래서 비상수 반복자를 리턴하는 begin 을 호출 후 상수반복자 type 의 변수에 대입하여 사용하는 식으로 구현 되었었지요.



하지만 C++11에선 상수반복자를 리턴하는 cbegin 이 추가되었습니다.
왜냐구요? auto 키워드의 존재 때문입니다. 

사용해보신 분은 아시겠지만 auto 는 한번 써보고 나면 없으면 stl 쓰기 싫어질 정도로 반복자와 함께 사용할때 아주 편한 기능인데, auto는 인터프리팅 언어들처럼 동적타입 변수가 아니라 우변의 type을 유추해서 컴파일타임에 type이 정해지기 때문에 begin 으로 리턴받은 반복자는 반드시 비상수 반복자가 됩니다.


그렇기에 C++11에서는 auto와 함께 사용할 수 있는 상수 반복자를 리턴하는 별도의 함수가 추가되었습니다. 애초에 상수반복자를 리턴하기 때문에 auto로 선언해도 좀 더 안전한 코드를 짤 수 있게 됩니다.


TAG •
?

Lyn
조회 수 4557 추천 수 0 댓글 1
Atachment
첨부 '1'
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

C++ 은 C에서 유래한 오래된 언어 답게 가능한 한 최소한의 라이브러리만 가지고 있던 시절이 있었습니다. 

하지만 시대의 흐름은 거스를 수 없었고, STL이 추가 된 이후 200년대 이후 TR1을 시작으로 매우 많은 라이브러리들이 추가 되었습니다.

 

이 많은 라이브러리들은 모두 (당연하게도) 모두 C++로 만들어 져 있었으며 template 을 상당히 예전부터 가지고 있던 언어 답게 매우 많은 라이브러리가 template 기반으로 되어 있었고 template 의 특성상 라이브러리의 소스가 모두 공개될 수 밖에 없기 때문에 별다른 작업이 없이도 C++ 프로그래머들은 표준 라이브러리의 소스를 마음껏 볼 수 있었습니다(의외로 특정 언어의 라이브러리가 그 언어로 다 만들어진 경우가 드뭅니다)

 

덕분에 대체 tuple 의 소스는 어떻게 구현되어 있을까 궁금해서 열어봤다가, 2개부터 N개까지의 tuple 이 전부 따로 구현되어 있는 것을 보고 매우 실망했던 (T.T) 가슴아픈 기억도 있는데, C++ 표준위원회는 이러한 특정 라이브러리를 더 깔끔하게 만들기 위해 새 문법이 필요하다면 컴파일러 개발사들의 구현 가능여부 (....) 따위는 고려하지 않고 새 문법을 추가하였고(tuple 을 구현하기 위해 추가된 variadic template 라던가... 물론 이것도 고수들은 나름대로 다른곳에 쓸 방도를 찾아 내더군요. 그러라고 만들어준게 아닌 template 으로 metaprogramming을 한 것 처럼) 결국 영원히 추가되지 않을 듯 한 export 키워드라는 흑역사도 만들어 내었습니다.

 

하지만 C++11에서 Type Traits가 추가되면서 사정이 좀 달라지는데, 당시까지의 C++ 문법으로는 구현이 불가능한 함수들이 표준에 포함 되었기 때문입니다.

예를들어 std::is_integral<T> 는 해당 T type 이 정수형인가를 판정하는 함수인데, 이는 아주 단순하게 존재하는 모든 기본type 에 대해 해당 template 을 특수화 함으로서 해결하였습니다. 그 일부를 보면

 

01.png

 

대략 뭐 이런식이죠.

 

하지만 std::is_enum<T>, std::has_virtual_destructor<T> 등은 분명 라이브러리 형태로 제공 되어야 하나, 어떤 방법으로도 해당 정보를 프로그래머가 얻어낼 수 없습니다. 그렇다고 해당기능을 연산자로 넣기에는 너무 많은 연산자가 추가되어야 하고, 연산자 주제에 상당히 긴 이름을 가질 수 밖에 없는 문제가 있습니다. 물론 reinterpret_cast 같이 기존에도 이름이 긴 연산자가 있었으나, 이는 의도적으로 길게 만들어진 작명으로서 가능하면 쓰지 말라는 의미와 함께 만약 사용하였을 경우 눈에 잘 띄도록 하는 의미도 있습니다.

 

결국 언어에 문법을 추가되지 않았으나, 제공해야 하는 기능은 생겨 났고, 그 결과는 별 수 없이 컴파일러에 의해 코드가 자동 생성되도록 하는 대량의 컴파일러 확장키워드의 추가로 나타났습니다. 예를들어 VC++2015는 아래와 같은 매크로를 제공하는데, __(언더바 2개) 로 시작하는 함수는 전부 실제 존재하는것이 아닌 컴파일러가 컴파일 시점에 알아서 채워 주는 값들입니다.

 

// COMPILER SUPPORT MACROS

// VC++ V14 SUPPORT
  #define _IS_BASE_OF(_Base, _Der) \
: _Cat_base<__is_base_of(_Base, _Der)>
  #define _IS_CONVERTIBLE(_From, _To) \
: _Cat_base<__is_convertible_to(_From, _To)>
  #define _IS_UNION(_Ty) \
: _Cat_base<__is_union(_Ty)>
  #define _IS_CLASS(_Ty) \
: _Cat_base<__is_class(_Ty)>
  #define _IS_POD(_Ty) \
: _Cat_base<__is_pod(_Ty)>
  #define _IS_EMPTY(_Ty) \
: _Cat_base<__is_empty(_Ty)>
  #define _IS_POLYMORPHIC(_Ty) \
: _Cat_base<__is_polymorphic(_Ty)>
  #define _IS_ABSTRACT(_Ty) \
: _Cat_base<__is_abstract(_Ty)>
  #define _IS_FINAL(_Ty) \
: _Cat_base<__is_final(_Ty)>
  #define _IS_STANDARD_LAYOUT(_Ty) \
: _Cat_base<__is_standard_layout(_Ty)>
  #define _IS_TRIVIAL(_Ty) \
: _Cat_base<__is_trivial(_Ty)>
  #define _IS_TRIVIALLY_COPYABLE(_Ty) \
: _Cat_base<__is_trivially_copyable(_Ty)>
  #define _HAS_TRIVIAL_DESTRUCTOR(_Ty) \
: _Cat_base<__has_trivial_destructor(_Ty)>
  #define _HAS_VIRTUAL_DESTRUCTOR(_Ty) \
: _Cat_base<__has_virtual_destructor(_Ty)>
  #define _UNDERLYING_TYPE(_Ty) \
__underlying_type(_Ty)
  #define _IS_LITERAL_TYPE(_Ty) \
: _Cat_base<__is_literal_type(_Ty)>
  #define _IS_ENUM(_Ty) \
: _Cat_base<__is_enum(_Ty)>
  #define _IS_DESTRUCTIBLE(_Ty) \
: _Cat_base<__is_destructible(_Ty)>
  #define _IS_NOTHROW_ASSIGNABLE(_To, _From) \
: _Cat_base<__is_nothrow_assignable(_To, _From)>
  #define _IS_NOTHROW_DESTRUCTIBLE(_Ty) \
: _Cat_base<__is_nothrow_destructible(_Ty)>
  #define _IS_TRIVIALLY_ASSIGNABLE(_To, _From) \
: _Cat_base<__is_trivially_assignable(_To, _From)>
  #define _IS_CONSTRUCTIBLE \
__is_constructible
  #define _IS_NOTHROW_CONSTRUCTIBLE \
__is_nothrow_constructible
  #define _IS_TRIVIALLY_CONSTRUCTIBLE \
__is_trivially_constructible

 

 

전 이런 결과가 된 것이 언어가 제 컨트롤을 벗어난 것 같아 좀 아쉽기도 하고 한편으로는 라이브러리의 형태로 제공되느라 지저분해진 것들이 많은데(예를들면 std::map 이라거나 ... 요즘은 많은 언어들이 map 정도는 라이브러리가 아니라 문법차원에서 지원 하죠) 언어를 깔끔하게 만들기 위해선 좋다고 생각합니다. 

TAG •
?
  • ?
    사무엘 2016.01.01 03:46
    요즘 C++ 라이브러리는 반쯤은 언어를 확장해 가면서 제공되고 있군요. ㄷㄷㄷ
    reinterpret_cast는 일부러 가능한 한 쓰지 말라고 저렇게 길게 작명된 것이었고.. 좋은 정보 감사합니다!

Lyn
조회 수 31905 추천 수 0 댓글 4
Atachment
첨부 '1'
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

C++의 STL 에서는 여러가지 알고리즘을 제공한다.
그중 "임의의" 동작을 할 수 있는 알고리즘들은 그 "동작" 의 대상이 되는 인자를 받도록 되어 있는데, 
그 "동작"의 조건은 ()연산자로 호출이 가능할것! 이다.


그 동작을 만족시키는것은 C에서는 함수가 있다.
또 C++에서는 STL 과 함께 소개된 함수객체(Functor)가 있으며, STL 초기부터 제공된 bind1st, bind2nd가 있고, boost에서 제공되는 mem_fn 도 있으며, 이 모든것을 통합한 범용 bind(C++11 or boost에 포함)도 존재한다.

그리고 최신의 C++11 표준에 포함된 lambda도 있고, boost의 lambda도 있지만, 이쪽은 C++11 표준에 lambda가 포함 된 이상 더이상 쓸 일은 없을테니 이번 실험에선 제외한다.


실험순서는 전역함수, bind된 전역함수, 함수객체, 람다, bind된 람다, auto를 이용해 bind된 람다 의 순이다.

실험은 Visual C++ 2010 Sp1, x86 Debug Build에서 테스트 하엿다. Release Mode 도 특성은 동일하다.

궂이 Debug Build로 테스트 한 이유는 Release모드에서 자꾸 전역함수를 inline화 시키는 바람에 =_=;


코드 나간다.


#include <cstdlib>
#include <cstdio>
#include <vector>
#include <random>
#include <cstdint>
#include <algorithm>
#include <functional>
#include <windows.h>
 
using namespace std;
 
__int64 g_NumberSum;
 
void GetSumFunction(int Num)
{
	g_NumberSum = g_NumberSum + Num;
}
 
struct GetSumFunctor
{
	void operator()(int Num)
	{
		g_NumberSum = g_NumberSum + Num;
	}
};
 
void wmain()
{
	const int NUMBER_COUNT = 100000000;
 
	mt19937_64 RandomEngine;
	uniform_int <> RandomRange(0, INT32_MAX);
	RandomEngine.seed(GetTickCount());
 
	vector<int> RandumNumbers;
	RandumNumbers.reserve(NUMBER_COUNT);
	for (int i = 0; i < NUMBER_COUNT; ++i)
	{
		RandumNumbers.push_back(RandomRange(RandomEngine));
	}
 
	DWORD Tick;
//function
	g_NumberSum = 0;
	Tick = GetTickCount();
	for_each(RandumNumbers.begin(), RandumNumbers.end(), GetSumFunction);
	printf("Global Function :: Sum : %I64d, Time : %dms\n", g_NumberSum, GetTickCount() - Tick);
//bind function
	g_NumberSum = 0;
	function<void(int)> FunctionObject = bind(&GetSumFunction, tr1::placeholders::_1);
	Tick = GetTickCount();
	for_each(RandumNumbers.begin(), RandumNumbers.end(), FunctionObject);
	printf("Bind Function   :: Sum : %I64d, Time : %dms\n", g_NumberSum, GetTickCount() - Tick);
//functor
	g_NumberSum = 0;
	Tick = GetTickCount();	
	for_each(RandumNumbers.begin(), RandumNumbers.end(), GetSumFunctor());
	printf("Functor         :: Sum : %I64d, Time : %dms\n", g_NumberSum, GetTickCount() - Tick);
//C++ 11 Lambda
	g_NumberSum = 0;
	Tick = GetTickCount();
	for_each(RandumNumbers.begin(), RandumNumbers.end(), 
		[](int Num)
		{
			g_NumberSum = g_NumberSum + Num;
		});
	printf("C++11 Lambda    :: Sum : %I64d, Time : %dms\n", g_NumberSum, GetTickCount() - Tick);
//C++11 Bind Lambda
	g_NumberSum = 0;
	Tick = GetTickCount();
	function<void(int)> BindLambda = 
		[](int Num)
		{
			g_NumberSum = g_NumberSum + Num;
		};
	for_each(RandumNumbers.begin(), RandumNumbers.end(), BindLambda);
	printf("Bind Lambda     :: Sum : %I64d, Time : %dms\n", g_NumberSum, GetTickCount() - Tick);
//C++11 Auto bind Lambda
	g_NumberSum = 0;
	Tick = GetTickCount();
	auto AutoBindLambda = 
		[](int Num)
		{
			g_NumberSum = g_NumberSum + Num;
		};
	for_each(RandumNumbers.begin(), RandumNumbers.end(), AutoBindLambda);
	printf("Auto Bind Lambda:: Sum : %I64d, Time : %dms\n", g_NumberSum, GetTickCount() - Tick); 
} 



아래는 결과이다.

lambda.png


결과를 보면 lambda 가 가장 빠른 것을 볼 수 있다. 길게 나불대지 않고 성능 이슈와 원인을 아래 간략히 적어본다.
1. 전역함수의 경우 함수 Call 오버헤드에 의해 속도가 조금 감소하엿다.

2. lambda, functor 는 사실상 오차범위 내의 차이라고 보인다.

3. bind lambda 의 경우는 std::fuction 객체가 함수호출 정보를 RTTI에 의존하는 특징때문에 속도를 왕창 까먹게 된다.

4. bind 된 전역함수의 경우는 RTTI의 오버헤드 + 함수호출로 인해 가장 느려진다.

5. auto를 사용해 변수에 저장한 lambda 는 std::fuction객체에 저장 하는 것이 아니라 일종의 inline 함수처럼 구현해준다. 그래서 오버헤드가 전혀 없이 빠른 속도를 보여준다. 즉 같은 함수객체를 2번이상 이용 할 경우 코드를 Copy&Paste 하지 않아도 auto를 이용하면 성능과 중복방지 두마리 코드를 다 잡을 수 있다.

?
  • ?
    elrha 2012.08.16 18:27

    으아 이거 좋은정보네요


    테스트는 안해봤지만 auto 객체 마우스 오버해보면 std::function으로 나올듯 한데..


    결국 컴파일러 지능테스트인건가요 ㅋㅋㅋㅋ

  • profile
    Lyn 2012.08.17 07:23

    아뇨 함수포인터 취급해요 ㅎㅎ


    컴파일 타임에 완전한 호출 정보를 알고있는 상황에서 궂이 오버헤드가 있는 std::function으로 컴파일할 이유가 없죠

  • ?
    11ho 2014.03.25 05:22
    감사합니다. 속이 다 후련하네요 ㅠㅠ
  • ?
    해피 2015.07.17 18:45
    퍼가용

Atachment
첨부 '3'
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

C++ 템플릿 상속엔 골 때리는 문제가 있는데 ...

바로 베이스클래스의 멤버에 접근하려면 베이스 클래스의 이름을 명시해야 한다는 것이다... 안그러면 이름을 못찾아온다

사람 상당히 귀찮게 만드는놈이라 할 수 있겠다.

보통 일반적으론 볼일이 없고 Mixin 을 이용하거나 아니면 Effective C++ 을 읽으면서 알게된다(책에는 "못찾는다" 라고 되어 있다)


간단히 말하면 이런 코드다

#include <cstdio>

void foo()
{
	printf("Global Function\n");
}
template <typename T>
class Cls1
{
	T Var1;
public:
	void foo()
	{
		printf("Member Function\n");
	}
};

template <typename T>
class Cls2 : public Cls1<T>
{
	T Var2;
public:
	void test()
	{
		Cls1<T>::foo();
	}
};

int main()
{
	Cls2<int> cls2;
	cls2.test();

	return 0;
}


근데 만약 명시 하지 않으면 어떻게 될까?


일단 최신의 VC++ 2012에서 돌려보자

01.png


헐...? 정확히 멤버 함수를 찾아온다. 여기엔 올리지 않겠지만 VS2005~2010 도 모두 같은 동작을 한다.

다른컴파일러에서 해보자. gcc 4.4다.


02.png


헐?! 글로벌 함수를 찾는다 (...) 이거뭥미.


그럼 최신의 C++0x를 지원하는 gcc4.7에서 해보자.


03.png


역시 전역함수를 찾는다.


표준문서는 귀찮아서 (...) 확인하지 않았지만 관련 서적 등을 보면 gcc의 동작이 맞는 것으로 보인다.
하지만 저런 코드를 짜면서 gcc 쪽 동작을 원하는 사람이 과연 있을까... 하는 생각이 든다. 일반적인 클래스를 만드는 느낌으로 당연히 멤버함수가 호출 될 것이라고 생각 하지 않을까? 이 결과를 확인하면서 C++은 당최 생각대로 움직여 주지 않는 매저키스트 들을 위한 언어란 누군가의 말이 귓가에 맴돈다 (...)


결론 : EC++에 나온대로 그냥 제대로 포커스 지정 하자 (...) 야!


PS. gcc 에서는 저렇게 두가지 모두 있는 경우가 아니라 전역 foo 함수가 없는 (즉 이름을 찾을 수 없는) 경우에는 당연히 이름을 찾지 못해 에러를 내는데, 이 경우 컴파일 옵션에 -fpermissive 를 추가 하는 것으로 멤버함수로의 연결이 가능하다(워닝은 뜬다)
단 전역 foo 함수가 존재 할 경우 저 옵션을 그냥 무시하고 그냥 전역 함수로 연결해 버린다.


PS2. 혹시 LLVM-clang 을 사용할 수 있는 환경에 계신분은 어떤 결과가 나오는지 알려주시면 좋겠다.



?
  • ?
    123 2012.09.03 03:48
    VS 에서는 자동으로 찾아주네요.. 역시 상용이라 틀린가보네요..
    clang 으로 컴파일 해서 실행해보니 gcc 하고 같네요. .
    관련글에는 이렇게 나오네요
    While non-dependent names are resolved "normally" – when the template is defined,
    the resolution for dependent names happens at the point of the template’s instantiation.
    그러까 템플릿 인스턴스시 resolve 가 되게할려면 dependent name 으로 만들어 줘야 되네요
    Cls1<T>::foo() or this->foo() 이런식으로..

    http://eli.thegreenplace.net/2012/02/06/dependent-name-lookup-for-c-templates/

Lyn
조회 수 5152 추천 수 0 댓글 1
Atachment
첨부 '3'
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

상당히 많은 언어가 예외 처리기를 가지고 있는데, 각각의 언어별로 특성이 있습니다.
try - catch - finally 를 모두 가지고 있는 언어(C#, Java 등) 도 있고

try - except (C 계열의 try - catch 에 대응) 와 try - finally 를 가지고 있지만 try - except 뒤에 finally 가 붙을 수 없어서 아래와 같이 중첩을 해야 하는 Pascal 계열의 언어(주로 Delphi 겠지만..) 도 있습니다


try

  try 

    //do something

  except

    //do something

finally

  //do something 


네 그리고 대망의 C++은.. finally 그런거 없습니다 (...)
C++ 표준협회에서는 stack 에 생성된 객체의 소멸자를 이용하라고 하는데 다른 언어의 코드를 C++로 옮기다가 보면 해제할것 하나하나마다 객체 만들어 주기도 보통 일이 아닙니다. 하지만 의외로 타 언어의 샘플을 C++로 옮기는게 자주 발생 하는 일이기도 하지요.


그래서 전 람다를 이용한 꼼수를 이용해서 코드를 옮길때 자주 써먹고 있습니다.
바로 아래와 같은 객체를 사용 해서요


class Finalizer
{
public:
    Finalizer()
    {

    }
    Finalizer(std::function<void(void)> fPtr)
    {
        this->fPtr = fPtr;
    }
    ~Finalizer()
    {
        if (fPtr != nullptr) fPtr();
    }
    void SetFunction(std::function<void(void)> fPtr)
    {
        this->fPtr = fPtr;
    }
private:    
    std::function<void(void)> fPtr;
};


소멸자에서 function 을 호출해 주느 매우 단순한 구조입니다.
이걸 어떻게 쓰냐면 


void test1()
{
    char* arr = new char[100];
    Finalizer final([&]
    {
        delete[] arr;
        wcout << L"Test1 : Delete Arr" << endl;
    });

    //do Something
    wcout << L"Test1 Code End" << endl;
    
    return;
}


이렇게 씁니다.

저 Finalizer 의 생성자로 lambda 를 넘겨서 finally 블록으로 삼는거죠.
그럼 포커스를 잃는순간 호출 되면서 실행 되게 됩니다.

final1.png


그럼 exception 이 발생 했을때는 어떨까요?
간단하게 아래와 같은 코드를 생각해 볼 수 있습니다


void test2()
{
    try
    {
        char* arr = new char[100];
        Finalizer final([&]
        {
            delete[] arr;
            wcout << L"Test2 : Delete Arr" << endl;
        });
        //do Something
        wcout << L"Test2 : Code End" << endl;
        
        throw L"Exception";
        
        return;        
    }
    catch (...)
    {
        wcout << L"Test2 : Exception" << endl;
    }    
}


하지만 이 코드는 문제가 하나 있는데, 코드 흐름이 다르다는겁니다

final2.png


블록을 빠져나오는것이 catch 로 넘어가는것보다 우선이기 때문에 finally 로 사용하려 했던 코드가 예외처리 코드보다 먼저 실행되어 버립니다.

이걸 해결하는건, C++은 블럭을 자유롭게 구성할 수 있다는걸 이용해서.. 바깥에 블록을 하나 더 만들어서 해결합니다




void test3()
{
    {
        Finalizer final;
        try
        {
            char* arr = new char[100];
            final.SetFunction([&]
            {
                delete[] arr;
                wcout << L"Test3 : Delete Arr" << endl;
            });
            //do Something
            wcout << L"Test3 : Code End" << endl;

            throw L"Exception";

            return;
        }
        catch (...)
        {
            wcout << L"Test3 : Exception" << endl;
        }
    }
}


위 코드는 어차피 저 코드밖에 없기 때문에 추가적인 블록이 필요 없긴 하지만... 일반적으론 그런 코드는 많지 않겠지요


final3.png


실행결과는 다음과 같습니다.
finally 블록이 다른 언어에서의 코드와 다르게 맨 뒤가 아닌 중간에 와야 하는게 맘에 들진 않는데...
대신 다른 언어에서 try 블록 내부에 선언된 변수를 finally 에서 쓸 수 없어 변수만 위쪽으로 옮기거나 하는 단점이 사라져 좋아진 것도 있습니다.


뭐 어차피 급하게 쓸때 쓰는 "꼼수" 라서요


PS. 테스트는 메모리 해제 코드로 했는데..... 메모리는 그냥 unique_ptr 이나 shared_ptr 계열 쓰세요 (...)

PS2. 더 좋은 방법 있으시면 좀 알려주세요.


아래는 전체 테스트 코드입니다

#include <iostream>
#include <functional>

using namespace std;

class Finalizer
{
public:
    Finalizer()
    {

    }
    Finalizer(std::function<void(void)> fPtr)
    {
        this->fPtr = fPtr;
    }
    ~Finalizer()
    {
        if (fPtr != nullptr) fPtr();
    }
    void SetFunction(std::function<void(void)> fPtr)
    {
        this->fPtr = fPtr;
    }
private:    
    std::function<void(void)> fPtr;
};


void test1()
{
    char* arr = new char[100];
    Finalizer final([&]
    {
        delete[] arr;
        wcout << L"Test1 : Delete Arr" << endl;
    });

    //do Something
    wcout << L"Test1 Code End" << endl;
    
    return;
}

void test2()
{
    try
    {
        char* arr = new char[100];
        Finalizer final([&]
        {
            delete[] arr;
            wcout << L"Test2 : Delete Arr" << endl;
        });
        //do Something
        wcout << L"Test2 : Code End" << endl;
        
        throw L"Exception";
        
        return;        
    }
    catch (...)
    {
        wcout << L"Test2 : Exception" << endl;
    }    
}

void test3()
{
    {
        Finalizer final;
        try
        {
            char* arr = new char[100];
            final.SetFunction([&]
            {
                delete[] arr;
                wcout << L"Test3 : Delete Arr" << endl;
            });
            //do Something
            wcout << L"Test3 : Code End" << endl;

            throw L"Exception";

            return;
        }
        catch (...)
        {
            wcout << L"Test3 : Exception" << endl;
        }
    }
}

void wmain()
{
    test1();
    wcout << endl;
    test2();
    wcout << endl;
    test3();
}
TAG •
?

Lyn
조회 수 10394 추천 수 0 댓글 0
Atachment
첨부 '10'
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

nuget이 뭔가 하니... 

java의 maven, ruby의 gem, node.js 의 npm 같은 패키지 저장소입니다. ms가 만든거죠


필요한 라이브러리를 매번 찾아서 세팅하려면 귀찮으니 인터넷에서 받아서 자동설치 하자... 의 개념입니다.
저도 C#으로 개발할 때는 매우 잘 이용하고 있었는데... 멍청하게도 이게 C++을 지원한다는걸 모르고있었습니다.

얼마전 알게된 김에 한번 테스트 해 보았습니다.


모든 스크린샷은 최근에 무료 배포되는 VS2013 Community Edition입니다.


그럼 새 Console 프로젝트를 하나 만들고, 

Project -> Manage Nuget Packages... 를 클릭합니다


1.png



그리고 Serch Online 텍스트박스에 설치하고자 하는 패키지명을 넣습니다.
전 흔히 쓰는 boost로 해 보겠습니다


2.png


VC++ 2013 는 버전으로는 12.0 이므로 boost-vc120 을 선택하여 설치합니다

3.png


install을 누르면 설치되는데 속도는 꽤 빠릅니다.
boost가 5분정도만에 설치 되더군요


4.png


설치가 끝나면 프로젝트에 패키지 파일하나만 달랑 추가됩니다. 깔끔하네요

5.png


그럼 정말 잘 되는지 테스트를 해야겟죠?

boost::shared_array 를 사용한 후 빌드를 해 봤습니다


6.png


깔끔하게 잘 진행 되네요.


그럼 패키지 파일들은 어디에 저장 되는지 궁금해 지는데,

솔루션 폴더(프로젝트가 아님!) 내의 package 폴더에 저장됩니다


7.png



그런데 이상한점이 있는데, 프로젝트 옵션 어디에도 저 Path에서 lib나 include 를 하고 있지 않습니다.
그럼 대체 어떻게 include 와 링크가 성공하는걸까요?

9.png


해답은 프로젝트파일에 있습니다.

ExtensionTargets 을 추가해서 빌드 targets 파일을 추가 해 주는거죠

10.png


그래서 프로젝트에 파일이 등록되어 있지 않아도 정상적으로 include 와 link 가 가능해 집니다.


PS. 다른 라이브러리는 몰라도 boost는 nuget 안쓰는게 좋을지도...

5G 가 프로젝트 생성될때마다 추가되면 (.....)


#본격_SSD_용량_줄어드는_파일.jpg

8.png


TAG •
?

Lyn
조회 수 23053 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

정성태님의 홈페이지를 정독하던중 오랫만에 C++ 관련 글이 하나 올라 왔길래 확인해 보았습니다.
바로 g++에서 inner 클래스를 사용한 템플릿이 제대로 선언 되지 않는다는 문제인데요, 코드는 아래와 같습니다(조금 다릅니다. 원본에 오타가 있어서 좀 고쳣습니다)


원본 : http://www.sysnet.pe.kr/Default.aspx?mode=2&sub=0&pageno=0&detail=1&wid=1791


#include <iostream>
#include <vector>
#include <map>

typedef char BYTE;
typedef int _int;
typedef std::vector<BYTE> _byteArrayHolder;
typedef long _long;

template <class T, class V>
class KeepAliveReceiver
{
};

template<class Receiver, class ErrorAction, _int MAX_CONTENT_SIZE = 8192>
class MultiPartByteArrayReceiver : public KeepAliveReceiver< MultiPartByteArrayReceiver<Receiver, ErrorAction>, ErrorAction>
{
	class MultiPartByteArray
	{
	public:
		_int key;
		std::vector<BYTE> byteHolders;
		_long totalSize;

	public:
		MultiPartByteArray(_int _key) : key(_key), byteHolders(), totalSize(0)
		{
		}

		void AddBytes(_byteArrayHolder bytes)
		{
			totalSize += bytes.size();
		}
	};

	typedef KeepAliveReceiver< MultiPartByteArrayReceiver<Receiver, ErrorAction, MAX_CONTENT_SIZE>, ErrorAction> Super;
	typedef MultiPartByteArrayReceiver<Receiver, ErrorAction, MAX_CONTENT_SIZE> This;

public:
	typedef std::map<_int, MultiPartByteArray>  MultiPartBytesMap;
	MultiPartBytesMap receivedMultiPartedBytes;

public:

	MultiPartByteArrayReceiver() : Super(), receivedMultiPartedBytes()
	{}

	void Test()
	{
		MultiPartByteArray a(1);
		std::map<_int, MultiPartByteArray>::iterator iter = receivedMultiPartedBytes.find(1); //컴파일 오류
	}
};

int main()
{
	std::cout << "Hello World" << std::endl;

	MultiPartByteArrayReceiver<int, int> t;
	t.Test();

	return 0;
}


바로 위와 같은 코드인데, 이는 template 이 완전히 생성 되기 전에, 그 템플릿에 의존하는 type을 인식할 수 없기 때문에 발생합니다
(이런 경우는 템플릿 클래스가 부모 템플릿의 함수를 호출한다거나 할때도 발생합니다)

VC++은 그냥 적당히 알아서 (...) 인식해서 넘어 가는데 이걸 오류로 처리하는 컴파일러도 있습니다. 뭐 만드는사람 취향문제겟지만.


이 문제의 해결법은 바로 type을 인식하지 못하는 것이니 이게 template의 type 명을 나타낸다고 알려주는겁니다.
바로 typename 키워드를 쓰는것인데 그럼 아래와 같게 됩니다



typename std::map<_int, MultiPartByteArray>::iterator iter = receivedMultiPartedBytes.find(1); //컴파일 오류 


이렇게 하면 뒤의 템플릿 선언문을 타입으로 인식하여 정상적으로 컴파일 됩니다. 물론 VC에서도 마찬가지입니다.
또 템플릿을 선언 할 때 처럼 class 키워드를 써도 OK 입니다. 전 typename 키워드가 헤깔리지 않아 선호하는 편이지만요


PS. 사실 이 모든 문법적 지저분함을 해결하는 마법의 키워드가 C++에 있으니...

그냥 auto 쓰면 됩니다 (...) C++11에서 추가된 auto와 decltype 의 타입추론 시스템은 템플릿을 정말 간단하게 만들어주는 축복이지요

TAG •
?

Lyn
조회 수 25858 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
void foo1(string str = "DefaultString")
{
//값으로넘기기
}
 
void foo2(const string str = "DefaultString")
{
//const 값으로넘기기
}
 
void foo3(string& str = "DefaultString")
{
//이건 에러남...
}
 
void foo4(const string& str = "DefaultString")
{
//const 레퍼런스로 넘기기
}
 
void foo5(string& name = string("DefaultString"))
{
//임시객체 넘기기
}
 
void foo6(const string& name = string("DefaultString"))
{
//const 임시객체 넘기기
}
 
static std::string DEFAULT_STRING = "DefaultString";
void foo7(string& str = DEFAULT_STRING)
{
//이건 DEFAULT_STRING이 바뀔 가능성이 있음.. 위험한코드
}
 
const static std::string CONST_DEFAULT_STRING = "DefaultString";
void foo8(const string& str = CONST_DEFAULT_STRING)
{
//static const 레퍼런스 객체 넘기기 (boost가 자주 쓴 방식... string은 아니지만)
}
?

2009.08.19 03:08

C++ new 연산자의 진실

Lyn
조회 수 57728 추천 수 0 댓글 2
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

new 연산자의 진실

 

C++에서는 메모리를 할당할 때 new 연산자를 사용합니다.

그리고 이 new 라는 연산자는 오버로딩이 가능합니다. 그럼 과연 이 new 의 정체는 뭘까요?

new 를 호출하면 실제로는 malloc 이 내부에서 다시 호출 된 다는 것은 일단 다 안다고 가정하고 넘어가겠습니다.

 

첫 코드 나갑니다. 연산자 new 를 오버로딩 한 경우입니다.

#include <stdio.h>

#include <stdlib.h>

 

class Test

{

public:

           int a;

 

           void* operator new(size_t size)

           {

                     printf("한 개 할당중\n");

                     Test* temp = (Test*)malloc(size);

                     return temp;

           }

           Test()

           {

                     printf("Test Constructor\n");

           }

};

int main()

{

           Test* t1;

 

           t1 = new Test;

 

           system("pause");

           return 0;

}

 

new 에는 size_t 형태의 파라메터가 하나 존재합니다. 이 파라메터로 할당 해야 할 크기를 알려줍니다. 단순히 그 크기로 메모리를 할당 하고 리턴 만 하엿습니다.

 

실행결과는 아래와 같습니다.

 

image1.png

 

우리는 부른적도 없는 생성자가 호출되었습니다. new 가 단순히 메모리 할당만 하도록 오버로딩 하엿는데요. 여기서 new 는 실제로는 오버로딩이 되지 않았다고 할 수 있겠습니다. 뭔가 수상하군요. 디스어셈블 해 보았습니다.

 

image2.png

 

이런 우리는 new 를 호출했을 뿐인데 실제로는 operator new 라는 함수와 생성자를 따로따로 호출 하고 있었네요. 그럼 우리가 수정한 것은 operator new 라는 함수 일 뿐 new 연산자 자체가 아니라는것을 알 수 있습니다.

 

심지어 윗줄에서는 할당 할 메모리 크기를 스택에 집어넣어주는 친절함(?) 까지 엿볼 수 있군요. Pop 이 호출부위 아래에 존재한다는 것은 operator new cdecl 방식으로 call 되고 있다고 짐작 할 수 있겠습니다.

 

그럼 new 는 단지 operator new 와 생성자를 호출 하고 있을 뿐이라면 이 두 함수를 따로 따로 호출하는것도 가능하지 않을까요? 다음과 같은 코드를 짜 보았습니다.

#include <stdio.h>

#include <stdlib.h>

 

class Test

{

public:

           int a;

 

           void* operator new(size_t size)

           {

                     printf("한 개 할당중\n");

                     Test* temp = (Test*)malloc(size);

                     return temp;

           }

           Test()

           {

                     printf("Test Constructor\n");

           }

};

int main()

{

           Test* t1;

 

           t1 = (Test*)Test::operator new(sizeof(Test));

           t1:Test();

 

           system("pause");

           return 0;

}

 

그리고 실행 해 보았습니다.

 

image3.png

 

이런 완전히 똑같군요.

 

 

그럼 이렇게 결론 내릴 수 있을까요? new 연산자는 operator new 함수를 호출 한 후, 생성자를 호출 해 주는 연산자이다.

 

그런데 이게 또 아닌거 같습니다. 왜냐면 이 두 함수에는 VMT(Virtual Methor Table) 을 생성 해 주는 부분이 없거든요. 가상함수가 한 개 이상 존재하고 상속관계가 있는 클래스(상속 받았던 상속 했던) 에는 반드시 VMT의 포인터가 존재합니다. 그럼 이 VMT는 언제 등록되었을까요? 살짝 코드를 고쳐보았습니다.

 

#include <stdio.h>

#include <stdlib.h>

 

class Test

{

public:

           int a;

 

           void* operator new(size_t size)

           {

                     printf("한 개 할당중\n");

                     Test* temp = (Test*)malloc(size);

                     return temp;

           }

           Test()

           {

                     printf("Test Constructor\n");

                     func();

           }

 

           virtual void func()

           {

                     printf("Test::func()\n");

           }

};

 

class Test2 : public Test

{

           virtual void func()

           {

                     printf("Test2::func()\n");

           }

};

int main()

{

           Test* t1;

 

           t1 = new Test2;

 

           system("pause");

           return 0;

}

 

 

생성자에서 func라는 가상함수를 호출 하고 있습니다.

우리는 Test2를 생성하였으므로 Test2::func() 가 출력 될 거라고 기대 할 수 있겠습니다. 결과를볼까요?

 

image4.png

 

어라 뭔가 이상합니다. Test::func() 가 출력되었네요. 이게 어찌 된 일일까요?

그 이유는 생성자를 호출 하는 시점에서는 VMT의 포인터가 제대로 등록 되지 않기 때문에, 가상함수 본래의 역할을 제대로 하지 못하는 겁니다. 디스어셈블 한 코드를 보겠습니다.

 

image5.png

 

생성자를 호출 한 다음에도 추가적인 작업을 하고 있습니다.

그 중 빨간 네모로 표시 된 부분이 가상함수가 없을때는 존재하지 않던 부분입니다.

즉 저 부분에서 VMT포인터를 추가하는 작업을 하고 있다고 생각 할 수 있겠습니다.

 

이제 new 의 진실이 밝혀졋군요.

new 연산자를 호출하면

 

1.     메모리 할당을 위해 operator  new 함수를 호출한다

2.     생성자를 호출한다

3.     VMT를 등록해 준다

 

3가지 과정으로 new 의 역할은 모두 종료됩니다.

쉽고 편하게 쓰던 연산자가 참 하는 일도 많네요 : )

 

그럼 또 다른 언어인 Delphi 의 경우는 어떨까요?

 

program Project2;

 

{$APPTYPE CONSOLE}

 

uses

  SysUtils;

 

type

  Test = class

  public

    a : Integer;

 

    procedure func;virtual;

    constructor Create;

  end;

 

  Test2 = class(Test)

  public

    procedure func;override;

  end;

 

constructor Test.Create;

begin

  func;

end;

 

procedure Test.func;

begin

  WriteLn('Test.Func');

end;

 

procedure Test2.func;

begin

  WriteLn('Test2.Func');

end;

 

var

  T : Test;

begin

  T := Test2.Create;

  ReadLn;

end.

 

출력 결과는 아래와 같습니다.

image6.png

 

Delphi는 생성자 호출 시점이 VMT 생성 시점보다 뒤입니다.

Delphi 에서는 생성자 내에서 가상함수를 호출하더라도 정상적으로 작동합니다.

?

Lyn
조회 수 33000 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

사후 디버깅을 위해 가장 많이 쓰이는 방법중 하나가 메모리 덤프를 남기는 방법입니다.

보통 아래와 같은 형태로 구현 하게 되는데요. 과연 이 프로그램은 덤프가 남을까요?


#include <Windows.h>
#include <DbgHelp.h>
#include <cstdio>
#include <string>


using namespace std;

#pragma comment(lib, "dbghelp.lib")

LONG __stdcall TopLvFilter(PEXCEPTION_POINTERS pExceptionPointer)
{
	MINIDUMP_EXCEPTION_INFORMATION MinidumpExceptionInformation;
	std::wstring DumpFileName = L"dmpfile.dmp";

	MinidumpExceptionInformation.ThreadId = ::GetCurrentThreadId();
	MinidumpExceptionInformation.ExceptionPointers = pExceptionPointer;
	MinidumpExceptionInformation.ClientPointers = FALSE;

	if (DumpFileName.empty() == true)
	{
		::TerminateProcess(::GetCurrentProcess(), 0);
	}

	HANDLE hDumpFile = ::CreateFile(DumpFileName.c_str(),
		GENERIC_WRITE,
		FILE_SHARE_WRITE,
		nullptr,
		CREATE_ALWAYS,
		FILE_ATTRIBUTE_NORMAL, nullptr);

	MiniDumpWriteDump(GetCurrentProcess(),
		GetCurrentProcessId(),
		hDumpFile,
		MiniDumpNormal,
		&MinidumpExceptionInformation,
		nullptr,
		nullptr);

	::TerminateProcess(::GetCurrentProcess(), 0);

	return 0;
}

void main()
{
	SetUnhandledExceptionFilter(TopLvFilter);	
	atoi(nullptr);
}


네. 결론부터 말하자면 위 코드에서는 덤프가 남지 않습니다.
왜냐면 CRT 에서 에러가 발생하면 UnhandledExceptionFilter 를 CRT가 자신의 예외 핸들러로 다시 세팅 하기 때문입니다.

그러나 우리가 바라는건 별로 친절하지도 않은 (...) CRT의 에러메세지가 아니라 메모리 덤프지요.

우리가 원하는대로 덤프를 남기는 방법은 여러 가지가 있지만 그 중 한가지로 해결 해 보겠습니다.

이번에 사용 할 방법은 코드를 패치해서 CRT가 감히 내가 만든 예외처리기를 바꾸지 못하도록 (...) 하는 방법입니다



#include <Windows.h>
#include <DbgHelp.h>
#include <cstdio>
#include <string>

using namespace std;

#pragma comment(lib, "dbghelp.lib")

BYTE HotPatchingBackup[5];

LPTOP_LEVEL_EXCEPTION_FILTER WINAPI NullSetUnhandledExceptionFilter(
  _In_  LPTOP_LEVEL_EXCEPTION_FILTER lpTopLevelExceptionFilter
)
{
    return nullptr;
}

void InstallAPIHook_SetUnhandledExceptionFilter()
{
    BYTE *pSetUnhandledExceptionFilter;

    DWORD ProtectOption = 0;
    DWORD Temp = 0;

    pSetUnhandledExceptionFilter = (BYTE*)&SetUnhandledExceptionFilter;

	HANDLE hSelfProcess = OpenProcess(PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE , FALSE, ::GetCurrentProcessId());
	VirtualProtectEx(hSelfProcess, (void *)pSetUnhandledExceptionFilter, 5, PAGE_EXECUTE_WRITECOPY, &ProtectOption);     	

    memcpy(HotPatchingBackup, pSetUnhandledExceptionFilter, 5);

    *pSetUnhandledExceptionFilter = 0xE9;
	pSetUnhandledExceptionFilter++;
    *((DWORD *)(pSetUnhandledExceptionFilter)) = ((DWORD)NullSetUnhandledExceptionFilter) - ((DWORD)pSetUnhandledExceptionFilter + 4);	
	pSetUnhandledExceptionFilter--;

	VirtualProtectEx(hSelfProcess, (void *)pSetUnhandledExceptionFilter, 5, ProtectOption, &Temp);

	CloseHandle(hSelfProcess);
}

void UnInstallAPIHook_SetUnhandledExceptionFilter()
{
    BYTE *pSetUnhandledExceptionFilter;

    DWORD ProtectOption;
    DWORD Temp;

    pSetUnhandledExceptionFilter = (BYTE*)&SetUnhandledExceptionFilter;
	
	HANDLE hSelfProcess = OpenProcess(PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE , FALSE, ::GetCurrentProcessId());
	VirtualProtectEx(hSelfProcess, (void *)pSetUnhandledExceptionFilter, 5, PAGE_EXECUTE_READWRITE, &ProtectOption);    

    memcpy(pSetUnhandledExceptionFilter, HotPatchingBackup, 5);

	VirtualProtectEx(hSelfProcess, (void *)pSetUnhandledExceptionFilter, 5, ProtectOption, &Temp);     

	CloseHandle(hSelfProcess);
}

LONG __stdcall TopLvFilter(PEXCEPTION_POINTERS pExceptionPointer)
{
    MINIDUMP_EXCEPTION_INFORMATION MinidumpExceptionInformation;
    std::wstring DumpFileName = L"dmpfile.dmp";

    MinidumpExceptionInformation.ThreadId = ::GetCurrentThreadId();
    MinidumpExceptionInformation.ExceptionPointers = pExceptionPointer;
    MinidumpExceptionInformation.ClientPointers = FALSE;

    if (DumpFileName.empty() == true)
    {
        ::TerminateProcess(::GetCurrentProcess(), 0);
    }

    HANDLE hDumpFile = ::CreateFile(DumpFileName.c_str(),
        GENERIC_WRITE,
        FILE_SHARE_WRITE,
        nullptr,
        CREATE_ALWAYS,
        FILE_ATTRIBUTE_NORMAL, nullptr);

    MiniDumpWriteDump(GetCurrentProcess(),
        GetCurrentProcessId(),
        hDumpFile,
        MiniDumpNormal,
        &MinidumpExceptionInformation,
        nullptr,
        nullptr);

    ::TerminateProcess(::GetCurrentProcess(), 0);

    return 0;
}

void main()
{
    SetUnhandledExceptionFilter(TopLvFilter);
    InstallAPIHook_SetUnhandledExceptionFilter();
    atoi(nullptr);
    UnInstallAPIHook_SetUnhandledExceptionFilter();
}


API 훅을 해서 필터를 바꾸려 하면 아무 일도 하지 않는 NullSetUnhandledExceptionFilter 이 호출되도록 하여 막는 방법입니다...
멋있어 보이기는 하지만 이 코드는 64bit/32bit 를 따로 만들어야 하고, 심지어 윈도우 8 에서는 이 코드가 정상적으로 동작 하지 않습니다 (....) 아마도 강화된 보안때문에 그런게 아닌가 싶은데...

어쨋든 윈도우7 까지는 정상적으로 덤프가 남습니다.


그럼 이런 편법 말고 좀 정석적인 방법이 필요한데... 그건 다음글로...

TAG •
?

Lyn
조회 수 25781 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

두번째 방법으로는 CRT의 예외 핸들러에서 UnhandledExceptionFilter로 데이터를 넘겨서 생성하는 방법인데요...
이는 안정적이고 정석적이지만 치명적인 단점으로 CRT에서 던지는 예외가 하나가 아니라는겁니다... 


어쨋든 코드를 보면


#include <Windows.h>
#include <DbgHelp.h>
#include <cstdio>
#include <string>

using namespace std;

#pragma comment(lib, "dbghelp.lib")

LONG __stdcall TopLvFilter(PEXCEPTION_POINTERS pExceptionPointer)
{
	MINIDUMP_EXCEPTION_INFORMATION MinidumpExceptionInformation;
	std::wstring DumpFileName = L"dmpfile.dmp";

	MinidumpExceptionInformation.ThreadId = ::GetCurrentThreadId();
	MinidumpExceptionInformation.ExceptionPointers = pExceptionPointer;
	MinidumpExceptionInformation.ClientPointers = FALSE;

	if (DumpFileName.empty() == true)
	{
		::TerminateProcess(::GetCurrentProcess(), 0);
	}

	HANDLE hDumpFile = ::CreateFile(DumpFileName.c_str(),
		GENERIC_WRITE,
		FILE_SHARE_WRITE,
		nullptr,
		CREATE_ALWAYS,
		FILE_ATTRIBUTE_NORMAL, nullptr);

	MiniDumpWriteDump(GetCurrentProcess(),
		GetCurrentProcessId(),
		hDumpFile,
		MiniDumpNormal,
		&MinidumpExceptionInformation,
		nullptr,
		nullptr);

	::TerminateProcess(::GetCurrentProcess(), 0);

	return 0;
}
void InvalidParameterHandler(const wchar_t* expression, const wchar_t* function, const wchar_t* file, unsigned int line, uintptr_t pReserved)
{
	EXCEPTION_POINTERS ExceptionPointer;
	EXCEPTION_RECORD ExceptionRecord;
	_CONTEXT ContextRecord;

	ZeroMemory(&ContextRecord, sizeof(ContextRecord));
	RtlCaptureContext(&ContextRecord);

	ZeroMemory(&ExceptionRecord, sizeof(EXCEPTION_RECORD));
	ExceptionRecord.ExceptionCode = STATUS_INVALID_CRUNTIME_PARAMETER;	
	ExceptionRecord.ExceptionAddress = (PVOID)ContextRecord.Eip;
		
	ExceptionPointer.ExceptionRecord = &ExceptionRecord;
	ExceptionPointer.ContextRecord = &ContextRecord;

	TopLvFilter(&ExceptionPointer);
}
void main()
{
	SetUnhandledExceptionFilter(TopLvFilter);
	_set_invalid_parameter_handler(InvalidParameterHandler);
	atoi(nullptr);	 
}



구조는 간단합니다. RtlCaptureContext 를 이용해서 현재 쓰래드의 Context를 캡쳐 해 오고, 익셉션 코드와 현재 코드가 실행중인 위치를 넘겨 주면 되는데요..
x86 시스템에서 현재 실행중인 위치는 Eip 레지스터에 있기 때문에 캡쳐해온 Context에서 Eip를 
ExceptionAddress로 넘겨 주면 됩니다.


이 방식은 안정적이고 백신이 오진을 할 가능성도 없고 Windows 8 에서도 아무 문제 없이 작동 하지만 ... 위에서 말한것처럼 예외가 이거 하나가 아니라는게 문제가 됩니다.
예를들어 메모리 할당 예외는 _set_invalid_parameter_handler 로 처리 할 수 없습니다. 하지만 어차피 몇개 안되기도 하고 (...) 그냥 몇개 더 만들어주면 될 문제지요.


정말 골때려 지는건 3rd party 에서 SetUnhandledExceptionFilter 를 호출해서 자기껄로 만들어버리는 라이브러리가 있다는겁니다 =_=; 적은 내안에만 있는게 아닌거죠...그래서 첫번째 방법과 두번째 방법을 모두 적용해 두는게 좋다고 생각 합니다


TAG •
?

Lyn
조회 수 23800 추천 수 0 댓글 0
Atachment
첨부 '1'
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

전 직접 빌드해서 써서 별로 쓴일이 없긴 했는데..

문닫는거 보니 가슴이 좀 아프네요


boostpro.png

TAG •
?

Lyn
조회 수 208443 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
?

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄

주의 : 본 글은 거의 2년전 시점에 씌여진 글을 깜빡하고 안올리고 (...) 있던걸 꺼낸라 현재의 boost 최신버전하고는 상황이 다를 수 있습니다.


boost::interprocess::managed_shared_memory(이하 msm)에 관하여.

 

msm는 내부적으로 Red-Black Tree 를 이용하여 구현되어 있다

서로 다른 프로세스에서 공유 가능한 std::map<string, void*> 라고 보면 간단하게 이해된다.

공유메모리를 map의 형태로 기능확장한 것.

 

msm 는 생성시 mutex를 가지게 됨. Msm rb-tree를 구성하는 boost::rbtree_best_fit boost::interprocess::interprocess_mutex 를 상속받은 header_t 구조체를 소유하고 있음.

header_t 구조체는 추가적으로 msm의 헤더를 관리하기위한 멤버를 소유하고 있고, 이것들은 메모리 세그먼트를 관리할때 자동으로 scoped lock 이 걸림

 

msm 생성시 POXIS에서는 shm_open 를 이용하고윈도우에서는 CreateFile를 이용한다

 msm 생성 과정에서는 OS에 의해서 보호된다여기서 의문인 것은 왜 CreateFileMapping 을 이용한 Windows OS의 공유메모리 메커니즘을 사용 하지 않았는가 이다.

물론 FILE_ATTRIBUTE_TEMPORARY 플래그를 주어 파일을 메모리에 생성 하긴 했지만 그다지 효율적으로 보이지는 않는다궂이 예측 하자면 CreateFileMapping이 생성시의 이름을 어떻게 주느냐에 따라  세션관련 제어 기능을 가지게 되는데 그것을 의도적으로 피하고자 함이 아닌가 싶다

boost의 기본 설계 방침은 “플랫폼 특화” 된 기능을 막아서라도 같은 인터페이스를 제공 하는 것이라고 하니까아니면 그냥 단순히 POSIX랑 똑같이 하고 싶어서 일수도 있고.

 

msm는 윈도우에서는 추가적인 과정이 있는데만약 공유위반으로 인해 생성이 실패 할 경우 250ms 간격으로 최대 3번까지 재시도 하게 된다

이는 MSDN 에 명시된 동작으로 실제 사용 하지 않더라도 OS의 백그라운드 조각모음 때문에 일시적으로 파일이 잠길 수 있다고 하고 있다또한 FILE_SHARE_READ, FILE_SHARE_WRITE, FILE_SHARE_DELETE 권한이 있다 하더라도 파일 생성 중에는 lock이 걸려 공유위반이 발생 할 수 있다단 이것은 임시파일이 아닐 경우인데실제 테스트 결과 임시파일에서는 아무리 빠르게 반복해도 관련 현상을 재현할 수 없었다.

 

어쨋든 Windows, POSIX 양쪽 다 OS 차원에서 “파일 생성” 이라는 부분은 완벽히 동기화 시켜주기 때문에 절대로 “같은 이름을 가진 msm 객체가 생성 될 수 없다” 또한 open_or_create를 사용 하여 생성 할 경우 반드시 성공한다는 것을 보장 하게 된다.

 

msm 의 읽기,쓰기 동작(find, construct )도 일부러 nolock 버전의 함수를 호출하지 않는 이상 thread safe 하다 find → add 의 동작을 반복 할 필요가 없다.

 

construct 는 이미 존재하는 Key 대해 요청 할 경우 exception 을 발생 시킨다.

이것의 예외 처리는 매우 중요한데만약 한쪽에서 construct 가 중복 실행되어 exception 이 발생 될 경우 예외처리를 제대로 하지 않으면 msm 내부의 lock이 풀리지 않아 무한히 대기 하게 된다. Windows , POSIX 양쪽 다 프로세스가 Crash 되어 종료된 상황에서도 lock 이 해제되지 않는것이 확인되었다이런 경우를 방지하기 위해 find_or_construct 를 제공 하므로 이쪽을 사용 하는 것이 바람직하다.

 

위의 내용에 덧붙이면 사실 윈도우에서 제공하는 모든 동기화 객체는 lock의 재진입을 지원하고 프로세스 레벨의 레퍼런스 카운팅을 제공하여 프로세스가 죽으면 그 프로세스가 획득한 모든 Lock이 해제되도록 되어있다문제는 boost의 구현방법에 있는데 posix 에서는 pthread mutex를 사용하는것이 기본인 반면 Windows 시스템에서는boost가 자체 구현한 spin_mutex를 사용하는것이 default로 되어 있다그런데 이녀석은 커널 레벨에서 시스템 전체를 관리하는게 아니라 프로세스 레벨에서 atomic operation을 이용해 임의로 구현한 기능이므로프로세스가 Exception에 의해 Crash 되었을 경우의 뒷처리를 전혀 할 수 없다 Windows 시스템의 안정적인 관리 기능을 사용하려면 boost::interprocess::windows_mutex를 명시적으로 선언해야 한다이는 공유메모리도 마찬가지로기본적으로는 위에 적은것 처럼 CreateFile 을 사용 하고 있지만 boost::interprocess::windows_shared_memory 를 명시적으로 사용하면 CreateFileMapping를 이용하는 공유메모리가 생성되며 Windows에서 제공하는 기능 전체를 사용할 수 있다.

 

TAG •
?

Board Pagination Prev 1 ... 2 3 4 5 6 7 ... 8 Next
/ 8