봉봉이의 블로그 봉봉이의 블로그

std::bind(), std::function()은 callable에 대한 이야기이다.  "callable"은 호출 가능한 객체 또는 표현식이다. 즉, 함수처럼 호출할 수 있는 객체를 말한다.  std::function 함수를 통해 기존에 정의된 함수, 클래스의 멤버로 정의된 멤버함수, 람다 함수를 변수화하여 정의할 수 있다.예제 코드 std::function을 주로 사용하는 이유는 callback 함수 처리에 대한 유용성이 뛰어나기 때문입니다. 동일 함수의 시그니처를 container를 통해 관리할 수 있습니다. std::bind 함수는 이미 정의된 함수를 재정의하여 사용할 수 있습니다. std::bind는 std::placehoders를 인풋 파라미터로 정의하여 추후 자유롭게 파라미터를 설정할 수도..

mutex와 condition variable은 모두 쓰레드를 제어하기 위해 사용된다.그럼 mutex는 뭐고 condition variable 무엇을 뜻하면 이들의 차이점은 무엇일까? mutex는 thread가 코드를 사용할때 해당 코드 블럭의 소유를 하나의 쓰레드에게 부여하게 해준다.그럼으로 멀티 쓰레드환경에서 하나의 변수에 여러 쓰레드가 서로 값을 읽고 쓰려는 race condition 상태를 배제하게 해준다. 그럼 condition variable은 무엇일까?condition variable 을 사용하면 mutex 또한 사용하게 되는 condition varibale은 언제 사용하는 걸까?condition variable은 publisher - subscriber 구조에서 많이 사용된다. 멀티 쓰레..

0 - 표준입력 1 - 표준출력 2 - 표준출력 nohup ./${실행 파일 name} >> metric.log // 표준 출력과 에러를 각각의 파일에 출력하고 싶을때 nohup ./${실행 파일 name} 1 >> metric.log 2 >> error.log // 표준 출력과 에러를 하나의 파일에 출력하고 싶을때 nohup ./${실행 파일 name} 1 >> metric.log 2>&1 // metric.log 출력에서 keyword 아래로 20줄 출력 tail -f metric.log | grep ${추출할 keyword} -A 20

conan config home cat ${conan config home}/profiles/default [settings]

문득 queue에서는 왜 iterator가 없는지, iterator가 정확히 무엇인지에 대한 궁금증이 생겨 자료를 찾아보았다. 컨테이너(데이터 컬렉션)의 원소를 순회(traverse)하는 데 사용되는 개념이다iterator는 일종의 포인터처럼 작동하여 컨테이너 내의 원소에 접근하고 수정할 수 있는 방법을 제공벡터(vector), 리스트(list), 맵(map), 셋(set) 등에서 iterator를 사용하여 컨테이너 내의 원소에 반복적으로 접근큐(Queue)는 특정한 종류의 컨테이너로, 원소들이 들어온 순서대로 처리되는 구조이러한 특성 때문에 큐에서는 일반적으로 iterator를 지원하지 않습니다. 큐의 목적은 원소들을 앞에서부터 순차적으로 처리하는 것이며, iterator를 제공한다면 이러한 처리 방식..

이 글을 쓰게된 이유는 알고리즘 문제를 풀다가 아래와 같은 생각이 들었다. 자료구조인 Heap을 사용하는 대신 이진검색을 이용하여 컨테이너에 값을 삽입하면 힙과 같을까? 결론을 말하자면 Heap은 이진검색을 사용할 때 보다 효율적이다. 그런데 생각해보면 Heap은 max heap/min heap 모두 사입/삭제에 log(N)이 사용되고 이진검색도 배열에서 값을 찾기위해 log(N)의 연산이 사용된다. 그러나 이 둘의 차이는 Heap은 완전이진트리 구조라는 것이다. 완전이진트리인 Heap은 최악의 경우에도 log(N)이 걸리지만 이진검색은 최악의 경우 N의 연산이 사용된다. 자세한 내용은 ChatGPT가 정리한 것을 참고하면 된다. 완전이진트리 VS 이진검색 https://chat.openai.com/sh..

하나의 프로세스는 file descripotr 생성에 제한이 있다. 이 설정을 확인하기 위해서는 아래 설정을 통해 확인이 가능하다 ulimit -a 여기서 open files 뿐만아니라 core file size나 max user processes와 같은 설정도 확인할 수 있다. (core file size가 0일 경우 core 파일이 생성되지 않음) 뿐만 아니라, ulimit 명령어는 아래와 같이 설정 수정도 가능하다. ulimit -n 30000 하지만, 위와 같이 설정을 변경하더라고 현재 활성화된 터머널에서만 해당 설정값이 유지된다. 모든 설정을 영구적으로 변경하기 위해서는 '/etc/security/limits.conf'에서 다음과 같이 파일의 내용을 추가시켜줘야 한다. sudo vi /etc/s..

c/c++ 실행 중, 에러로 인한 프로세스가 멈추면 core 파일 생성 ulimit -c unlimited sysctl kernel.core_pattern --> core 파일 생성되는 위치 확인 만약, core 파일이 생성되는 위치를 수정하고 싶다면 /etc/sysctl.conf 파일 수정 kernel.core_pattern = ${코어 파일 생성 위치} ${코어파일 생성명} 코어 파일 생성 위치 ex) /home/bong/Desktop/core/ (끝에 / 유의) 코어파일 생성명 ex) core.%e.%p.%t sysctl -p 를 통해 수정한 파일 적용