http://moogi.new21.org/tc/ 그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라. 2025-02-26T21:23:44+09:00 Textcube 1.7.8 : Con moto (주의사신) http://moogi.new21.org/tc/293#comment531 2010-06-12T09:46:36+09:00

Visual Studio 쓰다가 export를 써 봤는데, 파란 색으로 표시해 주길래, 우와 드디어 VS가 export를 지원하는구나 생각을 하고 썼습니다. 컴파일 결과, "미래의 사용을 위해 예약 중" 이라는 문구가 뜨더군요.(영문판을 쓰기 때문에 정확한 문구가 기억이 나지는 않습니다. 써 보면 되긴 합니다만...) 그래서 다시 template을 원래대로 돌려놓았던 기억이 납니다.

(김 기윤) http://moogi.new21.org/tc/293#comment532 2010-06-12T13:50:55+09:00

Visual Studio 2010 에서 확인 warning C4237: 'export' keyword is not yet supported, but reserved for future use 주의사신님이 말씀하신 것과 같은 에러가 뜹니다 (..) 문법적으로는 있으면 좋은데, 실제 구현이 정말 어려워서 죽어버린 키워드? (..)

(사무엘) http://moogi.new21.org/tc/293#comment533 2010-06-12T16:18:38+09:00

비주얼 C++ 2003은 export를 예약어로 전혀 인식하지 않으며(export 뭐임? 먹는 거임? 우걱우걱.. 컴파일러가 먹는 건 일반 심볼들.. ㅋㅋ), 참고로 덧붙이자면 vector<list<int>> ap; 도 2003에서는 에러가 나는 반면, 2008은 정상 처리되네요. (닫는 꺽쇠를 > >로 띄워야 함) 2005는 결과가 어떤지 모르겠습니다. 말이 나왔으니 말인데, C++0x는 정말 기괴한 변화가 많아서 컴파일러 구현의 난해함은 한층 더 안드로메다로 갈 듯합니다. R-value 참조자 && 는 가히 억소리 나고 특히 람다 대수 개념 도입 덕분에(함수도 자유롭게 value 취급) 이제 C++도 사실상 nested function 구현이 가능해진 거나 마찬가지로 보입니다.

(김 기윤) http://moogi.new21.org/tc/293#comment534 2010-06-12T16:48:36+09:00

가히 '억' 소리 나는 C++0x 의 변화 ㄲㄲㄲ 람다 함수는 정말 ...... 자유도는 상승했지만, 난이도도 덩달아..

(김재주) http://moogi.new21.org/tc/293#comment535 2010-06-12T19:53:52+09:00

이쯤되면 아예 C++의 호환을 포기해버리는 것도 한 방법이 아닐까 싶군요. 사실 C도 C++도 너무 낡았죠? C#만 믿고 갑시다. M$님이 다 해주실 거야..

(김 기윤) http://moogi.new21.org/tc/293#comment536 2010-06-12T21:35:03+09:00

그런데 기존에 C/C++ 으로 쌓아올린 것의 양이 너무 많다는 것이 문제입니다. C++ 의 호환을 포기하고 C# 만 믿고 가려면 기존의 라이브러리 등을 모두 포팅해야 하는데 과연... + 그리고 게임 등의 속도가 중요한 프로그래밍은 수행속도 등의 문제 때문에 C# 으로는 좀 곤란...합니다. 좀 더 하드웨어 성능이 올라가면 모르겠는데, 현재로써는...

(김재주) http://moogi.new21.org/tc/293#comment537 2010-06-13T00:03:52+09:00

김 기윤님께 // 지금까지 쌓아둔 코드의 양이 많아서 다른 언어로 넘어갈 수 없다면, 50년이 지나도 100년이 지나도 계속 C,C++을 사용해야겠죠. 그건 아무리 생각해도 현명한 일은 아닙니다. 현대 컴퓨터 언어들이 그동안 이뤄낸 많은 발전들을 모두 포기해야 하니까요. 그리고 게임 엔진 정도라면 C++로 구현하나 C#으로 구현하나 속도면에서 대단한 차이가 나지는 않습니다. 왜냐면 요즘 게임들은 많은 경우 CPU보다는 GPU의 연산량이 더 많은 경우가 많고, 컴퓨터들도 2개 이상의 CPU 코어를 가지고 병렬로 처리하기 때문이죠. 오히려 Memory leak 등이 잘 발생하지 않기 때문에 C#이나 JAVA를 이용하는 편이 나은 부분도 있습니다. 이로 인한 오버헤드가 있긴 하지만 개발 편의 같은 부분에서 얻는 트레이드 오프 관점으로 생각하면 됩니다. 다만 지금까지 만들어진 게임 엔진들이 C++을 기반으로 만들어져 있고, XBOX 360이나 PS3용으로 .NET 프레임워크가 포팅되지 않았기 때문에 사용하지 않고 있을 뿐입니다.

(사무엘) http://moogi.new21.org/tc/293#comment538 2010-06-14T13:14:09+09:00

김재주 님 C# 꽤 좋아하시는 듯.. ㅋ 차라리 C++ 복잡 흉악함에 대한 대안은, 동급의 네이티브 코드 생성 언어인 D 언어가 될 수도 있겠다는 생각이 드네요.

(김재주) http://moogi.new21.org/tc/293#comment539 2010-06-15T14:40:49+09:00

C#처럼 실무에도 써 먹을만 하면서 파 보면 재밌는 언어도 흔치는 않죠. 만약 네이티브 코드 생성이 반드시 필요하다면 D보다도.. 아예 새로 디자인하는 게 낫지 않을까 생각합니다.

(김기윤) http://moogi.new21.org/tc/293#comment540 2011-01-18T15:26:53+09:00

C#이라던가 Java 를 수업시간 등을 통해서 좀 익힌 뒤로 저의 관점이 좀 바뀌었습니다. 많이 알아야 많이 보이는 듯 합니다... 다만 왠지 C#이나 Java 는, (게임 프로그래머의 입장인 저한테는) 왠지 표현력이 적다...랄까, 답답하다는 느낌이 들었습니다. 단순히 익숙하지 않아서 그럴 수도 있겠지만, 왠지 의존적인 성향이 강하달까.. 그런 느낌이 듭니다. 아이러니한건, 의존성으로 따지면 객관적으로 볼때 C++ 이 최악이라는 건데도 이렇게 느낀다는 것...

(사무엘) http://moogi.new21.org/tc/293#comment541 2011-01-18T21:14:52+09:00

무슨 뜻인지 알겠고 C/C++ 중독자-_-로서 저 역시 그 관점에 동의해요. C#과 자바의 생산성은 C/C++이 가히 엄두도 못 낼 수준인 건 사실입니다. 허나 C/C++만이 지니고 있는 그 자유도와 포스는.. 소위 C/C++의 단점을 보완했다는 후대 언어들에서는 결코 찾을 수 없을 것입니다. 참고로 저도 자바와 C# 중에서는 C#이 더 좋습니다. 그냥 괜히 느낌이요. ^^;;

(iruis' me2day) http://moogi.new21.org/tc/293#trackback2 2011-01-18T15:25:40+09:00

트위터 타임라인에서 보게 된 템플릿의 export 키워드. 닷넷같은 바이트코드가 아니면 구현이 안될 줄 알았는데 C++도 가능 하긴 하구나. 근데 이게 구현되면 컴파일러끼리 호환이 문제 될듯, 그