Purewell.BIZ

각종 비리로 특권층 살지우기 1번 영향으로 IMF터짐 새로운 정부가 2번 뒷바라지 10년동안 뒤치닥거리 했다고 정부에 반감 자... 4번에서 생긴 반감이 있다고 치더라도 1번 특권층을 다시 뽑아야할까? 풉... IMF 또 겪고, 또 많은 사람이 명퇴하고, 또 많은 사람이 자살해야 할까? 만약 그렇다면 대한민국 국민은 M기질이 다분하다고 봐야겠다. 뭔게 계속 괴롭혀주고, 막막한 현실을 계속 제공해줘야하나보다. Powered by ScribeFire . 원본 위치: http://purewell.egloos.com/3507928

rein님의 C/C++의 예외 모델 차이 포스팅에서 C와 C++ 예외 모델 차이, 나와 다른 견해에 대해 깔끔하게 잘 설명하셨다. rein님 포스팅을 보고 내 포스팅 에 덧글로 달까...라고 생각했지만 말도 길어지고 해서 트랙백납치!! 100년도 안 되는 삶을 살아오면서 실무에 setjmp/longjmp를 쓴 적은 단 한 번도 없다. 누구나 생각하듯 나 역시 'setjmp/longjmp는 미친 짓이야!'라고 밖에 설명할 길이 없다. (오로지 컴파일러나 커널/드라이버 만드는 사람이나 쓰는 system call이라 생각하고 있다!) 그러나 본인은 rein님과 달리 C++코드에 거침 없이 do-while(false)를 쓴다. 그것이 C++답지 않다는 것도 물론 알고 있다. 그것이 C++에서보다 좀더 신경써야할 것이 많다는 것도 알고 있다. 하지만 실무를 하면서 - 그것도 미칠 듯한 퍼포먼스를 내야할 Router나 기타 서버 프로그래밍을 하면서 try-catch는 내겐 너무 버겁다. 예외상황이 전체 프로그램에서 크게 차지하는 부분이 많지 않더라고 해도, 가끔씩 나는 장애와 그에 따라 발생하는 수많은 예외상황에 try-catch는 너무너무 무겁다. 결국 rein님한테 하고 싶은 소리는 저도 setjmp/longjmp는 쓰지 않아요. 업무 요건 상 한 번 예외상황이 발생하면 허천나게 발생해서 try-catch는 너무 무거워요. 결론은 업무요건에 맞춰 알아서 쓰자~* 원본 위치: http://purewell.egloos.com/3507734

예외를 처리하기 위해 여러가지 방법이 있는데, C++에서 표준으로 제공하는 try-throw-catch가 있다. 그러나 이 방법은 exception을 처리하기 위해 갖가지 삽질을 내부적으로 하는 것으로 매우 느리다는게 잘 알려져 있다. 그래도 얼마나 느린지 알고 싶었다. 그래서 do {} while (false)와 비교해보기로 했다. #include <exception> #include <iostream> #include <sys/time.h> using namespace std; static size_t gTestCount(100000); typedef long long ts_t; ts_t getTimestamp(void) { static __thread struct timeval tv; gettimeofday(&tv, NULL); return 1000000LL * tv.tv_sec + tv.tv_usec; } inline void funcDOWHILE(void) { static __thread size_t i(0); do { ++i; if ( i%2 ) break; return; } while (false); ++i; return; } inline void funcEXCEPTION(void) { static __thread size_t i(0); static exception _e; try { ++i; if ( i%2 ) throw(exception()); } catch(const exception&) { ++i; } return; } int main(int argc, char* argv[]) { ts_t t1, t2, diff; t1 = getTimestamp(); ...

발로 짠 UN*X message queue 프로그래밍. 아... 귀찮스러... CMake가 깔려 있다면, 아래와 같이 입력하면 대략 안성 맞춤이다. $ cmake . $ make msgprj.zip 원본 위치: http://purewell.egloos.com/3506312

요새 욕설이나 19禁 영상 등을 이글루스에 올려 동의 없이 게시물이 감춰지는 현상을 목격할 수 있다. 이에 블로거는 시대가 어느 때인데 사전 검열이나 그런 것으로 제한하려고 하느냐고 반발한다. (옳소!) 그런데 불평의 대상이 정보통신윤리위원회가 아니라 SK라는 것에 새삼 놀라울 따름이다. 더더욱 놀란 것은 이러한 검열(?)때문에 설치형 블로그로 옮긴다는 말도 안 되는 포스팅이 눈에 띄였다. 거참... 대단하다. 설치형 블로그 쓰면, 정보통신윤리위원회에 안 걸려들 것 같은가? 아무리 포털 블로그를 쓰지 않는다고 해서 정보통신윤리위원회가 적용하고 있는 법률을 피해가긴 어려울 것이다. 왜? 서버가 우리나라에 있으니깐. orz... 차라리 구글의 Blogger.com이나 MS의 MySpace 같은 곳으로 옮기겠다고 하는게 옳지 않을까? 덧글: 그나마 포털에 있는 블로그니까 이런 식으로 경고에 끝나는게 아닐까? 설치형블로그로 갔을 경우에는 호스팅 업체에 직접 압박이 가해지거나, 정보통신윤리위원회(또는 검경찰)를 직접상대해야할 것 같은데... 결론: 19禁 영상은 감추는게 맞고, 욕설이 뭐 어떠냐... 영화에도 다 나오는데... 관련법규 개정하라고 압력 넣는게 옳다! 결론2: 레진, 지못미 ▶◀ 결론3: 그냥 해외 포털로 옮겨라. Powered by ScribeFire . 원본 위치: http://purewell.egloos.com/3505932

따쉭 폼잡기는... 한 주먹도 안 되는군. 자매품 -_- 세스 아깽들... (참고로 가운데 뒤집어진 녀석이 오드 아이인데 불쌍하게도 돼지풀(가칭) 운영자 사악드르(가칭)에게 팔려갔다.) 원본 위치: http://purewell.egloos.com/3505117

Linux에서 잘 써먹고 있는 파일처럼 쓸 수 있는 shared memory interface인 shm_open. 이게 표준안(POSIX.1)에 있길래 아무런 의심 없이 잘 썼지. 그런데 아쉽게도 FreeBSD에서 이 녀석은 단순히 open을 wrapping한 것일뿐. 즉, 그냥 일반 파일을 조작하는 것에 불과하다는 것이지. 현재 FreeBSD 6.2가 나왔지만 FreeBSD에서 제공하는 man page 에는 아직도 래핑함수라는 걸 명시하고 있네. In the FreeBSD implementation, POSIX shared memory objects are implemented as ordinary files.  The shm_open() and shm_unlink() act as wrappers around the open(2) and unlink(2) routines, and path, flags, and mode arguments are as specified for those functions.  The flags argument is checked to ensure that the access mode specified is not O_WRONLY (which is not defined for shared memory objects). 에구구... 안타까워라. 실제로도 FreeBSD에서 shm_open하면 실행한 디렉토리에 바로 파일이 만들어지네... Powered by ScribeFire . 원본 위치: http://purewell.egloos.com/3502714