발아 바라 프로그래밍

제목을 보고 당황스러운 사람들이 꽤 많을것이라고 생각할 것이다. 누가 뭐래도 Javascript 언어의 대세는 Typescript 이기 때문이다. 그런데도 이 글을 쓰는 이유는 왜 Javascript 에서 Typescript 로 넘어가는지 생각해보는 시간을 갖기 위해서다. Typesciprt와 Javascript 누가뭐래도 Typescript 를 사용하는 이유는 Type 을 제공하지 않는 Javascript 에서 형식을 지정할 수 있기 때문이다. 왜 굳이 Type 이 필요한지 의문이 들 수 있는데, Java 와 같은 형식이 있는 언어를 사용하던 개발자들에게 Type 이 없다는 것은 낯설고 거북스러울 수 밖에 없다. 그런 개발자들에게 Typescript 는 축복일 수 밖에 없다. 무엇보다도 형식(Type)..

서론 언리얼 엔진4의 서버는 간단하면서도 매우 복잡한 구조로 이루어져 있다. 서버를 프로젝트에 적용하기 위해서는 많은 노력이 필요하다. 기본적으로 언리얼에서 제공하는 수많은 도큐먼트들을 정독해야만 한다. 무작정 코드를 따라하더라도 원하는대로 동작하지 않을 수 있고, 문제가 발생한 경우 이를 알아차리기란 어렵다. 이번 포스트의 목표는 공식 도큐먼트를 읽기 전에 언리얼 서버의 기본 구조를 감으로나마 익히게 해주는 것이다. 이를 읽고 많은 도움이 되었으면 한다. 본론 서버와 클라이언트의 관계 가장 먼저 이해해야하는 것은 서버와 클라이언트의 관계라 말할 수 있다. 언리얼에서 서버는 절대 권력의 존재이다. 서버에서 일어나는 일들은 모든 클라이언트가 따라한다. 즉 클라이언트는 오직 서버에서 일어나는 일들을 따라할 ..

C++11 로 오면서 push_back 과 같은 역할을 하는 함수 emplace_back 이라는 함수가 등장한 것을 볼 수 있다. 왜 이 함수가 등장했는지 어떠한 장점과 단점이 있는지 살펴보자. std::vector vs; vs.push_back("xyzzy"); 위 코드에서 함수로 전달되는 타입은 std::string 이 아닌 문자열 리터럴이다. 템플릿에 선언된 타입과는 다른 타입이라는 것이다. 컴파일러는 형식 불일치를 인지하고 문자열 리터럴의 형식을 다음과 같이 변환한다. vs.push_back(std::string("xyzzy")); 이것이 의미하는 것은 임시 스트링 객체가 생성된다는 것이다. 또 벡터 내부적으로 원소를 집어넣을때 객체를 한 번 더 생성한다. 심지어 함수의 실행이 끝나면 임시 스트링..

매개변수를 받는 방법에 대해서 우리는 왼값, 오른값, 보편 참조를 이용해서 전달하는 방법을 배웠다. 특히 왼값과 오른값 모두 구현하는 경우에는 보편 참조를 이용하여 구현하였다. 그런데 보편 참조를 이용하게 되면 우리가 원하지 않는 타입에 대해서도 인스턴스화되고, 보편 참조로 전달할 수 없는 경우에도 난감한 상황이 생기게 된다. 그런데 우리가 앞서 보았던 방법 외에도 가장 기초적인 값으로 전달하는 방법이 있다. 다음의 코드를 보자. class Widget { public: void addName(std::string newName) { names.push_back(std::move(newName)); } ... }; 위 코드는 어떠한 문제도 발생하지 않는다. 하지만 이전부터 값 전달의 성능은 좋지 않다고 ..

프로그래머들은 종종 volatile 과 std::atomic 을 혼동한다. 그러나 이 두 개는 서로 전혀 다른 역할을 한다. std::atomic 은 원자성을 보존해주기 위해서 사용된다. 다시 말하자면 mutex 없이도 두 개의 스레드가 동시에 접근해도 data race 문제가 발생하지 않는다. volatile 은 컴파일러가 최적화하며 특정 라인을 수행하지 않는 경우가 없도록 해준다. 코드로 살펴보자. volatile int vi(0); ++vi; --vi; std::cout

두가지 스레드에서 하나의 스레드의 작업이 끝나야만 시작되는 스레드가 있다고 하자. 이 같은 상황에서 작업이 다 끝났음을 알려주는 방법은 무엇일까? 한 가지 명백한 방법은 조건 변수를 사용하는 것이다. 이 변수를 조건에 따라 저장하는 과제를 검출 과제라고 하고, 이 조건에 반응하는 과제를 반응 과제라고 하자. 어떤 방법이 있는지 알아보자. std::condition_variable std 에서 제공하는 방법으로 다음과 같이 사용할 수 있다. std::condition_variable cv; std::mutex m; // 검출 과제 { ... cv. notify_one(); } // 반응 과제 { ... { std::unique_lock lk(m); cv.wait(lk); ... } ... } 위 코드는 잘..

항목 37에서 합류 가능한 스레드가 동작중에 스레드 객체가 소멸되면 프로그램이 종료된다고 하였다. 스레드와 비슷한 async 객체가 남기는 future 객체는 암묵적 join과 암묵적 detach와 비슷한 행동을 수행한다. 그럼에도 스레드와 다르게 프로그램이 종료된다거나 미정의 행동을 하지는 않는다. 어떻게 동작할 수 있을까? 공유 상태 우선 스레드의 결과가 어디에 저장되는지 살펴보아야 한다. 생각할 수 있는 가능성은 두가지일 것이다. 스레드를 생성한 쪽이거나 스레드로 생각할 수 있다. 그러나 두가지 모두가 아닌 외부에 저장된다. 그 이유를 생각해보자. 스레드를 생성한 쪽에 저장되는 경우 위와 같은 경우에는 future 객체에 저장될 것이다. 그런데 future 객체는 std::shared_future ..

모든 스레드 객체는 합류 가능이거나 합류 불가능이다. 여기서 말하는 합류는 join 을 사용할 수 있는 상태를 말한다. 합류 불가능 스레드는 다음의 목록이 존재한다. 기본 생성된 std::thread 실행할 함수가 없이 생성된 객체는 바탕 실행 스레드와는 대응되지 않는다. 다른 std::thread 객체로 이동된 후의 std::thread 객체 이동이 완료되면 기존의 스레드는 대응되는 스레드가 존재하지 않는다. join 에 의해 합류된 std::thread join 이 완료되면 대응되는 스레드가 존재하지 않는다. detach 에 의해 탈착된 std::thread 스레드 객체와 바탕 스레드와의 연결이 끊어져 합류 불가능 상태가 된다. 문제점 합류 가능성이 중요한 이유는 합류 가능 스레드의 소멸자가 호출되면..