공부정리

https://vhxpffltm.tistory.com/274 위 내용의 후속으로 아래 글을 이용해서 VS 솔루션으로 바이너리 실행시 정말 긴 경로를 잘 인식하는지 설정해야한다. 먼저, 레지스트리 편집기를 통해 긴 경로를 설정해도 VS의 바이너리에서는 런타임에 적용이 안되는 문제가 있을 수 있다. https://stackoverflow.com/questions/71602123/how-to-enable-long-path-aware-behavior-for-setting-the-current-directory-in-a How to enable "Long Path Aware" behavior for setting the current directory in a C++ windows console app In a ..

먼저, 이게 나온게.. 전처리 경로의 파일을 찾다 나온것인데... 상대 경로로 지정될때, 파일을 찾을 수 없다고 한다... 그런데 260자가 넘어가도 경로를 지정하면 잘 된다. ../ | ./ 와 같은 슬래시 및 마침표를 적용한 것은 사용할 수 없다는 것이 MS의 설명이다. 최대 경로가 260자가 넘어가면 접두어에 \\?\ 이 사용되며 이것이 적용된 이상 슬래시와 마침표는 사용할 수 없다.. https://learn.microsoft.com/ko-kr/windows/win32/fileio/maximum-file-path-limitation?tabs=registry 최대 경로 길이 제한 - Win32 apps 최대 경로 길이 제한. learn.microsoft.com 이를 풀어주는 것은 쉽게 찾을 수 있듯..

CL 컴파일러를 사용하면서 이제까지 잘 되던 빌드가 깨지는 문제가 있었다. 무슨 컴파일을 하는데.. sqlite와 관련한 DB API 코드쪽에서 컴파일 에러가 발생했다. 흠.. 코드 변경사항도 없고 빌드가 먼저 시작되는 부분이고.. DB 관련이라 느낌이 쌔했는데 역시나 프로젝트 경로에 한글이 있어서 문제였다. 경로에 "과제" 라는 한글이 있었고 해당 경로를 영문으로 변경하여 처리하였다. 항상 변경점을 잘 생각해보고 확인해보자. VS 2019로 업그레이드 하라는 VS 포럼도 있는데 여기에 낚이지 말자...

이슈 확인중 재현해보니... stack oveflow였고 호출스택을 보니... 같은 함수가 무지막지하게 호출되고 있었다. 해결하는 방법은 많은데 그중 들은건 릴리즈시, 스택 크기를 기본 1MB가 아닌 좀 더 늘려서 하자는 거였다. 음.. cmake인데.. 어떻게하지..? 간단하다. 우선 Visual Studio에서는 프로젝트 속성에서 수정할수 있다. 아래 그림처럼 '링커' -> '시스템' 에서 적당히 고쳐주면 된다. 바이트 크기이다. 그렇다면 cmake에서는 어떻게 할까? 아래 링크를 참조할 수 있다. 먼저, VS에서 링커 옵션중 /STACK 옵션을 사용한다. 이것이 위 그림의 '스택 예약 크기' 이다. 필자의 Cmake는 target(최종 빌드 결과물)이 되는 3개의 바이너리에 target_link_o..

32비트 바이너리를 매일 빌드하는데... 최근 사내 업데이트로 바이너리를 x64 비트로 빌드해야 하는 작업을 하고 있다. VS code에서는 configuration을 아래 그림과 같이 편하게 잡아주기 때문에? 금방 작업할 수 있는데... Visual Studio는 상단에 실행 / 디버그 쪽에 x64를 체크하면 되는걸로 알고있다. 하지만!? 없는 경우가 있었고 임의로 사용 확장 가능한 아키텍처를 임의로 고르다 보니 여러 이상해졌다. 구성 관리자가 Win32 밖에 없었고... 뭐 새로 추가해서 마음대로 하니 빌드가 안돼고 이상해졌다. 그래서 프로젝트 속성(C/C++ , 링커)과 솔루션 속성에 들어가서 확인해봤는데 별로 문제가 없어보였다. 명령줄에 machine 옵션, 솔루션 구성 설정에 들어간 라이브러리 ..

c++ 테스트 코드를 작성하면서 발생한건데 검색해보면 많이 확인할 수 있다. 먼저 필자는 순수 가상 함수를 가지는 추상 클래스의 개체를 생성하려고 한것이 문제였다. 그것을 제대로 모르고 해당 순수 가상 함수를 &연산자를 사용하여 참조할 수 있도록 주소 객체를 만들고 그 객체로 접근하려다 보면..... 산으로 빠져버린다.. 과연 아래코드는 컴파일이 될텐데 에러가 없을까..? 에러 내용만 보고 고치면 이렇게 고칠수 있다... 이를 피하려면 문제의 원인이 추상 클래스임을 알고 추상 클래스가 상속된 파생 클래스의 개체를 생성해서 사용할 수 있다. 항상 코드가 어떻게 구성되어 있는지 잘 보자.. 쉽지 않겠지만.. 문제는 아래처럼 단순하면 금방 발견할수 있는데... 코드가 복잡하고 많다보니 쉽게 발견못할수도 있다...

보통 윈도우 10 업데이트를 꺼놓는데 사내 PC는 최신 업데이트를 받는다. 그리고 보통 목요일 오후에 그 작업이 이루어지는걸로 보인다. 그렇게 있는데.... 문제는... 업데이트 이후.... 어디선가.. 충돌이 났는지... 우선 찾아보니 에러는 아래와 같다... : C:\Windows\Logs\WindowsUpdate 파일탐색기에서 에러가 났고 Refersh 기능에 문제가 있었다. 새폴더 생성 및 삭제가 바탕화면 및 파일탐색기에서 바로 보이지가 않았고 새로고침하거나 다시 뒤로갔다 돌아와야 생성과 삭제가 되는것을 볼 수 있었다.. 이게 freecommand에서도 마찬가지 였다... 관련된 글을 찾아보면.. 1. 파일탐색기 프로세스 재시작 -> 처음에 제대로 동작한 후, 두번째부터 다시 문제가 발생 2. 레..

C++을 공부하는데 static 변수가 좀 특이한것을 확인할 수 있다. 특히, static 변수의 경우 컴파일러에 따라 특징을 나타낼수 있었다. VS에서는 inline 키워드를 함부로 사용할 경우 컴파일 에러를 나타낸다. 하지만, GCC에서는 컴파일 에러가 나타나지 않는다. 또한, GCC에서는 표준에 따라 차이가 있는데 static 키워드의 정의를 할수 있는가? 초기화는? class 내부에 선언된 static 변수를 사용할때 어떻게 해야하는가..? 아래 코드가 VS에서 그리고 Gcc c++17 문법에서 inline이 있을때와 없을때 어떻게 되는지 확인할 수 있다. 간단히 보면 GCC에서는 inline 키워드로 static 변수를 class 선언 파일에서 바로 정의가 가능하다. VS에서는 inline 키워..

C++ Idiom을 알게되면서 꼭 정리하고 배워야 할 내용이 있다. 더 찾아봐야겠지만, Pimpl과 Factory 클래스, templete 패턴 등 적용하고 알아야할게 많았다. 지금은 Pimpl에 익숙하도록 하고 있는데 적용중에 발생한 문제다. 위의 에러가 발생하면서 곤란했는데.. 음 Piimpl을 사용할때는 복사 생성자.. copy constructor를 꼭 지정해주도록 하는게 좋아보인다. 이 외에 Impl 클래스나 구조체에서 생성자를 선언만 하지말고 {}로 정의해주는것을 잊으면 안된다. 또한, operator= 연산자에 대해 swap 함수를 사용해 Pimpl을 스왑한다. https://stackoverflow.com/questions/21943569/deleted-function-unique-ptr ..

처음 사용하는데... 이것때문에 진짜 너무 많은 시간을 허비했다... 문제는 아카이브 빌드였다. 에뮬레이터로 빌드했을때는 문제없이 성공했는데 이상하게 아카이브 빌드는 실패한다.. 뭔가 이상하다.. 그러면서 발견하게 된 2개의 기능을 찾았다.. 1. 먼저 아카이브 빌드가 에뮬레이터로 하면 활성화 되어 있지 않을텐데 에뮬레이터가 아닌 Generic IOS Device로 설정하면 아카이브 빌드가 활성화된다. 2. Build가 실패했을때.. 아니 무슨 에러 내용이 없길래 무슨 에러인지 찾는게 너무 힘들었다.. 그 내용은 아래 그림에서 찾을 수 있었다. Xcode의 상단과 우측 상단에 에러내용이 표시되었다... 이런 상황에서 문제의 원인은 Project Target의 Singing 이였다.... 지금은 해결해서 ..