|
http://www.patentmaps.org/pub/nap/nn-src/ 인터넷에서 찾은 ANN (Artificial Neural Network) 에 관한 괜찮은 자료이다. ( 오래된 내용이긴 해도 reference 로는 괜찮은 듯.. ) 왜 국내 웹사이트 중에는 이렇게 소스코드 레벨로 제공되는 좋은 자료들을 찾아보기 힘들까는 생각을 잠시 해 보면서.. 신경망에 대해 처음 접했을때는 많은 매력을 느꼈다. 그런데 최근에는 출판되는 책이나 논문 동향을 봐도 그렇고, 1990 년대까지 한창 신경망 연구에 대한 붐이 일다가 2000 년 이후로는 신경망에 대한 연구가 좀 활기를 잃은 느낌을 받는다. 인공지능 박사 과정에 있는 친구도 신경망에 대한 전망을 어둡게 얘기하곤 했다. 일단 내가 느껴 본 바로는 신경망의 단점들이 몇가지가 있는데, 그중에서도 가장 큰 게 느껴지는 것은 구성된 신경망 내부 구조에 대해서는 디테일하게 내부 파악이 어렵다는 점이다. 이는 디버깅이 어렵다는 말과도 동일하다. 처음 신경망 구성 알고리즘을 설계하고 나면 이 알고리즘으로 생성되는 신경망의 결과는 실험을 통해서만 검증할 수 있다. 혹자는 이를 가르켜 "논리의 부재" 라고 설명하기도 하는데, 주어진 입력에 대해서 신경망 학습을 통해 원하는 결과에 가깝게 출력하도록 훈련 시킬수는 있지만 근본적으로 이 입력에서 왜 이런 결과가 나오는지의 논리에 대한 설명은 신경망이 갖고 있지 않다는 것이다. 또 하나는 신경망을 구성하기 위한 학습을 하는데 과도한 시간이 걸리며, 더 큰 문제는 학습이 끝나는데 ( 학습이 끝난다는 것은 최적화 된 신경망 구성이 완료된다는 의미로 말할 수 있겠다) 시간이 얼마나 걸릴지 알 수 없다는 점이다. 경험한 바로는 신경망 구성을 위한 학습에 시간이 무지막지하게 소요되고, 어느정도 만족한 결과가 나온 시점에서 이 상태보다 더 나은 결과가 나오는데 과연 얼마나 더 많은 학습이 필요한지 ( 혹은 현 시점의 신경망 구성 알고리즘으로는 더이상 개선된 결과가 나오지 않을 수도 있다. 이는 결국 실험을 통해서 재검증 할 수 밖에 없다 ) 사전에 알 수 없다는 문제가 있다. 그래서 최근 연구들을 보면 기존 신경망의 단점을 개선하는 방향에 대한 연구가 많이 진행되고 있는데 읽어본 내용 중에는 신경망 학습에 소요되는 시간을 줄이기 위해서 분산처리 시스템을 활용한다든지, Generic Algorithm 을 적용하는 등의 방법등이 있었다. 'IT Story > etc' 카테고리의 다른 글
|
BLOG ARTICLE IT Story | 59 ARTICLE FOUND
- 2010/01/28 Neural Networks Source Code + 단상
- 2010/01/25 [사용후기] 다나와 표준PC 200912 - 120 만원대 익스트림 (2)
- 2010/01/11 Visual Studio 2005 에서 SP1 을 설치했을 때의 개선사항 (2)
- 2009/12/29 C++ 에서 간단하게 OLE DB 사용하기 (ODBC vs OLEDB) (2)
- 2009/12/27 네트워크 서버를 만들던 중 몇가지 생각들. (4)
- 2009/11/23 티맥스소프트 구조조정
- 2009/11/17 IT 위기론 (3)
- 2009/11/02 C++ 과 C# 의 차이 (6)
- 2009/10/23 어제 부터 오늘 오전에 걸쳐 한 삽질. (2)
- 2009/10/06 Outlook 2003 의 pst 용량 제한...
- 2009/08/02 SW Algorithm 강의 - 문병로 교수님 (4)
- 2009/07/27 SW 개발자의 희생을 요구하는 문화는 바뀌어야 한다 (2)
- 2009/07/20 크라우드 소싱(Crowdsourcing)
- 2009/05/18 Visual Studio LNK 4222 경고 - exported symbol 'symbol' should not be assigned an ordinal
- 2009/03/25 Visual Studio 에서 재미있는 delete 현상 (4)
- 2009/03/18 디버그 사례 - Visual Studio 6.0 에서 close() 함수 사용시 (2)
- 2009/03/11 [사용후기] 아이리버 Dicple D30c 2Gb (2)
- 2009/03/09 Windows 의 긴 파일명, 폴더명 오류 (MAX_PATH 경계값 관련) (2)
- 2009/02/23 Visual C++ 6.0 에서 유니코드 사용하기 (2)
- 2009/02/09 fwrite 와 fprintf 의 차이점 (8)
|
2005 년 Pentium 3.0GHz + 보드 를 교체 한 이래 만 4 년이 넘게 이 PC 로 버티다가... 이젠 너무 PC 가 느리다는 것을 체감하면서 PC 를 교체하기로 맘 먹었다. 성능 안좋은 장비로 일하는 것 만큼 효율이 떨어지는 짓도 없다. 꽤나 오랫동안 이것 저것 벤치마킹을 하다가 이번 연말에 과감하게 질렀다. 한동안 계속 직접 조립을 했었는데... 조립하는데 드는 번거로움 + 가끔 골치를 썩이는 부품간의 호환성 문제 등등으로 인해 이제 더이상 직접 조립하는 삽질은 하지 말자고 생각하고.. 이것 저것 알아보다가 다나와에서 표준 PC 로 판매하는 제품을 구입했다. 원래 염두에 두고 있었던 것은 이번에는 베어본을 한번 써 보자~~ 하고 생각하고.. 계속 보던 제품은 바로 Shuttle SX58H7 이다. 그런데 가격대 성능비가 너무 안좋고.. 어차피 외관보다는 성능 우선으로 가는 것이 맞는 듯 하여.. 조립 PC 로 결정했다. 다나와 표준 PC 를 써보니... 장점 - 다양한 가격대의 제품 라인업을 갖추고 있어 선택의 폭이 넓다. - 가격도 조립 PC 치고는 괜찮은 편이고, 가격대비 성능도 따져보면 쓸만하다. - A/S 가 확실하다고 광고하고 있는데 이건 내가 아직 경험해 보지 못했으므로 패스... 단점 - 가끔 이상한 부품으로 제품 구성을 하는 경우가 있다. 예를 들면 2009년 11월 표준 PC 제품군에 사용된 메모리는 많이들 쓰는 삼성이 아닌 이케이(EKMEMORY) 라는 첨 들어보는 업체의 메모리가 사용되었는데 이게 불량률 때문에 이슈가 좀 되었던 것 같다. - 라인업이 다양하다고는 해도 사실 완벽하게 자기 입맛대로 조립하기는 어렵다.. 그래서 어느정도 적절하게 타협을 해야 했다. 이런 류의 조립 PC 구매시에 주의할 점이, 업체에서 부품 품절을 이유로 갑작스럽게 다른 싸구려 부품을 대신 끼워넣어서 판매하는 장난을 치는 경우가 종종 있어서 주의해야 한다. 나 역시 주문하고 나니 파워 서플라이가 품절이라는 연락이 왔는데, 좀 찾아보니 원래 넣기로 한 부품과 동급에 가격도 비슷한 제품이길래 그냥 ok 했다. 그리고 한달이 지난 지금까지 일단 잘 쓰고 있다. 다나와 12월 표준PC 상세 스펙 http://blog.danawa.com/prod/?blogSection=2&cate_c1=860&cate_c2=865&cate_c3=1141&cate_c4=0&depth=3&prod_c=978188 위의 스펙에서 그래픽 카드는 GTS 250 이 아닌 GTX 260 이었고 ( 초기에는 260 으로 판매하다가 중순 이후로 250 으로 바뀌면서 가격을 좀 내린 모양이다 ) 파워는 히로이치 500WP 대신 ToPower 500W 으로 왔다. 써본 후에 소감... 1. 일단 조립이 깔끔하지 못한 상태로 왔다. 부팅이 안되길래 확인해 보니 그래픽 카드가 제대로 보드에 꽂혀있지 않아서 나사를 풀고 다시 제대로 꽂았다. 배송 중에 충격으로 그럴 수도 있겠지만 아무래도 이 가능성은 낮아 보인다. PC 는 OS 도 안깔린 상태로 배송되는데, 제대로 OS 는 설치해서 잘 돌아가는지 테스트는 해 보고 출하한 것인지 조금 의심이 든다. 2. 확장이 생각보다 불편했다. 파워 서플라이의 하드디스크 파워 케이블이 총 3개 밖에 없어서 하드디스크는 3개 뿐이 쓸수 없었는데, 그것도 길이가 좀 짧아서 CD-ROM 위치를 변경하는 대공사 끝에 겨우 하드디스크 2개를 추가로 다는 공사를 마무리 지을 수 있었다. - 케이스를 뜯은 내부 모습 - 하드디스크를 넣는 브라켓은 위와 같이 배기 프로펠러와 연결된 형태로 되어 있어서, 하드디스크를 탈착하려면 저거 전체를 분리해야 하는 구조이다. 좀 불편하다. 3. 위의 문제들 외에는, 현재 한달이 넘게 아주 잘 쓰고 있다. 앞으로 몇년간은 이걸로 쾌적하게 사용할 듯.. 'IT Story > etc' 카테고리의 다른 글
|
|
Visual Studio 2005 에서 서비스 팩 1 (SP1) 을 설치할 경우 몹시 불편하던 점 2 가지가 개선된다. 1. "찾기" 기능에서 찾기 범위로 "전체 솔루션" 이 추가된다. 여러 프로젝트가 붙어있는 솔루션 환경에서 개발할때 매우 유용하다. 참고로, Visual Studio 2008 에서는 기본적으로 제공하고 있는 기능이다. 영문판의 경우 "Entire Solution" 이라고 표기된다. 2. SourceSafe 에서 수정사항이 발생하면 자동으로 "편집하기 위해 체크아웃" 상태가 된다. 이것도 매우 편리하다. 이 기능이 없으면 매번 수동으로 체크아웃을 해줘야 하기 떄문이당. 이 걸 제대로 안해주면 다른 개발PC 에서 개발한 내용이 제대로 반영이 안되는 형상관리가 제대로 안되는 문제가 생길 수 있다. ps ) 참고로 Windows 7 에서 Visual Studio 2005 를 사용하려면 무조건 SP1 을 설치해야 한다. 그냥 Visual Studio 2005 만 설치한 상태로 쓰려고 하면 호환성 오류가 나서 실행이 안됨... 'IT Story > etc' 카테고리의 다른 글
|
|
프로그래밍을 할때 가끔 DBMS 에 연결해서 무언가 CRUD 작업을 하는 경우가 생긴다. 보통 이럴 때는 ODBC 혹은 OLEDB 를 사용한다. ODBC 를 쓰는 경우 해당 장비에 ODBC 설정을 해 줘야 하는데 이 작업이 매우 귀찮기 때문에... ; (물론 코드 레벨에서도 제어가 가능하기는 하다... ) 개인적으로는 OLEDB 사용을 선호한다. OLEDB 사용 방법과 관련해서 쉬운 링크 간단하게 OLEDB 사용하기 ODBC 와 OLE 의 차이점 ODBC 는 Open Data Base Connectivity 라 하여, 데이터 소스에 연결하는 방법을 제공하는 표준 API 를 말한다. DB 에 접근하기 위해서는 DSN 을 이용한 SQL driver 혹은 기타 다른 driver 같은 것을 설치해야 한다. 대부분의 DBMS 들은 ODBC 를 지원한다. OLE 는 Object Linking and Embedding 의 약어로서, OLEDB 는 흔히들 "automation"(자동화) 라고 말하는 OLE 와는 구분된다. OLEDB 는 MS 에서 제공하는, ODBC 를 계승한 기술로서 VB 나 C++ 기반의 GUI 를 제공하는 "front end" 와 SQL Server, DB2, mySQL 등과 연결하는 "back end" 의 두 컴포넌트로 구성되어 있다. OLEDB 는 많은 경우 ODBC 보다 좋은 성능을 보여준다. OLEDB 는 DSN driver 등을 설치할 필요가 없으며, VB 어플리케이션 개발에서 많이 이용되며 ADO 와 유사하다. 또한 SQL 7.0 에서 COM, DCOM 과 함께 동작한다. 원문 'IT Story > etc' 카테고리의 다른 글
|
|
최근에 네트워크 서버를 개발하면서, 이에 따른 멀티스레드 구현을 하면서 몇가지 정리~ 1 대의 서버가 N 개의 클라이언트들을 상대로 서비스를 하다보니 결국 멀티스레드로 구현하게 되었다. 네트워크 프로그래밍을 함에 있어서 스레드 사용은 필수라는 생각이 든다. 멀티 스레드에서 조심할 것은 하나의 자원에 대해서 여러개의 스레드가 동시에 접근하지 못하도록 제한을 걸어야 하는 것이다. 하나의 자원에 대해 두개 이상의 스레드가 동시에 접근할때 바로 OS 시간에 배웠던 Race Condition 상태가 발생할 수 있는 것인데, 보통 이를 해결하기 위해서 Mutex, Critical Section ( Critical Section 을 우리나라 말로는 "임계 영역" 이라고 하고, 일본에서는 "위험역(危險域) 이라고 한다는군), Semaphore 등을 사용 한다. Mutex 와 Critical Section 의 차이는 서로 다른 프로세스 간의 동기화도 지원하는 Mutex 와 달리 Critical Section 은 하나의 프로세스 내에서만 사용할 수 있다는 점이다. 그래서 보통 Mutex 는 프로그램의 중복 실행을 방지하는 용도로 많이 쓴다. Semaphore 는 뮤텍스와 비슷한데, 접근 가능한 스레드의 갯수를 지정할 수 있다는 점이 다르다. 외부에서 사용되는 변수를 스레드 내에서 변경하는 행위 등도 상당히 조심해야 한다. 특히 이 변수들이 스레드 외부 다른 곳에서 수정이 발생하는 경우 값이 꼬일 가능성이 커지므로 주의해야 한다. 이런 실수를 종종 하게 되는 이유는 스레드가 생성되는 순간부터 메인 프로세스 외에 스레드 함수가 병렬적으로 실행되고 있다는 것을 늘 머리속에 염두를 해 두어야 하는데, 사실 인간의 직관이 병렬 처리라는 개념으로 코딩하는게 쉽지 않기 때문이다. 서버와 클라이언트가 연결을 맺고 파일 전송과 같은 sequential 한 작업을 진행하는 도중에는 이 작업의 atomicity( DB 에서 트랜젝션 처리등에서 말하는 "원자성" 이다 ) 를 보존해 주는 처리가 있어야 한다. 예를 들면 파일 전송이 끝나지 않은 상태에서 또다른 파일을 열어서 같은 소켓으로 전송을 시도하려고 하는 경우등에 에러가 발생할 소지가 있을 수 있다. 여러 스레드가 동시에 파일을 읽는 경우, 동시에 파일을 쓰는 경우 등에 대해서도 잘 고려해 봐야 한다. 여기에 대해서는 친구가 좋은 팁을 알려줬는데, 일단 메모리상에 파일 버퍼에서 파일들을 저장해 놓고 있다가 큐에 일정 용량이 쌓이거나 일정 주기가 되면 그때마다 file write 를 하라는 것이다. client 가 주는대로 서버에서 그때마다 스레드 생성해서 각각이 file open 해서 파일을 쓰는 경우 상당히 퍼포먼스 측면에서 부담이 커진다. 그런데 현재 테스트 해 본 바로는 파일 크기가 그리 크지 않은 경우 ( 수백 kb 정도 ) 에서는 동시에 여러개 ( n < 10 ) 의 스레드로 파일 쓰기를 반복 시도 하여도 체감상 느껴지는 부하는 없었다. 지금은 최대한 심플하게 만들기 위해서 간단하게 비동기 소켓으로 만들고 있지만 보통 이렇게 다중으로 file write 를 해야 하는 경우 IOCP 를 많이 쓰는 것 같다. 이쪽은 나중에 시간나면 더 찾아봐야 겠다. 어쨌든 네트워크 프로그래밍은 어렵다. 일단 개발 및 테스트를 위해 장비가 최소 2 ~ n 개가 준비되어야 하고, 네트워크가 일시적으로 단절되는 경우 등 통신 상에서 필요한 여러가지 예외처리를 해 줘야 하는 부분들이 있다. 역시 많은 노하우가 필요하다고 생각된다. 'IT Story > etc' 카테고리의 다른 글
|
-
Hyperdash
2009/12/28 10:22
댓글주소
수정/삭제
댓글쓰기
서버에서 파일 쓰기를 할 경우에는 락을 거는것과 동일한 효과이기 때문에
정확한 성능 테스트를 해보려면 테스트 클라이언트 천개정도 붙여서 지속적인 파일 쓰기 요청을 해본후
응답시간이 어느정도인지 확인하는 것이 좋을 듯하다. 같은 네트워크에서 20ms 가 넘어간다면 딜레이가 발생한다는 뜻... -
김훈동 2009/12/30 15:12 댓글주소 수정/삭제 댓글쓰기
나 병특할때 그러니까 2000년대 초 쯤에는 , IOCP 니 Overlapped IO 니 그런걸로다 대용량 네트워크 서버를 많이 만들곤 했던 기억이 있당…
2003년 이후부터는 ACE 프레임워크 같은걸 많이 썼었지.... 대용량 서버를 직접 만들고 최적화 하는 곳은 일부 게임회사등을 제외하고는 많지 않았던 듯.... windows nt 계열 서버를 쓰는 데는 거의 IOCP 를 많이 썻고, 유닉스 나 리눅스 쓰는 데는 게임회사들도 ACE 를 많이 썼었는데.. 그러다가 ACE 가 운영체제마다 최적화된 메커니즘이 아닌지라 ASIO 라는 프레임워크로 또 나중엔 대세가 넘어가는거 같기도 했고.(요즘유행은 잘 모르겠음. 게임업계를 떠난지가 언 5년이 다되가니..) ASIO 는 ACE 와 달리 운영체제마다 최적화된 메커니즘으로 되어 있어서 windows nt 계열에서는 IOCP 를 쓴다더군... ASIO 는 안써봤지만.. ACE 를 쓰면서 느낀점은....역시.... 공부해가면서 내가 직접 짜는 것 보다는 검증된 Open 소스도 잘쓰면 업계 평균 이상은 된다는 것...
나같은 경우는 회사에선 걍 WCF 나 웹서비스로다가 몇줄만에 IOCP 로 하던 코딩을 끝네고 대용량 다중 접속 처리를 웹서버에다가 떠넘기고 있지만.... (WCF 가 좋은 점은 웹서비스로 가면 독립 어플리케이션은 양방향 통신에서 자체가 웹서버 역할은 못하니까 클라이언트 역할 밖에 못하는데.... WCF 는 웹서버 없는 클라이언트가 자체적으로도 웹서버 처럼 웹서비스 호스팅 기능을 가지고 있다는 것...)
3년여 전부터 금융권에 몸담으면서 네트워크 코딩이 극명하게 두가지로 나뉘었는데..한가지는 편하면서 범용적으로 코딩하는 경우와 또 한가지는 실시간 계좌이체 처럼 속도와 안정성이 대단히 민감한경우... 전자는 자바등 레거시와의 연동이슈 때문에 최근 1~2년 사이에는 소켓통신 거의 안쓰고 SOAP 이나 REST, JSON 같은거 쓰고 있고.. 후자는 Tmax 나 Tuxedo 등 상용 미들웨어를 쓴다는점... 게임업계처럼 오픈소스나 자체 제작을 안해서 요즘은 IOCP 구경 할 일이 거의 없어서 IOCP 는 아련한 기억으로만 남아있당…
|
티맥스 소프트. 지난 7월에,그러니까 불과 몇달 전에 OS 와 Office 제작발표회를 하면서 엄청난 이슈를 불러 일으켰는데... 그러고보니 내 블로그에도 관련 글을 하나 올렸었군 누적된 적자와 사업부진으로 인해 최근 500 명에 달하는 인력(언론에 보도된 내용으로는 200 명) 을 구조조정한다고 한다. 올해 11월에 출시하겠다던 티맥스 윈도우의 출시도 내년으로 미뤄졌고... 향후 티맥스의 행보를 지켜보자. 구조조정 칼바람, 티맥스 운명은? 구글 크롬OS 와 티맥스윈도 티맥스의 안타까운 행보들 ps1) 개인적으로 티맥스소프트의 박대연 회장은 정말 대단한 분이고, 그가 걸었던 길을 보면 진짜 존경할만한 사람이라고 생각한다. 다만 "무조건 열심히 하면 된다" 는 식의 열정만으로 모든 게 해결될 수 있다고 너무 믿은 것은 아닌지... [인물포커스] 웹통합미들웨어개발 박대연 KAIST 교수 위키피디아 - 박대연 'IT Story > Gossip' 카테고리의 다른 글
|
|
IT 업계가 어렵다는 위기설이 주위에서 모락모락 들리는데... 이를 반영하는 factor 중 하나가 국내 대학들의 전산과(컴퓨터공학과) 의 커트라인이 매년 조금씩 낮아지고 있다는 것. 참고 : 2009 정시 대학 배치표 보기 ( 가, 나, 다 군 별로 선택해서 봐야 함 ) 화학/생명/생물 공학 관련 전공이 요새 뜨는 이유는 의학전문대학원 때문이라는군... ps ) 수능 끝난지 얼마 안되서 쉽게 찾을 수 있을 줄 알았는데, 의외로 무료로 볼수 있는 대학 배치표를 찾기 힘들어서 한참 찾았다. 입시 학원에서 입시생을 상대로 배치표를 2-3 만원씩 돈받고 파는 수익도 쏠쏠할듯... 펌글 IT 업계 종사 7년만에 상당한 위기를 느낍니다. 'IT Story > Gossip' 카테고리의 다른 글
|
|
앞으로 공적으로는 C++ 을 쓰고, 사적으로는 C# 으로 쓰기로 마음먹었다. C# 자체도 좋은 언어이지만, WCF, WPF, Silverlight, ASP.Net 사용도 고려해 볼때 꼭 익혀놓아야 하는 언어임은 틀림없다. C# 을 쓰면서 느끼는 C++ 과의 차이점들을 정리해 놓고자 한다. 1. Windows Application 개발 환경의 차이. C# 의 개발 환경은 전통적인 Visual C++ 보다는 Visual Basic 에 가깝다. 폼을 디자인하고, 이 폼을 동작하는 코드를 별도로 코딩하는 환경은 보다 RAD 를 지향하고 개발생산성을 중시한 C# 의 철학을 잘 보여준다. 또한 윈도우즈 어플 개발시 Visual C++ 에서 나눠져 있던 SDI, MDI, Dialog Based 구분이 없어지고 C# 에서는 Windows Forms 이라는 하나의 형태로만 존재한다. ( 도구상자에 MDI Parent 라는 컨트롤이 존재하는 것은 확인했다. ) 2. 보다 강력해진 Intellisense Visual C# 의 Intellisense 는 정말 강력하다. 예약어로 정의된 키워드들과, 라이브러리에 이미 정의된 멤버들이 팝업으로 표시되는 것은 물론이고, 심지어 개발자가 정의한 변수/함수 들도 인텔리센스에서 나타난다. 이걸 처음에 보고 얼마나 감동받았는지 ㅜ.ㅜ 덕분에 코딩 시간이 많이 단축된다. 여담이지만, TopCoder 를 할 때 C++ 개발자들은 조금이라도 코딩을 빨리 하기 위해서 자주 사용하는 긴 문장들은 매크로를 즐겨 쓴다. 예 ) #define FOR(i,a,b) for(int i = (a); i < (b); ++i) #define REP(i,n) FOR(i,0,n) 그런데 C# 에서는 굳이 저릴 필요가 없다. 인텔리센스가 잘 받쳐주고 있으니까... 사실, 인텔리센스는 언어의 기능이 아니라 툴의 기능이므로, 이런 강력한 인텔리 센스는 Visual C++ 에도 충분히 도입할 수 있다고 보여지는데... C# 과 C++ 에 차이를 둔 것은 결국 정책적으로 MS 가 C# 을 밀고 있다는 이야기만 확인시켜주는 셈이다... 그리고 여담. 나는 ret 이란 변수를 즐겨 쓰는데 이걸 쓰다보면 인텔리센스가 return 으로 자꾸 인식해서 좀 불편하다. 3. C# 은 더욱 더 강력하게 객체지향적이다. 자료구조등을 새로 선언할때 class 형으로 만들어서 써야 한다. 4. 자료 구조의 차이 C++ STL 의 List, Vector 대신에 C# 에서는 ArrayList 가 제공된다. C++ STL 의 Map 대신에 C# 에서는 Hashtable 이 제공된다. C++ STL 의 Pair 대신에 C# 에서는 KeyValuePair 가 제공된다. C++ 의 경우 STL 에서 제공하는 자료구조들을 쓰기 위해서 C# 에서는 Collection 을 인클루드 한다. 5. 형변환이 보다 엄격하면서도, 쉬워졌다. 예를 들어 C++ 에서 허용되는 다음과 같은 코드가 C# 에서는 에러가 난다. 반면에 데이터 타입의 변환은 Convert 라는 객체를 통해서 ToString, ToInt16, ToInt32, ToDateTime 과 같이 다양한 형태의 형변환을 메소드로 지원해서 형변환이 아주 쉬워진다. 6. 클래스 멤버들의 public, private, protected 구분이 더 엄격해졌다. C++ 과 달리 C# 에서는 메소드, 변수 마다 붙인다. struct 의 경우 C++ 에서는 별도로 선언을 하지 않아도 암시적으로 모든 멤버가 public 으로 선언된다. 하지만 C# 에서는 struct 를 사용할때 위와 같이 멤버들에 대해서 명시적으로 public 인지 지정해야 한다. 7. C# 은 가비지 콜렉션을 지원하며 C++ 과 달리 new 는 존재하지만 delete 는 없다. C# 에서 객체를 생성할때는 항상 new 로 생성한다. 하지만 C++ 과 달리 delete 를 해줘야 하는 것이 아니라, 가비지 콜렉터가 자동으로 매니지드 힙의 메모리 영역에서 생성된 객체의 메모리를 지워준다. 예를 들어 C# 에서 배열을 선언할 때 아래와 같이 쓴다. int [] dat = new int []; 2차원 배열은 아래와 같이 할당한다. int [,] dat = new int [100,100]; // 다중 배열에서 콤마를 쓰는 이런 방식이 처음엔 상당히 생소했다. new 로 생성하지만 delete 를 하지는 않는다. 명시적으로 프로그래머가 힙 영역에서 데이터를 삭제할 때는 Dispose 명령을 사용한다. 'IT Story > Programming Language' 카테고리의 다른 글
|
-
김훈동 2009/11/13 17:57 댓글주소 수정/삭제 댓글쓰기
2. 에 추가하여... 코드 스니펫 이라는 게 있는데.... 자주 쓰는 긴 코드의 코딩 패턴을 XML 로 정의 해놓고, 거기에 바뀌는 부분만을 tab 으로 옮겨가며 코딩 하는게 있어...
예를 들어 prop 라고 치고 tab 을 두번 눌러봐바.... 자바에서 멤버변수 선언하고 getter , setter 를 쫙 써준 다음에 그걸 하나의 DTO 클래스 혹은 ValueObjce 클래스로 만들어서 객체를 쓰던 방식을 .NET 에서는 프로퍼티 라는 걸로 깔끔하게 선언해 쓰는 것을 권장하고 있는데... prop 텝 2번 눌러서 멤버변수 영역에서 변수를 프로퍼티 로 정의하면 private 변수와 이를 public 으로 노출하는 getter 와 setter 가 한방에
코드 제너레이션이 가능해...
swich 구문이나 foreach 구문 등도 미리 예약된 코드 스니펫 단축명령어가 다 존재하고 혹은 내가 자주 사용하는 코딩 패턴을 코드 스니펫으로 custom 지정도 가능해.... 그리고 custom 코드 스니펫 만들때는 복잡하게 XML 을 일일이 짜줄 필요는 없고.... 코드 스니펫을 자동으로 만들어서 VS 에 연동시켜주는 Free 소프트웨어들이 인터넷에 많이 돌아다녀... 자주쓰는 DB 접속 구문이나 Try Catch 구문, Using 구문, 그리고 특히 프로젝트 표준 주석등을 쓸때 스니펫을 쓰면 딱이쥐... -
김훈동 2009/11/13 18:07 댓글주소 수정/삭제 댓글쓰기
4. 에 추가하여... .NET Generic 도 잘 배워봐...
STL 의 대부분의 기능이 구현되어 있고.. Java Generic 보다 훨씬 빠로고 안정적이야..
아래는 C++ 템플릿과 C# Generic 의 차이를 알려주는 MSDN 의 내용....
[generics 구현]
C++에서 템플릿은 사실 매크로일 뿐이며 컴파일된 이진수로 유지되지 않습니다. 특정 형식의 템플릿 클래스를 사용하지 않으면 컴파일러가 템플릿 코드를 컴파일할 수도 없습니다. 형식을 지정하면 컴파일러가 코드를 인라인에 삽입하여 generic 형식 매개 변수의 모든 항목을 지정된 형식으로 바꿉니다. 템플릿 클래스에서 발생한 컴파일 오류는 템플릿 클래스를 사용할 때만 발견할 수 있습니다. 또한 특정 형식을 사용할 때마다 컴파일러는 사용자가 이미 응용 프로그램의 다른 곳에서 템플릿 클래스에 대해 해당 형식을 지정했는지에 관계없이 형식별 코드를 삽입합니다. 따라서 코드가 비대해져 로드 시간이 길어질 뿐 아니라 메모리 공간도 많이 차지하게 됩니다.
.NET 2.0에서는 generics가 IL(Intermediate Language) 및 CLR 자체를 기본적으로 지원합니다. generic C# 서버 쪽 코드를 컴파일하면 컴파일러가 이를 다른 모든 형식과 마찬가지로 IL로 컴파일합니다. 그러나 IL에는 실제 특정 형식의 매개 변수나 자리 표시자만 들어 있습니다. 또한 generic 서버의 메타데이터에는 generic 정보가 들어 있습니다.
클라이언트 쪽 컴파일러는 해당 generic 메타데이터를 사용하여 형식의 안전성을 지원합니다. 클라이언트가 generic 형식 매개 변수 대신 특정 형식을 제공하는 경우 클라이언트의 컴파일러는 서버 메타데이터에 있는 generic 형식 매개 변수를 지정된 형식으로 대체합니다. 그러면 generics가 전혀 사용되지 않은 것처럼 클라이언트의 컴파일러에 서버의 형식별 정의가 제공됩니다. 이러한 방법으로 클라이언트 컴파일러는 올바른 메서드 매개 변수, 형식 안전성 검사 및 형식별 IntelliSense®도 적용할 수 있습니다.
흥미로운 점은 .NET이 서버의 generic IL을 기계어 코드로 컴파일하는 방식입니다. 사실, 실제로 만들어지는 기계어 코드는 지정된 형식이 값 형식인지 아니면 참조 형식인지에 따라 달라집니다. 클라이언트가 값 형식을 지정하면 JIT 컴파일러가 IL에 있는 generic 형식 매개 변수를 특정 값 형식으로 바꾸고 네이티브 코드로 컴파일합니다. 그러나 JIT 컴파일러는 이미 생성한 형식별 서버 코드를 추적합니다. 이미 기계어 코드로 컴파일한 값 형식을 사용하여 generic 서버를 컴파일하도록 JIT 컴파일러에 지정하는 경우 해당 서버 코드에 대한 참조만 반환됩니다. JIT 컴파일러는 차후의 모든 항목에서 동일한 값 형식별 서버 코드를 사용하므로 코드가 비대해지지 않습니다.
클라이언트가 참조 형식을 지정하면 JIT 컴파일러가 서버 IL에 있는 generic 매개 변수를 개체로 바꾸고 네이티브 코드로 컴파일합니다. 해당 코드는 차후의 모든 참조 형식 요청에서 generic 형식 매개 변수 대신 사용됩니다. 이러한 방법으로 JIT 컴파일러는 실제 코드만 다시 사용합니다. 인스턴스는 여전히 크기에 따라 관리 힙에 할당되며 캐스팅은 없습니다.
[generics 이점]
.NET에서는 generics를 구현할 때 사용한 코드와 작업을 generics를 사용할 때 다시 사용할 수 있습니다. 값 형식을 사용하거나 참조 형식을 사용하거나에 관계없이 코드를 비대하게 만들지 않고도 형식 및 내부 데이터를 변경할 수 있습니다. 코드를 한 번 개발하고 테스트하고 배포한 후에는 모든 컴파일러 지원과 형식 안전성이 보장되는 상태에서 미래의 형식을 포함한 모든 형식에 다시 사용할 수 있습니다. generic 코드를 사용하면 값 형식을 boxing 및 unboxing하거나 참조 형식을 다운 캐스팅하지 않아도 되므로 성능이 크게 향상됩니다. 값 형식을 사용하면 형식에 액세스할 때 일반적으로 성능이 200% 향상되며, 참조 형식을 사용하면 100%의 성능 향상을 기대할 수 있습니다. 물론 전체 응용 프로그램의 성능은 향상될 수도 있고 그렇지 않을 수도 있습니다. 이 기사에서 사용한 소스 코드에는 간단한 루프에서 스택을 실행하는 마이크로 벤치마크 응용 프로그램이 포함되어 있습니다. 이 응용 프로그램을 사용하면 개체 기반 스택과 generic 스택에서 값 형식 및 참조 형식을 사용해 볼 수 있으며 루프 반복의 수를 변경하여 generics가 성능에 미치는 영향을 확인할 수도 있습니다. -
김훈동 2009/11/13 18:13 댓글주소 수정/삭제 댓글쓰기
7. 에 추가하여...
.NET 은 기본적으로 명시적인 delete 는 없는데....
프로젝트를 하다보면 그시점에 명시적으로 delete 를 하고싶을때가 분명 있거든... 그때 쓰는게... using 구문이쥐...
네임스페이스 지정하는 using 문 말고... 아래 같은거 할때 쓰는 using...
파일오픈 객체 소멸을 가비지 컬렉터한테 넘기는 우는 처음 시작하는 .NET 개발자가 자주 범 하는 실수 중 하나쥐...
using (System.IO.StreamReader sr = new System.IO.StreamReader(@"C:\Users\Public\Documents\test.txt"
)
{
string s = null;
while((s = sr.ReadLine()) != null)
{
Console.WriteLine(s);
}
}
|
fopen 을 사용하는 모 프로그램을 구현중인데. foepn 하면 자꾸 파일 포인터가 NULL, 즉 파일을 제대로 못 읽어오는 에러가 계속 뜬다. 분명히 해당 경로에 파일이 존재하는데.. 왜 이럴까... 몇시간 동안 고뇌에 빠져 있었다. 원인은 바로... 최근에 노트북을 포맷해서, 파일 보기 설정이 늘 하던대로 되어 있지 않고 위와 같이 디폴트 설정이었다. 예를 들어 test.txt 파일로 테스트하기 위해 메모장을 열어서 text.txt 를 생성해서 저장해 놨는데 이게 확장자 숨기기 모드라서 사실은 test.txt.txt 파일로 저장되었던 것. 그나마 빨리 발견해서 다행이네... -0-;; 'IT Story > etc' 카테고리의 다른 글
|
|
메일은 꾸준히 아웃룩으로 보관하면서 모아놓는 스타일인데, 드디어 Office 2003 의 Outlook 의 메일파일 (pst 파일) 의 저장 한계에 다다랐다. 20 기가... 예전에 Outlook 97 에서는 pst 파일 당 저장 용량이 2 기가에 불과해서 ( pst 크기 정보 변수가 integer 였나 보다) 몹시 불편했는데, Outlook 2003 으로 버전업 하면서 pst 파일의 2 기가 제한이 풀렸길래 이제는 수십기가 이상도 저장이 가능할 것이라 지레 짐작을 했다. 그래서 첨부파일이 큰 메일들도 별 생각없이 (백업 차원에서) 계속 저장하다 보니 몇년만에 드디어 pst 파일 크기가 20 기가에 도달하면서... 더이상 메일을 다운받아도 메일 다운은 성공하되, 실제 편지함에 받은 메일은 생성이 되지 않는 버그가 나타나기 시작했다. 다행히 서핑을 좀 해보니 쉬운 해결안이 있었다. pst 가 커지면 메일을 적당히 나눠서 "내보내기" 메뉴를 통해서 별도의 pst 로 분리할 수 있다. 그런데 outlook 의 또다른 버그인지 pst 로 옛날 메일들을 분리한 후에 분리한 옛날 메일과 폴더들을 완전히 삭제해도 outlook.pst 파일 크기는 줄어들지 않았다. 그래서 pst 파일 압축하기를 했더니 outlook.pst 파일 크기가 점점 줄어들기 시작한다. pst 가 내부적으로 어떤 자료구조로 되어 있는지는 몰라도 제대로 정리되지 않은 빈공간을 정리해 주는 작업을 하는 듯 하다. 문득 생각난 건데, 32 비트 signed integer 가 표현할 수 있는 2,147,483,647 이라는 제한 때문에 일부 프로그램들은 2 기가 이상의 램을 인식하지 못한다든지, 2 기가 이상의 하드디스크를 인식하지 못하는 문제들이 있는 경우가 있었다. 하드디스크야 요즘은 테라바이트 시대이니 그런 문제를 잘 찾아볼 수 없지만, 아직 2 기가 이상 램을 쓰는 컴퓨터가 그리 많지 않아서인지 2 기가 이상 램을 체크하지 못하는 버그를 가진 프로그램은 주변에서 종종 보곤 한다. ㅋ 'IT Story > etc' 카테고리의 다른 글
|
|
지난 주에 사내 강좌로 3 일간 SW Algorithm 이란 과목을 들었는데, 강사가 서울대학교 문병로 교수님이었다. 듣기로는 요새는 사내 교육에 대한 투자가 늘어서 사내 강의에도 현직 교수님들을 초빙하곤 한다는데... 참 흔치않은 좋은 기회를 잡은 느낌이다. 문병로 교수님은 실제로 뵙는 것은 이번이 처음이었지만 "쉽게 배우는 알고리즘" 이란 교재로 지면을 통해 만나뵌 적이 있었고, 인터넷을 떠도는 "나의 꿈" 이란 글을 읽은 적이 있어서 매우 친근한 느낌이다. 3일이란 짧은 교육시간이지만, 하루 8 시간의 강의니까 일반 학부 강의가 주당 3 시간이라고 하면 대략 시간상 한 학기의 절반 정도는 커버하는 분량이 아닌가 싶다. 이론 위주로만 강의가 진행 되었는데, 강의 시간을 좀더 늘리고 직접 코딩도 해 보는 시간을 가졌으면 더 좋았을 뻔 했다. 그래도 지금까지 들었던 알고리즘 강의들 중에서 가장 훌륭한 강의였다. 가르치는 사람의 지식 수준과 해당 내용의 이해도에 따라서 배우는 사람의 학업성취도에도 차이가 있기 마련인데, 예전에 강의를 들을때는 정확하게 이해하지 못하고 넘어갔거나 평소에 궁금하던 의문점들이 많이 해소가 되어서 무척 의미있는 시간이었다. 그리고 sort 에 대해서도 심도있게 생각해 보는 시간을 가질 수 있었다. sort 는 사실 자료구조나 알고리즘에서 워낙 잘 알려진 주제라서 이미 여러번 책과 강의를 통해서 배워왔던 내용이지만, 이런 새로운 관점에서도 sort 에 대해 생각해 볼 수 있다는 사실이 매우 재미있었다. sort 가 갖는 재귀적 성질, In-Place Sorting, external sorting 의 차이 ( 예전 수업시간을 돌이켜 보면 정렬에 대해서 배울때 항상 이상하게도 이 부분은 스킵하는 경우가 많다 ), 비교정렬이 아닌 O(n) 소트 ( 논문을 통해서 O(n) 소트들에 대해서 읽어본 적은 있었지만 강의를 통해서 새롭게 리뷰를 하니 무척 흥미로웠다. ), Hash table 에서 load factor 와 Rehash 에 대한 상세한 소개. 그리고 반도체 설계에서 저항의 위치를 결정하는 방법에서 Minimum Spanning Tree 를 사용한다는 이야기 등.. ( 이 부분은 교수님이 예전에 LG 전자 반도체 사업부에 근무할 당시의 경험을 토대로 이야기 하시는 것 같다. ) 'IT Story > Gossip' 카테고리의 다른 글
|
-
JM
2009/08/03 07:36
댓글주소
수정/삭제
댓글쓰기
문병로 교수님 랩에서 algo trading 관련 연구를 한다는 이야기은 들어 알고 있는데 자세한 것은 못 들어봤어요. 어떤 얘기 하시던가요? (말하셔도 되나.. ^^

-
soyoja
2009/08/03 14:59
댓글주소
수정/삭제
짧은 시간이기는 했지만, 제가 이해한 내용으로는 기본적 분석 방법을 통해 저평가된 우량 종목들을 선정하고, 이 종목들의 매수/매도 타이밍은 기술적 분석 방법을 활용하는 듯 합니다. 차트상에서 기술적 분석에서 많이 사용하는 패턴 매칭을 통해서 매매 타이밍을 찾는데 10년간의 KOSPI 시장 매매 시뮬레이션 결과 KOSPI 평균 상승률보다 높은 수익률을 올렸다고 하는군요. 구체적인 알고리즘에 대한 설명은 부족해서 아쉬웠습니다. 문교수님 연구실에서 발표한 논문이 있는지 좀 찾아볼 생각입니다... ^^
ps1 ) JM 님도 블로그에 algo trading 글 많이 좀 올려주세요..
ps2 ) 유키님이 그 연구실에 있으니... 물어보시면 자세히 얘기해 주지 않을까용?
-
-
JM
2009/08/15 08:13
댓글주소
수정/삭제
댓글쓰기
음, 그렇군요. 기본적으로 국내외에서 algo trading 은 execution strategy (매매/매도 타이밍과 양 결정 문제) 에 국한된 거 같아요.
포스팅은.. 저도 좀 배워야 하던지 말던지 할거 같네요 -_-;;; 하하
|
ZDNet 에 좋은 칼럼이 올라왔다. [칼럼] SW 개발자의 희생을 요구하는 문화는 바뀌어야 한다 이번 처럼 이렇게 좋은 칼럼도 자주 쓰시곤 한다. 얼마전에 내가 블로그에도 글을 올렸던, 티맥스의 OS 개발 발표회에 대한 글이다. 티맥스에 대해서 지적하고 싶은 세가지 내용을 아주 속 시원하게 잘 언급했다. 특히 이 구절이 매우 마음에 든다.
'IT Story > Gossip' 카테고리의 다른 글
|
|
이전에는 해당 업계의 전문가들이나 내부자들에게만 접근 가능하였던 지식을 공유하고, 제품 혹은 서비스의 개발과정에 비전문가나 외부전문가들의 참여를 개방하고 유도하여 혁신을 이루고자 하는 방법이다. 내부의 전문가나 해당 분야 전문가들은 소유한 자원 및 결과를 공유하고 개방하여 해당 또는 다른 분야 전문가 혹은 일반 대중과 함께 연구 개발을 진행하게 된다. 이를 통해 한정적인 내부의 인적 자원에만 의존하지 않고 많은 외부의 인적 자원의 도움을 받을 수 있으며 또한 외부인은 이러한 참여를 통해 자신들에게 더 나은 제품,서비스를 이용하게 되거나 이익을 공유하는 것도 가능하다 'IT Story > Gossip' 카테고리의 다른 글
|
Visual Studio LNK 4222 경고 - exported symbol 'symbol' should not be assigned an ordinal
IT Story/Programming Language 2009/05/18 11:22|
LNK4222 경고는 주로 Visual Studio 6.0 에서 개발한 dll 을 2003 이상에서 빌드할 때 발생한다. 6.0 에서는 보통 dll 의 def 파일을 다음과 같이 생성한다. 예를 들어 dll 의 TEST.def 파일이 아래와 같이 되어있다면 DllCanUnloadNow @1 PRIVATE DllGetClassObject @2 PRIVATE DllRegisterServer @3 PRIVATE DllUnregisterServer @4 PRIVATE Visual Studio 2003 이상의 컴파일러는 다음과 같은 경고를 발생시킨다. 1>.\TEST.def : warning LNK4222: 내보낸 'DllCanUnloadNow' 기호를 서수로 지정하면 안 됩니다. 1>.\TEST.def : warning LNK4222: 내보낸 'DllGetClassObject' 기호를 서수로 지정하면 안 됩니다. 1>.\TEST.def : warning LNK4222: 내보낸 'DllRegisterServer' 기호를 서수로 지정하면 안 됩니다. 1>.\TEST.def : warning LNK4222: 내보낸 'DllUnregisterServer' 기호를 서수로 지정하면 안 됩니다. ( Visual Studio 영문 버전의 경고 문구는 아래와 같다. ) warning LNK4222: exported symbol 'DllRegisterServer' should not be assigned an ordinal http://msdn.microsoft.com/ko-kr/library/8e705t74(VS.80).aspx 위의 MSDN 을 읽어보면 도움을 얻을 수 있는데, 결과적으로 얘기하자면 6.0 에서 쓰던 것과 같은 서수 표기방식은 아래 함수들에 대해서는 사용하면 안된다. ( 이유 : 기호를 서수로 표기할 경우 실제 사용할 주소 테이블보다 큰 슬롯을 사용할 수 있음 ) 그러므로 아래 함수들에 대해서는 서수 표기방식을 사용해서는 안된다. DllCanUnloadNow DllGetClassObject DllGetClassFactoryFromClassString DllInstall DllRegisterServer DllRegisterServerEx DllUnregisterServer 위의 def 파일 코드는 아래와 같이 고쳐주면 깔끔하게 해결이 된다. DllCanUnloadNow PRIVATE DllGetClassObject PRIVATE DllRegisterServer PRIVATE DllUnregisterServer PRIVATE 'IT Story > Programming Language' 카테고리의 다른 글
|
|
이런 코드가 release 모드에서 정상적으로 실행되는 것도 이상하다. 하다못해 컴파일러가 warning 이라도 띄워주는 것이 맞지 않을까 싶다. 'IT Story > Programming Language' 카테고리의 다른 글
|
|
남이 짜놓은 VS 6 프로젝트를 VS 2005 로 포팅중 다음과 같은 디버그 에러를 발견... 실제로 close.c 함수를 찾아서 따라가 보면 close.c 함수의 47 번째 라인은 아래와 같다. 즉, file 등을 사용한 후에 닫을 때 fd = close() 처럼 리턴 결과를 fd 로 넘기는데, open 에 실패하여 fd 값이 음수인 경우 정상적으로 close 를 시킬 수 없으므로 위와 같이 Assertion Failed 를 내게 되어 있다. 예를 들어서 아래와 같은 코드에서 assertion failed 가 발생할 수 있다. 위의 경우 파일 열기에 실패하여 fd 값이 음수로 오는 경우 6 라인에서 open 도 안했는데 close() 를 호출한 것이 되어 close 함수가 정의되어 있는 close.c 함수에서 Assertion Failed 가 된다. 이런 경우, open 에 성공했을 때만 close 해줘야 하므로 close 함수는 4 라인에 위치해야 한다. 결국, Call Stack 을 열심히 뒤져본 끝에 위와 같이 close() 함수를 잘못 호출하고 있는 부분을 찾은 끝에 디버깅에 성공했다. 재미있는 것은 위와 같은 코드가 VS 6.0 에서는 정상적으로 빌드가 되고 실행이 된다는 것. 이와 같은 잠재적인 버그도 검출하지 못하는 VS 6.0 은 역시 하루빨리 버려야 한다 -0- 참고로 소켓 통신등을 구현할때에도 VS 6.0 에서 문제없이 쓰던 close( sock ) 함수는 closesocket( sock ) 와 같이 closesocket 함수로 바꿔 써줘야 한다. 'IT Story > Programming Language' 카테고리의 다른 글
|
|
'IT Story > Gossip' 카테고리의 다른 글
|
|
윈도우즈 프로그래밍을 하다가 파일 경로나 파일명 관련된 구현을 하다 보면 종종 MAX_PATH 매크로를 자주 사용하게 된다. stdlib.h 에 정의되어 있는 MAX_PATH 는 260 으로 정의되어 있다. 그런데 간혹 착각을 하는 것이, 이 MAX_PATH 가 허용하는 길이는 폴더의 길이 및 파일의 길이이지, 파일명과 폴더명을 포함한 경로를 커버하는 크기는 아니란 것이다. 그러므로 파일명이 포함된 폴더 경로를 나타내는 배열을 아래와 같이 잡으면 경로가 길 경우에 에러가 발생할 소지가 있다. 그리고 윈도우즈에서 확인한 결과 재미있는 버그를 하나 발견할 수 있었다. 파일명을 260 글자 까지 만들 경우 이 이상 파일명을 늘릴 수 없다. 마찬가지로 폴더를 생성한 후에 이 폴더명을 260 자까지 만들 경우 이 이상으로 폴더 명은 늘릴 수 없다. MAX_PATH 에 정의된 크기만큼 생성된 것이다. 이 때, 이 폴더나 파일을 복사나 삭제등을 하려고 하는 경우 파일 탐색기가 런타임 에러 팝업도 없이 그냥 죽어버리는 신기한 버그가 발견된다. (지금 바로 해 보시라.. ㅋㅋ ) 이 외에도 260 글자 길이의 폴더나 파일을 가지고 파일 작업을 할 경우 여러가지 오동작을 일으킨다. 구글을 찾아보니 이 문제는 Windows XP 와 Windows Vista 에서 공히 발견되는 꽤나 유명한 버그였다. http://blog.cumps.be/explorer-bug-long-path-damaged-directories/ 참고 : MSDN 의 Path Limits 'IT Story > Gossip' 카테고리의 다른 글
|
|
IT 산업의 최첨단을 달리는 소프트웨어 개발자들이 오히려 새로운 기술/툴 의 사용에는 둔감한 모습을 보이는 경우를 종종 보곤 하는데, 개인적으로 그 대표적인 예 중 하나로 출시된 지 이미 10 년이 넘은 Visual C++ 6.0 을 아직도 많은 이들이 사용하는 것을 꼽고 싶다. Visual C++ 6.0 은 가볍다는 장점도 있으나, 그에 못지 않게 최신 MFC, STL 지원 미비, 닷넷 기술 사용 불가, VC 6.0 컴파일러의 비표준 코드 생성, VC 6.0 의 컴파일러의 오류, 유니코드 사용의 불편함 등 여러 문제점이 더욱 크다고 생각된다. (VS 6.0 의 문제점에 대해서는 싹 정리해서 따로 포스팅을 해보고 싶다. ) 사실 주변을 둘러보면 개발자가 VC 6.0 을 고집하는 주요 이유로 Visual Studio .Net 이 익숙치 않아서... 가 가장 크지 않을까도 싶다. 어쨌든 Visual C++ 6.0 에서 유니코드를 쓰려다 빌드시 mfc42ud.lib 가 없다는 링크 에러로 한참 고생했다. VS 6.0 설치시 default 로 설치하면 유니코드 관련된 라이브러리는 깔리지 않는다. Custom 설치를 선택해서 위의 "Static Libraries for Unicode", "Shared Libraries for Uniode" 를 선택해서 깔아줘야 한다. 유니코드 프로그래밍이 기본이 되고 있는 요새 이런 불편을 겪게 하다니... VS 6.0 을 하루빨리 버려야 하는 또다른 이유를 찾았다. -0- 'IT Story > etc' 카테고리의 다른 글
|
|
fwrite 와 fprint 의 차이점은? 위의 질문은 친구가 넥슨에 면접을 보러 갔을때 나온 질문이었다고 한다. 술자리에서 잠시 나온 이야기였지만, 흥미가 생겨서 지금 찾아보니 잘 정리된 글이 있다. fwrite() & fprintf() -- binary or text?? 우선, 저수준함수인 fwrite 를 오버라이딩해서 파라미터에 따른 서식에 맞게 보다 편리하게 출력할 수 있도록 만든 것이 fprintf 이다. 위의 링크 글에 설명되었듯이, fwrite 는 버퍼에 있는 내용을 그대로 다 출력한다. 반면에 fprintf 는 표준출력 (Standard output stream) 모드로 동작하여 일반적인 문자열 버퍼 출력 방식을 따르게 된다. 즉 '/0' 과 같은 문자열 종료 캐릭터를 만나면 출력을 종료한다. 아래 예제를 보면 명확하다. fprintf 를 사용하여 출력하는 경우 HELLO 까지만 찍고, 문자열 종료 널문자 '\0' 을 만났기 떄문에 출력을 종료한다. 반면에 fwrite 는 '\0' 와 상관없이 버퍼 전체의 내용을 그대로 출력해서 HELLO\0WORLD 를 모두 출력한다. ( 텍스트 파일에서는 HELLO WORLD 로 보임 ) 결국 printf 서식에 맞게 문자열 출력방식으로 출력하고 싶으면 fprintf 를 쓰고, 버퍼에 있는 모든 내용 혹은 버퍼내의 특정 범위의 내용을 그대로 출력하고자 할 때는 fwrite 를 쓰면 된다. 'IT Story > Programming Language' 카테고리의 다른 글
|


이올린에 북마크하기
이올린에 추천하기



