http://www.boost.org/users/history/version_1_52_0.html

 

갱신 라이브러리

Thread

신기능

C++11준수: 부족한 async()를 추가(#4710)

C++11준수: notify_all_at_thread_exit를 추가(#7283)

C++11준수: recursive mutextry_locknoexcept를 추가(#7345)

 

 

Unordered

- 요소 추가 시 기존의 노드를 다시 이용할 수 있을 때는 재이용하도록 했다

 

 

 

출처: http://boostjp.github.io/document/version/1_52_0.html

 

 

저작자 표시
신고
by 흥배 2015.12.21 10:00

http://www.boost.org/users/history/version_1_51_0.html

 

새 라이브러리

Context

- 문맥 전환 라이브러리

개발자: Oliver Kowalke

 

 

갱신 라이브러리

Asio

- ip::tcp::iostream C++11에서의 비 호환성을 수정(#7162)

- GCC의 속성 이름과의 상호 작용을 막기 위해서 사용자 정의 매크로를 언더스코어로 장식(#6415)

- #include 가 빠진 것을 추가. MinGW에서 필요.

- GCC ARM CPU용 임베디드 atomic 기능이 이용 가능한 경우에는 그것을 사용하도록 했다(#7140)

- strand의 소멸 시에 아무것도 하지 않는다(no-op). 이 수정에 의해서 strand 개체가 연결되어 있는 io_service 객체가 파기된 후에도 파기 가능하다

- 새로운 버전의 glibc의 경우 epoll_create1() 함수를 제공하도록 했다. 다만 어떤 함수는 항상ENOSYS에서 실패한다(#7012)

- SSL 초기화에 실패한 경우에 예외를 던지도록 했다(#6303)

- buffered_write_stream 회귀 버그를 수정(#6310)

- Linux x86, x86-64 플랫폼에서 다양한 작은 퍼포먼스 향상을 구현

 

 

Hash

- C++11 표준 스마트 포인터를 지원

- 암시형 변환을 회피하기 위해서 hash_value() 함수를 SFINAE를 사용하도록 수정

- 새 설정 매크로를 사용

 

 

Lexical cast

- 퍼포먼스 개선, boost::array<character_type, N>std::array<character_type, N>의 메모리 사용량의 삭감

- volatile 수식된 입력 값에 대한 실행 시 assertion 수정(#7157)

 

 

 

출처: http://boostjp.github.io/document/version/1_51_0.html

 

 

저작자 표시
신고
by 흥배 2015.12.18 10:00

Array

- Boost.Hash 지원 추가(#6791)

 

 

Asio

- EPOLL_OUT 이벤트를 위해 epoll_reactor 백 엔드를 지연 등록하도록 변경.

- epoll_reactor 대역 외 데이터가 지난 릴리스에서는 불완전한 수정에 의해서 깨져 있어서 수정했다.

- Boost.Asio SSL 래퍼를 OPENSSL_NO_ENGINE define에 배려하도록 수정(#6432)

- C++11의 무브 세멘틱스를 지원하는 Windows 컴파일러(g++ )를 위해 windows::object_handle 수정.

- strand 재 스케줄링 성능을 향상.

- g++4.7 C++11 모드에서의 컴파일을 지원(#6620)

g++4.7에서 명칭이 변경된s td::chrono(monotonic_clock → std::chrono::steady_clock의 차이에 대응

- io_serviceconcurrency_hint1로 구축한 경우 signal_set이 전달되지 않는 문제를 수정(#6657)

 

 

Iostreams

gzip 지원(#5908)

최신 Boost.Filesystem Boost.Test의 테스트로 갱신

몇 가지 문서의 오류를 수정(#6530)(#6650)

 

 

Thread

신기능

- lock_guard / unique_lock 에 대응하는 unlock_guard의 리퀘스트(#1850)

- shared_mutextimed_locktimed_lock_shared 멤버를 리퀘스트(#2637)

- 포터블 및 포터블 하지 않은 스레드 속성의 대응 제안(#2741)

- shared_lock_guard의 리퀘스트(#3567)

- Boost.Move기반의 무브세멘틱스 대한 변경(#6194)

- 시간 관계의 인터페이스를 Boost.Chrono로 구현(#6195)(C++11표준에 대한 추종)

- Howard Hinnant가 제안한 인터페이스에 shared_mutex를 확장(#6217)

- noexcept를 컴파일러가 지원하고 있는 경우 noexcept를 지정(#6224)(C++11표준에 대한 추종)

- locks를 명시적인 bool 형태로의 변환을 추가(#6226)(C++11표준에 대한 추종)

- promise에 메모리 할당기를 지정 가능한 생성자를 추가(#6228)(C++11표준에 대한 추종)

- C++11 표준으로 정해진 예외 통지 방법으로 변경(#6230)(C++11표준에 대한 추종)

- thread의 소멸자는 joinabletrue를 돌려줄 경우에 terminate를 부르도록 변경(#6266)(C++11표준에 대한 추종(파괴적 변경) → 기본적으로 예전처럼 detach 행동. BOOST_THREAD_PROVIDES_THREAD_DESTRUCTOR_CALLS_TERMINATE_IF_JOINABLEdefine하면 새로운 동작으로 전환할 수 있다.

- thread는 무브 대입 시에 joinabletrue를 돌려줄 경우에 terminate를 부르도록 변경(#6269)(C++11표준에 대한 추종(파괴적 변경)→ 기본적으로 지금까지처럼 동작. BOOST_THREAD_PROVIDES_THREAD_MOVE_ASSIGN_CALLS_TERMINATE_IF_JOINABLEdefine하면 새로운 동작으로 전환할 수 있다.

- thread::idhash 특수화를 준비(#6272)(C++11표준에 대한 추종)

- 조건 변수 wait계통 함수용 cv_status 열거형을 추가(#6273)(C++11표준에 대한 추종)

- 문서에 BasicLockagle 요건에 관한 기술을 추가(#6231)(C++11표준에 대한 추종)

- C++11 표준용으로 once_flag를 수정(#6342)

- upgrade_lockmutexrelease 멤버가 부족했던 것을 수정(#6671)

- upgrade_lock에 시간을 멤버로 취하는 생성자가 부족했던 것을 수정(#6672)

- upgrade_lock용의 프리 함수판 swap이 없었던 것을 수정(#6675)

- packaged_taskresult_type와 메모리 할당기를 취하는 생성자가 부족한 것을 수정

- packaged_task::reset()를 추가

 

 

 

출처: http://boostjp.github.io/document/version/1_50_0.html

 

 

 

저작자 표시
신고
by 흥배 2015.12.16 10:00
C++, vc, vc++

- 헤더 의존을 줄인다. 자주 변할 수 있는 코드는 헤더에 쓰지 않는다.

 

- 모듈화 하여 의존을 줄이거나 모듈을 dll화 하여 링크 시간을 단축하다(단 너무 나누는 것은 주의).

모듈별로 프로젝트를 분할하면 자연스럽게 의존이 없어지고 그 결과 프로그램 변경 시 빌드 시간 단축도 생긴다.

또 정적 링크(staticLib)에서 동적 링크(dll)로 바꾸는 것으로 링크 시간이 줄어진다.

 

- 프리 컴파일 된 헤더 / 병렬 빌드를 적절히 설정한다.

 

- PC 성능 업그레이드

CPU 성능을 올린다.

메모리를 늘린다. 빌드 시 HDD 스왑이 줄면서 빌드(링크도?) 속도가 개선된다.

HDD → SSD로 바꾼다.

 

- 소스 코드가 너무 크고 복잡하다

프리 프로세스에 시간이 걸리거나 소스 코드가 복잡하면 빌드 시간에 영향을 주고, 빌드 후의 OBJ 파일 사이즈가 너무 크면 링크에 영향을 미친다.

 

- 복잡한 템플릿

STL 이나 boost를 사용한 것만으로 빌드 시간이 늘어났다고 느낀 경험이 있을 것이다.

프리 프로세스에서 행해지는 템플릿 해석은 빌드 시간에서 템플릿의 전개에 의한 코드 사이즈의 증가로 링크 시간에 지대한 영향을 끼치므로 템플릿은 용법 용량을 지키고 올바르게 사용해야 한다.

 

- 대량의 강제 inline

강제 inline도 비교적 위험. 처리 속도를 높이는 것만이 최적화라고 믿는 사람이 상당수 존재하므로 모든 함수를 강제 inline화 했는데 알고 보니 OBJ 사이즈가 커져서, 빌드 시간이나 링크 시간에 영향을 미쳤다. 최대한 inline화는 우리보다 몇 배 똑똑한 컴파일러에게 맡기도록 한다.

 

- 엄청나게 큰 static 영역이 잔뜩(그렇게 영향 없을지도?)

소스에 엄청나게 큰 static한 배열이 있으면 OBJ의 사이즈가 크게 된다. 강제 inline이나, 과격 한 templete 사용이 없는데도 왠지 링크 시간이 너무 많이 걸리는 경우는 static이 원인 일수도 있다.

 

 

 

출처: http://qiita.com/DandyMania/items/2c44481f03f4d08a24ea

 

저작자 표시
신고
by 흥배 2015.12.09 08:00
C, C++

struct Point {

  int x;

  int y;

  int z;

}

 

int main(void){

 

    Point p;

    p.x = 100;

    p.y = 200;

    p.z = 300;

 

    cout << "p = (" << p.x << ", " << p.y << ", " << p.z << ")\n";

}

 

< 결과 >

p = (100, 200, 300)

 

 

위와 같은 구조체를 p[0], p[1], p[2] 처럼 배열처럼 사용하고 싶다면 아래와 같은 오퍼레이터를 추가하면 된다.

struct Point {

    int x;

    int y;

    int z;

 

    // x의 주소를 기준으로 한 인덱스 위치 참조를 반환한다

    int& operator[] (int index) { return *(&x + index); }

};

 

int main(void){

 

    Point p;

    p.x = 100;

    p.y = 200;

    p.z = 300;

 

    cout << "p = (" << p.x << ", " << p.y << ", " << p.z << ")\n";

 

    p[0] = 10;

    p[1] = 20;

    p[2] = 30;

    cout << "p = (" << p[0] << ", " << p[1] << ", " << p[2] << ")\n";

}

 

< 결과 >

p = (100, 200, 300)

p = (10, 20, 30)

 

 

오퍼레이터를 추가하는 것이 귀찮거나 or 외부 라이브러리라서 할 수 없는 경우에는 아래와 같이 할 수도 있다.

int main(void){

 

    Point p;

 

    int* p2 = &p.x;

    p2[0] = 10;

    p2[1] = 20;

    p2[2] = 30;

 

    cout << "p = (" << p.x << ", " << p.y << ", " << p.z << ")\n";

}

 

< 결과 >

p = (10, 20, 30)

 

 

 

출처: http://qiita.com/_meki/items/eb17ecae1a7ba2fd458a

저작자 표시
신고
by 흥배 2015.12.04 08:00
C++, vc, vc++

VC++을 사용할 때 링크 오류가 발생하여 시간을 허비하는 경우가 있다.

보통 아래의 이유로 링크 오류가 발생하는 경우가 많다.

 

- 문자 코드의 취급이 같지 않다.

Use Unicode Character Set, Use Multi-Byte Character Set

 

- [C/C++][Code generation][Runtime Library]의 취급이 같지 않다.

Release 모드| Debug 모드

정적 링크를 사용할 경우 Multi-threaded(/MT) | Multi-threaded Debug(/MTd)

DLL을 사용할 경우 Multi-threaded DLL(/MD) | Multi-threaded Debug DLL(/MDd)

 

- 링크 라이브러리의 디렉토리를 지정하지 않았다.

[VC++ Directories][library Directories]

 

- 링크하는 설정 lib 파일이 아직 준비되지 않았다.

Debug 모드 or Release 모드

문자 코드

MultiThread 취급

32bit Or 64bit

 

- 복사한 설정에서 잘못된 의존성·설정이 된 경우

 

- 설정에 다른 버전의 컴파일러가 사용 되었을 때

 

 

 

출처: http://qiita.com/nonbiri15/items/e8cffa47596f49023480

저작자 표시
신고
by 흥배 2015.11.27 08:00

* VS 2015 update11130일에 나올 예정인데 이 버전에서는 고쳐질 수도 있다.

 

Visual C++2012, 2013, 2015 std::this_thread::sleep_for 함수는 내부에서  std::this_thread::sleep_until 함수를 호출하고 있다.

구체적으로 말하면 sleep_for 인수에 전달된 시간 값을 현재 시간에 더해서 절대 시간으로 변환하고, 그것을 sleep_until 함수의 인수로 전달하고 있다.

 

이 구현 방법에는 문제가 있다. sleep_for 함수 처리 도중에 다른 스레드와 다른 프로세스에 의해서 시간이 변경되면(OS의 시간을 변경하면) 정상적으로 동작하지 않는다.

예를 들어 현재 PC 시간이 10 0 0초이고, sleep_for 함수의 인수에 1초를 전달하고 이 처리 도중에 사용자가 PC 시간을 9 0 0초로 변경했다면 다음과 같이 동작한다.

 

1. sleep_for 함수 내에서 현재의 PC 시간 10 0 0초와 인수 값 1초를 더하여 절대 시간 10 0 1초를 만든다.

2. 여기에서 유저가 PC 시간을 9 0 0초로 변경.

3. sleep_until 함수에는 10 0 1초를 준다.

4. PC 시간이 10 0 1초때까지 1시간 0 1초간 sleep 하게 된다.

 

 

gcc에서 사용하는 libstdc++, clang/LLVM에서 사용하는 libc++에서 sleep_for 함수는 인수의 시간 값을 시각으로 변환하지 않고 그대로 시스템의 sleep 함수에 전달하고 있어서 VC++과 같은 문제는 일어나지 않는다.

sleep_until 함수를 직접 호출한 경우는 동등한 문제가 생길 수 있지만 이 함수는 원래 특정 시간까지 대기하기 위한 함수이므로 용도 외에 사용하지 않는 한은 단순히 쓴 대로 움직인다.

 

 

출처: http://www.ruche-home.net/boyaki/2015-11-11/VCsleep_

 

저작자 표시
신고
by 흥배 2015.11.23 08:00
C++

WLW(Wonderlns Wars. 4vs4 전략 액션 게임 http://wonder.sega.jp/player/game.html ) 개발에 대한 경험담. 원문 자체가 번역하기 까다로워서 번역 상태가 좀 이상함 ;;;

 

 

 

최근 아케이드 게임 개발에 사용하는 기반은(Nu). Windows Embedded 8

 

stl은 표준, Boost, Zlib etc.. 원하는대로 아케이드 개발

 

프레임 레이트 30fps. CRI 미들웨어의 ADX2. 그래픽은 Acroarts 데이터 드리븐으로 사내 툴 사용.

 

C++ 툴계

C# 매칭 & 게임 서버는 C++.

DB Java & SQL.

STL은 컨테이너 조작으로 다양하게 사용

VS 2012 사용에 의해 일부 C++11 객체 지향 MVC 설계

 

병사 객체가 많이 나오는 거동은 기본

 

C++ 편리 기능

람다식. STL 알고리즘과 상성이 좋아서, 지금까지 콜백 함수 정의 부분과 사용 부분이 떨어져 있던 것이 한군데로 합쳐져서 상쾌. boost::bind투성이가 조금 좋아졌다.

std::function을 사용하여 식을 함수에서 반환 하는 것도 가능.

단 식이 너무 커지면 결국 보기 어렵게 되므로 적당히.

 

auto & decltype 를 컴파일러에 맡겨서 코딩이 상쾌. 쓸데없는 typedef를 없앨 수 있어서 편리.

auto &&(참조의 참조)에는 주의가 필요. →(정정)reference collapsing의 예로서 "&&에 대해서&가 우선한다"라는 것.

쓰는 법에 따라서 Reference Collapsing이 동작하거나 동작하지 않았는데 이를 몰라서 잠시 헤맸던 기억이...

 

range-based for로 반복. 함수가 필요 없다

 

std::tuple

구조체를 정의하는 것은 귀찮다. std::tuple를 사용하면 std::pair는 필요 없음. tuple의 구조가 달라졌을 때 주의

 

std::array

이터레이터를 사용할 수 있고, 범위 외 접근 체크도 쉬움. 예상 외로 전체 요소 비교가 편하다.

 

Scoped Enumeration통신 동기 · std::atomic

 

std::future & std::promise

어떤 처리 완료 결과를 비동기 얻을 때 편리하다. 다만 이것이 나중 문제로

 

static_assert

컴파일 시 에러 체크. 버그의 싹을 빨리 쌓아서 정말로 추천.

 

사용해본 C++편리 기능

final & override 수식자. 승계시의 관계가 알기 쉽고 승계 실수에 대한 오류를 뱉어 준다.

Boost.Property_tree. XML 형식의 파라미터 해석에 이용. 트리 구조의 범용 속성 관리에서 편리하다.

Boost.Preprocecor. 편리한 프리 프로세서 매크로 모음

 

고속화 하는 객체 수가 많아지면 컨테이너에 대한 접근 비용이 병목으로. std(list std::vector로 바꾼다.

상한이 정해진 것은 reserve 또는 std::array를 사용하도록 push**** emplace*로 치환.

원 알고리즘을 재검토한다.

컨테이너에 대한 액세스 범위 비를 한정하거나 처리

 

메모리 릭

std::thread, std::future, std::promise를 사용하면 메모리릭 발생. 아무래도 VS2012의 버그.

대응: boost가 제공하는 동종의 것으로 대체

 

 


출처: http://shinriyo.hateblo.jp/entry/2015/09/20/Event_for_Diverse_Game_Engineers

 

저작자 표시
신고
by 흥배 2015.10.26 08:00

cppjosa https://github.com/myevan/cppjosa

위 버전은 mac에서만 빌드 및 테스드 되었다고 해서 나는 Windows 에서 사용하는데 문제 없는지 테스트 해보았다.

대부분 문제가 없었지만 작은(?) 문제로 Windows에서는 컴파일 및 실행에 문제가 있어서 아주 조금 수정하였다.

https://github.com/jacking75/cppjosa

Visual StudioC++11 지원 등의 문제로 최신 버전인 2015를 사용하였다.

 

수정된 부분

1. 소스 파일의 인코딩 변경

원 버전은 UTF-8(Bom 없음)이지만 VS에서는 인코딩 문제로 컴파일 실패

'유니코드 - 코드페이지 1200'으로 변경

 

2. std::locale("ko_KR.UTF-8") 문제

Windows에는 "ko_KR.UTF-8"을 지원하지 않음

프리프로세스를 이용하여 윈도우 플랫폼에서 빌드할 때는 std::locale("Korean")을 사용하도록 변경

이 문제는 아래의 링크 글을 참고하기 바란다.

http://includes.egloos.com/v/1504676 , http://sjc333.egloos.com/3137637

 

 

Visual Studio 실행

WinTest 디렉토리의 WinTest.sln을 실행하면 된다.

 


ps: C# 버전도 있다. https://github.com/myevan/csjosa




원 개발자분이 제가 보낸 PR을 적용해서 VS 2013 지원까지 됩니다. 그러니 

https://github.com/myevan/cppjosa 

이것을 사용하는 것이 좋습니다^^

저작자 표시
신고
by 흥배 2015.10.08 08:00

오래 전부터 요구되었던 32비트 및 64비트 C++ 코드에서 동작하는 에디트 and 컨티뉴(EnC) 기능이 Microsoft에 의해서 구현되었다. VS2015 에서는 기본적으로 유효하다. VS2013에서는 32비트 코드용으로 기본적인 형식으로 지원되고 있었지만, 유효하게 하면 최신 기능을 모두 이용하지 못하는 상태였다. EnC에 의해 개발자는 디버거에서 실행 중인 프로그램의 코드를 편집 가능하게 된다. 프로그램의 실행을 재개하면 다시 컴파일을 하지 않아도 변경 결과를 확인할 수 있다.

 

이번 VS2015 에서는 진단 도구 창과 비동기 코드를 디버깅 하기 위한 확장 콜 스택 등, 다른 기능에 대한 액세스를 잃지 않는 EnC를 사용할 수 있다. 또한 개선점으로 64비트 코드에서도 에디트 and 컨티뉴를 사용 할 수 있게 되었다. 이는 VS2015의 새 기능이다.

 

새로 설치한 VS2015 RTM 상에서 작성한 신규 프로젝트에서는 기본 값으로 EnC가 유효하게 되어 있지만 경우에 따라서는 EnC를 사용를 할 수 없는 경우도 있다. 아래 항목이 설정 되어 있어야 EnC를 사용할 수 있다.

• 디버깅 정보의 포맷을 “Program Database for Edit and Continue(/Zi)"으로 설정해야 한다.

• 인크리멘탈 링크의 효율화에 “Yes(/INCREMENTAL)"를 설정해야 한다.

Debug->Option "Native Edit and Continue"를 유효하게 해야 한다.

첫 두 개의 항목은 프로젝트의 설정에서 적용한다. 세 번째 항은 Debug| Option 아래에 있다.

 

불행히도 제한이 남아 있어서 EnC가 기대대로 동작하지 않는 곳이 몇 가지 있다. VS2015 RTM 사용자에게 영향을 미칠 것도 있지만, 장래 VS2015의 업데이트로 대처할 예정이다. 먼저 꼽히는 것은 Windows 스토어용으로 컴파일된 바이너리가 EnC를 지원하지 않는 것이다. 마찬가지로 /DEBUG:FASTLINK로 컴파일 된 이진 파일도 지원하지 않는다. 최적화를 유효하게 한 컴파일된 바이너리에도 이와 같은 제한이 있다.

 

EnC를 사용하여 파일을 편집하는 경우 현행의 VC2015에서는 파일 편집 횟수가 제한되어 있다. 이것을 넘어서 편집 작업을 행했을 경우에는 예약 공간이 없음을 나타내는 오류 메시지가 표시된다. 이 예약 공간의 사이즈는 지금은 고정이지만 개발 팀은 이를 설정 가능하게 하여 보다 개발자 친화적으로 하는 것을 계획 중이다.

 

64비트 코드에서 EnC를 활용하려면 v140 도구 집합을 사용할 필요가 있다. 마찬가지로 32비트 코드로 EnC를 이용하는 경우는 v120 도구 세트가 대상이다.

 

 

출처http://www.infoq.com/jp/news/2015/08/enc-vs2015

 

 

저작자 표시
신고
by 흥배 2015.10.01 08:00
| 1 2 3 4 5 6 7 ··· 28 |

티스토리 툴바