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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

다운로드 링크 : http://www.microsoft.com/ko-kr/download/confirmation.aspx?id=41650


변경사항은 주로 하위버전 IE(IE10, IE9) 와의 충돌 문제 해결이 많은거같네요.

?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

http://windows.microsoft.com/ko-kr/windows/preview-download?ocid=tp_site_downloadpage


아쉽게도 한국어는 없군요. 설치 후기는 차후 올려보겠습니다.
아직 자료 정리중이라

?

?

단축키

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
조회 수 5914 추천 수 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
조회 수 5793 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

업데이트 하다가 설정 꼬여서 오밤중에 쇼를 했구나 (...)


왜이리 웹서버 설정이 어려운거야...





근데 하고 나니 뭔가 좀 빨라진 느낌이 든...다?

?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

우분투 14.04 에서 apt-get 으로 libssh2-php만 나중에 따로 설치시 php5-mysql 모듈이 날라가버리는 버그가 있다 (....)

어이없지만 조심해야할부분.


다시설치하면 되긴한다

TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

After Update VS2015 Update 2, nuget has problem.

 

fix that

 

0. Visualstudio 2015 Run As Administrator(Importent!)

1. Open TOOLS -> Options -> Nuget Package Manager -> Package Source

 

01.PNG

 

2. Click Plus Button

 

3. Change Name to any name, and Source to https://api.nuget.org/v3/index.json

02.png

and Click Update

03.PNG

 

4. Retry use nuget package

 

5. Profit!

 

TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

예전 x86 시절에는 다양한 calling convention 이 있었습니다.

MS가 OS API 의 디폴트로 사용한 pascal 식 호출방식(__stdcall) 막상 언어로 파스칼을 쓰는 델파이가 파스칼식을 사용 하지 않고 사용하고 있던 fastcall, 그리고 c에서 사용하는 cdecl

 

이 각각의 호출 방식은 각각 장단점이 있었는데, pascal 식은 바이너리의 크기가 작아진다, fastcall 은 인자 전달에 레지스터를 사용 하므로 속도에 유리하다, cdecl 은 최적화 단계에서 스택 push ,pop 을 생략할 수 있으므로, 최적화에 유리하고 가변인지를 지원 할 수 있다는 장점이 있었습니다.

 

그러나 바야흐로 x64 시대, 컴파일러를 설계하는 사람들은 각각의 장점을 통합한 새로운 호출 방식을 만들게 되었습니다. 그 이후 calling convention 을 지정하는 모든 키워드는 x64 컴파일시에 무시되며, 그런거 신경 안써도 되는 평화로운 세월이 이어져 왔습니다.

 

그러나 시간이 흘러 CPU는 클럭경쟁의 시대가 막이 내리고, SMID 와 멀티코어의 시대로 넘어 왔는데... 당연히 CPU 제조사들은 새 SIMD 명령어를 추가 하기 시작 했고, 그에 맞춰 새 명령어용 레지스터가 추가 되었습니다. 그 시점에서 컴파일러 개발자들은 이렇게 생각 햇나 봅니다 "어? 레지스터가 놀고있네?" 라고. 그리하여 VS2013 이후부터는 __vectorcall 이라는 키워드가 추가되어, 더이상 x64 바이너리에서도 calling convention 을 무시 할 수 없게 되었습니다.

 

간단한 예제를 보겠습니다.

 

#include <cstdio>
#include <intrin.h>

__m256i func(double d1, double d2, double d3, double d4, __m256i f)
{
    printf("%f %f %f %f\n", d1, d2, d3, d4);

    printf("%lld %lld %lld %lld\n", 
        f.m256i_u64[0], f.m256i_u64[1], f.m256i_u64[2], f.m256i_u64[3]);

    return f;
}

int __cdecl main()
{
    __m256i f;

    for (int i = 0; i < 4; ++i)
    {
        f.m256i_u64[i] = i;
    }
    
    f = func(0.1, 0.2, 0.3, 0.4, f);

    return 0;
}

 

이코드를 빌드해서 실행 해 보면 다음과 같은 코드를 볼 수 있습니다.

vc1.PNG

 

 

그리고 함수의 프로토타입에 __vectorcall 을 추가하여

__m256i __vectorcall func(double d1, double d2, double d3, double d4, __m256i f)

와 같이 만든 후 다시 빌드 해 보겠습니다

 

 

 

vc2.PNG

 

차이가 보이시나요? 첫 줄에서 ymm4 라는 avx 레지스터가 추가적으로 함수 전달에 쓰이는 것을 볼 수 있습니다.
매번 __vectorcall 을 붙이기 싫다면 

vc3.PNG

 

옵션에서 조정 하거나, /Gv 플래그를 추가하여 사용 할 수도 있습니다.
단 /Gv 플래그를 켤 경우, main 은 항상 __cdecl 이어야 한다는 조건이 있으므로, 위 코드처럼 __cdecl 을 붙여주지 않으면 경고가 발생 할 것이니 조심하세요.

TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

지인이 물어 온 김에 정리 해 둡니다.

 

결론부터 말하면 C++ 의 Lambda 의 Calling Convention 은 상황에 맞춰 "그때그때 다르다" 입니다.
 

기본적으로 cdecl(물론 VC++ 프로젝트 설정에서 옵션을 바꾸면 다른 것도 가능합니다) 멤버여야 한다면 thiscall 그렇지 않으면 대입 되는 함수 포인터의 type 에 따라서 결정됩니다.
즉 원하는 형태로 대입만 하면 거기에 맞춰 적절히 컴파일 됩니다.

 

lambda.png

 

외부에 callback 함수를 넘길 때 stdcall 로 선언해야 하는 경우가 꽤 되는데(특히 윈도우 API들) 이 때도 부담없이 Lambda 를 사용 할 수 있습니다.

 

단 아쉽게도 auto 와의 조합은 제공하지 않는데, 

 

auto __stdcall f1 = [](int num1, int num2, int num3) { printf("%d %d %d\n", num1, num2, num3); };

 

와 같은 문법은 경고를 내며 __stdcall 이 무시됩니다... 

TAG •
?

2015.04.20 22:38

Resharper C++ 사용기 - 1

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

코드의 네이밍 스타일을 지정하는 옵션입니다.
 

1.png2.png

 

더블클릭하면 스타일을 지정 할 수 있게 되어있습니다.
기본은 C++표준에서 자주 쓰이는 전부소문자 형태이네요. 전 Windows API 에서 주로 쓰는 Pascal 스타일을 주로 쓰니 본격적으로 쓰기 시작하면 바꿔놔야 할 것 같습니다

 

 

아래는 특정 코드 패턴에 대해 색으로 표시를 해 주는 기능입니다(보통 정적분석이라고들 부르죠)
목록을 보면 boost를 사실상 표준 라이브러리 취급을 해줘 버리는 느낌이네요. boost 라이브러리 관련 기능도 들어 있습니다.
사실 저도 굉장히 많이 씁니다. 특히 boost::format 같은건. stringstream 은 정말 극혐이라서요.


어쨋든 잘못된 패턴의 코드에 눈에 띄게 색을 입혀준다는것은 코딩 실수를 방지하기 위해 아주 좋은 방법이지요. 몇가지만 테스트 해 보겠습니다.

5.png

 

아래처럼 구형 C스타일의 캐스팅을 사용하면 녹색으로 밑줄이 그어지면서 전구 모양의 아이콘이 생깁니다.
어떤 문제로 전구가 떳는지 알려며, 아래같은 경우는 Use static_cast 를 클릭하면 자동적으로 C++ 스타일의 캐스팅 연산자를 쓰도록 변환됩니다

6.png

 

 

아래처럼 printf(위 메뉴목록을 보시면  알겠지만 boost::format 도 지원 합니다) 의 파라메터가 잘못된것은 빨간줄로 나타납니다.
이 줄 색은 등급을 어떤것으로 해 놓았냐의 문제인데, 기본 옵션에서 format string이 잘못된 것은 error 취급하게 되어 있으므로 빨간줄입니다.11.png

 

잘못된 format string에 커서를 갖다 대면 빨간 전구 아이콘이 뜨고, 클릭하면 %s를 %d로 자동으로 변환 해 줍니다.

12.png

 

의외로 모르는 사람이 많은 부분인데 64bit 정수의 경우 %d로 출력할 수 없고 %lld 를 사용해야 합니다.(gcc의 경우 %I64d를 사용합니다)
이 부분에 대해서도 정확히 처리를 해 주고 있습니다.

20.png

 

한가지 아쉬운것은 error로 세팅을 하더라도 빌드 자체는 문제 없이 진행됩니다.
오류 메세지를 띄워서 빌드를 막아줫으면 좀더 좋지 않았을까 하는 아쉬움이 있습니다

13.png

 

하지만 처음부터 하는게 아니라 프로젝트 중간에 툴을 도입하여 코드를 정리하려고 하면 눈으로 일일히 찾으려면 고생좀 해야 할텐데요...

Next Issue in File 을 클릭하면 이슈를 하나 하나 추적해서 고쳐나갈 수 있습니다.

14.png

아래는 코드를 ReFormatting 할때 사용할 옵션들입니다.
거의 모든 경우의 옵션을 다 지원 합니다... 만 이미 VS2013의 Format 옵션도 충분히 다양해져서 그리 큰 의미가 있어 보이진 않습니다.
 

코드가 어떻게 바뀌는지 미리보기 하는 기능도 VS 자체에서 이미 제공되는 기능입니다.

 

3.png

 

그나마 장점이라면 VS에 내장된 옵션의 불성실한(....) 미리보기 화면과 달리 유저가 실제로 보게 되는것과 같은 코드 색을 입혀준 정도의 장점이 있겠습니다.
옵션도 아주 쬐금 더 다양하구요. 유명한 프리셋을 몇 종류 제공한다는것도 일단 장점이라면 장점입니다(애초에 편의성때문에 사용하는 툴이니까)

21.png

 

Source Reformat 은 영역 선택으로도 가능하고, 파일 전체 역시 가능합니다.
이 역시 원래 VS 내장 기능으로도 제공되던 부분입니다.

10.png

뭐 별로 눈에 띄지 않는 헤더 자동완성입니다.

8.png

 

만약 헤더를 못찾을 경우 붉은 밑줄을 그어 주며, 자신이 어디에서 include를 시도했는지 알려줍니다.

7.png

 

이거 굉장히 맘에 들었던 기능인데... 사용 하지 않는 헤더를 어둡게 처리 해 줍니다.
다른 언어에선 많이들 지원되는 기능인데(주로 VM 언어들에서...) C++ 에서는 쓰는지 안쓰는지 잘 몰라서 그냥 냅둔 경우가 많았습니다.
안그래도 다른 언어에 비해 거지같이 컴파일 느린 C++인데 쓸데없는 헤더를 제거하는것으로 조금이나마 컴파일 속도를 올릴 수 있다면 그것만으로도 유용하겟죠 

9.png

 

제가 굉장히 많이 쓰는 기능중 하나인, 헤더 선언하고 구현부 자동생성하는 기능입니다.

15.png

 

이부분이 Visual Assist 대비 장점이 있는데, VA 는 여러번 클릭하면 컴파일이 되던말던 중복생성 (....) 해 주는 무식한 짓을 하는데 비해, Resharper 의 경우 즉시 아이콘이 navigate 로 바뀝니다.

16.png

 

흔히 사용하는 Extract Method 기능입니다.
뭐 대부분의 툴과 비슷해서 별로 설명할게 없습니다.

17.png

 

Refactoring 기능은 좀 많이 아쉽습니다.
코드가 어떻게 바뀌는지 전혀 미리 보여주지 않습니다. 실수하기전에 체크할수 없고 바뀐 뒤에 한번 더 코드를 눈으로 확인해야합니다.

18.png

 

 

아래 기능은 코드 자동생성 기능인데... 뜬금없이 닷넷용 소스 생성 기능이 들어 있습니다.
문제는 이 글을 쓰기 위해 새로 세팅한 VM위에 달랑 VS2013과 Resharper C++만 설치해 놓은 상태인데도 이게 뜹니다 (....) 절대로 닷넷용 Resharper 가 설치되어 있는 상황이 아닙니다. 심지어 C++/CLI 는 없고 vb.net 과 C#만 있습니다;

4.png

 

 

 

PS. Resharper 는 생각하는 중입니다 (....)

19.png

 

PS2. 가격은 Visual Assist 279달러 Resharper C++ 229달러로 50달러 쌉니다.
가격을 생각하면 선택 해 볼만한 툴중 하나입니다.

 

PS3. 전체적으로 Visual Assist 는 결과가 좀 이상하더라도 일단 빨리 보여주는 쪽으로 개발이 되어있는-0-;; 느낌이 강하게 나는데(코드 분석하는 동안엔 정말 말도 안되는 결과도 가끔 보여주죠....) 이쪽은 확실히 정확한 결과를 보여줍니다. 단지 분석이 좀 느리네요

 

PS4. 사실 치명적인문제는... 베타시절보단 많이 빨라 졋지만 그래도 느립니다.
제가 예전에 작업하던 중대형 프로젝트(프로젝트 크기가 약 25만라인)를 열어 봤는데... 이건 머 코딩이 불가능할 정도입니다. 정말 심각하게 느려요.
사실 전 툴이 느리다고 불평하는 사람한텐 똥컴쓰지 말고 장비좀 좋은거 쓰라고 하는데(특히 맥북에어 쓰면서 느리다고 징징대는놈들한테....) 이건 뭐 답이 안나옵니다.

이클립스랑 IntelliJ 느린건 뭐 애교로 보이는 수준으로 툴이 느려집니다.
컴퓨터를 업그레이드 하려고 해도 제가 저 프로젝틀을 열어봣던 장비가 Intel i7 4770K이 달려있어서.. 더이상 딱히 올릴 방법도 없는 상태구요

 

가장 골때리는건 Visaul Assist 처럼 Enable/Disable 전환이 그리 쉽지 않아서 필요할때만 켜는것도 좀 애매하단 겁니다... 차기 버전에서 속도 개선이 필수적으로 이루어 져야 겠네요. 뭐 중규모 정도의 프로젝트라면 별 문제 없어 보입니다만...

 

일단 어차피 생겼으니 더 써보면서 두번째 글 올려보겠습니다.

TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

ov.PNG

 

네 3번째는 OpenVPN GUI Client 입니다.

High DPI 지원을 하지 않아, 강제확장 기능이 없는 구버전의 OS에서는 읽을 수 없는 크기의 로그를 (....) Windows 10 에서는 흐릿하게 보이는 로그를 자랑 하고 있습니다.

 

역시 얘도 그다지 자주 볼 화면이 아니니 상관은 없지만 무신경한건 마찬가지죠

TAG •
?

2016.06.21 06:28

Visual C++ C4503 Warning Fix

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

크게 작게 위로 아래로 댓글로 가기 인쇄
#include <map>
 
using namespace std;
 
struct VeryLongClassNameType1
{
 
};
struct VeryLongClassNameType2
{
 
};
struct VeryLongClassNameType3
{
 
};
struct VeryLongClassNameType4
{
 
};
struct VeryLongClassNameType5
{
 
};
typedef map<VeryLongClassNameType1VeryLongClassNameType2LongNameStdMap;
typedef map<VeryLongClassNameType3LongNameStdMapLongNameStdMap2;
typedef map<VeryLongClassNameType4LongNameStdMap2LongNameStdMap3;
typedef map<VeryLongClassNameType5LongNameStdMap3LongNameStdMap4;
 
int main()
{	
	LongNameStdMap4 a;
}

 

위와 같은 코드를 빌드 하면 컴파일과 실행엔 문제가 없지만 C4503 Waring 이 뜹니다.

이 Warning 은 http://msdn.microsoft.com/query/dev14.query?appId=Dev14IDEF1&l=EN-US&k=k(C4503)&rd=true 에서 보다 시피, type명이 너무 길어서 짤릴 수 있다는 경고인데, 이 경우 나중에 크래시 덤프 등을 얻어서 처리할때 type 이 매칭 되지 않을 우려가 있습니다. 사실 4098 라는 type 길이는 충분했... 어야 했는데 template 가 겹치고 겹치면서(주로 Map을 겹쳐서 tree 형태의 자료구조를 구성 할 경우겠지만 ....) 의도하지 않게 긴 type 명을 가지게 되어 버리는 경우가 있습니다.

 

이 경우 위의 MSDN 링크 에서는 아래와 같은 방식의 다른 클래스로 한번 Wrapping 하는 해결책을 제시 하고 있습니다.

typedef map<VeryLongClassNameType1VeryLongClassNameType2LongNameStdMap;
typedef map<VeryLongClassNameType3LongNameStdMap_LongNameStdMap2;
struct LongNameStdMap2
{
	_LongNameStdMap2 Element;
};
typedef map<VeryLongClassNameType4LongNameStdMap2LongNameStdMap3;
typedef map<VeryLongClassNameType5LongNameStdMap3LongNameStdMap4;
struct NewClass
{
	LongNameStdMap4 Element;
};

이 경우 map 에 대한 접근이 a.Element.find() 처럼 한단계가 더 들어가게 됩니다... 만약 이름이 그 이상으로 길어서 2~3번 더 중간에 이름을 끊어 줘야 하는 경우, a.Element.Element.find() 와 같은 상황이 발생합니다. warning 을 제거하기 위해 의도와 다른 불편한 사용 방법을 강요받게 되는거지요. 이건 좋은 방법이라고 할 수 없습니다.

 

이럴때는 

typedef map<VeryLongClassNameType1VeryLongClassNameType2LongNameStdMap;
typedef map<VeryLongClassNameType3LongNameStdMap_LongNameStdMap2;
class LongNameStdMap2 : _LongNameStdMap2
{
 
};
typedef map<VeryLongClassNameType4LongNameStdMap2LongNameStdMap3;
typedef map<VeryLongClassNameType5LongNameStdMap3LongNameStdMap4;
class NewClass : LongNameStdMap4
{
 
};

 

처럼 public 상속을 해버리면 간단합니다... 그럼 일반적으로 map을 쓰는것과 전혀 다르지 않는 방법으로 코딩하면서 워닝만을 제거 할 수 있습니다.

TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

NF.PNG

 

두 번째는 네이버에서 배포하는 네이버 폰트 인스톨러입니다.

Uncode 지원을 하지 않아 박살나는 한글과, 역시 High DPI 지원을 하지 않아 흐릿하게 보이는 글씨를 볼 수 있습니다.

아무리 한국어OS 사용자가 사용할 가능성이 99%가 넘는다 해도 한국 최고의 IT 대기업 치고는 너무 무신경하네요.

TAG •
?

Lyn
조회 수 4700 추천 수 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
조회 수 4411 추천 수 0 댓글 0
?

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

어떨라나요. 좀 빨라졌으려나요?

?

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

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

WSM.PNG

 

첫 타자는 Windows Service 관리도구입니다.

MS의 OS 의 일부임에도 불구하고 이놈은 최신의 WIndows 10 에서 조차 HighDPI 에 대한 처리가 전혀 되어 있지 않습니다 (...)

아무리 일반인이 자주 보지 않는 프로그램이라곤 하지만 좀 MS의 무신경함은 좀 심하네요.

TAG •
?

?

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

Windows 가 유니코드 기반의 OS가 된지 데스크탑 OS만 따지면 무려 15년, 기업용 워크스테이션 OS까지 따지면 그 이상이 지났고, High DPI 지원도 비슷한 시간을 보내 왔습니다.

 

그나마 High DPI 의 경우 꽤 오랜기간 96DPI 를 넘는 고해상도 장비가 나오지 않았으니 그나마 정상참작(?) 의 여지가 있긴 했지만 적어도 2016년 현재 시점에는 오히려 96DPI 해상도의 장비를 보기가 더 힘든 지경입니다(특히 모바일에서는)

 

하지만 MS Windows 는 그 이후 새로 나온 플랫폼도 아니고, OSX 처럼 레거시 API를 완전히 배제하여 호환성을 포기하지도 않은 덕분에, 아직까지도 이 두가지를 전혀 신경 쓰지 않은 어플리케이션이 꽤 많이 돌아다니고 있습니다. MS에서는 프로젝트 생성시 디폴트를 유니코드로 바꾸고, 심지어 최신의 VS에서는 아예 Non-Uncode 버전의 MFC 를 탑재하지 않는 강수를 두었음에도 궂이 프로젝트 옵션을 바꿔가면서까지 유니코드를 사용하지 않는 개발자들이 있습니다.

 

그래서 제발! Windows Application 의 퀄리티가 올라가길 바라는 심정으로, 이 두가지를 무신경하게 취급하는 SW 를 한번 정리 해 보고자 합니다.

 

단 아래와 같은 경우는 배제하겠습니다.

 

1. SW가 마지막 업데이트가 된지 3년이 넘은 구형 SW

 

 

전체목록 : 

http://lunapiece.net/Article/14007794 : 1. Windows Service Manager

http://lunapiece.net/Article/14007798 : 2. NAVER Font Installer

http://lunapiece.net/Article/14007820 : 3. OpenVPN GUI Client

TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

Devpia 에 질문 올라온김에 정리 해 두는데


크게 특별한 것이 아니라 ... 

http://www.jiniya.net/tt/788 여기 있는 내용 그대로다.
혹시 링크 깨졋으면 http://lunapiece.net/Article/27343 여길 봐라


하면안되는짓이 같은 이유는 InitInstance / ExitInstance  는 결국 DllMain 의 Reason 에 따라 분기하는 함수이기 때문


관련 자료는 아래 링크에서 찾을 수 있다 
https://msdn.microsoft.com/ko-kr/library/66f127e5.aspx


"MFC에서 제공하는 DllMain 함수는 DLL이 로드될 때 InitInstance를 호출하고, DLL이 언로드되기 전에 ExitInstance를 호출합니다"

TAG •
?

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

단축키

Prev이전 문서

Next다음 문서

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

단축키

Prev이전 문서

Next다음 문서

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

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

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

 

vul.PNG

 

?

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