Lyn
조회 수 5754 추천 수 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
조회 수 10718 추천 수 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
조회 수 23102 추천 수 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
조회 수 25860 추천 수 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
조회 수 57908 추천 수 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
조회 수 33024 추천 수 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
조회 수 25803 추천 수 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
조회 수 23830 추천 수 0 댓글 0
Atachment
첨부 '1'
?

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

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

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


boostpro.png

TAG •
?

Lyn
조회 수 208495 추천 수 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 •
?

Lyn
조회 수 22200 추천 수 0 댓글 0
Atachment
첨부 '5'
?

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

이 코드는 Visual Studio 2012 Update3에서 테스트 되었습니다.


boost 1.46 부터 추가된 icl 컨테이너들은 범위를 가지는 데이터들을 넣을 수 있게 되어 있는 컨테이너다


이것들은 주로 일정 등의 데이터를 관리하기에 아주 좋게 되어 있고(boost 예제도 대부분 그런쪽입니다) 매우 확장성이 좋게 설계 되어 있어 다양한 용도로 활용 가능하지만 개인적으론 map의 기본형인 boost::icl::intervap_map<T1, T2> 의 형태가 매우 비상식적이라고 생각한다.


그래서 interval_map 을 원하는 형태로 만들어서 쓰고 싶었고 그 과정에서 알게된 것을 정리 해 본다.

내가 최종적으로 원하는 형태는 프로그램이 처음 시작할때 로딩되는 범위를 가지는 데이터를 관리 하고, 중복되는 경우가 있을경우 데이터 오류로 취급하여 예외를 발생 하는 형태입니다.


하나씩 알아보자면 interval_map 의 기본 개념은 기존의 std::map 과 같지만, 몇가지 추가적인 개념이 존재한다.

1. 구간.

구간이란 0~1, 2~3, 12:00~13:00 처럼 범위를 가지는 데이터. 수학시간에 배웠던것처럼 개구간, 폐구간, 반폐구간(좌/우) 가 존재합니다.
뭐 이건 문제될 것 없는 당연한 경우라고 보입니다.


2. Combine

입력한 구간이 서로 겹칠 경우 그 구간에 대해 Combine 동작을 시행합니다.
이것에 대해선 아래에서 마저 합니다.


3. 기본값

웃기게도 왠지 모르겠지만 (...) 기본값에 대한 처리를 변경할 수 있습니다.

여기에서 기본값이란 static T; 로 선언 했을때의 초기값입니다. int라면 0, float 라면 0.0f, std::string 이라면 길이0인 문자열인 식입니다.


1번 구간에 대해서는 별로 문제가 될 경우가 없을겁니다. 상식적으로 사용 할 수 있지요.
계속 울궈먹을 기본 코드 하나 넣겠습니다


#include <boost/icl/interval_map.hpp>
#include <string>
#include <utility>
#include <cstdio>

void wmain()
{
	using namespace std;
	using namespace boost;
	using namespace boost::icl;

	interval_map<int, wstring> ivm;

	ivm.add(make_pair(interval<int>::right_open(0, 2000), L"Right"));
	ivm.add(make_pair(interval<int>::left_open(2000, 3000), L"Left"));
	ivm.add(make_pair(interval<int>::closed(3000, 4000), L"closed"));
	ivm.add(make_pair(interval<int>::open(4000, 5000), L"Open"));

	auto it = ivm.find(1000);
	if(it != ivm.end())
	{
		wprintf(L"Find %s\n", it->second.c_str());
	}
	else
	{
		wprintf(L"Not Found");
	}
}


기본적인 사용 방법은 위와 같습니다. 구간을 지정해서 데이터를 넣고 find로 찾아오는형식으로 map과 완전히 동일합니다.

결과도 별다를게 없구요


1.png


위 코드를 자세히 보시면 3000 이라는 값은 left, closed 두개의 데이터가 겹치는 구간이라는 것을 알 수 있습니다.
이때 3000을 찾아서 출력해 보면 어떤 결과가 일어 나냐면....


2.png


이런 상황이 벌어집니다 (...) 
왜냐면 interval_map은 구간이 겹칠 경우 Combine 작업을 진행 하는데 이 단순히 interval_map<T1,T2> 로 선언한 Combine의  동작이 + 연산입니다.

즉 겹치는 구간의 데이터를 몽땅 더해서 출력해 버립니다. 숫자라면 값이 더해질것이고 문자열이라면 위처럼 문자열일 경우 두 문자열이 붙어서 나타납니다.

이 Combine 연산을 미리 몇가지 제공 하고 있는데, 이렇게 더한다던지, stl 컨테이너에 insert 를 한다던지 최대값/최소값으로 교체한던지 하는 기본적으로 많이 쓸만한 연산을 제공 하고 있습니다....만 내가 필요한 문제있을시 예외던지는 Combine은 제공 하지 않습니다.


두번째로 기본값 문제입니다. 위 코드를 수정해서 아래처럼 바꾼 후 실행해보겠습니다.


3.png



[0~2000) 구간에 빈 문자열을 넣었지만 찾을수 없다고 하고 있습니다.

왜냐면 그 Type의 기본값이 들어갈 경우 데이터를 넣지 않는것이 interval_map 기본형의 동작입니다


하지만 이 상황에서 내가 원한건 데이터 없음과, 빈 문자열을 데이터로 가지는것을 확실하게 구별 해야 하는겁니다.

값이 빈값인건 빈값이고,  없는건 없다고 할수 있어야되는 상황이더 많다고 생각되는데.... 왜 이런지는 모르겠습니다.


이 동작을 바꾸는 기능을 icl 은 제공 하고 있는데 두가지 옵션을 하나의 구조체로 만들어 총 4종류의 형태를 제공합니다.
partial_absorber, partial_enricher, total_absorber, total_enricher 의 4가지입니다.

여기서 뒤에 붙은 absorber, enricher 이 기본값을 어떻게 처리할지 결정합니다.
absorber는 날려버리고(초기형태) enricher 는 보존합니다. partial_enricher 로 바꾼 뒤 다시 한번 실행해 보겠습니다.


4.png


보다시피 찾아오는것에 성공하는 것을 볼 수 있습니다.

다음으로 앞에 붙은 partial, total 은.... 당췌 이게 어떻게 돌아가는지 모르겠습니다 =_=;;;;; 뭘로 하던 내가 원하는 동작에 지장이 없었기에 넘어갔습니다.
차후 추가적인 확인이 필요할듯 합니다. 아마 사용자 정의 type 에서만 영향을 미치는지도 모르겠습니다. 기본형은 이미 다 되어있고 ...


그리고 이제 combine 을 방지해야 하는데... combine functor 를 새로 만듬으로서 가능했습니다. 
겸사겸사 실수로 substract 를 호출하는것을 방지하기 위해 inverse functor 도 만들었습니다. 어차피 오류낼거니 궂이 따로 만들 필요는 없어서 그냥 같이 쓰도록 되었네요.


5.png


그 결과가 이 코드입니다. 중간에 less는 std::less 입니다. 비교 functor 가 템플릿에서 앞에 있는 바람에 저렇게 들어가버렷네요.

어쨋든 멋지게 assert 를 내 주네요. 원하는 동작이 만들어 졋습니다. 구간별 데이터를 안전하게 저장 할때 사용할수 있겠습니다.
궂이 사용 예를 추가해 보자면 ip 별 지역 정보를 넣어놓고 빠르게 검색할때 사용할 수 있겠네요.

TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

boost  shared_ptr 은 편한 놈이지만..

문제가 생기는 상황이 몇 가지 있다 있다그 중 하나 바로 객체 내부에서 전역 함수(혹은 다른 class 의 함수)를 호출 할 때 this 를 넘기는 문제인데

 

왜나면 아래와 같은 코드가 안되기 때문이다.

 

shared_ptr과 포인터형은 서로 대입이 되지 않기 때문에 위와 같은 코드는 컴파일 에러를 뱉는다그럼 아래와 같이 고치면 어떨까.

 

 

this 를 shared_ptr<SPtrTestthisptr(this);

로 변환 해서 넘겻다.

 

이렇게 하면.

SPtrTest::Operation이 끝날때와 Func 가 끝날 때 2 destructor 가 호출 되게 되어 에러가 난다.

이걸 방지하는 방법은 자기 자신의 shared_ptr 을 레퍼런스 카운트 문제가 생기지 않도록(this 를 넘길 때도 레퍼런스 카운터가 증가 하는하는 것이다.

 

즉 boost::enable_shared_from_this<T> 를 상속 받은 class 를 만드는 방법이다.

boost::enable_shared_from_this<T> 를 상속 받은 뒤 shared_from_this() 를 호출 하면 자기 자신의 shared_ptr 을 리턴 해 준다.

 

그럼 아래와 같이 된다

#include <boost/shared_ptr.hpp>

#include <cstdio>

 

using namespace boost;

 

class SPtrTest;

 

void Func(shared_ptr<SPtrTestsp);

 

class SPtrTest

{

public:

        int var1;

        SPtrTest()

        {

               printf("Constructor\n");

        }

        ~SPtrTest()

        {

               printf("Destructor\n");

        }

        void operation()

        {

              

               Func(this);

        }

};

 

void Func(shared_ptr<SPtrTestsp)

{

        sp->var1++;

        printf("%d\n"sp->var1);

};

 

int _tmain(int argc_TCHARargv[])

{

 

        shared_ptr<SPtrTesttestclass(new SPtrTest);

        testclass->var1 = 0;

        testclass->operation();

              

        return 0;

}

 

이렇게 하면 아무 문제 없이 작동이 가능하다.

 

 

 

Ps. 특히 조심해야 할 것은..

shared_ptr<SPtrTestthisptr(this); 를 여러 번 생성 한다고 레퍼런스 카운터가 증가하는 것은 아니다레퍼런스 카운터의 증가는 변수끼리의 대입에 의해서만 증가할 뿐저런 선언은 카운터1짜리 변수를 여러 개 늘려 에러를 내게 할 뿐이다.

#include <boost/shared_ptr.hpp>

#include <cstdio>

 

using namespace boost;

 

class SPtrTest;

 

void Func(shared_ptr<SPtrTestsp);

 

class SPtrTest

{

public:

        int var1;

        SPtrTest()

        {

               printf("Constructor\n");

        }

        ~SPtrTest()

        {

               printf("Destructor\n");

        }

        void operation()

        {

               shared_ptr<SPtrTestthisptr(this);

               Func(thisptr);

        }

};

 

void Func(shared_ptr<SPtrTestsp)

{

        sp->var1++;

        printf("%d\n"sp->var1);

};

 

int _tmain(int argc_TCHARargv[])

{

 

        shared_ptr<SPtrTesttestclass(new SPtrTest);

        testclass->var1 = 0;

        testclass->operation();

              

        return 0;

}




#include <boost/shared_ptr.hpp>

#include <boost/weak_ptr.hpp>

#include <boost/smart_ptr/enable_shared_from_this.hpp>

#include <cstdio>

 

using namespace boost;

 

class SPtrTest;

 

void Func(shared_ptr<SPtrTestsp);

 

class SPtrTest : public boost::enable_shared_from_this<SPtrTest>

{

public:

        int var1;

        SPtrTest()

        {

               printf("Constructor\n");

        }

        ~SPtrTest()

        {

               printf("Destructor\n");

        }

        void operation()

        {

               Func(shared_from_this());

        }

};

 

void Func(shared_ptr<SPtrTestsp)

{

        sp->var1++;

        printf("%d\n"sp->var1);

};

 

int _tmain(int argc_TCHARargv[])

{

 

        shared_ptr<SPtrTesttestclass(new SPtrTest);

        testclass->var1 = 0;

        testclass->operation();

              

        return 0;

}

?

2012.01.14 00:40

Boost 빌드 방법

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
1. Gem 만들기
bootstrap 실행 -> b2 실행파일이 생성

1.48.0에선 bjam -> b2 로 바뀌었다. 근데 bjam 도 그대로 된다 (...) 같은걸 2개 만들어줌

2. b2 빌드옵션
toolset=<>            ▷ 컴파일러 설정
--buildtype=<>      ▷ 빌드방법 설정
--libdir=<>            ▷ output 폴더 설정
--architecture=<>   ▷ target platform 설정
address-model=<>  ▷ bit수 설정
install                    ▷ 빌드방법 설정
define=<>              ▷ define 상수 설정
-j<>                      ▷ 병렬컴파일할 코어갯수 설정

절대로 = 앞뒤에 공백 넣지 말것. 반드시 원하는 컴파일러/bit수의 Command Prompt  에서 실행할것

3. 예제
vc++ 2010으로 모든형태의 라이브러리(debug dll, debug static, release dll, release static)를 CRT 버전을 최신으로 하여 특정 Path에  쿼드코어로 빌드 할경우

AMD64(EM64T)는 x86 아키텍쳐에 address 를 64bit로 지정해야한다. x64, AMD64, EM64T 등의 키워드는 불가능

  1. 32bit build

    b2 -j4 toolset=msvc-10.0 --build-type=complete define=_BIND_TO_CURRENT_VCLIBS_VERSION  --libdir=c:\library\boost\lib\i386 install

  2. 64bit build
    b2 -j4 toolset=msvc-10.0 --build-type=complete  define=_BIND_TO_CURRENT_VCLIBS_VERSION --libdir=c:\library\boost\lib\amd64 architecture=x86 address-model=64 install
?
  • profile
    Lyn 2012.01.14 00:41

    실수로 글을 지워서 다시썻다 씁 ㅡㅡ;


?

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

여러가지 jar을 가져다 쓰다 보면 안에 있는 License 관련 파일이 겹쳐서 충돌 나는 경우가 있다.

이 경우 Gradle 스크립트의 android 섹션에 


packagingOptions {

        exclude 'META-INF/DEPENDENCIES.txt'

        exclude 'META-INF/LICENSE.txt'

        exclude 'META-INF/NOTICE.txt'

        exclude 'META-INF/NOTICE'

        exclude 'META-INF/LICENSE'

        exclude 'META-INF/DEPENDENCIES'

        exclude 'META-INF/notice.txt'

        exclude 'META-INF/license.txt'

        exclude 'META-INF/dependencies.txt'

        exclude 'META-INF/LGPL2.1'

    }


를 추가해서 패키지에서 빼 주면 해결이 가능하다

TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

오오 멋지다...

안드로이드 허니콤 이후로는 블록킹 되는 네트워크 함수를 UI Thread에서 호출하면 android.os.NetworkOnMainThreadException 가 발생한다.

병신같은 코드를 양산하는 개발자들을 막기위해 플랫폼 차원에서 강제한것.



테스트 코드를 만들 때 조차 완전한 형태의 코드를 만들어야 해서 귀찮지만, 평균적인 App의 퀄리티를 올리기 위한 아주 좋은 선택이었다고 생각한다.
MS도 이런걸 해 줫으면 좋았을텐데.
TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

install package nautilus-admin 

 

ex > sudo apt-get install nautilus-admin

 

nau.png

 

it's good

TAG •
?

Atachment
첨부 '1'
?

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

11월 6일 현재 해결되었습니다. VMWare 업데이트 하세요

관련링크 : http://lunapiece.net/Article/14007397



uhul.png


어제 업데이트 된 2014년 10월 정기 업데이트(한국시각 10월 15일) 이후 VMWare 에서 메모리 오류가 발생합니다.

이는 KB2995388 와 관련된 오류로서, 이를 업데이트 하지 않음으로서 일시적으로 방지할 수 있습니다.

(이미 업데이트 했다면 저것만 골라서 언인스톨해도 OK입니다)


아마 VMWare 측에서 새로운 업데이트가 나오지 않을까 싶네요



?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

얼마전 .net 4.7이 출시되어 시간난김에 구경하는데

 

DirectX Dependency

The .NET Framework 4.7 now uses DirectX 11 components for WPF. These components are available as part of the operating system in recent versions of Windows including Windows 10, Windows Server 2016, Windows 8.1, and Windows Server 2012 R2.

 

같은 내용이 있네요

 

DX11은 Windows 7 에서도 지원 하는데, 7 지원을 빼버린거 보니 슬슬 끝물인가봅니다

TAG •
?

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