C#과 자바의 차이점?

geekforum의 이미지

안녕하세요 이제 막 프로그래밍 언어에 관심을 갖게 된 학생입니다 요즘 언어를 접해보면서 C#이야기를 많이 듣습니다. C#에 대한 논란은 끊이지 않는데 제일 궁금한 것은 정말 C#과 자바의 차이점에 관한 것입니다. 어떤 분은 C#이 완전히 자바와 똑같다고 하는데 어찌하였든 조금의 차이라도 좋으니 C#과 자바의 차이점을 알고 싶습니다. 그리고 앞으로 C#이 얼마나 쓰일지도 궁금하고요. 에반스 데이터 코퍼레이션이 실시해 최근 발표된 일련의 연구자료에서 보면 곧 자바의 사용자가 C의 사용자를 넘어선다고 하는데요. C#과 자바의 운명에 대한 예측을 듣고 싶기도 합니다. 요즘은 언어 자체보다는 언어를 둘러싼 논쟁이 더 재미가 있기도 해서...부탁드립니다...
----
관리자 코멘트: C#이 좋은지 자바가 좋은지, 그외의 다른 언어가 좋은지는 이미 많은 논쟁이 있었으니 기술적인 측면에서 두 언어의 공통점/차이점을 이야기해 보았으면 좋겠습니다. 어느 하나가 일방적으로 좋다/나쁘다 식의 이야기는 접어 주십시오....

댓글

익명 사용자의 이미지

무슨 구석기 시대에 사시는 것도 아니시고...^^;
썬이 뭐하는 회사인지 모르고 자바가 뭔지 모를리가요?
요즘같이 컴터랑 네트웍이 대중화 되어 있는 세상에서
누구나 한번쯤 부닥쳐 본것들일텐데요....그리고 실질적으로
그런 제품을 사서 쓰는 사람들의 대부분은 네트웍세대가 아닐런지.

님의 글을 쭈욱 보고 있었지만..
무슨 불만이 그렇게 많으신지...모르겠군요
거의 다 시비조로 쓰신 글들이고....
포트리스같으면 강퇴당하실 분이예요..^^;;

익명 사용자의 이미지

음 지리한 사움일 뿐입니다.

전 이렇게 생각합니다.

C#이나 자바나 모두 랭귀지 일뿐...

배우는거 자체는 사람마다 차이는 있겠지만..

결과적으로 익히는 것이니... 결국에 가선 동등해

진다 입니다..

그럼 차이는 어디서 생기느냐..

논리적인 사고가 사람 개개인 마다 얼마나 있느냐에

따라서 달라진다 생각합니다.

고로 C#이 좋네 자바가 좋네 할 것이 아니라..

논리적인 프로그래밍에 관심을 많이들 가졌으면 좋겠네여..

^^

익명 사용자의 이미지

제생각에는 이러한 말씀을 하실려면 이 토론 자체에 참가를 하지 마셔야 할꺼 같은데요?
이 토론의 목적은 C#과 Java의 차이점의 비교가 주제이지, 논리적 프로그래밍에
관련한 내용이 아니지 않습니까?

익명 사용자의 이미지

전 자바와 C#(J2EE와 .NET)의 구도를 구조적 투명성 측면에서 보고자합니다.

전 얼마전 .NET 책을 보고 요즘은 sun의 Web Service(썬도주로 IBM자료를 사용함)보고 있는데 구조적 투명성 측면에서 볼때 전 자바의 손을 들어 주고 싶습니다.
.NET과 SUN의 Web Service(jdk1.4)의 목적은 같습니다만 그 구조의 투명성에 있어 Sun 진영이 좀더 좋다고 판단 했습니다.

익명 사용자의 이미지

모두들 대단한 이야기들을 나누고 계시는 군요.

제가 느끼는 C#이라는 언어는
Java + C++ +Delphi정도가 아닐까 생각합니다.
많은 장점들을 썩어두었다고 보는 것이 맞을런지는 모르겠지만...

하여간 기대해볼만한 언어인것은 사실입니다.

그리고 JVM이 꼭 자바만을 지원하는 것은 아니라고 볼수도 있습니다. 그것은 다른 언어가 Java Bytecode를 생성할 수 있다면, 그것도 JVM에서 돌아 갈 수 있겠지요.
이점에서 차이는 MS는 .NET을 내놓으면서 여러가지 언어들을 함께 포팅해 가고 있습니다. 그러나 SUN은 그러지 않았죠.
꼭 C++의 Compile된 Code가 실행 파일이라고 하지 않아도 좋다는 것이죠. 속도는 C++보다 느리겠지만 JVM에서 돌아갈수 있게 할수 있다는 것이죠.
VM이라고 하는 것이 가지는 특징이겠지요.
그리고 .NET과 J2EE의 차이점이라는 것이 VM은 같을 수 있지만, 거기에서 쓸수있는 Base Classes들의 차이점이 너무 크지 않나 생각합니다. 위에서 이야기 했던 C++가 JVM코드로 나오기 위해서는 언어의 많은 제약이 될것이빈다. 그것을 통해서 기존 Java언어의 Library를 손쉽게 사용할 수 있다면 .NET과 언어와 라이브러리 측면에서 붙어볼만하지 않을까 생각합니다.

.NET위에서 돌아가는 Application과 J2EE(Java)에서 돌아가는 Application에서 느낄 수 있는 속도차이는 엄청나다고 하더군요. 그것은 기본 VM의 Assambly Cdoe의 설계의 차이라고 합니다. 이 부분도 봐두시면 재미있을 듯 합니다.

한가지만 더 이야기 하자면 분명히 두 언어가 객체지향 언어인것은 사실입니다. 그러나 이제 시대의 흐름이 Component로 넘어가고 있는실정에서 어떤 Platform이 Component를 쉽게 설계, 개발, 설치할 수 있는냐는 문제가 나오게 될 것입니다. 이부분에서 저는 MS의 손을 들어주고 싶군요.
이유는 제가 익숙해서가 아니라 (참고로 저는 Delphi사용자) 나름대로 좋은 툴을 싼가격(?)에 제공한다는 것이죠. 참고로 C#도 Notepad로 프로그래밍 해도 된다는 사실은 아시죠?
그리고 테스트 하기 위한 하드웨어 환경도 요즘 컴퓨터 시세로 100만원정도면 충분히 테스트 할수 있죠. 여러가지 차이점이 있겠지만 저는 현재로서는 MS의 손을 들어주고자 합니다.

앞으로 SUN에서 하는 것을 봐야겠지요.

lamp의 이미지

제가 보기엔 이곳에는 자바로 한 목 잡겠다는 분이 많은 것 같네요. 공부는 즐기면서 해야지요. 그런 불순한 동기로 하면 힘들어져요. 누가 무슨 이야기를 하면 혹시 자기 밥 그릇 없어질까 봐 비꼬기나하고 심하면 인신공격까지 하니 좀 한심하네요 나도 잘못한게 많습니다. 덕이 모자라서 험한글이 나왔으니.. 오늘밤 좆잡고 반성하도록 하겠습니다

익명 사용자의 이미지

lamp님..

자의든 타의든 툴이라는건 항상 바꿀수 있는겁니다.
어차피 이길로 벌어먹구 살겠다고 하니..애정어린충고를 드립니다.
한가지만 판다는 장인 정신이 이계통예서는 그리 좋은 것많은 아니예요.

나이 40까지 코딩만 할게 아니라면..
툴을 배우지 말고 프로그램을 공부하세요.

그리고 남의 이야기에 귀를도 귀울이시고요..큰프로젝트를 하다보면 팀워크만큼중요한게
없습니다..

girneter의 이미지

어려서부터 엘리트 교육을 받으신 모양입니다.
그런 경우 자신이 틀렸다는 사실을 인정하기가 매우 어렵죠.
자신이 보고 경험한 것만이 전부라고 믿기 쉽게 되고...
(어렸을 때는 학교에서 내가 최고였으니까요)

저도 대학 다닐 때까지는 그랬는데...

사회 나와서 이 사람 저 사람 만나보니
내 자신보다 (천부적으로나 혹은 피나는 노력을 통해) 뛰어난 사람들이
많더군요.
언제나 내가 틀릴수도 있다는 사실을 염두해 두지 않으면
아집과 독선의 함정에서 헤어나오지 못하게 됩니다.
(그렇다고 아래 논쟁에서 님이 틀렸다는건 아닙니다.
님의 말이 정말 맞을지도 모르지만...
님이 틀릴수도 있다는걸 전혀 받아들이려 하지 않는 님의 태도가 문제지요)

그리구요,
저도 입이 험해서 친구들끼리는 쌍시옷이니 ㅈㅗㅈ 이니 하는 단어를
누구보다도 많이 사용하지만 여긴 수많은 리눅서들이 사용하는 공용의 게시판이니
좀 말을 가려서 하는게 어떨까요?
내게는 정말 달콤한 한 모금의 담배 연기가 주위 사람에게는
독가스가 될 수도 있는거 아니겠습니까?

개념없는 초딩들은 좋은 말로 할때 DC나 웃대가서 놀아라. 응?

익명 사용자의 이미지

한분 때문에 토론 분위기가 많이 흐려진 것 같네요
원래 질문하신분은 Java와 C#에 대해 정말 궁금하셔서 질문하신 것 같은데
토론이 이상한 방향으로 흘러가면 그분께 미안하기도 하구요

괜히 답글 달아서 더 시끄럽게 하지 말고 원래 주제에 대해 열심히 논의해
보는게 더 생산적이지 않을까요?

익명 사용자의 이미지

둬헉
JVM 스펙은 비공개가 아니라 공개되어있다고 수정 좀 해줬기로서니 불순한 동기씩이나 품은 사람 되버렸네요
제가 알기로 C++에서 순수히 클래스 사용으로 인한 오버헤드는, 특히 알고리즘 구현에서는 별로 쓸모가 없는 vtable이나 exception을 제외한다면 사실상 this 포인터 하나밖에 없는 걸로 알고 있기에, 클래스 내부구조가 비공개;라느니 하면서 잘못된 정보를 유포하는 걸 좀 잡아드렸기로서니 너무하신 말씀같군요. 흘흘

익명 사용자의 이미지

스펙공개가 아닌 VM소스 공개를 원하시는게 아니었을까요?
원 저자님께서는..

jeweljar의 이미지

Sun의 J2SDK 1.3.1 소스도 공개되어 있습니다.

javac 컴파일러는 물론 java VM도 같이요.

라이센스 관련해서 자세한것은 잘 모르겠지만요..

lamp의 이미지

저는 휴학하고 자바를 공부할까하고 삼성 멀티캠퍼스에 알아보니 거기서 공부한 사람 거의다 SCJP합격한다고 하더군요. 한 두영 떨어진다나
그게 시험인가? 결과를 보면 썬사의 속이 휀이 보이지요. 더이상의 언급은 불필요!
지금은 L.A.M.P를 하나씩 접수하고 있는 중입니다.running linux부터 다시 진행중이지요.

익명 사용자의 이미지

자바 공부할까하고 삼성 멀티캠퍼스 알아봤다는건 자바를 직접 사용해 본적이
별로 없다는 말인가요..?
설마 학교에서 수업시간에 코드 몇개 깨작거려본걸로 썬 자바 개발자들
씹어대고 씨뿔이 씨에비해서 엄청 느리네 고런건 아니지요..?
요즘은 무서운 사람들이 많은것 같군..-.-

익명 사용자의 이미지

관리자님 삭제를 요망합니다.

도대체 자격없는 사람 하나가 좋은 게시판
망치는 거 순식간이군요.

익명 사용자의 이미지

안녕하세요. 나그네입니다.
저는 자주 이곳에 들러서 읽어 보는 편입니다.

제가 생각하기에는 이런메너 없는 토론은 모용지물인것 같습니다.상대방을 비방한다거나, 앏잡아 보는식의 토론을 삼가했으면 합니다. 읽는 나그네도 눈살이 찌뿌려집니다.

우리모두 토론문화를 개선해 나갑시다.

익명 사용자의 이미지

written by cache798@korea.com 오지훈

데브피아의 글을 퍼왔습니다.

NET vs J2EE, 그 피비린내 나는 전투
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
이 글은 저의 짧은 지식으로 작성 되었구요. 만약 다른 사이트에 배포하실 때에는 출처는 꼭 밝혀 주세요. 안 그러면 미워할꼬야.. 혹시 강좌 내용 중 의심나는 부분이 있으면 주저하지 마시고 좀더 나은 강좌를 위해 바로 위의 메일로 리포트해주세요. 리포트한번 해주시는데에 대해 뽀뽀한번..!!^^

우리가 꿈꾸는 세상..~~^^ by the .NET, of the .NET, for the .NET
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

안녕하세요. Cache임다. 아마 게시판에 제일 많이 올라오는 질문 중 하나가 C#과 Java중 어느것을 해야 하나요..? 일 것입니다. 많은 분들이 C#과 JAVA중 어느것을 선택할 지에 대해 많은 고민을 하고 계신 것이 사실이죠. 이에 저의 짧은 의견을 이렇게 한번 정리해 봅니다. 제목은 거창하죠..^^ 아래의 글은 전자신문에 난 기사를 보구 저의 입장을 피력한 것입니다.

닷넷과 J2EE의 피비린내(?)^^ 나는 싸움에 대한 cache의 입장..!! ^^

아마 이 두 환경은 여러 가지로 비스므리한 것이 많을 줄로 압니다. 아마 많은 개발자들도 숙지하셨을 거라고 생각됩니다만, CLR과 JVM, IL과 Bytecode 등등.. 여러 가지로 많은 부분에서 공통 분모를 가지고 있을 것입니다. .

우선 차이점을 논하려면 플랫폼과 그 지원되는 프로그래밍 언어의 차이점을 먼저 인지해야 할 것입니다.닷넷이 지원하는 언어로는 닷넷 버젼의 비주얼베이직(VB.NET), C, C#, C++, COBOL, Phython....이외에도 여러 언어들이 닷넷에서 지원되고 있는 반면에, J2EE는 온리 자바, 즉 자바를 위한 플랫폼이죠. 자바 아니면 암것도 할 수 없는 환경입니다.

이렇듯 닷넷은 여러 프로그래밍 언어를 지원하는 반면에, 플랫폼은 (아직까지는) 윈도우 플랫폼 뿐이 지원하지 않고 있습니다. 반면, J2EE는 자바라는 단 한가지의 언어를 지원하는 대신 (이론상) JVM이 설치된 모든 플랫폼을 지원할 수 있습니다.

이렇게 되면 개발자들의 선택은 조금 분명해 지리라 생각됩니다. 만약 자바 이외의 다양한 프로그래밍 언어를 이용해야 하는 개발자라면 닷넷 플랫폼을 택할 것이고, 윈도 시스템이 아닌 다양한 플랫폼을 지원해야 하는 개발자라면 당연히 J2EE를 선택해야 하는 것입니다.

하지만 이에 더해 얼마나 쉽고, 강력하며 생산성 높은 개발툴을 어느쪽이 좀더 잘 지원해 주느냐도 플랫폼의 성패를 결정짓는 아주 중요한 요소라고 생각합니다. 지금까지 MS의 윈도 플랫폼이 성공을 거둘 수 있었던 것은 바로 이 개발툴 덕분이었죠..

비주얼 스튜디오라는 놈이 윈도우즈를 먹여 살렸음에 반문을 달 사람은 없을 줄로 생각합니다.
이런 MS가 닷넷을 위해 만든 개발툴, VS.NET도 자기 모체격인 비주얼 스튜디오의 명성을 등에 업고 닷넷 상에서의 웹 서비스 제작을 훨씬 쉽고 빠르게 만들어 줄 것입니다.

몰론 J2EE 개발툴이 비록 업계에서 내노라 하는 기업들이 공급하는 것이긴 하지만, 솔직히 비주얼스튜디오의 위력 앞에선 크게 밀리고 있죠. 일단 비주얼 스튜디오가 다른 어떤 개발툴보다도 사용자수가 압도적으로 많죠. 허나 이런 자바 진형도 이에 대해 대책을 간구 하고 있을 줄로 생각됩니다.

그럼 J2EE와 닷넷중 어느 놈이 살아남을 까요...?
당연히 지금 현재 상황을 본다면 J2EE쪽을 선택할 것인지 닷넷쪽을 선택할 건지에 대해 많은 고민을 하고 있으시다고 생각됩니다. 아마 J2EE나 닷넷중 하나를 섣불리 선택했다가 나중에 시장에서 비주류로 밀려나지 않을까 하는 두려움 때문일 것입니다.

하지만 제 생각에는 현실적으로 둘 중 하나가 비주류로 밀려나거나 , 개발자들이 호환도 되지 않는 개발플랫폼에 갇히는 일은 없을 줄로 생각됩니다. 이유인 즉, J2EE와 닷넷 두 가지 플랫폼은 서로 공존할 가능성이 크기 때문입니다.

닷넷은 MS라는 강력한 후원자가 뒷받침하고 있는 반면, J2EE 뒤에는 많은 업계 대표적인 기술 제공 업체들이 버티고 있습니다. J2EE와 닷넷은 서로 경쟁하는 동시에, 공존하며 자기 발전을 꾀하기 위해 태어 났다고 생각됩니다. 이 두 플랫폼은 상호 경쟁하면서 각자의 취약점을 개선해 나갈 것이기 때문에 업계 전체로 봐서는 커다란 이득이 아닐 수 없죠..^^

여기서 우리는 보다 현실적인 전망들을 가져야죠. 개발자들이 어떤 플랫폼을 선택할 때에는 대개 차후의 전망보다는, 당장의 현실직인 요인에 의해 결정을 내리는 경우가 일반적이죠.. 우선 먹고는 살아야 하니깐요. 말하자면, 어떤 플랫폼이 약세고, 강세라는 사실을 떠나, 비주얼베이직이나 , C++프로그래밍에 더 능숙한 개발자라면 당연히 닷넷쪽을 선호할 것이고, 반면 자바쪽을 좀더 능수능란하게 다룰 수 있는 개발자라면 당연히 J2EE를 선택하리라 생각됩니다.

그리고 여기서 숙지해야 할 부분은요..
C#이냐 Java냐 와 같이 어느쪽 언어가 좀더 우수하고 좀더 성장 가능성이 뚜렷한가에 초점을 맞추기 보다는요...? 많은 사람들에게 자신이 어떠한 언어를 사용해서 무엇을 어떻게 보여줄 수 있느냐가 중요한 요소가 되겠죠... 다른사람에게 당당히 보여줄게 많은 개발자들은 어떤 언어를 사용하든간에 업체에서 가만히 놔두지는 않을 거라 생각됩니다.

또 우리(저를 포함한 C# 추종자)는 Java 개발자를 인정하여 주고 Java 개발자는 C# 개발자를 인정해 줄때 서로의 진형에 발생하는 시너지 효과는 엄청날 줄로 생각됩니다. 어느 한 진영을 아에 묵사발 내버리기 보다는 상대의 진영을 인정하여 주고 그 진영에 뒤지지 않기 위해 달음질하는 자세야 말로 정말 아름다운 모습일 줄로 생각됩니다. 만일 상대할 진영이 없다면 그 발전속도는 미비해 질것이고 현재의 위치에 만족하게 되고마는 불상사를 초래할 것으로 생각됩니다.

더군다나 상대가 쨉도 안되면 상대할 맘도 안생기고 능률도 안올르겠죠..!!
지금까지 저의 의견을 짧게나마 피력해 보았는데 다른 분들은 어떻게들 생각하시는지...?

그럼

knight2000_의 이미지

> 우선 차이점을 논하려면 플랫폼과 그 지원되는 프로그래밍 언어의 차이점을 먼저 인지해야 할 것입니다.닷넷이 지원하는 언어로는 닷넷 버젼의 비주얼베이직(VB.NET), C, C#, C++, COBOL, Phython....이외에도 여러 언어들이 닷넷에서 지원되고 있는 반면에, J2EE는 온리 자바, 즉 자바를 위한 플랫폼이죠. 자바 아니면 암것도 할 수 없는 환경입니다.

전에도 보았지만, 항상 잘못된 지적을 하고 있지요.
닷넷은 VB, C, C#, C++, COBOL, Phython... 이런 언어를 지원하죠. 하지만, 구현은 따로따로 해야되며, 앞서 말한 C, C++은 오직 VC만 지원합니다.
자바는 온리 자바이지만, 반드시 자바만이 바이트 코드를 만드는 것은 아니라고 했습니다.

반대로 보면, 닷넷은 온리 윈도이며, 윈도가 없으면 아무 것도 할 수 없죠. ㅡ.ㅡ;

익명 사용자의 이미지

남의 의견을 빌려오는것도 좋지만, geek에는 분명히 링크가 있는데
왜이렇게 쓰는지 모르겠습니다.
암튼, 글의 논지중 멀티플 언어에 관련한 내용이 있는데, 이것에 저는 회의적입니다.

과연 .NET의 멀티플 랭귀지의 생각은 실행될까요?
.NET 스펙과 거의 동일한 C#과 VB.NET이 존재하는데

그들의 MSIL에 최적화된것은??
웃긴 일입니다.

거기에 MS의 최고 지원 언어 역시 C#과 VB.NET이 될텐데요.

하지만, 저는 MS프로그래밍의 가장 부러운점은 막강한 VS로 일관되는 프로그래밍
환경입니다.

JBuilder.. JDK 1.4 이후 버전에는 UI의 처리부가 괜찮아 질것을 기대하지만,
글쎄요..

ihavnoid의 이미지

하지만 슬프게 제 생각에는 MS가 J2EE를 묵사발 내도록 엄청난 노력을 할 것 같은 예감이 드는 것은 왜일까요... ㅡ.ㅡ

Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24

익명 사용자의 이미지

그건 마케팅의 측면에서 본다면 당연한 것이 아닐까요?
그런데 왜 SUN은 조용히 있는 것일까요?
이렇게 묵사발이 나도록 맞고 있는데, 신음소리 한번 제대로 안내고 있습니다.
마지막 역전드라마를 준비하는 것이 아닌지 모르겠군요.

제가 보기에는 SUN은 MS에게 언어적인 측면(?)과 기술적인 측면(?)그리고 마지막으로 마케팅적인 측면(?)에서도 할말이 없는 것이 아닌지 모르겠군요.

누구 편드는 것이 아니라, 그냥 저의 생각입니다.

그럼 수고하십시요.

익명 사용자의 이미지

썬 같은 경우 회사사정이 많이 어려운것으로알고 있습니다...
M$같이 돈이 넘쳐나지 않아서 막대한 마케팅 비용을 쏟아 부을수도 없겠죠...

돈으로 다른 회사들을 협박할수도 없을꺼고...

익명 사용자의 이미지

지나가던 개가 짖고있다고 생각하나보죠... ㅋㅋㅋ

lamp의 이미지

제가 자료구조라는 과목을 수강하면서 겪은일인데 같은 코드의 C와 C++를 실행시 C++에서 클래스를 사용할 경우 속도에 엄청난 차이가 생기는 것을 경험했습니다. 교수님도 결과를 의아해 하시더군요. 글을 쓰시는 분들이 두 언어의 문법이 유사하다고 같은 부류로 보시는 경향이 있는데 퍼포먼스에서는 완전히 다릅니다. 완전 객체 언어인 자바는 속도면에서 C++와의 비교는 어떨지 몰라도 C와의 비교는 잘못된 것입니다.

어떤 알고리듬을 객체지향 언어로 구현했을 경우 클래스 내부구조로 인해 실제 우리가 기대하는 것과는 전혀 동떨어진 성능을 보이는 것입니다.
일반적으로 많은 클래스의 내부구조는 비공개지요 자바는 아마 극단적일 걸요?
객체언어는 성능보다는 구현에 관점을 두고 있습니다. 그러므로 이런류의 언어에서 성능향상을 기대하려면 표준공개와 리눅스의 커널과 같이 개발자의 공개적 참여가 필요합니다.
저는 자바VM의 문제점이 단지 기능 구현(그나마 엉터리)에만 급급한 현재의 개발방식에 있다고 봅니다.
아마 썬사에 저보다 똑똑한 개발자나 경영자가 없나 봅니다. 그것도 아니면 스콧 맥닐리가 돈에 귀신이 씌어서 판단마비상태에 빠져 있거나..

knight2000_의 이미지

저도 요즘에 자주 겪는 문제입니다.
같은 코드를 C로 짠 것이 C++로 짠 것보다 눈에 띄게 빠른 경우가 생기죠.
흠... 원인은 단순했죠.

부르지도 않은 std::xxxx 어쩌구저쩌구가 어디선가 튀어나와서는... 성능에 흠집을 마구마구 내더군요. ㅡ.ㅡ;

아마도... 위에서 구현했다는 코드도 그런 문제가 발생한 것은 아닐까요?

익명 사용자의 이미지

님은 공부부터 더 해야겠군요...

아 참... 공부에 앞서 컴퓨터 용어사전부터 펴 보시길...

언제부터 개나소나 지식이랍시고 떠드는 게시판이 된건지...

당신같은 입만 어설프게 산 사람들 때문에, 국내 기술력이 계속 떨어지는 것 같군요.

정말 한심합니다. 한심해... 쯧쯧...

익명 사용자의 이미지

C++는 그렇게 느리지 않습니다.
단지 C++프로그램을 제대로 작성하지 못한 것 뿐입니다.
그 증거로 아래 다른 분이 virtual이나 exception의 사용에 대해 말씀하신 것에 대해
아무런 답변도 하지 못하고 있지 않습니까?

혹시 C를 사용하실 때는 직접 코딩하시고
C++을 사용하실 때는 STL을 가져다 쓰신 것 아닙니까?

그리고 C++의 클래스 내부구조가 어떤 점에서 비공개라고 하시는지도 의문입니다.
(극단적..이라고 하신 것은 자바지만, '비공개'라고 하신 것은 '객체지향'이었습니다.
발뺌하지 마시길.)
직접 코딩하신 클래스라면 메모리 바이트 하나하나까지 알 수 있습니다.
다중 상속 등을 사용하셨다면 컴파일러마다 구현이 다른 부분도 있겠지만
비공개라는 말은 어폐가 있습니다.

Library라고 하더라도, 템플릿 라이브러리가 비공개일 수 있습니까?
물론 비공개인 상용 라이브러리도 있겠지만
설마 그런 것을 가지고 C++ 가 늦다고 하신 것을아니겠지요?

익명 사용자의 이미지

로딩시간을 제외하였을 경우 :)
C vs Java의 속도는 1:1.2 정도 밖에 안되었습니다. ( 알고리즘 책에 있는 Maximum sub sum 문제에 관한 프로그램이었습니다 )

그리고 클래스 내부구조가 비공개라는건 무슨 뜻이신지 궁금합니다.
클래스 소스의 경우라면 Sun에서는 JDK API의 소스를 계속해서 공개하고 있고
VM 상에서의 클래스 구조라면 JVM 표준이 있을 꺼라 생각됩니다.

익명 사용자의 이미지

신기하네요 C++로 짠 프로그램이 C에 비해 엄청나게 느렸다니..
얼마나 차이가 났는지 어떤 프로그램이었는지 궁금합니다.

저는 여태까지 그런적이 없었거든요.
C로 엄청나게 최적화를 했거나 C++로 엉성하게 프로그램을 짰거나
컴파일러를 잘못 사용했거나 3가지 중 하나 아닐까요?

익명 사용자의 이미지

둬헉 엄청난 분이시군요 썬에 있는 사람들보다 똑똑하시다니
근데 표준공개라니요? 자바 랭기지 스펙 공개되어있는데요?
컴파일러도 VM도 다 써드파티에서 만든것들이 널려있는데, 무슨 말씀이신지 영 -_-a

참고로 C++에서 클래스를 사용함으로해서 생기는 오버헤드라하면 보통 virtual 메소드 사용과 exception 때문인데, 사실 알고리즘 구현하는데는 그런 걸 쓸 이유가 별로 없지요. virtual 메소드야 안쓰면 되고 exception도 컴파일러 옵션으로 disable시키면, C++ 클래스를 쓴다고 해서 그다지 느려질 건 없는데요?

익명 사용자의 이미지

오해가 있군요
나는 썬사의 정책에 문제가 있다는 말을 돌려서 표현했는데 당신같은 반응이 나온다면 할말이 없네요.
당신 그리고 C++를 제대로 이해 못하는 것 같아요
되도 않는 글을 올리는 것 보니 - 당신이 대학가서 교수하시요

익명 사용자의 이미지

알고리즘 구현하는데 C++이 C보다 엄청나게 느려질 구조적인 이유가 vtable이랑 exception 말고 뭐가 있는데요? 정말 순수하게 궁금해서 묻는겁니다

lamp의 이미지

이보시오 벌써 1년 가까이 된 과제라서 당신같이 시비거는 인간에게 일일이 대답하기는 나도 괴롭소
그런데 당신이 말하는 것이 내가 목격했던 결과와 무슨 관계가 있을 것이라 생각하오?
설사 가상함수를 많이 생성해서 그걸 추적하느라 버벅거린다해도 무려 100배 이상이나?
내가 사용한 것은 벡터컨테이너클래스였소.
좆도 모르면서 시비걸지 마시오.
나는 시비조로 비꼬는 인간이 가장 싫어
내가 똑똑하면 당신이 먹여 살려주실거요?
국어도 제대로 못하는 인간이..

익명 사용자의 이미지

둬헉
STL 컨테이너 그대로 가져다 사용해서 알고리즘 구현하면서, C랑 엄청나게 차이난다고요?
STL이 vtable을 안써서 나름대로 오버헤드가 적은 건 사실이지만, allocation도 반복적으로 많이 할 뿐더러, 심지어 allocation을 위한 글로벌 lock 같은 것도 쓰기 때문에 결코 lightweight하다곤 못하지요. exception도 안끄고 사용한다면 더더욱..
결론: 님이 예로 드신 경우는 C++에서 클래스를 사용했기 때문에 느려진게 아니라,
STL을 썼기 때문에 느려진 거구만요. 아닌가요?

익명 사용자의 이미지

빠른거 좋아하면.. 어셈 쓰면 대구..

편한거 좋아하면.. C++ 쓰면 ..

편한거에 원하는 기능이 없으면...... 만들어 쓰던지..

이것저것 아니면.. 걍 씨나 써서 열나게 노가다 하구.....

아님 어셈써서 머리에 쥐 좀 잡던지....

Anonymous wrote...
> 둬헉
> STL 컨테이너 그대로 가져다 사용해서 알고리즘 구현하면서, C랑 엄청나게 차이난다고요?
> STL이 vtable을 안써서 나름대로 오버헤드가 적은 건 사실이지만, allocation도 반복적으로 많이 할 뿐더러, 심지어 allocation을 위한 글로벌 lock 같은 것도 쓰기 때문에 결코 lightweight하다곤 못하지요. exception도 안끄고 사용한다면 더더욱..
> 결론: 님이 예로 드신 경우는 C++에서 클래스를 사용했기 때문에 느려진게 아니라,
> STL을 썼기 때문에 느려진 거구만요. 아닌가요?

익명 사용자의 이미지

C++를 조금이라도 아는 사람이라면
관계가 있다는 정도는 누구나 알고 있습니다.
어떤 식으로 코딩을 하셨을지 눈에 선하군요.

lamp의 이미지

나는 버렸는데 내가 혹시 그 과제 결과물 찿으면 올리지 돌들아! 병신들아!
MS VB조금하면서 대단한 프로그래머인양하던 인간들 여기서 또 보는 것 같네

익명 사용자의 이미지

욕하는걸 보아니 상당히 똘똘한 양반이구랴 ^^
똘~똘~ 소리까지 나는 구랴

익명 사용자의 이미지

위에위에 글 쓴 사람은 아닙니다만
궁금하네요 위에위에 글 쓰신 분이 어떤 점에서 C++을 제대로 이해하지 못하고 계신건지
썬사의 분들보다 더 똑똑하신 분께서 가르쳐 주세요

익명 사용자의 이미지

그건.. MS도 못지안지 않나요?
우선 구현해놓고.. 엄청난 마케팅으로... 경쟁상대 죽이는거...
그건 MS가 힘하지 않나요?

단지 문제는 그런 MS를 이기는 전략은 SUN에서는
"이에는 이, 눈에는 눈"를 선택한 거라고나 할까..

아님... SUN이 MS를 마케팅에서 이길수 있어라고 생각하는지...

lamp의 이미지

정말 가관이네 여기 수준이 언제부터 이렇게 낮아졌나?
도대체가 학교에서 국어시간에 잠만잤나?
나는 썬사가 자바의 성능개선보다는 돈벌이에 집착하는 정책이 마음에 들지않아서 글을 쓰게 되었는데 별걸 가지고 시비네
그래 내가 똑똑하면 어쩔건데 돌들아

익명 사용자의 이미지

에라~ 빌게이츠 똥꼬털 다듬어주는 시다바리같은놈아.
상업성하면 MS~! 누가 부인하랴~?
그리고 말좀 곱게해라 스불 지기미...

익명 사용자의 이미지

정말 고약한 사람이군:<
자기가 한 말을 해명하지도 못하면서 무조건
화만 내고 욕만 퍼붓는군.
실력이 문제인지 인격이 문제인지?
(정답 둘다)

lamp의 이미지

해명 위에 했어요
자료구조공부하다보면 성능측정하는 것 배우지요 그게 C++에서는 씨도 먹히지 않더라는 것을 겪었다고 말씀드렸는데 나를 썬사에 있는 병신들하고 비교하면서 비꼬면 나라고 기분 좋겠어요.
대부분 사람들은 자료구조 공부를 어떻게 했는지 모르지만 (대단하신분들이니 잘하셨겠지?) 나를 비꼬시는 분들에게 가장 좋은 방법은 소스를 보여 드리는 방법밖에 없지 않겠어요. 그런데 문제는 나는 그 자료가 없어요. 내가 멍청해서 그런 결과가 나왔을 지도 모르지만 날 가르친 교수님도 엄청난 속도차를 이해 못하시더라구요.
그러면 그분도 멍청하신가 글쎄요
그 분 S대 과기원에서 박사학위 받고 전공 DB그리고 계속 자료구조 파일구조 DB만 강의하시던 젊은 교수님인데 바보로 보기에는 좀 ..
제 표현이 좀 지나쳤다면 사과하지요

익명 사용자의 이미지

다른 사람들도 C++로 코딩해서 충분히 성능 측정을 해 보았으며,
또 다른 사람들의 측정 결과를 알고 있기 때문에 lamp님의 글에 반대하는 것입니다.

그러나 아무리 그래도 100배라...
그것은 이리저리 꼬인자료구조 안에서
객체지향이라는 미명 하에 포인터를 겹겹히 쌓고
new/delete가 남발했기 때문인 것으로 보입니다. 어떻습니까?

(그런데 도대체 해명이 어디에 있다는 것입니까?
저것이 해명입니까?)

그리고 교수님의 권위를 아무리 빌어 본들 이 문제에서는 아무 도움이 안 됩니다.
Sun의 핵심 프로그래머들이 그보다 못한 사람들이 아닙니다.
또한, 스스로 공들여 코딩을 하는 것과
학생이 작성한 코들 슥 훑어보는 것에는 본질적인 차이가 있습니다.
그 코드는 virtual이 속도차이가 있는지 없는지조차 모르는 lamp님이 작성하신 것이지
그 교수님이 작성하신 것이 아닙니다.

lamp의 이미지

다른 사람들도 C++로 코딩해서 충분히 성능 측정을 해 보았으며,
또 다른 사람들의 측정 결과를 알고 있기 때문에 lamp님의 글에 반대하는 것입니다.
## 저도 십년전에는 그렇게 알았어요 ##

그러나 아무리 그래도 100배라...
## 솔직이 백배 넘었어요 C -> 0 : C++ -> 0.00*** (<- 잘기억나지 않지만 소수점아래 몇개의 유효숫자가 있었어요) ##

그것은 이리저리 꼬인자료구조 안에서
객체지향이라는 미명 하에 포인터를 겹겹히 쌓고
new/delete가 남발했기 때문인 것으로 보입니다. 어떻습니까?
## 위 시간을 보시면 아시겠지만 복잡하고 지저분한 플그램이 아니고 아주 컴팩트하고 깨끗한 플그램이었읍니다 ##

(그런데 도대체 해명이 어디에 있다는 것입니까?
저것이 해명입니까?)
## 그래서 국어교육이 중요하다는 것입니다. 내가 이야기하려는 본질을 회피하고(아니 머리가 짧아서 본질을 못본 것일지도)
클래스가 개입되면 외관상으로 효율적으로 보이는 구조가 실제 기대한대로 성능을 보이지 않을거란 이야기를 했는데 되지도 않은 vtable을 들먹거리니 분에게 내가 뭔 답변을 해드려야 할지? 그거 개입되서 100배씩 차이나나? 지금 무슨 내가 C++입문서나 보는 애긴줄 아시오? ##
그리고 교수님의 권위를 아무리 빌어 본들 이 문제에서는 아무 도움이 안 됩니다.
Sun의 핵심 프로그래머들이 그보다 못한 사람들이 아닙니다. 또한, 스스로 공들여 코딩을 하는 것과 학생이 작성한 코들 슥 훑어보는 것에는 본질적인 차이가 있습니다.
그 코드는 virtual이 속도차이가 있는지 없는지조차 모르는 lamp님이 작성하신 것이지
그 교수님이 작성하신 것이 아닙니다.
## 나는 그 교수보다 못할거란 생각 한번도 못해본 사람이오 뭐가 아쉬워서? 그리고 자바 이야기가 아니라 씨++ 이야기하는데 왜 썬사의 졸개들 들먹거리나? 당신도 썬사의 개인가? 정말 병신새끼하고 상대할려니 신경질 나네. 왜? 당신이 C++제대로 하려니 어렵고 자바는 만만한데 내가 혹 자바를 욕하는 것 같아서 방어본능이 발동한 건가? 앞으로 밥줄 떨어질까바서. 나는 자바를 욕한게 아니라 그걸로 한목 단단히 잡을려고 벼르는 썬사의 돈벌래들에게 화가 난거야. 그리고 지금 이대로라면 5년안에 자바는 메이저리그에서 마이너리그로 추락할 걸 ##

익명 사용자의 이미지

둬헉

C -> 0 : C++ -> 0.00*** 이라구요?

실례지만 저 시간의 단위가 어떻게 되는지 좀;;;
설마 miliseconds나 microseconds 는 아니겠지요? ;;;;;;;;

익명 사용자의 이미지

1.
그 시간을 보면 프로그램의 실행횟수가 매우 적기 때문에
애당초 제대로 된 속도측정이 아니라는 것만을 알 수 있습니다.

2.
Sun의 쟁쟁한 프로그래머들의 권위도 이미 무시하셨는데
교수님 한 분이, 그나마 슥 훑어보신 것에 대해서
권위를 주장하는 것이 우습다는 것입니다.
국어 교육이라....

3.
virtual의 속도 문제에 대한 이해 자체가 전혀 없으신 것에 대해서
100배 운운하는 것으로 유야무야하시려는 것 자체가 어이가 없군요.
C++를 오래 사용하셨다고 한들 무슨 소용이 있겠습니까?
이해가 결여된 상태로 이해가 결여된 코드만을 되풀이하여 만들어낸 경험만으로
C++를 저절로 이해하게 되지는 않습니다.

물론 lamp님은 스스로가 그 교수님만큼 훌륭하다고 생각할 수도 있습니다.
이 곳의 글을 보면
적어도 본인은 충분히 그렇게 생각하고도 남음이 있습니다.

4.
Sun의 상업성 자체는 비난할 수도 있겠습니다만...
이 곳에서 Java와 맞서는 것은 바로 MS에서 나온 C#이 아닙니까?
전혀 설득력이 없습니다.

p.s.
저런 분을 계속 상대하는 글을 올린 것에 대해
다른 분들께 죄송하게 생각합니다.
지금까지의 글에 대해서는 용서를 구하며
더이상 lamp님의 글에는 reply를 붙이지 않겠습니다.

익명 사용자의 이미지

모지?
소스코드도 없다면서 왜 얘기를 질질 끄십니까? 이만 접으시지요.

아무도 설득하지 못한다면 더 이상 얘기를 할 이유가 없습니다.

익명 사용자의 이미지

자바와 썬 이야기가 왜 나오나요?
C++의 성능에 대한 이야기를 하고 있는건데.
그리고 누가 님을 비꼬던가요?
암만 봐도 님을 비꼬는 사람은 없는데 혼자
열내고 토론 분의기를 흐리고 계시는 군요.

# 솔직이 백배 넘었어요 C -> 0 : C++ -> 0.00*** (<- 잘기억나지 않지만 소수점아래 몇개의 유효숫자가 있었어요) #
=> 도대체 이건 뭔가요? 말이 안되는 거 같군요.

그리고 국어 교육이 필요한 건 님같군요.

# 그래서 국어교육이 중요하다는 것입니다. 내가 이야기하려는 본질을 회피하고(아니 머리가 짧아서 본질을 못본 것일지도)
클래스가 개입되면 외관상으로 효율적으로 보이는 구조가 실제 기대한대로 성능을 보이지 않을거란 이야기를 했는데 되지도 않은 vtable을 들먹거리니 분에게 내가 뭔 답변을 해드려야 할지? 그거 개입되서 100배씩 차이나나? 지금 무슨 내가 C++입문서나 보는 애긴줄 아시오? #

=>실제 기대한 대로 성능이 나오지 않으면 툴 고유의
문제도 있겠고 알고리즘 문제도 있겠고, 코딩 문제나
디자인 문제가 있는 겁니다. 그러니 그걸 한번 고려해
보자는 이야기 아니였던가요?

님은 썬의 정책 비판할라구 c++까지 덤으로 비판한
건가요?

그리고 토론시에는 좀 진지하고 핵심에 주목해 주시기
바랍니다.
제가 님을 오독했으면 멍청하다 하지 마시고 어디가
어떻게 잘못되었는지 밝혀 주세요.

익명 사용자의 이미지

국어 교육을 받아야할 건 lamp 니놈인거 같은데?

공개 토론장에서 막되먹은 글을 쓰다니

논점도 빗나갔고

그리 남을 이기고 싶어하나?

니가 잘났어 너 천재야 -_-)=b

이럼 됐지? 이제 고만해라 아가야? :P

lamp의 이미지

자바의 마이너리그 진입 기정 사실

앞으로 플그램 임베디드 기기들이 일상적으로 사용될 것이고 시간이 지나면 지날수록 시장규모는 엄청나게 커질것임. 자바의 VM이 구현가능한 수단이 될 수 있겠지만 썬사가 이것을 통해서 한 목 단단히 잡으려 하기 때문에 하드웨어 업체에서는 비용이 들지 않는 대체 기술을 찿을 것임

서버사이드 플그램이 지나치게 비싸고 반면에 클라이언트 쪽 VM이 기본적으로 내장되지 않을 예정이므로 웹 사이트에서도 대체 기술쪽으로 선회할 것으로 예상됨

리눅스에서 오픈진영의 C#지원으로 C#의 성능이 윈도우에서와 비슷해질 것으로 생각됨(자바의 가장 큰 취약점 -> 리눅스에서는 개 떡 같음 윈도우에서 제대로 돌아가는 것은 리눅스에서 문제 있고 그 반대도 심각할거라 생각되지만 반대위주로 제작된 사이드나 플그램을 찾을 수가 없어서 모르겠음)

5년만 플그램하실거면 미친듯이 자바하시요 나는 한 10년이상 할것이기 때문에 자바 맛만보고 다른데나 더 신경쓰렵니다

익명 사용자의 이미지

너 신경쓰라고 한 사람 아무도 없어 쿄쿄쿄

lamp의 이미지

공부하는 학생이 무얼집중해야 될지를 묻는데 나름대로 내가 선택한 것에 대한 이유를 조금 언급했습니다.
자바보단 다른것에 더욱 힘쓰라는 뜻에서 말입니다.
자바는 그냥 하나의 언어에 불과하고 그것도 얼마 안가서 주류 시장에서 퇴출될 것이니 너무 힘쓰면 어린 인생이 불쌍하잖아요.

익명 사용자의 이미지

난 lamp님이 더 불쌍해 보이는데 ;)

익명 사용자의 이미지

프로그래밍 개념이나 코드형태면에서 C 이후로 큰 차이를

못느끼니 어느쪽이든 쉽게(?) 적응가능하다는 뜻인 것 같습니다.

이부분에 대해서는 같은 생각입니다...

익명 사용자의 이미지

쭉~ 가장 아래의 게시물에 단다는 것이 실수... -_-;

익명 사용자의 이미지

자바도 바이트코드 때문에 보안에 문제가 있다고 하죠.
역컴파일로 앞전에 주식조작사건도 있었잖습니까..

똑같이 C#도 바이트코드 형태로 작동하기 때문에 보안이
문제일 겁니다.

사용자 층은 JAVA가 월등합니다.

C#은 높은 사양의 시스템을 요구하므로 당분간 적용되기
어려울 것 같습니다.

자바진영과 시샵진영이 둘로 나누어져서 공존할 것 같습니다.

학생이라면 양쪽을 조금씩 함께 공부하는 것이 좋겠습니다.
개인적 추천은 자바입니다만 새로운 것에 대한 관심이 있다면 시샵을 먼저 해 보세요.

익명 사용자의 이미지

Aug 28, 2001
.NET Hello World is working under Mono! The latest snapshots will let you run it.

Hello World consits of 1821 CIL instructions, performs 66 subroutine calls and loads 12 classes from the corlib.dll

Good work Mono team!

다들 벌써 아시고 계신건지도 모르겠군요..

저는 오늘 발견한 지라..^^

너무 신기하네요..모노 프로젝트...

전 아직도 말만 오가는 걸로 생각하고 있었는데..

리눅스에서 C#으로..

Hello World 한 번 찍어봐야겠네요..

링크
http://www.go-mono.com/

익명 사용자의 이미지

홋홋. 같이 mono 공부합시다.~~
멜링리스트 만들까용? ^^

익명 사용자의 이미지

자바보다 C#이 분명 장점이 될 한가지는 프로그래머에 있어 개발환경이 아닐까 합니다.

자바프로그램을 하다보면서 느낀건데 첨에는 개발툴도 없이 텍스트편집기로 하다가 Swing같은 그래픽 프로그램을 작성할 땐 텍스트 에디터가 여간 불편한게 아니더군요.. 특히 디버그는 거의 죽음입니다. Java에서 제공하는 JDB는 사용법이 좀 어렵고 인터페이스도 불편하거든요.. 어찌보면 GDB를 보고 만든것 같은데 것보다 훨씬 기능이 못하지요..
자바의 IDE 개발툴은 JBuilder, 포르테, 까페등이 있는데 JBuilder와 포르테는 자바기반으로 작성된 언어라 기존의 윈도우 개발환경에서 작성하시던 분에게는 많은 인내심을 필요로 합니다. 개인적으로 전 위 3가지 툴중 까페가 가장 마음에 드는데 영어를 못하는 저로선 한국어판 메뉴얼 한권없는 비주얼까페를 쓰기가 쉽지는 않을 꺼 같습니다. 대중적으로 인기있는 VC는 메뉴얼이 너무 많아 문제지만(-.-)..
어떻게 보면 위의 단점을 자신의 실력과 최고가 되고자하는 노력으로 극복할 수 있겠지만, 저는 자바프로그래밍을 할때마다 가끔 선에 원망하곤 합니다. 왜이렇게 개발자를 힘들게 하냐구..

익명 사용자의 이미지

자바의 GUI 플밍이라
저도 한 kawa 로 몇달동안 짰더니
자바가 질리더군요 ㅡ.ㅜ
물론 visualage 이런게 있다고는 하지만
어렵더라구여

ihavnoid의 이미지

IBM에서 나온 VisualAge for java 괜찮습니다.
처음 보시는 분들에게는 약간 당황스러울 수 있는 인터페이스를 제공하지만...
익숙해지면 Forte 보다는 훨 낫더군요...

참고로 저는 여태까지 VisualCafe, Forte, VisualAget 써 봤습니다...
(역시 Forte는 인내심을 필요로 하더군요.. ^^)

Consider the ravens: for they neither sow nor reap; which neither have storehouse nor barn; and God feedeth them: how much more are ye better than the fowls?
Luke 12:24

익명 사용자의 이미지

동감입니다 TT
아무리 vi가 강력하다고 하지만 GUI 프로그래밍을 할 때는 죽음이죠 -.-

익명 사용자의 이미지

그냥 궁굼해서 여쭤보는 건데요..

자바에서 non-blocking 으로 소켓프로그래밍 할 수 있나요??

여기 저기 책 뒤져봐도 못 찾겠더라구요..

여기면 고수분들이 많이 오실 거 같아서..

쓸데 없는 글 올려서 죄송합니다..

익명 사용자의 이미지

내부적으로 select() / poll() 등을 이용하는 진정한 non-blocking I/O는 Java 1.4에서부터 가능해질겁니다 (java.nio.*)

참고로 Matt Welsh의 NBIO:Nonblocking I/O for Java 란 것도 있구요
linux/solaris에서 사용가능합니다
http://www.cs.berkeley.edu/~mdw/proj/java-nbio/

익명 사용자의 이미지

잠시 KLDP에 들렀다가 님의 글을 보았습니다.
일단은... non-blocking socket programming은 가능하구요.
참고자료로는 JAVA Network Programming이라는 책(번역서도 있더군요)을 참조해보세요.

그리고... non-blocking이라는 것 자체가 Thread를 기바으로 하고 있으므로 스레드에 대한 이해가 많이 필요합니다.
이것은 Orelly에서 출판된 Java Thread라는 책이나 인포북에서 번역서로 출판된 '자바 쓰레드 능숙하게 다루기'라는 책을 참조해보세요.

PS : 웹상에 메일주소를 올려놓았더니 각종 홍보성 메일이 쏟아지더군요.
또한, 문의메일도 받고싶지 않아 test로 올렸습니다. 죄송합니다. ^^;

익명 사용자의 이미지

InputStream의 available() 메소드를 사용하면 가능한 걸루 알고 있습니다.

bsheep의 이미지

C#과 자바...

기술적인 면 :
1. 자바는 main이 없어도 컴파일이 된다,
C#은 안된다.
2. C#에 GoTo가 추가되었다.
3. C#은 Monitor & Mutex 를 사용하여 멀티쓰레드를 간편화했다.
4. C#이 그 외에 몇가지 개념을 더 추가했는데..
(제가 잘 모름.. -.-a 그러나.. 이름들은..)
Indexers, Attributes, Delegates

운명은...? :

어짜피 C#은 java/c++에서 발전한 것이기 때문에
개념적으로는 한두단계 더 앞서있지 않을까요?

그러나 c#은 아직 완성되지 않은 것입니다.
5년 동안 고처지고 발전해온 자바의 나이를 무시하지
못 할 것입니다. 특히 SCP를 통한 외부 사람들의
참여로 산업자체게 필요한 것을 추가,발전할수
있게 되어있지요.

MS가 발표한 일들을 성공만 한다면, 자바는 발 디딜틈이
없을 것입니다. 그러나,,, 여러분 MS를 믿쉽니까?~~~

그러나 MS는 돈이 많습니다. 버그가 많고 불안하다면서
사용하는 것이 윈도우 입니다. MS가 그 많은 돈으로
그 머리 좋은 많은 두뇌를 고용하여 만드는데 제품이
아무리 나쁘다 하여도 소프트웨어 업개에서 MS를 능가하는
곳은 많지 않을 것입니다.
필요하면 상대방 회사의 핵심 인물들을 대리고 오면
게임이 끝나거든요. ^^;; (볼란드가 당했지요....)

고로 MS 또한 무시 못하겠지요.. ^^;;;;;;

결론 :
현재 - 자바와 경쟁할 C#은 아직 존재하지 않는다. -.-;
자바 WIN.
2,3년 후 - C# 탄생, 성숙. 윈도백으로 밈.
자바와 대등하게 시장을 놓고 싸우겠지요.
서버쪽은 자바가 굳건히 잡고 있을 것입니다.
그리고 모바일도 자바가 조금 더 유리하지
않을까 생각되네요.
클라이언트 쪽은 VB만큼, 아니 그 이상 C#이
차지 하겠지요.

그러나 3년 후면, MS에서 또 다른 프로젝을 발표하지
않을까 생각합니다. 시장은 급변하고 경쟁자들이 계속
만들어 놓은 것을 대항하려면, 현재처럼 계속 개념적인
것을 발표해야하니깐요. 그래서 타회사가 시장을 완전
장악하지 못하게 시간을 버는 것이지요.

PS. MS에 주시는 하되, 끌려 다니지 맙시다. :)

익명 사용자의 이미지

샵이 예약어 몇개 더 추가한것 빼곤 문법구조로만 봐서는 자바와 거의 차이가 없구요.

기본적으로 클래스를 만들고 사용하는 메커니즘 역시 자바와 전혀다를게 없구...

뭐 차이라면 자바의 경우 피어라고 하는 최소한의 윈라이브러리를 쓰는 반면에 샵은 거의 모든 윈도 리소스를 샵으로 래핑해서 쓰지않나 싶군요.

때문에 샵의 경우가 훨씬 다양한 기능이나 표현이 가능하겠죠.사용법은 비슷하지만

뭐 거의 VC수준의 플밍을 자바식으로 다룬다 정도...

어떤이는 내용적으로 마는 차이가 있다곤 하는데..
public override void Draw(Graphics g) {
g.DrawPath(..);
}

pblic void paint(Graphics g) {
g.drawLine(..);
}
대부분이 이런데..차이가 있다고 해야되는지 모르겠군요.
헸갈리기만 하죠 ^^;

차이가 있다면 샵의 경우는 MS가 제공하는 완벽한(?)제품 지원아래 개발이 이뤄지고 자바의 경우는 스펙을 구현하는 여러 개발사의 지원을 받는다는 정도...

그외는 빌게이츠가 겨우 40몇살이고 스캇맥닐리는 입이 험하다는 정도.ㅎㅎ

익명 사용자의 이미지

아주 초짜가 본 것 :
흠.. 전.. 포인터 있는 씨샵이 좋던데. ^-^;
비록 리눅스를 하긴 하지만..
많이 알고있는 C++을 기본으로 닦여진 씨샵이
더친근하네요. ^^
물론 자바도 배우기 쉽더라구요 책을 보면서하니까.
금방 배우긴하던데..^^
초보자에겐(씨를 조금 아는.. ) 씨샵이 쉽다.. ^^ & 친근하다

익명 사용자의 이미지

JNI하세요 --;

익명 사용자의 이미지

좀 납득이 안가는군요.
C#이 C++의 특징을 바탕으로 만들었다뇨..
자바를 바탕으로 만들었죠.
뭐. C++처럼 짤 수 있다고는 하지만 그럼 C++를 쓰지 왜 C#을 쓰겠습니까?

아직 베타이긴 하지만 리소스 반환문제는 전혀 해결이 안되어있는 C#...
그리고 리소스도 너무 소모가 심해요. 폼만 띄어도 10M는 가뿐히 넘어가니..
그리고 아직 윈도우2000에서만 깔리는 VM등..
속도는 워낙 덩치가 커서 저사양을 생각한다면 자바보다 빠르다고 하기 좀 뭐하네요.
좀 더 덩치가 큰 프로그램이 나와야 정확한 자료가 나올텐데...
지금 베타판을 보면 형편없습니다.
그렇다고 MS의 말만 믿고 정품은 이럴 것이다라고 기대할 수도 없는 일이고..

음.. 기다려봐야겠습니다.

익명 사용자의 이미지

C++로 ASP.NET기반 어플리케이션 만드나요??

C++로는 ISAPI만들져.;;

lamp의 이미지

저는 c/c++를 조금 사용하고 있는 리눅서입니다. 자바열풍이 불어서 저도 그대열에 합류하려고 아주 초보적인 책을 좀 읽었지요. 그 책에서 자바의 가장 큰 장점을 꼽는 것중의 하나가 분산처리프로그래밍을 쉽게 할수 있는 거의 유일한 언어라고 하는 것이었습니다. (운영체제에 쓰인 분산처리기법은 아주 대단한 전문가들이 c로 어렵게 구현) 그래서 그런지 학교에서 분산처리과목을 자바로 하더군요.
그러나 사용자 입장에서 그런 자바의 잇점은 눈에 보이지 않는 부분이고 웹상에서 보이는 자바는 웬지 상당히 불완전하다는 느낌이 듭니다. 가령 드림위즈의 자바게임은 리눅스상에서 거의 사용이 불가능합니다. 그리고 홈페이지에 뜨는 자그마한 광고는 웬 암호문 투성이 그리고 이곳저곳에 돌아다니면서 부딪히는 문제들..
즉 자바의 핵심인 VM이 문제 투성인 것 같습니다.
물론 플랫폼에 자유로운 실행을 보장한다는 것이 쉬운일이 아니겠지만 자바가 나온지가 상당히 되었다는 것을 감안하면 이 계획은 실패한 것이 아닌지?
그러다 보니 C#에 관심을 갖게 됩니다. 뭐 대단한 기대는 하지 않지만 MS가 만만한 회사가 아닌만큼 무언가 사건을 만들지도?

익명 사용자의 이미지

말씀에 약간의 어폐가 느껴지네요.
.NET역시 리눅스상에서 지운이될까요?

아마 화면에 뿌리는건 아예안될꺼 같은데요.
JDK 1.4 에서 이제 쓸만해 진거 같은데 UI는요. 컴퓨팅 파워가 올라가서도 그렇지만.

JDK1.4의 스펙을 본이후 이제 Java의 부족한 점은 특별히 못찾겠어요 --;

lamp의 이미지

표준이 공개되니 mono와 같은 프로젝트가 생길 여지가 있지요. 하지만 자바VM은 이와는 다릅니다.
제가 2대의 컴퓨터를 이용하여 윈도우와 리눅스를 동시에 쓰고 있는데 리눅스쪽에서는 자바가 제대로 작동하지 않는 사이트가 너무 많은 것 같습니다.
단순 무식하게 생각하더라도 같은 코드를 써서 동일한 결과를 얻지 못한다면 문제는 이것을 돌려주는 연장에 문제가 있다고 볼 수 밖에 없지 않을까요?
저는 썬사가 좀 무능력하다는 판단이...

익명 사용자의 이미지

글쎄요 자바의 핵심인 VM은 별루 문제가 아닌것 같은데..
자바가 특히 불안정한 모습을 보이는 곳은 User Interface가 들어간 곳이거나 애플릿 등에서죠.
AWT, Swing 등. 다양한 플랫폼에서 공통의 API로 UI를 구현하려 하니 많은 문제가 발생할 수 밖에 없겠죠.
command line 인터페이스의 자바 프로그램의 경우 VM의 문제는 거의 겪어 보지 못했습니다. 오히려 Exception을 확실하게 처리해줌으로 인해서 더욱더 안정하다는 느낌을 받기는 하지만요

Java는 분산 처리 이외에도 많은 장점을 가지고 있습니다. 물론, 서버 side 쪽에서는 그 점이 가장 큰 장점으로 다가올 수 있겠지만요.

순수한 언어 자체만으로 보았을 때
Garbage collection
보다 완벽해진 OOP
Platform Independent
등 여러 장점을 가지고 있습니다.

속도 면으로 봤을 때도 알고리즘만을 구현한 프로그램의 경우, JIT compile 기법에 의해서 C/C++로 짠 프로그램과 거의 같은 속도를 보여줍니다.

C#도 이와 비슷한 장점을 가지고 있는 것으로 알고 있습니다.
Java의 좋은 기능들은 거의 포함하고 있죠.

제가 걱정이 되는 것은 워낙 Windows 기반이 강한 MS에서 C#을 모든 Platform에서 골고루 잘돌아가게 만들 수 있을까 하는 겁니다.
개발자들도 Windows 적인 생각을 많이 하게 될 위험성이 많고, Windows 쪽 VM에 더 무게를 두게 되게 쉽기 때문에 상대적으로 다른 Platform의 VM들의 기능이 떨어질 수 있지 않을까요?

익명 사용자의 이미지

글쎄요... 저도 자바를 몇년 사용해봤지만
한번도 c++ 정도 속도나온다는 말을 믿을수가 없네요
저도 알고리즘 공부를 자바로 하고 있는데..
c++ 이 백배는 빠른거 같거든요?
물론 실행중에는 비슷하다고는 하지만 로딩시간이 너무 깁니다
그리고
.NET OR JAVA VM
을 대체하는
INSTANT VM 이 나온다고 하네요
c++ ,c , object c,java 지원한다고 하고
빠른것도 같네요.. 차라리 이거에 기대를 해보겠습니다

익명 사용자의 이미지

intenet VM 아닌가?

익명 사용자의 이미지

포트 죽었을때 쓴거라 -_-

익명 사용자의 이미지

제가 말씀드린 건 실행중의 속도 입니다~
물론 로딩시간은 엄청 길죠 TT

bsheep의 이미지

오랫만에 글을 올려보네요..

제가 보기에도 c/c++가 더 빠르지 않을까 생각이 되네요.
그렇지만, java가 ArrayList나 Tree등을 사용할때
c/c++에서 STD를 사용한다면, 자바가 도리어 빠른 속도를
낸다고 합니다. c/c++에서 속도를 내는 것은 주로
프로그램어가 모든 메모리 관리와 어떤 변수가 어떤 스택에
가고 사용되고.. 등을 다 관리 해주었을 때만 최상의
속도 (자바를 많이 능가하는) 를 낸다고 합니다.

개발시간이 특히 더 촉박한 한국의 실정으로 좀 더 빠른 속도를
위해서 메모리 관리까지 다 해주는 것이 현실적인가요?
아니면, 참을수 있을 만한 속도에 빠르게 코드할수 있는 것이
더 좋을까요?

그리고 아쉽게도.. INSTANT VM 이 아니라 Internet VM입니다.
결국은 C를 bytecode로 변경하여, ivm에서 돌아가게 하는 것이고 합니다.
(물론 많고 높은 기술을 요구되는 것이며..)
결국 프로그램하기 어렵고 보안상 문제가 전혀 고려되있지 않다고 합니다.
보안이 전혀 없는 인터넷 프로그램을 실행시키고 싶은 사람은 별루
없을 것입니다. ^^

현재의 프로그래밍에서 중요한 것은 여러 사람과 협동하여
만들수 있는 것입니다. 강력하고 잘 정리된 API를 제공하여
쉽게, 일관적으로 프로그래밍을 할수 있게 하는 자바를 속도
라는 요소로 무시하지 말아주셨으면 합니다. 컴퓨터의 속도는
매우 빠른 속도로 증가하고 있고, 어느 순간에는 자바의 속도가
c/c++의 속도를 하드웨어로 충분히 커버할 것입니다.

c/c++에 특출난 요소를 더 이상 제공하지 못한다면, 자바에게
영원히 밀릴것입니다. 특히 자바가 더 배우기 쉬운 이 시점에서는요..

그리하여 c#의 출현은 기대반,두려움 반이지요..
(내용이 다르니.. 새로운 글로 쓰지요..)

익명 사용자의 이미지

궁금한게 있는데 어차피 OOP 적인 설계,
등등은 같은 것 아닌가 하네요.
거의 비슷한게 아닐까요? 무엇을 먼저하
든 조금만 더 배운다면 상대편의 진영으로
쉽게 넘어갈 듯한데요.
물론, 기초적인 부분에서의 언어를 뜻합니다.

익명 사용자의 이미지

OOP적인 설계의 원론적인 이야기로 무마하기에는 너무 어중간한 입장이 아닐까요?
그렇게 비슷이란걸 말씀하시면, Internet VM, Smalltalk, Objective C 도 다 같은데요.

논의 자체가 필요 없습니다.

익명 사용자의 이미지

위에위에분 말씀이 바로 그거같은데요
'내가 보기엔 논의자체가 필요없다.'

익명 사용자의 이미지

허허허허허허

익명 사용자의 이미지

이 시점에서 볼때, 2001년 2002년에 하셨던 미래 예측은.. 모두 잘못되었네요.
여전히 Oracle과 JAVA의 시대니까요.

익명 사용자의 이미지

지금이 오라클과 자바의 시대라니...

어이구~~

익명 사용자의 이미지

과거나 현재나 변함없군...

실력은 쥐뿔도 없으면서 손꾸락만 살아있는 찌질한 키보드워리어들...

ps. lamp? 지금 이글을 보면 얼마나 쪽팔릴까? 지가 무슨 예언자인양... 후후...

페이지

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.