GitHub: https://github.com/Microsoft/vcpkg
demo 영상: https://www.youtube.com/watch?v=y41WFKbQFTw
Visual C++에서 OSS의 라이브러리를 사용하기 위한 패키지 매니저.
인스톨 순서는 다음과 같다.
1. https://github.com/Microsoft/vcpkg.git 을 복제.
2. 복제한 디렉토리에서 powershell-exec bypass scripts\bootstrap.ps1 를 실행하여 빌드 한다.
3. .\vcpkg integrate install 로 사용자 전체에 설치(첫 회는 관리자 권한 필요).
4. 패키지 설치는 아래처럼 한다
..\vcpkg install sdl2 curl
작업 예와 대응 패키지에 대해서:
https://github.com/Microsoft/vcpkg/blob/master/docs/EXAMPLES.md
MIT 라이선스.
중에서
Go 1.7은 컴파일 시간과 런타임 성능을 크게 개선하고 있다.
또 계층적 테스트와 벤치 마크, Linux on IBM z Systems(s390x)상의 Linux 공식 지원도 추가한다.
Go 1.7의 컴파일러 개선은 주로 SSA(정적 단일 대입) 형식에 의거 amd64 플랫폼용 Go의 새로운 컴파일러 백엔드에 관계하고 있다. 새로운 백엔드는 다수의 선진적인 최적화 덕분에 더 작고 고속의 코드를 생성한다.
최적화는 경계 표시 삭제와 공통 식의 삭제가 포함된다.
Google의 벤치 마크에 의하면 런타임은 5– 35% 고속으로 되고, 컴파일 시간과 바이너리 사이즈는 최대 20– 30% 감소된다.
때로는 벤치 마크는 크게 바뀔지도 모르지만 몇몇 Hacker News 사용자는 빌드 속도가 2배 향상하고 있다고 말하고 있다.
SSA 백엔드는 amd64 플랫폼만 사용할 수 있다. 하지만 Google의 엔지니어 Brad Fitzpatrick씨에 의하면 지원하는 전 아키텍처로 이식은 Go 1.8의 주요 목표의 하나라고 한다. 그리고 오래 된 백엔드를 삭제하는 것으로 프론트 엔드는 더 간단하게 될 것이라고 한다. 익서은 또 다른 성능 개선을 가져올 것.
2017년 2월 릴리스 예정의 Go 1.8에 관한 자세한 것은 GoLang Dev 포럼에서 찾을 수 있다.
Go 1.7에서 또 주목해야 하는 변경으로 서브 테스트와 하부 벤치 마크가 있다. 이는 계층적인 테스트나 테이블에 의한 벤치 마크 정의를 가능하게 한다.
-run 및 –bench 플래그의 인수에 슬래시 단락의 정규 표현 리스트를 지정하면 된다.
마지막으로 Go 1.7은 표준 라이브러리의 일부로서 context 패키지를 채용했다. 이것은 네트워킹 시의 취소, 타임 아웃, 리퀘스트 범위에 한정한 데이터의 교환을 간단하게 한다. 또 vendor 디렉토리 사용도 표준이 됐다.
이로써 GOPATH이나 표준 라이브러리에서 자동적으로 끌고 오는 대신 개발자는 외부 의존물의 로컬 복사본을 사용하게 된다.
Go 1.7의 기능 추가, 개선, 버그 수정에 대한 자세한 설명은 릴리스 노트를 보자.
유니버설 C런타임 라이브러리에 대해서
Visual C++2015에서는 C런타임(CRT) 라이브러리가 크게 리팩터링 되어서 Universal CRT(UCRT)와 그 이외의 런타임(vcruntime140.dll 등)의 2종류로 구성되어 있다.
UCRT에는 널리 이용되는 표준적인 C 런타임 라이브러리 코드가 구현 되어 있으며 안정된 API를 갖추고 있기 때문에 Visual Studio의 릴리스마다 버전 변경할 필요가 없는 Windows OS의 컴포넌트의 일부로서 자리 매김 되어 있다.
UCRT는 Windows 10에는 기본으로 설치되어 있지만 이전 OS에 대해서는 Visual C++2015 재 배포 가능 패키지를 사용하여 설치할 수 있다.
UCRT에 대해서는 아래의 블로그 글을 참조.
Introducing the Universal CRT
https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
애플리케이션 개발과 배포 시에 상기의 변경에 대해서 의식할 필요는 거의 없으나 CRT 배포 방법으로 "로컬 배치"를 검토하고 있는 경우에는 UCRT의 로컬 배치에 관하여 주의할 필요가 있다.
Visual C++2015에서 CRT 로컬 배치에 대해서
애플리케이션의 실행에 필요한 C 런타임 라이브러리를 실행 환경에 배포하는 방법으로는 재 배포 가능 패키지 등을 사용하여 시스템 폴더에 런타임을 설치하는 방법이 일반적이며, 이와 같이 시스템 폴더에 런타임을 설치하는 것을 "집중 배치"라 부른다.
이에 대한 시스템 요건 등에 의한 집중 배치를 채용하기 어려운 경우는 애플리케이션 배포 처 폴더에 런타임을 배치할 수 있으며 이러한 배치 방법은 "로컬 배치"라 부른다.
집중 배치와 로컬 배치에 대한 자세한 내용은 아래의 문서를 참조.
배치 방법 선택
https://msdn.microsoft.com/ja-jp/library/ms235316.aspx
로컬 배치할 때 Windows 10보다 이전의 OS에서는 전술의 UCRT도 실행 환경에 배치할 필요가 있다는 것에 유의하자. 구체적으로는 Visual Studio 2015를 설치한 환경에서 아래의 폴더에 있는 DLL을 모두 exe와 같은 폴더에 배치할 필요가 있다.
<UCRT 배포 원 폴더: 64 bit OS에 Visual Studio 2015를 설치하고 있는 경우>
(64 bit응용 프로그램용)C:\Program Files(x86)\Windows Kits\10\Redist\ucrt\DLLs\x64
(32 bit응용 프로그램용)C:\Program Files(x86)\Windows Kits\10\Redist\ucrt\DLLs\x86
또한 UCRT 이외의 CRT는 기존대로 redist 폴더 아래에 저장되어 있다.
<CRT 배포 원 폴더: 64 bit OS에 Visual Studio 2015를 설치하고 있는 경우>
(64 bit응용 프로그램용)C:\Program Files(x86)\Microsoft Visual Studio 14.0\VC\redist\x64
(32 bit응용 프로그램용)C:\Program Files(x86)\Microsoft Visual Studio 14.0\VC\redist\x86
Visual C++2015 응용 프로그램에서 C 런타임 라이브러리를 로컬 배치할 필요가 있는 경우에는 위 내용에 대해서 유의하자.
출처: https://blogs.msdn.microsoft.com/jpvsblog/2016/08/04/ucrt_local_deployment/
출처: https://www.infoq.com/news/2016/05/bowers-lessons-learned-nosql
주로 NoSQL을 처음 도입할 때 어떻게 해야 하냐의 이야기에 가깝다.
….
NoSQL 데이터베이스의 채용에는 NoSQL을 지지하는 지도자와 개발자 및 경영진의 적극적인 관여가 필요하다.
교훈 1:
NoSQL을 지지하는 리더가 조직에 있을 것: 조직 전체에 영향력을 갖고 기업 내의 개발자뿐만 아니라 경영진을 납득시키는 인물의 존재가 필수적이다.
교훈 2:
경영진의 적극적 관여를 얻을 것: 대기업 경영진은 기업용 상용 데이터베이스를, 신흥 기업의 고위 관리직은 오픈 소스 데이터베이스를 각각 좋아하는 경향이 있다. 즉 NoSQL 인수 팀이 NoSQL데이터베이스를 도입하려면 조직의 관리 계층의 개입이 필요한 것이다.
교훈 3:
개발자의 적극적 관여를 얻을 것: 개발자에게 NoSQL이 다양한 데이터 구조를 지원하고 애자일 개발을 실현할 것임을 보여야 한다.
키/값 데이터베이스가 고 성능을,
와이드 컬럼 데이터베이스가 인터넷 레벨의 스케일링을 제공하는 것에 대해,
문서 NoSQL 데이터베이스는 단기간에 앱 개발을 실현하는 것이다
라고 그는 지적한다.
교훈 4:
훈련, 훈련, 훈련: 개발자가 NoSQL에 익숙해지는 것이 무엇보다 중요하다.
기술을 수반하지 않는 NoSQL 도입 활동은 편리한 훈련대에 불과하다.
그가 권하는 방법은 NoSQL을 사용한 현실적인 솔루션을 단기간에 저렴하게 구축하고 그것을 성공의 실례로 상층부에 알리는 것이다. 데이터베이스 라이선스와 개발 비용의 감소, 확장성 향상이라는 목표를 실증하는 데 의미가 있다.
그는 높은 대역 폭, 저 레이턴시, 분석성, 운용성, 볼륨, 속도 같은 요건에 대해서 다른 데이터베이스와 비교하는 방안도 제안했다. 데이터 모델의 유연성, 퍼포먼스, 혹은 수평 측정 가능성 등, NoSQL 데이터베이스 채용의 원동력이 될 수 있는 팩터를 그 안에서 찾아내는 것이다.
의사 결정 프로세스에는 팀 전체의 집단 소유권이 있기 때문에 NoSQL 데이터베이스의 채용은 팀 내에서 합의하는 것은 불가피하다.
C++로된 프로그램과 C#으로 만든 프로그램이 서로 패킷을 주고 받는 경우 외부 라이브러리를 사용하거나 C# 기본 기능을 사용한다.
외부 라이브러리로 CGDBuffer, protobuf, msgpack 등을 사용하거나 아니면 아래와 같이 직접 한다.
(C++)
// 패킷 헤더
struct PktHeader
{
short PacketID;
short BodySize;
};
// 로그인 패킷
struct PktReqLogin
{
char UserID[17];
char UserPW[17]
};
struct PktResLogin
{
short ErrorCode;
};
[ C++ 서버로 패킷 보낼 때 ]
short packetID, string userID, string userPW;
var asciiUserID = System.Text.Encoding.Default.GetBytes(userID); // 멀티바이트 문자열. 유니코드 문자열은 System.Text.Encoding.Unicode.GetBytes
var dataUserID = new byte[16+1];
Buffer.BlockCopy(asciiUserID, 0, dataUserID, 0, asciiUserID.Length);
var asciiUserPW = System.Text.Encoding.Default.GetBytes(userPW);
var dataUserPW = new byte[16 + 1];
Buffer.BlockCopy(asciiUserPW, 0, dataUserPW, 0, asciiUserPW.Length);
List<byte> dataSource = new List<byte>();
dataSource.AddRange(BitConverter.GetBytes(packetID)); // 패킷 ID
dataSource.AddRange(BitConverter.GetBytes((Int16)(dataUserID.Length + dataUserPW.Length))); // 패킷 데이터(body)의 크기
dataSource.AddRange(dataUserID);
dataSource.AddRange(dataUserPW);
var send_data = dataSource.ToArray() // byte[]로 변환
[ C++ 서버에서 패킷 받았을 때 ]
var recvData = Network.Receive(); // receive로 데이터 받음
var packet = new PacketData();
packet.PacketID = BitConverter.ToInt16(recvData, 0);
packet.DataSize = BitConverter.ToInt16(recvData, 2);
packet.BodyData = new byte[packet.DataSize];
var errorCode = BitConverter.ToInt16(packet.BodyData, 0);
struct PacketData
{
public Int16 PacketID;
public Int16 DataSize;
public byte[] BodyData;
}
이것 이외에도 방식은 있으니 구글링도 해보기 바란다
댓글