개발자를 넘어 과학자로!!

if문에서 처리하는 명령어 하나 else문에서 처리하는 명령어가 하나일때 이걸 하나의 문장으로 줄여서 처리할수 있다. c; a = 10 b = 20 if ( a > b ) c = a else c = b 위 조건식을 한줄로 표현하면 다음과 같다. c = ( a < b ) ? a : b 사용법만 안다면 이렇게 사용하는것도 나쁘지 않은것 같다.

보통의 경우 파일을 처리할때 open보다는 fopen을 사용한다. O_CREAT니 O_RDWR과 같은 옵션을 외우느니 그런 옵션이 내장되어 있어서 사용하기 편한 fopen을 사용한다. 습관의 차이일수도 있다.(보통은 open보다는 fopen을 먼저 접한다 ) 그런데 가끔은 open을 사용해야하는 경우도 있다. 파일을 빈번히 열고 닫을 경우 fopen보다는 open이 속도가 빠르기 때문이다. 정말로 그런지 테스트를 한번 해보았다. 첫번째 파일은 test_open.c로 open, close만 10,000,000번 한다. 두번째 파일은 test_fopen.c는 fopen, fclose만 10,000,000번 한다. 테스트는 test_open한번 실행하고 test_fopen실행하는 식으로 총 5번 시간을 측정했..

프로그램에서 특정 변수가 char형으로 사용했다가 특정 컴파일 조건에서는 unsigned short 형으로 동작을 한다. 그래서 이 변수가 사용되는 함수에서는 void *로 변수를 받아서 형변환을 해서 사용한다. 그런데 생각했던 것과 다른 값이 나오는 경우가 있었다. unsigned short 형으로 데이터가 동작할때 void 포인터로 받아서 포인터 값을 1만큼 증가시켜 다음 데이터 값을 가리키도록 해야 하는데 이것이 생각했던 것과는 다른게 동작을 한다. 쉽게 코드로 하면 ((unsigned short*)p)++; 이런식으로 하면 p가 +2( unsigned short 의 크기 )만큼 증가하기를 기대했는데 컴파일은 되는데 "use of cast expression!s as lvalues is deprec..

32비트 머신에서는 warning 없이 잘 컴파일 되던 것이 64비트 머신으로 갔더니 cast from pointer to integer of different size 이런 메세지가 뜬다.. unsigned short int* 형을 unsigned int형으로 바꾸는 부분에서 발생한 warning인데 sizeof로 확인해보니 unsigned short int*가 64비트에서는 8byte 자료형이고, unsigned int는 4byte 자료형이라서 발생하는 문제였다. 그래서 unsigned int를 unsigned long int로 수정했더니 warning이 사라졌다.

64 비트 머신에서 달라지는 변수의 크기 char : 1byte short : 2byte int : 4byte long int : 8byte ( 32 bit 머신에서는 4byte ) float : 4byte double : 8byte unsigned long : 8byte ( 32 bit 머신에서는 4byte ) 모든 포인터 : 8byte(2^64) ( 32 bit 머신에서는 모든 포인터 4byte(2^32) ) 32비트 머신일때와 64비트 머신일때 각각 컴파일 하기 위해 명시적으로 64비트 머신에서 컴파일 하기 : gcc -m64 -g -o test test.c 명시적으로 32비트 머신에서 컴파일 하기 : gcc -m32 -g -o test test.c

무얼 하든 상 받을 정도로 열심히… 땀방울이 스펙(영어·학점 등 조건)을 눌렀다 "우리 학교에 영어 토익 점수는 700점대밖에 안 되는데도 은행을 비롯해 대기업 여러 곳에 동시 합격을 한 선배가 있습니다." 본지의 '대학생취업자문단'으로 활동하는 전북대 이동현(경영학과 4)씨의 제보를 받고 수소문을 했다. 소문의 주인공은 지난 2월부터 인천 고잔동의 기업은행 남동중앙지점에서 막 수습행원(5급) 생활을 시작한 김재영(27)씨였다. 김씨는 지방대(전북대 무역학과 03학번) 출신으로 입사지원서에 토익 점수 제출도 안 했지만 취업 한파가 무색하게도 대학 졸업도 하기 전에 기업은행을 포함, 삼성증권·LG파워콤 등 5개 대기업에 동시 합격했다. 합격한 5곳을 놓고 행복한 고민을 하다가 '인간적인 분위기'에 끌려 기..

작은 차이가 명품을 만든다. 문제는 작은 차이를 만드는 것이 큰 차이를 만드는 것보다 힘들다는 점이다. 기업의 말단조직, 보이지 않는 부분을 바꿔야 하는 디테일 경영은 말처럼 쉽지 않다. 기업문화와 조직수준이 높아야 디테일을 완성할 수 있다. 글로벌 기업 중에서도 톱 기업에서만 그 사례를 찾을 수 있는 것도 이 때문이다. 하지만 디테일이 갖춰지면 강력한 무기가 된다. 이제 모든 휴대전화의 표준이 된 ‘통화(send)’버튼과 ‘종료(power)’버튼이 위에 있는 자판 배열은 사실 1998년부터 시작됐다. 그전에 모든 휴대전화는 이 두 버튼이 자판의 맨 아래 양쪽에 배치돼 있었다. 버튼 하나만 위로 올렸을 뿐인 이 사소한 변화는 휴대전화 사용자들의 숨은 욕구를 간파한 것이다. 그리고 그 변화를 만든 사람은 ..

[지디넷코리아]IT조직에게 ‘장애’는 두려운 존재다. 장애가 발생하는 경우 IT조직의 무능함을 질타하는 사용자 측의 비난을 만나게 된다. 들 불처럼 일어나는 장애에 대한 관심도 IT조직의 입장에서 부담스럽다. 그런데 이렇게 두려운 장애임에도 불구하고, 장애에 대응하는 일부 IT조직의 접근법은 나이브(naïve)하기 그지없다. 이들 IT조직들은 장애의 직접적인 발생원인을 찾아내는 데에만 집중할 뿐, 장애가 발생하게 된 다양한 원인들을 찾아내는 활동은 게을리하고 있다. 장애에 대한 단순한 대응은, 유사한 원인으로 인한 장애의 재발을 막을 수가 없다. 단순한 장애 대응으로 IT장애를 반복하고 있는 IT조직에 대해서 이야기 해보겠다. ■ 장애 대응의 사례 A회사 IT조직의 장애 기록을 검토하면서 발견한 장애 대..

LG전자는 지난달 초 ‘ERM(Enterprise Risk Management)’ 태스크포스(TF)라는 조직을 신설했다. 상무급을 팀장으로 15명 정도로 구성한 이 팀의 목표는 세계 사업장에서 발생할 경영 위험을 사전에 예측하고 이를 최소화하는 표준 업무 프로세스를 만드는 것이다. LG전자는 ‘별동부대’ 천지다. 지난 2월 말 이후 본사와 사업본부에 크고 작은 TF가 잇따라 생겼다. 내부도 정확한 팀 수를 파악하기 힘들 정도로 많다. LG전자 관계자는 “대략 오는 6월까지 만들어지는 TF를 따지면 500개 정도”라고 말했다. 본부마다 80∼90개 팀을 만드는 셈이다. 참여 인력만 4000명 정도다. 2만여 명 직원 중 20%다. 팀장도 차장부터 임원까지 다양하다. 규모도 5∼6명 수준부터 20명까지 있다..

strchr() 두 가지 버전이 있다. const char * strchr ( const char * str, int character ); char * strchr ( char * str, int character );VC++ 2005에서 char* isDigit(char _nextChar) { return strchr("0123456789", _nextChar); } 이렇게 하면 아래와 같이 에러가 난다. error C2440: 'return' : 'const char *'에서 'char *'(으)로 변환할 수 없습니다. 그러면 두 가지 방법이 있다. 하나는 isDigit() 함수의 리턴형을 const char*로 바꿔주던가(위에 첫번째 프로토타입처럼) 아니면 아래와 같이 하는 방법이 있다.(위에 두..