발아 바라 프로그래밍

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

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 스레드 객체와 바탕 스레드와의 연결이 끊어져 합류 불가능 상태가 된다. 문제점 합류 가능성이 중요한 이유는 합류 가능 스레드의 소멸자가 호출되면..

이전 포스트에서 이야기한것처럼 std::async 는 스레드를 생성하지 않을 수도 있다. https://pppgod.tistory.com/56 불러오는 중입니다... 시동 방침을 통해 비동기로 수행되도록 할 수 있다. 시동 방침이 무엇인지 알아보자. std::launch::async 이 조건문을 사용하면 항상 스레드를 생성하게 된다. std::launch::deferred 해당 조건을 사용하면 get 이나 wait 을 호출할 때까지 함수가 실행되지 않는다. 위의 두가지 시동 방침을 살펴보았는데, 기본 시동 방침은 과연 무엇일까? 정답은 두가지 조건을 모두 사용한다. 다시 말하면 함수는 비동기적으로 실행될 수도 동기적으로 실행될 수도 있다. 그런데 위와 같은 특성 때문에 문제가 발생할 수 있다. 다음을 살..