본문 바로가기

Developement

(142)
socket 의 recv() 는 항상 원하는 크기대로 오지 않는다 ! 이전의 버퍼를 다 받아 오지 않던 문제를 ... 그간 PC 에서 socket processing 하던 편리함에 빠져 그 근본을 잊었던 것 같습니다. 임베디드 보드가 지속적인 메모리의 malloc() 과 free() 때문인지 죽어 버리는 문제가 발생 하지만, 적어도 30MB 의 데이터를 지속적으로 500번 가량 전송 하는데 성공을 했습니다. 이유는 간단히, recv() 함수가 가진 특성을 그간 간과 했기 때문 입니다. socket 에서 recv() 로 원하는 크기가 다 넘어 오지 않는다. 이 사실을 제가 간과 하고 있었네요. 너무나 기초적인 부분인데, 어찌 이런걸 제가 그간 잊고 있었을까요? 그래서 코드를 다음과 같이 수정 하였습니다. int nRecvSize = 0; bool bRecvDone = fal..
임베디드 리눅스의 이 난감한 상황은 ... 시그윈에서 socket 과 inet 만으로 단순 socket server 를 만들었습니다. class 로 wrapping 해서 쓰기 편하게 만들어서 돌렸더만 잘 돌기에 힘들게 porting 한 embedded linux 에 넣고 짠! 하고 잘 돌줄 알았더니, 흠 - 얘가 뭔가 뾰로퉁 하게 도네요 .. 30MB 짜리 버퍼를 보내는데 4KB 보내고 멎어 있습니다. socket server 를 non-blocking, async 로 설계한 이유는 아닌거 같은데, FD_ISSET() 이나 ioctl() 에서 멎는 문제도 아닐텐데, 그 이유를 찾기가 어려운 난감한 상황이 아닌가 합니다. 현재 GbE 로 연결된 상태라 전체 속도의 반인 60MBytes/sec 정도가 나와 주면 좋겠는데, 설계의 문제인지 아니면 제가..
Visual Studio 에서 import 한 프로젝트를 Code Blocks (gcc/minGW) 에서 빌드 실패 할때. 정말 많은 이유로 Visual Studio 를 싫어 하는 이유중, 그중 하나가 바로 위 이미지처럼 나오는 뭔가의 DLL 이 없어서 오류가 나는 경우 입니다. 멍청한 M$놈들이 지들이 만든 DLL 의 참조 오류가 많아지자, manifest 개념을 도입해서 DLL 특정 위치 해결 점을 어찌저찌 해 보고자 해 놓고선, 컴파일러 자체가 Visual Studio 에서 개발에서 쓰는 DLL 이 없으면 표준 WindowsAPI 로 도는 프로그램이 돌지도 못하게 해 놓은 것이죠. M$ 개발자들이 편하니, 사용자가 되는 VS 개발자가 개노가다 해야 하는 겁니다. 참으로 븅신같은 현상이 아닐수가 없죠. 분명히 프로젝트를 표준 Windows API 만을 사용하는 프로젝트로 만들어도, 저놈의 알수도 없는 DLL 참조 오류는 ..
내가 C# 을 싫어 하는 이유. - 읽으시기에 앞서 - 이 글은 저의 극히 개인적인 글 입니다. 이점 이해 하시고 읽어 주시면 감사 하겠습니다. 세상엔 많은 컴퓨터 언어들이 있지만, 유독 내 눈에 거슬리는 컴퓨터 언어가 있습니다. 그 존재는 바로 C#. 마이크로소프트(이하 마소)에서 개념차게 만들었다 주장하는 이 C# 이란 존재는 탄생이 다음 목적들을 가지고 있습니다. 1. C/C++ 의 문법에, Visual BASIC 의 빠른 개발 장점을 가지는 언어. 2. 32bit/64bit 나 x86, ARM 등 서로 각기 다른 platform 에 독립적인 동작을 보장하는 소프트웨어. 3. WPF 를 통한 매우 시각적으로 있어 보이는 소프트웨어를 만들 수 있음. 뜻은 좋습니다. 하지만 제가 C# 을 본의 아니게 사용하고 격어 보면서 위의 것들은..
[C/C++] precompile, 프리컴파일에 대해 ... 오랜만에 쓰는 강의 아닌 글이 입니다. 요즘 C 언어 한다고 자신감에 좀 쩔어 있는 몇몇 개발자들 보고 있으니, 프리컴파일이나 링크에 대핸 사전적인 지식은 전무 하더군요. (마소의 비주얼 스튜디오 덕분에 디버깅도 비주얼 스튜디오 없으면 할 줄 모릅니다 ... ) 윈도우는 리눅스나 유닉스 기반과 달리, OS 가 설치되면 컴파일러는 사용자가 알아서 설치 해야 합니다. 사실 일반 사용자가 컴파일러를 쓰는게 이상한 일일 수도 있겠습니다만 .. 적어도 개발 한다는 친구들은 이 컴파일러에 대해 좀 알아야 하지 않을까요 ? 어셈블리어 까지는 몰라도 내가 만든 코드가 어떻게 컴파일러에서 Object 로 바뀌는지는 좀 알았으면 하는 마음에 글을 한자 써 봅니다. 먼저 아래 이미지 처럼 .. hello world 틱한 코..
DICOM tag reader/writer ... 그냥 내가 만들어 쓴다 -> 만들었다. 인터넷을 아무리 뒤져도 ... 그놈의 DCM 파일 읽고 쓰는 라이브러리 만 구하려니 .. 다 상용에다 쓰기도 빡센 이상한 애들 뿐. 그래서 회사에서 팀장님이 구해 준 C# 소스를 주워다 보고 C++ 로 그냥 새로 만들었다. (아 ... C# 으로 만들면 정말 얼마나 낭비가 심한지 다시금 깨닫게 되는 계기가 되기도 ... ) Tag 를 Element 단위로 읽어 들이고 써 주기 때문에 필요한 것 만 수정해서 다시 DCM 으로 만들수 있다. minGW 를 이용해서 만들어 진 상태이며, 코드상에 포인터 계산이나 이런 부분이 모두 integer-safe 코드 이므로 32bit/64bit 모두 사용이 가능하며, little-endian 및 big-endian 모두 사용이 가능하다. 아직은 처음 버젼이라 JPEG,..
CodeJoke, 나보고 빌드를 하라는 거냐? 말라는거냐? 휴가중에도 회사에서 진행 되는 프로젝트에 테스트를 해 보아야 할 CodeJoke 라는 MFC 용 UI 라이브러리를 테스트 해 봐야 할 필요가 있어 일단 자주 죽는 PC 겨우 살려 테스트 해 보기 위해 SourceCode 를 받아 빌드를 하도록 노력 해 보았습니다. 만! ... 장난하냐 .. CodeJoke ... 빌드를 static lib 으로 시도 했습니다. 당연 이 컴터에 설치된 컴파일러 라곤 Visual Studio 2010 뿐이라, 2010 용으로 빌드! 대박 오류 부터 납니다. CodeJoke 가 이게 상용 라이브러리 인데 .. 왜 오류지? 하고 보니. 응? afxwin.h ? MFC 용 라이브러리 인가? 싶어 확인 해 보았습니다. afxwin, afxext 등등 .. MFC 에서 자주 쓰는 쓰..
imebra 의 minGW 32bit pre-compiled library Free BSD project 중 쓸만한 DICOM read/write 라이브러리인 imebra 의 minGW 32bit 용 library 와 header, test code set 입니다. 2011년 4월 18일 밤 10시 48분 29초 빌드 소스를 이용해서 만들었습니다. imebra 공식 홈페이지 : http://imebra.com/ imebra Doxygen 홈페이지 : http://imebra.com/documentation/2011/html/main.html 사용법은 압축을 풀면 examples, include, lib, tests 폴더가 나옵니다. 이중 tests 는 QT lib 이 있어야 구동이 되는 것 이니 참조만 하시고, include 는 lib 에 있는 a 파일을 쓰기 위한 header..