제건 다지원하거든여?
char* 이먼지 아시고 말씀하시는거져? 그게있다고 무슨 인코딩을 지원안한다? 너무 어이없는소리네여..
그런 어이 없는 지식은 대체 어디서부터 가지게 되셨는지 몰라도.. 말도 안나오네여..
소스요? c 상용라이브러리들도 많구요. 일반 공개소스도 많으니 함찾아보세요.. google.co.kr 에서 보시면될꺼에여.
상용라이브러리나 회사소스 보여드려야할이유는 없겠져?
더구나 바로 이쓰레드에도 비슷한 함수 이미 누가 공개했져? 그거참고 하셔도되여..
그럼 님도 위에 사용한함수들 다좀 비슷한거라도 내놔바여.. 니가 알아서 찾아라하지마시고..
어떤 언어든지 문법 + API + 지원(라이브러리, IDE 등등)으로 되어있습니다. 이 세 가지를 모두 합쳤을 때는 C나 자바나 할 수 있는 건 거의 비슷하겠죠. 대신 자바는 '지원'의 영역에 속하는 것들을 문법이나 API에 미리 포함시킨 것입니다. 그런 의미에서 자바가 C보다 쉽다는 것이고요. 앞에서 문법 수준에서 자바가 더 쉽다는 사람은 없었습니다. 만약 문법만 가지고 따지면 C든 자바든 리습이나 하스켈 앞에서 버로우 해야 합니다.
그리고 harisoo님께서는 "C나 자바나 똑같지 쉬운 게 어딨냐"고 하시지만 적어도 자바는 메모리 관리가 자동으로 됩니다. 게다가 C가 더 쉽다는 익명 사용자도 있습니다만.
여기 저기에 써놓았지만 저는 자바를 쓰지도 않고 자바가 최고라고 주장할 생각도 없습니다. 그런데 말씀하신 "자바가 더 안 좋은 부분"은 누가 어떤 일을 하느냐에 따라 장점이 될 수도 있고 단점이 될 수도 있습니다.
예를 들어 'a'라는 문자 하나를 생각해봅시다. 이것은 ASCII 코드로는 97이죠. C에서는 이 두 가지가 근본적으로 구분되지가 않습니다. 그러니까 어떤 경우에는 간단하게 char capitalize(ch){ return (ch-32); }같은 코드를 작성할 수 있죠. 작성하기도 쉽고 속도도 빠릅니다. 적절하게 사용하기만 하면 자바보다 훨씬 낫습니다. 그러나 부적절하게 사용할 경우는 뒷감당할 수 없게 됩니다.
자바나 VB 같은 언어들은 C의 속도나 기능성을 일부 포기하더라도 프로그래머의 실수나 무능력으로 인한 부적절한 사용을 방지하는 데 주안점을 맞추고 있습니다. 그리고 그 결과는 상당히 긍정적입니다. 이 스레드에는 C가 쉽다고 얘기하는 사람이 몇몇 있습니다만 실제로 시장의 반응은 그렇지 않습니다. C로 개발되던 수많은 프로그램이 이제는 자바나 VB로 만들어지고 있습니다. 대부분의 프로그램에서 포인터로 메모리에 직접 접근해서 얻을 수 있는 장점보다 괜히 잘못 건드려서 세그먼트 폴트 에러가 나고 메모리 누수가 생기는 단점이 더 크기 때문이죠. 물론 운영체제를 만든다면 어떤 위험을 감수하고라도 직접 메모리를 조작해야겠죠. 그런데 그런 프로그램을 만드는 사람이 얼마나 되나요.
그리고 제가 여러 차례 질문했는 데 아무도 답이 없던데 다시 한 번 물어봅니다. C는 포트란보다 퍼포먼스가 떨어지고, 리습이나 하스켈보다 개발편의성이 떨어지죠. 그러면 C로 하는 일들을 전부 이 언어들로 해야할까요?
자바가 할 수 있는것은 c에서도 가능하다는 것이죠. 그러나 c에서 할 수 있는걸을 자바가 못할 수도 잇다는 것입니다.
이 말은 다르게 해석한다면 c에서는 쉽게 가능한데 자바는 어려운부분이 있다는 것입니다.
그렇기 때문에 자바보다 c가 쉽다는것에 대해서 이의를 제기한 것입니다.
위에서 제가 캐스팅부분에 대해 말한것도 이런 부분때문이고요..
실제 c에서 코딩할때는 다른 장비와 통신할때가 많습니다.
대개의 경우 프로토콜을 정해서 하죠. 이런 프로토콜은 ftp,http와 같이 알려진 프로토콜이 아니라서
장비와 통신할때는 맞춰줘야 합니다. 이럴경우 해당 데이터를 프로토콜에 맞춰서 읽어야 하는데
자바에서는 어렵다는 것이죠
어떤 언어든지 문법 + API + 지원(라이브러리, IDE 등등)으로 되어있습니다. 이 세 가지를 모두 합쳤을 때는 C나 자바나 할 수 있는 건 거의 비슷하겠죠. 대신 자바는 '지원'의 영역에 속하는 것들을 문법이나 API에 미리 포함시킨 것입니다. 그런 의미에서 자바가 C보다 쉽다는 것이고요.
위의 내용은 납득할 수 없습니다.
쉬운 예를 들어보죠
파일을 열어서 1라인의 내용을 가져오는 함수가 코드에서 필요하다고 합시다.
대개 c 초급자(제가 아직 이 등급에..)들은 만들어서 씁니다.
int ReadOneLine(unsigned char *line,int maxlen,FILE *fp,int *valid)
{
char *tmp;
int i, len;
if (!fgets(line, maxlen, fp))
return 0;
len = strlen(line) - 1;
line[len] = '\0';
for (i = 0; i < len; i++)
if (line[i] != ' ')
break;
if (i == len)
{
*valid = 0;
return 1;
}
if (line[i] == '#')
{
*valid = 0;
return 1;
}
*valid = 1;
return 1;
}
그러나 왠만한 중급이상은 저렇게 함수를 만들어서 사용안합니다.
기본 라이브러리(glibc)에서 제공하는 getline()함수를 사용하면 한줄이면 댑니다.
이런 상황에서 제 3자가 본다면 어느쪽이 쉬워 보일까요?
당연히 뒤쪽이겟죠. 쓴귤님이나 기타 다른 익명자님들도 c에서 제공하는
함수에 대해 다 알지 못하기 때문에 어렵다고 생각하지는 않는지요?
이 부분은 비단 c뿐만 아니라 자바에서도 마찬가지입니다.
위에서 예를 든 replace()함수도 알고잇는사람은 쓰겟지만,
모르는 사람은 위에 나온 코드처럼 만들어서 사용하죠.
자바에서 replace()라는 함수를 사용하기위해 자바가 제공하는 함수에 대해
알아야지 쉬운겁니다. 마찬가지로 c에서도 제공하는 함수에 대해 알아야지 쉬운겁니다.
c에서 기본적으로 제공하는 함수는 약 1108개입니다. 기본적으로 제공하는 함수만이죠.
이것도 다 알기 어려운데 다른 라이브러리에서 제공하는 함수는 얼마나 많을까요?
모르기때문에 어렵게 느껴지는 겁니다.
간단한 예를 들어 볼까요?
ftp로 자동로그인을 해서 파일을 다운로드하거나 업로드하는 프로그램을 만든다고 합시다.
제가 언어차원에서 지원되는 유니코드 지원을 사용하는거 맞습니다. 언어차원에서 char이 유니코드니까 처음 입력 받을때만 인코딩을 신경써주면 될뿐 그 다음 부터는 비교나 분리등의 문자열 처리시에 char를 그냥 글자 한글자로 다루면 됩니다.
그런데, 아직도 모르시겠나요?
프로그래머가 직접 수고해야 하는 많은 부분들이 언어나 플랫폼 차원에서 지원하게 되면 얼마나 편해지는지?
C 강력하죠. 이걸 부정하는게 아닙니다.
하지만 C는 강력한 만큼 고려해야 하는 부분도, 수고해야 하는 부분도 많습니다.
그래서 덜 수고하고도 비슷한 프로그램을 만들수 있는 언어차원이나, 플랫폼 차원에서 많은 일을 해주는 언어가 각광을 받는 거죠.
C에 비해 자바가 그랬고,
자바에 비해 파이썬이 그랬고, (언어차원의 테이블 지원이나 람다 같은건 지금 봐도 멋지죠.)
파이썬에 비해 루비와 루비온레일(웹어플리케이션분야)이 그러고 있죠.
이 "덜 수고할수 있다"는 것을 보통 쉽다고 이야기 하고요.
그런데 님께서는 C로 다른 언어에 비해 수고가 많은 것을 "어렵다"라고 인식하지 않으시는 거죠.
그리고 자바나 파이썬, 루비로 웹어플리케이션을 만든 수많은 사람은 C로 수고하는 것을 "어렵다"라고 인식하는 거고요.
님께서는 아마, 최적화되지 않은 어플리케이션을 죄악시하는 경향이 있을겁니다. 아마 그런 환경속에서 일을 하시겠죠.
반면에, 저와 비슷한 많은 SI 실무자들은 그러지 않아도 수없이 변하는 고객의 요구사항때문에, 조금 성능이 느리더라도 변경이나 작성이 쉬운 언어를 선택하는 겁니다.
자바의 WORA역시 요구사항의 변경에 맞춰줄수 있기 때문에 각광을 받은 것이죠. (고객이 "다른(더 빠른, 더 싼, 다른 벤더의) 서버로 바꾸고 싶은데요"라는 말하는 요구말입니다)
당장 1개월 내에 프로그래머 혼자서 게시판 수십개와 DB 테이블 수십개을 연결해서 물품 관리 웹어플리케이션을 만들어서 동작시켜야 한다.. 라는 고객의 요구사항이 있는데(실제로 경험한겁니다), 거기다 대고 "C가 쉬우니까 C로 만들어"라고 말할 사람은 별로 없습니다. 그때 저는 PHP로 만들었습니다. 개발 정말 빠르더군요. 2주만에 테스트 까지 끝냈습니다.
이때 제가 느낀 "쉬움"과 님이 가지고 계신 "쉬움"은 아마 다른 의미일 겁니다. (아마도 님의 쉬움은 더 성능이 좋은 어플리케이션을 만들기 위한 여러 툴들의 구비 여부겠죠. 메모리를 직접 관리할수 있는 포인터라던가 템플릿이라던가, 인라인 어셈이라던가..)
제가 가진 "쉬움"은 어플리케이션을 만들때 들여야 하는 노력과 시간을(비용) 말하는 것이고요.
그러니 같은 단어를 써도 서로 다른 의미인 셈이니 대화가 제대로 될리가 없죠.
하지만, 뭐 저도 글을 잘쓰는 편이 아니라, 게다가 인격자도 아닌지라^^ 이런 사실을 알면서도 글싸움을 좀 해봤습니다.
아마 님이 어느정도 수준이 되시는 분이라면, 제가 무슨 말을 하는지 아실거고,
아니라면야, 뭐 여태까지처럼 찌질대며 계속 싸움을 하게 되겠죠.
C는 무슨 라이브러리도 없는줄알고 어렵게 무조건 다만들어야되는줄아시는모양인데.. C도 라이브러리 엄청많고..공개소스도 엄청많고.
자바에비해 구현방법이나 테크닉도 훨씬 많거든요.?
자바는 라이브러리쓰면되고 C는 라이브러리 안쓰는줄아세여? 대부분 다 라이브러리 쓰지 안쓰는데가 있나요?
자바는 라이브러리 구축이 매우 힘들지만 C는 라이브러리 만들어내는거도 정말 다른언어에비해 누워서 떡먹기입니다.
그래서 재미로나 혹은 최적화를 위해 직접구현하는사람도 많구요.. 자존심때문에 그렇게 하는사람도 많아요.. 있는거 쓸려면 다써요..
사실 자바쉽다구요? 그쉬운 자바소스 거의 그대로 C도 되거든요.. 즉 자바로 되면 그대로 C도 됩니다. 최소한 C가 자바보다 어렵진 안아요.. 거기다가 포인터란 강력한도구도 있으니 C가 더쉽게 된다는건 두말하면 잔소리겠죠?
>> 그럼간단히 스트링내의 원하는 문자 제거하는 함짜보세여 예를들면 스페이스라던가..
>> 아니그냥 간단히 "skdkglsldslfldsf dskfkfsls ** dflsdf" d 제거하여 "skkglslslflsf skfkfsls ** flsf" 요렇게 되는거 만들어보셔요. 말만하지마시고. 얼마나 쉽게 되나 함바여..
그래서 멀티 인코딩 되는 C코드 한번 보자니까요?
실행 예랑 좀 보여줘 보시죠? 버그 있는 코드는 잘만 컴파일하고 실행 예 올려주시더니 유니코드 지원하는 Replace 코드좀 보자니까 왜 못보여주시나요?
음... 저는 소위 말하는 '자바 예찬론자'입니다만, 굳이 속도면에서 C++ 보다 느리다는 건 부정할 필요를 못 느끼겠습니다.
위에서도 나왔지만 자바의 철학은 '모든 환경에서 최고의 성능을'이 아니기 때문이죠. 위에서 어떤 분이 JIT 컴파일러의 최적화로 인해
C/C++에 비해 떨어지지 않거나 '일부분에서는' 오히려 우수한 성능을 보인다고 하신 말은 맞습니다. 그렇기 때문에 '충분히' 빨라진거죠.
하지만 그럼에도 불구하고 네이티브 언어보다는 느립니다. 각종 최적화 기법 때문에 앞서는 벤치마킹도 그 기법을 그대로 적용해준다면
네이티브 언어가 당연하게 더 빠르다고 답하신 분의 말도 맞는 말입니다. 만약 완벽하게 동일한 작업을 수행하는 자바 프로그램과 C/C++
프로그램이 있다면, 당연히 자바가 더 느립니다. 굳이 '그렇지만...' 이라고 덧붙일 필요를 못 느끼겠군요.
물론 편견을 가지고 아무런 근거없이 (어느정도 느리다도 아닌) 무조건 느리다고 말하는 사람을 볼 때, 울컥하는 건 사실입니다만 모르는 건
죄가 아니니 그냥 그러려니... 합시다.
저는 다시 원점으로 돌아가서 '8배 느리다?'라는 부분을 살펴봤으면 좋겠습니다. 수치가 문제가 아니라 질문의도가 '그렇게 못쓸 정도로 느리냐'
라는 걸로 보이는군요. 과연 8배나 느린가요? 정상적인 경우라면 그렇게 심각하지는 않습니다. 어떤 프로그램이 똑같은 언어로 쓴 다른 것보다
8배나 느리다면 그건 코드를 잘못 쓴 겁니다. C/C++을 아주 좋아하시는 몇몇 분들이라도 '자바가 느려서 이 프로그램이 C/C++로 짠것보다 8배
나 느린거야'라고 말씀하시지는 못할겁니다. 아, '이건 C로 만들었기 때문에 0.01초가 걸리고 이건 0.08초가 걸린다'라는 건 가능하군요.
하지만 '이건 C++로 짜서 1초가 걸리고 저건 자바로 짜서 8초가 걸리는거야!'라고 할 수는 없을 겁니다. '자바가 8배나 느리다'라는 말은
0.01초가 승패를 가르는 환경이 아닌 일반적인 경우라면 '말도 안되는 편견'입니다.
(개인적으로는 정상적인 자바 프로그램은 네이티브 코드에 체감속도가 10~20% 정도 느리다고 생각하고 있습니다. 실제 언어 자체의 속도를
떠나서 기본 클래스 라이브러리인 스윙이나 기타 등등의 문제로 말이죠)
하지만 저는 2초만에 응답하는 C/C++ 대신에 한참이 지난 2.2초가 되어서야 응답하는 자바 프로그램을 다음과 같은 이유로 선호합니다.
- 깔끔하고 읽기 쉬운 코드를 '상대적으로 더 쉽게' 작성할 수 있기 때문에(가독성이 높으면 유지보수도 쉬우니까)
- 한번 작성해서 여러 플랫폼이나 타겟에서 실행할 수 있기 때문에
- 메모리 관리가 귀찮아서!
- 썬의 Write Once, Run Anywhere라는 철학이 맘에 들고 오픈된 정책과 오픈소스 소프트웨어가 맘에 들어서 (Nice Eclipse!)
- 설마 사용자가 이걸 10번 실행한 다음 속도를 측정하고 '2초나 차이나잖아!'라고 외치지는 않겠지... 하는 생각에...
- 고작 10MB 가량 되는 JVM 용량 때문에 외면받는 프로그램이라면 뭘로 짜든 가치가 없다고 생각하기 때문에
만약 다음에 해당하는 사람이라면 자바가 기분나쁠 수도 있겠군요 (쓸데없는 기능이 주렁주렁 달려있으니)
- C/C++로도 충분히 가독성이 높은 코드를 작성할 수 있는 숙련된 프로그래머
- 프로그램 실행속도를 우선시하는 프로그래머
- 플랫폼 독립성 같은 괜히 이상적인 환경이 필요치않는 프로그래머
- 메모리 관리나 포인터 활용 등을 자유자재로 다룰 수 있어서 없으면 불편함을 느끼는 프로그래머
다시 읽어보니 굉장히 뻔뻔한 ('뻔'할 '뻔'자인) 내용이군요. 음... 그냥 그런 걸 어떡합니까...
뭐, 아니면 어떻습니까...... 각 지역과 나라마다 국어와 방언이 있고 모두가 거기에 자부심을 가지는게 당연한거니까요 ^^
자바느린건 맞는것 같고요. io쪽은 심하죠 nio나오면서 좋아 졌을려나 메모리 많이 먹고
생산성은 자바언어의 특성에 기반하기 보단 지원해주는 lib가 강력한 것이고
c에 동일한 종류의 lib이 잔뜩 있다면 생산성에 많은 차이는 없을듯하고요.
접근성은
두초보가 붙는다면 자바가 많이 우세할듯
두능숙이 붙는다면 약간 자바가 우세할듯
플랫폼에 무관하다는건 엄청 좋은것 같고요.
이상 주관적인 생각이었습니다.
개인적으로 자바에서 가장 마음에 안드는것.. 메모리 많이 잡아먹는것.
이클립스하나띄워도 150메가 울~~~~ 물론기능이 많지만
visual studio 는 1/10쯤되려나.
제발 jvm하나에 다중어플리케이션(?)좀 지원해라 ㅡ,.ㅡ
나온다나온다 하더만 아직도 안나오네 그려...
자바 느린건 맞는것 같다라.. NIO 나온지가 언제쩍 얘긴데.. 많이 좋아졌는지 안좋아졌는지도
잘 모르시는군요.. 거의 x이버 지식인에서 방금 검색한 따끈따끈한 수준의 정보군요..
Onjava.com에서 4년전쯤 type4 jdbc 드라이버와 type2 jdbc 드라이버 의 벤치 결과를 포스팅한적이 있습니다.
그결과를 검색해보시고, 주장하시기 바랍니다.
그리고, C에 동일한 종류의 LIB이 잔뜩있다라..
협업 가능성이 적은 소규모 개발 Domain에서의 비슷한 수준의 개발자들끼리 작업한다면,
C/C++이나 Java나 거기서 거기라고 생각합니다. Java가 조금더 좋긴 하겠죠.. 문법적 Simple함에서 오는
개발도구의 엄청난 편의성 때문에.
그러나 협업가능성이 많은 대규모 개발 Domain이나 향후의 유지보수를 감안한다면,
C/C++의 생산성과 꽉막힌 Flexibility는 태생적으로 Java의 그것과 비교할수가 없겠죠.. 이것마저 인정안하시는
분들은.. Java자체를 부정하는 것이며, Java가 현재와 같이 EE 환경에서 Prevalent한 현실을 인정하지 않으시는 분들이겠죠.
예를들어, .XLS를 디코딩해주는 루틴을 쓰고 싶을때, Java에는 세상에 널려있는 Excel관련 라이브러리의 JAR를 Classpath에 잡아주고,
단순히, API-DOC을 보면서 쉽게 개발하죠.. Unix / Linux쪽에서 C/C++에서 이와 같이 '쉽게' 이용가능한 XLS decoding library가 있나요.
물론, 개발해서 쓸수는 있겠죠.. C/C++에서도.
그리고 성능.
Java의 성능은 분명, 많은 경우 C/C++에 비해 떨어집니다.
그러나 많은 경우 이런 성능저하는 그리 크지 않고, 문제되지도 않지요. 특히나 Server side app. 의 경우엔 특히나.
또한, C/C++에서는 단순히 컴파일 타임 최적화만 가능합니다. 물론.. 런타임 최적화가 가능하긴 합니다만..
컴파일후, 몇번 실행해보고, 실행된 정보를 다시 컴파일러에 annotate해서 이 정보를 갖고 컴파일 타임 최적화를 수행하는 정도죠..
이런 수준의 최적화는 JVM내에서 이루어지는 최신의 런타임 최적화에 비해서는 정말 세발의 피죠..
특히나, 모든 system call을 프로그래머가 직접 코딩하는 것이 아니라, VM에서 intelligent하게 하므로,
상대적으로 system call을 줄일수 있게되고, 이에 따라 C/C++에 비약적인 성능 향상을 꽤할수가 있지요.
물론,,.. C/C++에서도 GC를 사용가능케 하는 기술들이 있습니다만.. 그런 여러가지 기술들을
사용한 코드와 그렇지 않은 코드간의 Compatability가 전혀 없다는 측면에서 Java나 기타 다른 VM기반의 랭귀지의 그것과는 한 수준 아래죠. 또한 그런 변종 라이브러리들의 성능이 최신의 JVM의 그것과 비교해서 얼마나 더 세련된 관리를 하는지도 의문입니다.
모든 랭귀지는 다 나름의 강점이 있습니다.
C를 써야 하는 App.이 있고, C++을 써야하는 App.이 있고, Java를 써야 하는 App.이 있죠.
디바이스 드라이버를 개발하는데 Java를 쓸수도 없는 일이고, 웹게시판을 만드는데, C-CGI를 쓰는것도 웃긴일이죠.
3d겜을 개발하는데 Java를 쓰는것도 웃긴일이죠.
개발자가 할일은.. 각 언어의 장단점을 잘 파악해서 상황과 스펙에 맞는 최적의 솔루션을 찾아내느것이죠.
잘알지도 못하면서, 자기가 하는 언어가 최고라고 자부하면서 다른 언어의 장점을 깔아뭉개면서 현실을 인식하지 않는
우물안 개굴의 태도는 버려야 한다고 생각합니다.
답글 달때는 글을 대강읽지말고 자세히 읽으시기바랍니다.
제글 및에 답을 다셨는데 상상의 나래가 너무 심하시군요^^;
인신공격성 글들은 배제 하시기 바랍니다.
이야기할때 상대방과 의견이 다르다고 비꼬면 수준이 낮은 토론자일뿐입니다.
그러한 태도는 고쳐할 점입니다. 말 조심하기 바랍니다.
주장한적도 없고 주관적인 생각일 뿐이라고 했습니다.
java gui와 일반(?) gui보면 응답성이 떨어집니다.
요즘같은 컴퓨터에서 프로그램의 응답성이 떨어지는걸 느끼지때문에 ...
이러한 느낌은 객관적일 수 없으니 주관적이라 써놓았습니다.
io는 많이 늦은 건 밝혀진 사실이고 nio의 성능에 대한 이야기는 듣지 못했기 때문에 ?형식으로 남겨뒀습니다.
동일한 lib와 동일한 framework이 존재할 때 c++이 java보다 어떤점에서 더 유리한가요?
gc기능?
런타임 최적화에 대한 오버헤드는 없나요?
system call호출해야 되는곳에 자바는 어떻게 피해가나요?
system call의경우 대부분 실시간으로 변하는 os level의 정보를 입출력하는데 사용하는데
호출하지 않고 어떻게 정보를 입출력하나요? os level의 정보가 캐싱되나요 이게되나?!
io작업을 모아서 콜하나요? 그럼 빨리써야하는 작업은? 어떤콜들을 어떻게 최적화하는지 궁금...
관련회사들은 잘 포장해서 설명할뿐입니다.
자바의 유비보수,플렉서블?
자바는 인터넷 인프라(마케팅 여기서 성공했죠)와 접근성(쉽다는것 c에비해) ....
Testing raw NIO performance
Posted by: Dion Almaer on 4? 05, 2004 DIGG
Cameron has written about his experience with NIO, which he uses in Coherence. He talks about how it is maybe slower than you think, and gives test code so you can see the results for yourself.
Excerpt
One of our early concerns with NIO was its raw performance, and for good reason: In it's original JDK 1.4.0 release, performance was terrible. By the 1.4.2 release, the performance had improved (in some tests) by a factor of 3:1, and you can see in the following test output that it's "only" about 3x slower than putting data into a byte array, and "only" about 4.5x slower than accessing data from a byte array. Since there should be nothing theoretically faster than accessing data from a byte array, this is impressive, right?
Read Cameron Purdy in Raw NIO Performance
일단 자바가 느립니다.
위에서 많이 안느리다고는 하나 실제로 짜여진건 밴치마크의 셈플처럼 전부 저런코드만 있는게 아닙니다.
대부분 스트링처리나 네트웍 db 그래픽 관련 인데 그런곳에서는 매우큰차이가 있습니다.
윗쪽에 스트링처리하나만하더라도 자바는 범용함수를 사용하여구현해야하는반면 c 는 그자체엔진에 적합한 맞춤형함수를
사용할수 있기때문에 성능차이는 매우큽니다. 함수하나에서만해도 수백%이상 성능차이가 나죠..
어쨋거나 전체적으로 따져보면 꽤성능차이가 납니다. 10~20% 정도가 아니고 보통 수백% ~수천% 정도 성능차가 납니다.
못믿으시겠지만 사실입니다..
단적인 예로 자바로 스타크레프트 만든다면 어찌될지...아마도최소한 10배는 느릴겁니다.
그렇다고 자바가 전혀 쓸모 없는것이란 말은 아닙니다. 누구나 공감하듯 개똥도 약에쓸일이있다고 그리 속도가 중요하지 않은곳에 쓰입니다.
하지만 분명한건 자바하시는분들은 왜그리 속도도 빠르다고 우기시는지..그건 아니라고 봅니다.
아마도 sun 의 자신들의 자바를 홍보하기위해 내놓은 그런 말만믿고 사실믿고 싶겠죠.. 그걸그대로 말하는경향이 있습니다.
이런 말들은 과거에는 없었는데 자바가 나오면서 이런현상이 나타나는것같습니다..
역시 자바때문에 말들이 많네요...
UTF-16으로..
UTF-16으로 0x1064 는 제대로 지원 않하는데요? ^^
그밖에도 UTF-16으로 0x64가 들어가는 모든 글자가 몽땅 깨지는 군요
심지어는 0x0064도 깨지네요. 다음 글자를 깨먹으니까요.
유니코드 개념도 모르시네...
아무리 익명이라지만
지킬건 지키세요
넷티켓이라는 단어가 왜 생겻는데요
여기는 프로그램에 대해 토론하고자 하는것이지
남을 비하하는 곳이 아닙니다.
그리고 자신이 잇다면 본래아이디로 접속하세요
비겁하게 익명으로 하지마시고
제가 밑에 올린 코드에서도 안대는지 확인해보세요.
다 지원한다면서요?
>> 위에작성된 C코드는 한글이건 유니코드 UTF-8 이든 전혀수정없이 요구사항을 완벽히 지원하는 소스입니다.
완벽히 지원한다면서요? UTF-16은 유니코드가 아닌가보죠?
논의 주제는 "코딩이 쉽냐 아니냐" 였죠.
자꾸 메모리 사용이니 뭐니 하면서 성능쪽으로 몰고 가시지 말고 처음에 논의시작이였던 코딩이 쉽냐를 이야기 해보자니까요.
주제도 님이 정하신 문자열 치환으로 한정해서요.
아래쪽의 코드가 쉽나요?
이 코드 하고
이코드나
똑같은 코드로 유니코드도 지원하는 이코드하고
어느쪽이 쉽다고 생각되세요?
아 물론 님께서는 C쪽이 쉽다고 생각되시겠죠?
헷깔려 하시는분이
헷깔려 하시는분이 있는거 같아 말씀드립니다.
전 애초 C소스 aaa()와 bbb() 만든사람입니다.
replace() 는 다른익명님이 만드신겁니다. 헷깔리지마세여..
님이 한말이죠?
>> 살펴보면 님은 함수도 쓰셨고 함수내부에서도 또 루프를돌며 무언가 작업을 하겠죠?
>> 일단 부하도 그렇거니와 구현자체도 C는 함수를 사용하지않고도 간단히 처리되는데반해 자바는 함수를 쓰고도 간단하지 않군요..
>> 대체머가 쉽다는건지..
와, 몇몇 명사만 치환하면 제가 드리고 싶은 말 그대로네요 ^^
C는 함수를 14번이나 호출하네요. 함수도 쓰셨고 함수 내부에서도 또 루프를 돌며 무언가 작업을 하겠죠? 함수를 쓰고도 간단하지 않네요?
정말 함수 않쓰고 간단히 처리되는쪽은 자바였군요 ^^
이러니 님이 뭘 모른다고 하는 겁니다.
그래서 님이 단순하다는 겁니다.
왜 위에 님들이 님보고 답답해 하는줄 모르시나 보네요
님이 제시한 코드는
단순히 d값이 잇을경우 dd로 바꾸는 것이고
제가 제시한 코드는
바꾸고싶은 문자나 문자열을 다른 문자나 문자열로 바꾸는겁니다.
단순히 d를 dd로 바꾸는것이라면 님이 제시한 코드로 충분합니다.
다만 제가 그 코드를 작성한것은
자바에서의 replace()함수의 결과랑 동일하게 나올수 잇는 c함수를 만들고자 한거죠
그리고 제글을 보셧다면
밑에 작성된 글에서 제가 프로그램 사용의 예를 보여준 부분은 보지 못하셧나요?
밑의 예제에서 d를 dd로 바꾸도록 되어 잇나요?
다른 사람을 비판하시려면 최소한 코드가 어떤의도로 작성되엇는지 확인하셔야죠
그리고 14번이나 함수를 호출한걸로 머라고 하시는데
자바에서도 제가 만든거랑 비슷하게 해보세요
14번이 나오든 적게 나오든 많이 나오든간에
님이 위에서 제시한 코드보다는 함수호출이 많이 나오겟네요
마지막으로 kldp에 방문하실정도면 왠만한 성인이실건데
기본예의부터 가지세요
다시 비교할까요?
replaceAll인가요?
C
Java (JDK 1.2 기준. 쉽게 말해 요즘에 비해 비효율적인)
자 어느쪽이 쉬워 보이시나요?
똑같은 replaceAll이고, 자바쪽은 추가적으로 유니코드나 다른 인코딩도 지원합니다.
왜 C로 된거 컴파일도 않해보는지 아시겠나요?
char *replaceAll(char * str,
char *replaceAll(char * str, char * findStr, char * replaceStr)
{
char *sp, *buf;
int i, j;
for( compare() ) bufcpy( buf, str, replacStr );
buf = 0;
return buf;
}
제가 사용하는 리플레이스 함수는 님꺼보다 훨씬간단 한데요..
자바는 너무 길고 어렵네요..
compare() 는 어디로 갔나요?
compare()는 어디로 갔나요??
그리고 이 코드가 서로 다른 인코딩으로 만들어진 문자열들을 지원하나요?
str이 utf-8이고 findStr이 utf-16, replaceStr이 euc-kr인 경우 같은거요?
같은 기능을 비교해보자니까요.
데이타도 드리죠.
원문 : 한글테스트
EUC-KR : c7 d1 b1 db c5 d7 bd ba c6 ae
UTF-8 : ed 95 9c ea b8 80 ed 85 8c ec 8a a4 ed 8a b8
UTF-16 : fe ff d5 5c ae 0 d1 4c c2 a4 d2 b8
원문 : 한글
EUC-KR : c7 d1 b1 db
UTF-8 : ed 95 9c ea b8 80
UTF-16 : fe ff d5 5c ae 0
원문 : 영어
EUC-KR : bf b5 be ee
UTF-8 : ec 98 81 ec 96 b4
UTF-16 : fe ff c6 1 c5 b4
님은
님은
StringBuffer();
indexOf(findStr, lastindex)
append()
substring(lastindex, indexOf)
이런거 다어디 갔나요?
님코드는 한글조합형도 지원하나요?
제건 다지원하거든요?
제말이 같이 비교해보자니까요..
한글 조합형 지원하는데요.
자바,한글 조합형 지원하는데요 ?
다른 인코딩으로 된 변수들의 비교 지원하세요? 님 함수로는 죽어도 지원 못할텐데요. char* 이거 쓰는 이상. 인코딩을 알수가 없잖아요. 뭐 비교전에 인코딩전환을 시도하여 같은 인코딩으로 만들어 주면 가능하겠네요. 그 인코딩 전환 코드는요?
소스요? JDK 받으시면 안에 src.zip이라는 거 있으니까 한번 보세요. java/lang/StringBuffer.java 보시면 될꺼에요.
Ps. 같이 찌질 거려 드리니까 좋나요? ^^
제건
제건 다지원하거든여?
char* 이먼지 아시고 말씀하시는거져? 그게있다고 무슨 인코딩을 지원안한다? 너무 어이없는소리네여..
그런 어이 없는 지식은 대체 어디서부터 가지게 되셨는지 몰라도.. 말도 안나오네여..
소스요? c 상용라이브러리들도 많구요. 일반 공개소스도 많으니 함찾아보세요.. google.co.kr 에서 보시면될꺼에여.
상용라이브러리나 회사소스 보여드려야할이유는 없겠져?
더구나 바로 이쓰레드에도 비슷한 함수 이미 누가 공개했져? 그거참고 하셔도되여..
그럼 님도 위에 사용한함수들 다좀 비슷한거라도 내놔바여.. 니가 알아서 찾아라하지마시고..
변수마다 들어간 데이터가 다른데요?
원문1 : 한글테스트
EUC-KR : c7 d1 b1 db c5 d7 bd ba c6 ae
원문2 : 한글
UTF-8 : ed 95 9c ea b8 80
원문3 : 영어
UTF-16 : fe ff c6 1 c5 b4
이런 문자열 데이터가 3개의 char * 포인터 src, find, replace에 각각 들어 있을때
님의 함수로 src에서 find를 찾아서 replace로 바꿔도 글자 인코딩 않깨져요? 뭐 찾아지지도 않겠지만.
제발좀 인코딩 정보가 없는 로데이터를 plain text라고 보고 처리하는 80년대식 코드는 좀 버리세요.
그리고 자바는 String이 내부적으로 인코딩 정보를 가지고 있고, char도 마찬가지입니다. 그래서 여태까지 보여드린 모든 코드가 유니코드나 다른 인코딩으로 된 걸 모두 지원해요.
변수마다 들어간
변수마다 들어간 데이터가 다르지 그럼 같은거 머하러할까요?
글짜가 깨지긴왜깨져요. 님같이 생각하니까 안데져..자신이할줄모른다고 남도 못할꺼라생각마세요..제발.
님이 만든게 않보이긴 하지만
결국 replace( src, find, replace) 이런 모양일꺼잖아요?
char * src = { 0xc7, 0xd1 , 0xb1 , 0xdb , 0xc5 , 0xd7 , 0xbd , 0xba , 0xc6 , 0xae}; // 한글테스트 의 euc-kr raw data
char * find = { 0xed , 0x95 , 0x9c , 0xea , 0xb8 , 0x80}; // 한글 의 utf-8 raw data
char * rep = { 0xfe , 0xff , 0xc6 , 0x1 , 0xc5 , 0xb4}; // 영어 의 utf-16 raw data
일때
replace(src, find, rep);
하면
님의 함수가 정상 동작하나요 ? ^^
못하니까 자꾸 다른데로 빼지 마시고요 ^^
정상동작하거든요?
정상동작하거든요? 어쩌라고요?
어이 없는사람이네. 뭐 자바만 한글되고 C는 한글도 안되는줄아시나?
웃겨서정말.. 수준이하 소리좀 그만하세요.. 유치해서 답변못해드리겠네여..
그 정상동작한다는 코드좀 보여주세요?
진짜로 있긴해요?
남의 소스를 함부로
남의 소스를 함부로 내놔바라? 남의 소스 공짜로 먹겠단 심보슈?
일정금액을 지불하시죠..
회사소스는 양심것 보여드릴수가 없고. 제가 직접만들어서 드리지요..
현제까지 보여준거도
현제까지 보여준거도 인정안하면서 무슨 찌질하게 달라붙어요..
애초 요구사항에서 벌써 몇번을 이거해봐라 저거해봐라 했죠?
애초요구사항에 대해선 자바가 속도도엄청떨어지고 구현하기도 힘들다는것부터 인정하시죠..
그러고 다음을 진행합시다.
인정할줄도 모르는 무식한사람과는 이제 대화안할테니 혼자떠드세요..
여태까지 여기 나왔던 코드 다 사용해 봤는데 않되던데요?
누가 C가 유니코드나 한글 지원 못한데요?
님의 제시한 함수로는 않되니까 그렇지
이제 제발 자바가
이제 제발 자바가 쉽다느니 빠르다느니 그런 무개념소리하지마세요..
자바가 쉽긴 머가 쉽나요..
C는 최소한 포인터도 몰라도 자바처럼 똑같이 짤수도 있어요..
거기에다가 포인터만 알면 더쉽고 간편하고 빠르게도 짤수있죠..
제발인정할건 하세요..
자바가 훨씬 쉽죠
문자열 몇개 처리하는데 온갖 라이브러리 동원해야 하는 C보다
언어레벨에서 유니코드/멀티인코딩 지원해서 일본어,한국어등등 여러나라 언어를 섞어쓸수 있는 자바가 훨씬 쉽죠
제발 인정할건 좀 하세요.
언어레벨에서든어디
언어레벨에서든어디서든 지원받아야만할수있고 없으면 하지도못하고 하늘만쳐다봐야하는 자바보다
로우레벨 비트및 포인터 컨트롤까지 다할수 있어 라이브러리 없어도 다할수있는 C가낮죠.
그리고 흔한 라이브러리 하나 붙여도되고.
하여튼 말도 안되는 어기지떼붙이시네요.
누가 C 강력하다는거 부인했습니까?
어떤 쪽이 쉬운가 보자면서요?
>> 그리고 흔한 라이브러리 하나 붙여도되고.
그럼 자바쪽이 쉽다는 건 인정?
말뜻을 못알아
말뜻을 못알아 먹으시네.. 그러니 자바보다 쉽다는겁니다..
유니코드/멀티인코딩 지원하는 replace 하나 제대로 제시 못하시면서
유니코드/멀티인코딩 지원하는 replace 하나 제대로 제시 못하시면서 C가 쉬워요 타령만 하고 계시네요 ^^
제가 제시해 드린 코드는 모두 유니코드/멀티인코딩 지원하거든요?
웬엉뚱한 소리세여?
웬엉뚱한 소리세여? 저기윗쪽에 제가 제시한 님보다도 더간단하면서 유니코드/멀티인코딩 다지원하는거 안보이세여?
몇번을 보여드려야되여?
님같이 눈귀다틀어막고 사시니 걍 혼자 많이떠드세요..
이미 여테나온걸보니 역시 자바는 말뿐이고 속도늦고 코딩도 어렵고 라이브러리 없으면 하늘만쳐다봐야되고..
말로만우기고 끝까지 인정도 못하고 그게결론이네요..
프로그래머가..
컴파일 되는 코드하나 제시 못하면서 말만 많은게 C 프로그래머였군요 ^^
뭐 보아하니 할줄 모르는거 같은데, 말만 앞세우지 말고 컴파일되는 코드를 보여달라니까요?
내가 못하는 사람에게 너무 밀어 붙였나?
못하는 사람은 못하는 사람나름대로 자존심이 있으실텐데, 자꾸 못한다 못한다 해서 미안합니다. ^^
무식하면 쵝오~!
무식하면 쵝오~!
자바에서는..
아마, 함수를 사용하면 C도 이렇게 쉬워진다를 말하고 싶으신거죠?
java.lang.String 에는 replaceAll 이라는 이미 잘 작동하는 메소드가 있습니다.
이렇게 쓰면 끝입니다. 훨씬 간단하죠?
C 에서도.. replace( src,
C 에서도..
replace( src, find, replace );
이렇게 쓰면 끝입니다 더간단하죠?
애들 장난이 되가는데요^^
받는거 없는 replace코드인가요? ^^
src.replaceAll( find, replace);
흠 All에 해당하는 글자만큼은 간단하네요. ^^
결국엔 님께서는 제대로 된 코드는 못짜신다고 보겠습니다 ^^
먼
먼 엉뚱한소리세요?
이제보니 무개념이다 무개념이다 님같으신분 첨보네여.. 허허허..
받은게 없다니요..? 함수가 먼줄은아세여? 제발 개념좀잡고 말씀하세여.. 아규먼트가 먼지부터 좀찾아보고오세요..
src로 뻔히 받는데 받는게 없다니여?
결국 "결국엔 님께서는 제대로 된 코드는 못짜신다고 보겠습니다 ^^" 요말은 님한테 해당한다는걸 아시겠져?
너무 고집피우시는거
너무 고집피우시는거 아니에요? 인정할건합시다.좀.
자바로 더간단하게..(애들 장난이군요^^)
s.r(f,r);
와 이것보다 짧을수는 없겠는데요. 알골기반의 언어에서는.
천만에요. C
천만에요. C 에서는
S
로도됩니다.
인정
그런데 매크로 S의 정의좀 보여주시죠?
s.r(f,r); 님부터
s.r(f,r);
님부터 요고좀 보여주시죠..
자 님논리대로 해봅시다.
위 append() substring()이 c에도 분명 라이브러리로 있겟지요
다만 제가 허접해서 어느 라이브러리에 잇는지 모를뿐입니다.
없다면 만들면 되지만요.
어쨋든 이런 라이브러리가 하나 있다면 코딩이 쉬운거겟네요?
이 글타래에서 코딩이 쉽다 어렵다는 라이브러리의 도움없이 작성하는걸 말하는겁니다.
물론 기본 라이브러리는 잇어야겟죠
님이 자바에서 지원하지 않는 함수를 만든다고 생각해 보세요
c나 자바나 똑같지 쉬운게 어딧습니까?
ps.회사에서 눈치보면서 만들엇지만 다시 댓글 다시면 퇴근 후에 답변드리죠.
이 글타래에서
어떤 언어든지 문법 + API + 지원(라이브러리, IDE 등등)으로 되어있습니다. 이 세 가지를 모두 합쳤을 때는 C나 자바나 할 수 있는 건 거의 비슷하겠죠. 대신 자바는 '지원'의 영역에 속하는 것들을 문법이나 API에 미리 포함시킨 것입니다. 그런 의미에서 자바가 C보다 쉽다는 것이고요. 앞에서 문법 수준에서 자바가 더 쉽다는 사람은 없었습니다. 만약 문법만 가지고 따지면 C든 자바든 리습이나 하스켈 앞에서 버로우 해야 합니다.
그리고 harisoo님께서는 "C나 자바나 똑같지 쉬운 게 어딨냐"고 하시지만 적어도 자바는 메모리 관리가 자동으로 됩니다. 게다가 C가 더 쉽다는 익명 사용자도 있습니다만.
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
자바가 더 안 좋은 부분도 있습니다.
대표적인 예가 캐스팅부분이죠
자바에서 스트링을 short,double형으로 쉽게 바꿀 수 있나요?
그리고 unsigned 자료형을 지원하는지요?
여기서 더 나아가 구조체형식을 쉽게 읽을 수 있나요?
모두 안하는걸로 알고 있습니다.
c에서는 간단합니다.
캐스팅하면 끝이죠
그러나 자바는 이러한 것을 처리해줄 함수를 따로 만들어야 하지 않나요?
자바가 모든 부분에서 좋진 않습니다
여기 저기에 써놓았지만 저는 자바를 쓰지도 않고 자바가 최고라고 주장할 생각도 없습니다. 그런데 말씀하신 "자바가 더 안 좋은 부분"은 누가 어떤 일을 하느냐에 따라 장점이 될 수도 있고 단점이 될 수도 있습니다.
예를 들어 'a'라는 문자 하나를 생각해봅시다. 이것은 ASCII 코드로는 97이죠. C에서는 이 두 가지가 근본적으로 구분되지가 않습니다. 그러니까 어떤 경우에는 간단하게 char capitalize(ch){ return (ch-32); }같은 코드를 작성할 수 있죠. 작성하기도 쉽고 속도도 빠릅니다. 적절하게 사용하기만 하면 자바보다 훨씬 낫습니다. 그러나 부적절하게 사용할 경우는 뒷감당할 수 없게 됩니다.
자바나 VB 같은 언어들은 C의 속도나 기능성을 일부 포기하더라도 프로그래머의 실수나 무능력으로 인한 부적절한 사용을 방지하는 데 주안점을 맞추고 있습니다. 그리고 그 결과는 상당히 긍정적입니다. 이 스레드에는 C가 쉽다고 얘기하는 사람이 몇몇 있습니다만 실제로 시장의 반응은 그렇지 않습니다. C로 개발되던 수많은 프로그램이 이제는 자바나 VB로 만들어지고 있습니다. 대부분의 프로그램에서 포인터로 메모리에 직접 접근해서 얻을 수 있는 장점보다 괜히 잘못 건드려서 세그먼트 폴트 에러가 나고 메모리 누수가 생기는 단점이 더 크기 때문이죠. 물론 운영체제를 만든다면 어떤 위험을 감수하고라도 직접 메모리를 조작해야겠죠. 그런데 그런 프로그램을 만드는 사람이 얼마나 되나요.
그리고 제가 여러 차례 질문했는 데 아무도 답이 없던데 다시 한 번 물어봅니다. C는 포트란보다 퍼포먼스가 떨어지고, 리습이나 하스켈보다 개발편의성이 떨어지죠. 그러면 C로 하는 일들을 전부 이 언어들로 해야할까요?
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
[Re:]자바가 모든 부분에서 좋진 않습니다
먼가 오해가 있으신거 같은데..
늦엇지만 답변드릴게요.
제가 이 글타래에서 댓글을 단것은
자바가 할 수 있는것은 c에서도 가능하다는 것이죠. 그러나 c에서 할 수 있는걸을 자바가 못할 수도 잇다는 것입니다.
이 말은 다르게 해석한다면 c에서는 쉽게 가능한데 자바는 어려운부분이 있다는 것입니다.
그렇기 때문에 자바보다 c가 쉽다는것에 대해서 이의를 제기한 것입니다.
위에서 제가 캐스팅부분에 대해 말한것도 이런 부분때문이고요..
실제 c에서 코딩할때는 다른 장비와 통신할때가 많습니다.
대개의 경우 프로토콜을 정해서 하죠. 이런 프로토콜은 ftp,http와 같이 알려진 프로토콜이 아니라서
장비와 통신할때는 맞춰줘야 합니다. 이럴경우 해당 데이터를 프로토콜에 맞춰서 읽어야 하는데
자바에서는 어렵다는 것이죠
위의 내용은 납득할 수 없습니다.
쉬운 예를 들어보죠
파일을 열어서 1라인의 내용을 가져오는 함수가 코드에서 필요하다고 합시다.
대개 c 초급자(제가 아직 이 등급에..)들은 만들어서 씁니다.
그러나 왠만한 중급이상은 저렇게 함수를 만들어서 사용안합니다.
기본 라이브러리(glibc)에서 제공하는 getline()함수를 사용하면 한줄이면 댑니다.
이런 상황에서 제 3자가 본다면 어느쪽이 쉬워 보일까요?
당연히 뒤쪽이겟죠. 쓴귤님이나 기타 다른 익명자님들도 c에서 제공하는
함수에 대해 다 알지 못하기 때문에 어렵다고 생각하지는 않는지요?
이 부분은 비단 c뿐만 아니라 자바에서도 마찬가지입니다.
위에서 예를 든 replace()함수도 알고잇는사람은 쓰겟지만,
모르는 사람은 위에 나온 코드처럼 만들어서 사용하죠.
자바에서 replace()라는 함수를 사용하기위해 자바가 제공하는 함수에 대해
알아야지 쉬운겁니다. 마찬가지로 c에서도 제공하는 함수에 대해 알아야지 쉬운겁니다.
c에서 기본적으로 제공하는 함수는 약 1108개입니다. 기본적으로 제공하는 함수만이죠.
이것도 다 알기 어려운데 다른 라이브러리에서 제공하는 함수는 얼마나 많을까요?
모르기때문에 어렵게 느껴지는 겁니다.
간단한 예를 들어 볼까요?
ftp로 자동로그인을 해서 파일을 다운로드하거나 업로드하는 프로그램을 만든다고 합시다.
제가 만든다면 한줄이면 끝납니다.
하지만 다른 사람들이 만들때는 복잡해 질수 있습니다.
제가 저런 함수가 있는 라이브러리를 알고 있기 때문이죠
자 이 시점에서 기본적으로 자바나 c에서 제공되지 함수를 사용해야 한다고 합시다.
그럼 자바가 쉬운가요? 아니면 c가 쉬운가요?
제 생각엔 둘다 어렵다는 것이죠.
둘다 그런 상황에서 해당 라이브러리를 찾거나 새로 구현을 해야합니다.
그래서 제가 위에서 캐스팅부분에 대해서 꼬집은 것이죠.
자바에서 기본적으로 제공되지 않는 부분이기때문에 자바에서는 새로 만들어야 하죠
하지만 c에서는 되기 때문에 쉽다는거죠.
이처럼 c가 쉬운부분도 있는것이고 상대적으로 자바가 쉬운부분도 있는것이죠
자바가 c보다 무조건 쉬운게 아니라는거죠.
C에서 '가' 라는 스트링을 캐스팅하면?
애초에 잘못하고 있다는 걸 모르시네..
님이 생각하는 스트링은 더이상 쓰면 않되는 겁니다.
'가' 라는 문자는
euc-kr로는 0xb0a1
utf-8로는 0xeab080
utf-16으로는 0xfeffac00
입니다. 어떤걸로 캐스팅 하시려고요?
문자는 문자이여야 한다는 20년에 걸친 교훈을 아직도 못배우셨나요?
그런데 자바도 되요, 모르셨나요? char a = 'a'; int b = (int) a; double d =- (double) a; 그런데 이런 코드를 쓰는 사람은 거의 없죠. 왜냐고요? 문자는 문자니까요.
구조체요? 자바는 OOP니까 클래스겠죠? serialization/externalization을 통해 쉽게 읽고 쓸수 있습니다.
unsigned 자료형 지원않합니다. 그런데요? c가 유니코드 언어차원에서 지원 않하는 것보다는 훨씬 편안한 한계인데요?
오히려 signed, unsigned 구분하면서 코딩하는 것보다 에러도 적고요. 모든 수는 +-를 가진다.라는 생각으로 다루면 되니까요.
님이 않된다고 하셨던거 거의 되는데요? 따로 않만들어도 되는 걸요? 그러니 님이 잘 모른다고 하는 겁니다.
어찌 저리
어찌 저리 무식하실까..
이쓰레드에서 문답법으로 공부하려는게 목적이신가?
글쓰는걸보아하니 대학 2~3학년정도되시는듯..
언어공부한지 설렁설렁해서 한 1년이 채안되는사람들이 할수있는말...
경험도 안목도 실력도 없이 말만 많으신 분이시네
글쓰는 거 보아하니 초딩 찌질이시네.
스트링을 자료형으로 바꾸는겁니다.
예를 들면
문자열이 "0xff0123"이라면 double형으로 쉽게 바꿀수 잇냐는 부분이죠
타입이 없는것보다
타입이 없는것보다 타입이 있고 어느정도 엄격히 하는것이 훨씬 유리하다는게 연구결과죠..
이 글타래에서
이 글타래에서 코딩이 쉽다 어렵다는 라이브러리나 다른함수의 도움없이 구현되나를 말하는겁니다.
라이브러리뿐아니라 함수쓸것같으면 머하러 비교하나요.
차라리 어느것이 라이브러리가 많네 함수가 많네 그거비교하지요..
솔직히 함수쎳다면 함수쓴부분은 비교대상에서제외하고 생각하셔야되는거 아닌가요?
위에나온 소스중에서도 자바에서 함수쓴부분에 해당하는부분을 제외하고 나머지 부분만이라도 보세요..누가더쉽게됬나..
그리고 프로젝트할때 기본함수만 쓰나요? 자기가할수있는 가장 편한 방법으로 할겁니다. 누구든..
그럼 자바가 라이브러리 사용하듯이 C도 라이브러리 사용한다는가정하에 생각해야지요..
그러면 자바가 라이브러리나 함수가 풍부할까요 C가 풍부할까요? 혹은 공개소스가 어느게 더풍부할까요?
혹은 없는것들 신규로 만들어야할때 어느게 더쉬울까요?
생각해보면모르세요?
정리하면 일단 완전히 신규코딩부분에서는 자바가 C보다는 불리하다는것 아시죠?
최소한 C는 자바처럼만들수있습니다. 거기에 포인터 이용하면 더쉽게도되구요..
함수나 라이브러리, 공개소스 사용하는것까지 포함해보면 C가 다방면에 매우 풍부하게 있습니다. 자바는제공되는것외에 그리 많나요?
자기가할수있는
맞습니다. 그 결과 sourceforge.net에 있는 오픈소스 프로젝트 중에도, 시장에서 나오는 프로젝트도 자바가 제일 많습니다.
제가 여러번 말했지만 신규로 만드는 것이라면 리습이나 하스켈이 C보다 훨씬 쉽습니다. 하스켈로 퀵소트 알고리듬을 짜면 아래 두 줄이면 충분하죠. C로는 몇 줄이나 되나요?
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
한줄요.. qsort() 매우
한줄요.. qsort() 매우 흔한 소스죠. 아마 교과서에도 나올껄요..ㅎ
이랬다가 저랬다가
어느 익명 사용자 분인지는 모르겠습니다만 "신규로 만드는 것"이라고 써놨습니다만. 내장 qsort야 C 아니라도 거의 모든 언어에 다 있습니다.
http://mentalese.net
http://functional.or.kr
http://mentalese.net
http://functional.or.kr
java vs C vs C++ 검색어 :
java vs C vs C++
검색어 : xml parser
2009 vs 480 vs 709
검색어 : oracle
158 vs 46 vs 61
검색어 : mysql
532 vs 344 vs 356
sf.net 에서...
검색어 : messenger 155
검색어 : messenger
155 vs 82 vs 121
검색어 : mp3
212 vs 73 vs 265
역시 sf.net 에서
그나마 웹관련해서는
그나마 웹관련해서는 자바가 조금쓰입니다.
다른 php 나 기타 여러가지가 있지만 php 가 많이 쓰이는지 자바가 많이 쓰이는지 몰라도.
웹관련 외 에는 잘 쓰이지도 않고..
더구나 만약 자바가 아니었다면 우리는 이렇게 느린웹때문에 속터질일이 그나마 덜했을듯..
좀더 하고 싶지만
좀더 하고 싶지만 마지막으로
검색어 : editor
663 , 360 , 599
검색어 : game
1522, 1217, 2723
c++ 보다는 적지만 C 보다 많은 게임이 만들어 지고있군요
java : c/c++ 이니.. C와
java : c/c++ 이니.. C와 C++ 은합한값을 생각해야지요..
그리고 한가지 더 노파심에서 말하지만.
이 함수는 제가 만들지 않앗습니다.
저는 글을 올릴때 제 아이디로 올리지 님처럼 익명으로 하지 않으니까요.
굳이 익명으로 올릴 필요성도 없고요
그리고 제코드를 실제 돌려보시지도 않으셧죠?
일부러 컴파일에러나도록 햇는데..
그건제가
그건제가 한말인데요..
모든익명님들을 다 저라고 생각하지마세요.
전 위에님과 다른익명이에요.
다른 사람이라면
아이디를 공개하세요
그럼 아무도 오해를 안하죠 안그런가요?
이젠 글도 제대로
이젠 글도 제대로 안읽으셈? UTF-8 지원한다했지 누가 16지원한다 했나여?
그럼 님은 과거 구 한글조합형지원 하는거 해보시고..동시에 새로운 코드정의
한글조합형을 상위앞쪽바이트형태로 세부분을무조건3바이트가 1글자가 되도록 정의한 문서를 처리해보시죠..
그리고 결국 유니코드에 관해선 님도 구현하지 않고 라이브러리 제공되는루틴아닌가여?
그걸마지 자기는 만들지도 않으면서 자기가 만든양 큰소리치는거에여?
이제 님도 말로만하지말고 함만들어보시져?
하나도 만들줄모르고 라이브러리 제공되는함수를 자기가만든양 큰소리치지마시고.
추가로 익명으로 여러명이 쓰시는것같은데 저랑 다른익명이랑 헷깔리지마세여.
음 익명이 많긴하네요.
저는 유니코드를 지원하는 코드를 보여달라고 했지 utf-8만이라고 말한적 없습니다.
그리고 자바에도 구 한글 조합형지원하는 코덱있어요.코덱 확장도 다 됩니다.
제가 언어차원에서 지원되는 유니코드 지원을 사용하는거 맞습니다. 언어차원에서 char이 유니코드니까 처음 입력 받을때만 인코딩을 신경써주면 될뿐 그 다음 부터는 비교나 분리등의 문자열 처리시에 char를 그냥 글자 한글자로 다루면 됩니다.
그런데, 아직도 모르시겠나요?
프로그래머가 직접 수고해야 하는 많은 부분들이 언어나 플랫폼 차원에서 지원하게 되면 얼마나 편해지는지?
C 강력하죠. 이걸 부정하는게 아닙니다.
하지만 C는 강력한 만큼 고려해야 하는 부분도, 수고해야 하는 부분도 많습니다.
그래서 덜 수고하고도 비슷한 프로그램을 만들수 있는 언어차원이나, 플랫폼 차원에서 많은 일을 해주는 언어가 각광을 받는 거죠.
C에 비해 자바가 그랬고,
자바에 비해 파이썬이 그랬고, (언어차원의 테이블 지원이나 람다 같은건 지금 봐도 멋지죠.)
파이썬에 비해 루비와 루비온레일(웹어플리케이션분야)이 그러고 있죠.
이 "덜 수고할수 있다"는 것을 보통 쉽다고 이야기 하고요.
그런데 님께서는 C로 다른 언어에 비해 수고가 많은 것을 "어렵다"라고 인식하지 않으시는 거죠.
그리고 자바나 파이썬, 루비로 웹어플리케이션을 만든 수많은 사람은 C로 수고하는 것을 "어렵다"라고 인식하는 거고요.
님께서는 아마, 최적화되지 않은 어플리케이션을 죄악시하는 경향이 있을겁니다. 아마 그런 환경속에서 일을 하시겠죠.
반면에, 저와 비슷한 많은 SI 실무자들은 그러지 않아도 수없이 변하는 고객의 요구사항때문에, 조금 성능이 느리더라도 변경이나 작성이 쉬운 언어를 선택하는 겁니다.
자바의 WORA역시 요구사항의 변경에 맞춰줄수 있기 때문에 각광을 받은 것이죠. (고객이 "다른(더 빠른, 더 싼, 다른 벤더의) 서버로 바꾸고 싶은데요"라는 말하는 요구말입니다)
당장 1개월 내에 프로그래머 혼자서 게시판 수십개와 DB 테이블 수십개을 연결해서 물품 관리 웹어플리케이션을 만들어서 동작시켜야 한다.. 라는 고객의 요구사항이 있는데(실제로 경험한겁니다), 거기다 대고 "C가 쉬우니까 C로 만들어"라고 말할 사람은 별로 없습니다. 그때 저는 PHP로 만들었습니다. 개발 정말 빠르더군요. 2주만에 테스트 까지 끝냈습니다.
이때 제가 느낀 "쉬움"과 님이 가지고 계신 "쉬움"은 아마 다른 의미일 겁니다. (아마도 님의 쉬움은 더 성능이 좋은 어플리케이션을 만들기 위한 여러 툴들의 구비 여부겠죠. 메모리를 직접 관리할수 있는 포인터라던가 템플릿이라던가, 인라인 어셈이라던가..)
제가 가진 "쉬움"은 어플리케이션을 만들때 들여야 하는 노력과 시간을(비용) 말하는 것이고요.
그러니 같은 단어를 써도 서로 다른 의미인 셈이니 대화가 제대로 될리가 없죠.
하지만, 뭐 저도 글을 잘쓰는 편이 아니라, 게다가 인격자도 아닌지라^^ 이런 사실을 알면서도 글싸움을 좀 해봤습니다.
아마 님이 어느정도 수준이 되시는 분이라면, 제가 무슨 말을 하는지 아실거고,
아니라면야, 뭐 여태까지처럼 찌질대며 계속 싸움을 하게 되겠죠.
ps. 익명이 하도 많아서(저도 익명입니다만^^) 그냥 입장정리차원에서 써봤습니다.
이래서 님이 뭔가
이래서 님이 뭔가 크게 착각하고 계시다는겁니다.
C는 무슨 라이브러리도 없는줄알고 어렵게 무조건 다만들어야되는줄아시는모양인데.. C도 라이브러리 엄청많고..공개소스도 엄청많고.
자바에비해 구현방법이나 테크닉도 훨씬 많거든요.?
자바는 라이브러리쓰면되고 C는 라이브러리 안쓰는줄아세여? 대부분 다 라이브러리 쓰지 안쓰는데가 있나요?
자바는 라이브러리 구축이 매우 힘들지만 C는 라이브러리 만들어내는거도 정말 다른언어에비해 누워서 떡먹기입니다.
그래서 재미로나 혹은 최적화를 위해 직접구현하는사람도 많구요.. 자존심때문에 그렇게 하는사람도 많아요.. 있는거 쓸려면 다써요..
사실 자바쉽다구요? 그쉬운 자바소스 거의 그대로 C도 되거든요.. 즉 자바로 되면 그대로 C도 됩니다. 최소한 C가 자바보다 어렵진 안아요.. 거기다가 포인터란 강력한도구도 있으니 C가 더쉽게 된다는건 두말하면 잔소리겠죠?
누가 없데요?
참 글 못읽고 이해 못하고 오독 잘하시는 분이시네.
처음에
>> 모가 쉬워요?
>> 그럼간단히 스트링내의 원하는 문자 제거하는 함짜보세여 예를들면 스페이스라던가..
>> 아니그냥 간단히 "skdkglsldslfldsf dskfkfsls ** dflsdf" d 제거하여 "skkglslslflsf skfkfsls ** flsf" 요렇게 되는거 만들어보셔요. 말만하지마시고. 얼마나 쉽게 되나 함바여..
그래서 멀티 인코딩 되는 C코드 한번 보자니까요?
실행 예랑 좀 보여줘 보시죠? 버그 있는 코드는 잘만 컴파일하고 실행 예 올려주시더니 유니코드 지원하는 Replace 코드좀 보자니까 왜 못보여주시나요?
어려워서 그러신가봐요?
무식하면 쵝오..
무식하면 쵝오.. 아무이상없는코드도 컴파일할줄몰라 에러내는사람... 감당이 불감당이넹
개념도
개념도 없으신분이네요..
님한테 어울리는 속담이 있죠..
"다른사람장에가니까.. 거름지고 장에간다."
무조건 남따라 구현했다고 다되는줄아세요? 그리고 그게같나요? 너무개념없는소리참...
따라하실라면제대로 구현하세요..
풋..
코딩에서 얼마나 쉽게 할수 있느냐 해놓고
자기 코드와 동일한 코드로 자바도 되니까 할말이 없으신가봐요?
무개념의 코드를
무개념의 코드를 만들고 같다라고 하니 뭐라 하겠습니까..
개념정리가 안되니 같게 보이겠죠..
그리고 동일한코드? 자바가 쉽다고 우기더니 이제 동일한걸로 만족하시나보네요?
억지로 따라하려고 흉내만냈지.. 동일하지도 않지만.
저게 같다고
저게 같다고 생각하시니 자바하시는분들참.. 제발공부좀더하고.. 말하세요..
이건머 메모리 개념도 없으니 먼말을하겠수..
[Re:]그러니까 유니코드로 코드를 보여주세요.
vc++ 6.0 에서는 이상하게 메인에서 에러가 나는데 에러나는 부분인 free()할때이더군요 왜 나는지 이유를 알수가 없네요
같은 인코딩일때는
같은 인코딩일때는 잘 돌아갑니다만, 다음 처럼 서로 다른 인코딩일때는 제대로 동작하지 않지요.
다시말해, 아스키코드이거나, 같은 인코딩임을 제약시킬수 없는 char 로는 제대로된 유니코드를 지원하는 replace를 만들수가 없습니다. 그 말은, 국제화된 소프트웨어에서 이 함수를 사용하기 어렵다는 거죠.
그래서 조엘온소프트웨어에서 "There is no plain text!!!" 라고 말하는 거죠.
님자바소스에서
님자바소스에서 실행코드이 일부인 바이너리 코드중
char src[] = { 0xc7, 0xd1 , 0xb1 , 0xdb , 0xc5 , 0xd7 , 0xbd , 0xba , 0xc6 , 0xae, 0xed , 0x95 , 0x9c , 0xea , 0xb8 , 0x80, 0}; // 바이너리코드
char find[] = { 0xed , 0x95 , 0x9c , 0xea , 0xb8 , 0x80,0};// 바이너리코드
char rep[] = { 0xfe , 0xff , 0xc6 , 0x1 , 0xc5 , 0xb4,0};// 바이너리코드
src 에서 find 를 찾아 rep 로 교체해보시죠.. 재대로 동작하나.
C는 이런것도 매우잘 동작합니다만..
어쩌죠?
잘되는데요? 유니코드/멀티인코딩 지원하고, 바이너리 치환하고 다됩니다.
그런데 이런 코드는 자바에서 나쁜 코드죠. char를 숫자로 사용하려고 드니까요.
문자는 문자입니다. 좀 이해좀 하세요.
그런의미에서 유니코드/멀티인코딩 지원하는 C 함수좀 보여주시죠?
어쩌죠? 잘되긴요..
어쩌죠? 잘되긴요.. 틀렸네요..
앞쪽에 한글은 왜 안바꼈나요.. 그것도 바껴야지요..
바이너리코드가 저렇다했지 바이너리로 처리하라는말이 아니거든요..
님소스도 재대로 동작안하네요.. 재대로 만들어보여주시죠..
정말 모르시는 분일세..
다시 말하는데,
문자열 raw data는 인코딩을 모르면 사용할수 없는 데이터랍니다. 그래서 there is no plain text라고 하는 거고요.
이런것도 모르니까, 개념없다는 소리나 듣죠.
C로는 유닉스,
C로는 유닉스, 리눅스, M$ 윈도우등 다만들었는데.. 자바로 함만들어보세요..
보여주세요..
정말 모르시는 분일세..
저 자바 코드 linux, osx, windows, unix에서 다돌아가요^^
국어를 모르는분일세.
^^
만약 별도의 구조체나 class의 사용없이..
만약 별도의 구조체나 class의 사용없이 char만으로 유니코드를 다루려고 한다면, 정책 이외것으로는 막을 방법이 없죠.
그런데 정책만큼 무시 되기 쉬운 것도 없으니까요.
그래서 인코딩을 모르면 그 글자도 모른다고 생각하라 라는 말이 나옵니다.
ex) utf-16으로 'd'는 0xfeff0064 입니다.
일반적인 char 기반의 문자열 함수들은 3 바이트 읽고 "어 끝났네?" 할겁니다.
자바가 느린 것은 부정할 수 없습니다.
음... 저는 소위 말하는 '자바 예찬론자'입니다만, 굳이 속도면에서 C++ 보다 느리다는 건 부정할 필요를 못 느끼겠습니다.
위에서도 나왔지만 자바의 철학은 '모든 환경에서 최고의 성능을'이 아니기 때문이죠. 위에서 어떤 분이 JIT 컴파일러의 최적화로 인해
C/C++에 비해 떨어지지 않거나 '일부분에서는' 오히려 우수한 성능을 보인다고 하신 말은 맞습니다. 그렇기 때문에 '충분히' 빨라진거죠.
하지만 그럼에도 불구하고 네이티브 언어보다는 느립니다. 각종 최적화 기법 때문에 앞서는 벤치마킹도 그 기법을 그대로 적용해준다면
네이티브 언어가 당연하게 더 빠르다고 답하신 분의 말도 맞는 말입니다. 만약 완벽하게 동일한 작업을 수행하는 자바 프로그램과 C/C++
프로그램이 있다면, 당연히 자바가 더 느립니다. 굳이 '그렇지만...' 이라고 덧붙일 필요를 못 느끼겠군요.
물론 편견을 가지고 아무런 근거없이 (어느정도 느리다도 아닌) 무조건 느리다고 말하는 사람을 볼 때, 울컥하는 건 사실입니다만 모르는 건
죄가 아니니 그냥 그러려니... 합시다.
저는 다시 원점으로 돌아가서 '8배 느리다?'라는 부분을 살펴봤으면 좋겠습니다. 수치가 문제가 아니라 질문의도가 '그렇게 못쓸 정도로 느리냐'
라는 걸로 보이는군요. 과연 8배나 느린가요? 정상적인 경우라면 그렇게 심각하지는 않습니다. 어떤 프로그램이 똑같은 언어로 쓴 다른 것보다
8배나 느리다면 그건 코드를 잘못 쓴 겁니다. C/C++을 아주 좋아하시는 몇몇 분들이라도 '자바가 느려서 이 프로그램이 C/C++로 짠것보다 8배
나 느린거야'라고 말씀하시지는 못할겁니다. 아, '이건 C로 만들었기 때문에 0.01초가 걸리고 이건 0.08초가 걸린다'라는 건 가능하군요.
하지만 '이건 C++로 짜서 1초가 걸리고 저건 자바로 짜서 8초가 걸리는거야!'라고 할 수는 없을 겁니다. '자바가 8배나 느리다'라는 말은
0.01초가 승패를 가르는 환경이 아닌 일반적인 경우라면 '말도 안되는 편견'입니다.
(개인적으로는 정상적인 자바 프로그램은 네이티브 코드에 체감속도가 10~20% 정도 느리다고 생각하고 있습니다. 실제 언어 자체의 속도를
떠나서 기본 클래스 라이브러리인 스윙이나 기타 등등의 문제로 말이죠)
하지만 저는 2초만에 응답하는 C/C++ 대신에 한참이 지난 2.2초가 되어서야 응답하는 자바 프로그램을 다음과 같은 이유로 선호합니다.
- 깔끔하고 읽기 쉬운 코드를 '상대적으로 더 쉽게' 작성할 수 있기 때문에(가독성이 높으면 유지보수도 쉬우니까)
- 한번 작성해서 여러 플랫폼이나 타겟에서 실행할 수 있기 때문에
- 메모리 관리가 귀찮아서!
- 썬의 Write Once, Run Anywhere라는 철학이 맘에 들고 오픈된 정책과 오픈소스 소프트웨어가 맘에 들어서 (Nice Eclipse!)
- 설마 사용자가 이걸 10번 실행한 다음 속도를 측정하고 '2초나 차이나잖아!'라고 외치지는 않겠지... 하는 생각에...
- 고작 10MB 가량 되는 JVM 용량 때문에 외면받는 프로그램이라면 뭘로 짜든 가치가 없다고 생각하기 때문에
만약 다음에 해당하는 사람이라면 자바가 기분나쁠 수도 있겠군요 (쓸데없는 기능이 주렁주렁 달려있으니)
- C/C++로도 충분히 가독성이 높은 코드를 작성할 수 있는 숙련된 프로그래머
- 프로그램 실행속도를 우선시하는 프로그래머
- 플랫폼 독립성 같은 괜히 이상적인 환경이 필요치않는 프로그래머
- 메모리 관리나 포인터 활용 등을 자유자재로 다룰 수 있어서 없으면 불편함을 느끼는 프로그래머
다시 읽어보니 굉장히 뻔뻔한 ('뻔'할 '뻔'자인) 내용이군요. 음... 그냥 그런 걸 어떡합니까...
뭐, 아니면 어떻습니까...... 각 지역과 나라마다 국어와 방언이 있고 모두가 거기에 자부심을 가지는게 당연한거니까요 ^^
자바느린건 맞는것
자바느린건 맞는것 같고요. io쪽은 심하죠 nio나오면서 좋아 졌을려나 메모리 많이 먹고
생산성은 자바언어의 특성에 기반하기 보단 지원해주는 lib가 강력한 것이고
c에 동일한 종류의 lib이 잔뜩 있다면 생산성에 많은 차이는 없을듯하고요.
접근성은
두초보가 붙는다면 자바가 많이 우세할듯
두능숙이 붙는다면 약간 자바가 우세할듯
플랫폼에 무관하다는건 엄청 좋은것 같고요.
이상 주관적인 생각이었습니다.
개인적으로 자바에서 가장 마음에 안드는것.. 메모리 많이 잡아먹는것.
이클립스하나띄워도 150메가 울~~~~ 물론기능이 많지만
visual studio 는 1/10쯤되려나.
제발 jvm하나에 다중어플리케이션(?)좀 지원해라 ㅡ,.ㅡ
나온다나온다 하더만 아직도 안나오네 그려...
자바 느린건 맞는것
자바 느린건 맞는것 같다라.. NIO 나온지가 언제쩍 얘긴데.. 많이 좋아졌는지 안좋아졌는지도
잘 모르시는군요.. 거의 x이버 지식인에서 방금 검색한 따끈따끈한 수준의 정보군요..
Onjava.com에서 4년전쯤 type4 jdbc 드라이버와 type2 jdbc 드라이버 의 벤치 결과를 포스팅한적이 있습니다.
그결과를 검색해보시고, 주장하시기 바랍니다.
그리고, C에 동일한 종류의 LIB이 잔뜩있다라..
협업 가능성이 적은 소규모 개발 Domain에서의 비슷한 수준의 개발자들끼리 작업한다면,
C/C++이나 Java나 거기서 거기라고 생각합니다. Java가 조금더 좋긴 하겠죠.. 문법적 Simple함에서 오는
개발도구의 엄청난 편의성 때문에.
그러나 협업가능성이 많은 대규모 개발 Domain이나 향후의 유지보수를 감안한다면,
C/C++의 생산성과 꽉막힌 Flexibility는 태생적으로 Java의 그것과 비교할수가 없겠죠.. 이것마저 인정안하시는
분들은.. Java자체를 부정하는 것이며, Java가 현재와 같이 EE 환경에서 Prevalent한 현실을 인정하지 않으시는 분들이겠죠.
예를들어, .XLS를 디코딩해주는 루틴을 쓰고 싶을때, Java에는 세상에 널려있는 Excel관련 라이브러리의 JAR를 Classpath에 잡아주고,
단순히, API-DOC을 보면서 쉽게 개발하죠.. Unix / Linux쪽에서 C/C++에서 이와 같이 '쉽게' 이용가능한 XLS decoding library가 있나요.
물론, 개발해서 쓸수는 있겠죠.. C/C++에서도.
그리고 성능.
Java의 성능은 분명, 많은 경우 C/C++에 비해 떨어집니다.
그러나 많은 경우 이런 성능저하는 그리 크지 않고, 문제되지도 않지요. 특히나 Server side app. 의 경우엔 특히나.
또한, C/C++에서는 단순히 컴파일 타임 최적화만 가능합니다. 물론.. 런타임 최적화가 가능하긴 합니다만..
컴파일후, 몇번 실행해보고, 실행된 정보를 다시 컴파일러에 annotate해서 이 정보를 갖고 컴파일 타임 최적화를 수행하는 정도죠..
이런 수준의 최적화는 JVM내에서 이루어지는 최신의 런타임 최적화에 비해서는 정말 세발의 피죠..
특히나, 모든 system call을 프로그래머가 직접 코딩하는 것이 아니라, VM에서 intelligent하게 하므로,
상대적으로 system call을 줄일수 있게되고, 이에 따라 C/C++에 비약적인 성능 향상을 꽤할수가 있지요.
물론,,.. C/C++에서도 GC를 사용가능케 하는 기술들이 있습니다만.. 그런 여러가지 기술들을
사용한 코드와 그렇지 않은 코드간의 Compatability가 전혀 없다는 측면에서 Java나 기타 다른 VM기반의 랭귀지의 그것과는 한 수준 아래죠. 또한 그런 변종 라이브러리들의 성능이 최신의 JVM의 그것과 비교해서 얼마나 더 세련된 관리를 하는지도 의문입니다.
모든 랭귀지는 다 나름의 강점이 있습니다.
C를 써야 하는 App.이 있고, C++을 써야하는 App.이 있고, Java를 써야 하는 App.이 있죠.
디바이스 드라이버를 개발하는데 Java를 쓸수도 없는 일이고, 웹게시판을 만드는데, C-CGI를 쓰는것도 웃긴일이죠.
3d겜을 개발하는데 Java를 쓰는것도 웃긴일이죠.
개발자가 할일은.. 각 언어의 장단점을 잘 파악해서 상황과 스펙에 맞는 최적의 솔루션을 찾아내느것이죠.
잘알지도 못하면서, 자기가 하는 언어가 최고라고 자부하면서 다른 언어의 장점을 깔아뭉개면서 현실을 인식하지 않는
우물안 개굴의 태도는 버려야 한다고 생각합니다.
답글 달때는 글을
답글 달때는 글을 대강읽지말고 자세히 읽으시기바랍니다.
제글 및에 답을 다셨는데 상상의 나래가 너무 심하시군요^^;
인신공격성 글들은 배제 하시기 바랍니다.
이야기할때 상대방과 의견이 다르다고 비꼬면 수준이 낮은 토론자일뿐입니다.
그러한 태도는 고쳐할 점입니다. 말 조심하기 바랍니다.
주장한적도 없고 주관적인 생각일 뿐이라고 했습니다.
java gui와 일반(?) gui보면 응답성이 떨어집니다.
요즘같은 컴퓨터에서 프로그램의 응답성이 떨어지는걸 느끼지때문에 ...
이러한 느낌은 객관적일 수 없으니 주관적이라 써놓았습니다.
io는 많이 늦은 건 밝혀진 사실이고 nio의 성능에 대한 이야기는 듣지 못했기 때문에 ?형식으로 남겨뒀습니다.
동일한 lib와 동일한
동일한 lib와 동일한 framework이 존재할 때 c++이 java보다 어떤점에서 더 유리한가요?
gc기능?
런타임 최적화에 대한 오버헤드는 없나요?
system call호출해야 되는곳에 자바는 어떻게 피해가나요?
system call의경우 대부분 실시간으로 변하는 os level의 정보를 입출력하는데 사용하는데
호출하지 않고 어떻게 정보를 입출력하나요? os level의 정보가 캐싱되나요 이게되나?!
io작업을 모아서 콜하나요? 그럼 빨리써야하는 작업은? 어떤콜들을 어떻게 최적화하는지 궁금...
관련회사들은 잘 포장해서 설명할뿐입니다.
자바의 유비보수,플렉서블?
자바는 인터넷 인프라(마케팅 여기서 성공했죠)와 접근성(쉽다는것 c에비해) ....
처음에 흥미로워서 재미로 읽다가...
이런 논쟁은 그냥 가끔 일어나는 재밌는 논재거리네요 ^-^
읽다가.. Java는 C보다 느리다. C로는 Java가 하는 모든것을 할 수 있다. 등의 형식으로 말씀하시는 분들이
간혹 보여서 짧은 글 하나 남길려구요^^;
언어는 구현물이 빠르다고 훌륭한 언어라고 볼 수는 없는거 다들 아시잖아요.
여기서 등장한 C 와 Java 이외에도 세상엔 무수한 언어들이 존재하며, 각 언어들은 시장성, 디자인패턴 적용의 용이성, 프로토타입 구현의 용이성 등등에서
각각 장점들을 가지죠.
자신의 생각을 한글로 쓰는 것과 영어로 쓰는 등의 논쟁과 같은 맥락 아닐까요...
여하튼 유쾌하고 재밌었습니다.
다음엔 C, C++, Java 같은 대중성 있는 언어들로.. 그리고 속도 이외의 관점으로
다른 언어 사이의 비교를 하는 논쟁이 일어났으면 좋겠네요^^
C언어와 자바 속도
C언어와 자바 속도 논쟁은 무의미 하다고 생각합니다.
JDK 1.4에서 new IO는 이미 C언어에서 구현된 부분이기도 하지만,
그 부분은 C언어도에서도 진보에 진보를 거듭하면서 생겨난 부분이라고 알고있습니다.
제 칭구 닷넷에서 자바로 넘어왔는데 그 이유가 너무 좋은
공개된 개발 framework이 많기때문이라고 합니다.
저두 자바 하지만 솔직히 jdk 1.4이전에 new IO가 던지는
이슈에 대해서 고민해 본적이 없는데요.
저 하수 ㅠ.ㅠ 이런 논쟁을 보면 자바는 느리다라는 인식을
심어준 당사자(?)라서 맘이 아픕니다.
마지막으로 언어는 도구이니 그 특성에 맞게 쓰시기 바랍니다.
돌아만가면 되지 않나?
돌아만가면 되지 않나?
어디서 돌아가든 목적에 맞게 고객이 원하는데로만 돌아가면 된다.
Testing raw NIO
Testing raw NIO performance
Posted by: Dion Almaer on 4? 05, 2004 DIGG
Cameron has written about his experience with NIO, which he uses in Coherence. He talks about how it is maybe slower than you think, and gives test code so you can see the results for yourself.
Excerpt
One of our early concerns with NIO was its raw performance, and for good reason: In it's original JDK 1.4.0 release, performance was terrible. By the 1.4.2 release, the performance had improved (in some tests) by a factor of 3:1, and you can see in the following test output that it's "only" about 3x slower than putting data into a byte array, and "only" about 4.5x slower than accessing data from a byte array. Since there should be nothing theoretically faster than accessing data from a byte array, this is impressive, right?
Read Cameron Purdy in Raw NIO Performance
2004년의 nio대한 모 사용자을 내용.
일단 자바가
일단 자바가 느립니다.
위에서 많이 안느리다고는 하나 실제로 짜여진건 밴치마크의 셈플처럼 전부 저런코드만 있는게 아닙니다.
대부분 스트링처리나 네트웍 db 그래픽 관련 인데 그런곳에서는 매우큰차이가 있습니다.
윗쪽에 스트링처리하나만하더라도 자바는 범용함수를 사용하여구현해야하는반면 c 는 그자체엔진에 적합한 맞춤형함수를
사용할수 있기때문에 성능차이는 매우큽니다. 함수하나에서만해도 수백%이상 성능차이가 나죠..
어쨋거나 전체적으로 따져보면 꽤성능차이가 납니다. 10~20% 정도가 아니고 보통 수백% ~수천% 정도 성능차가 납니다.
못믿으시겠지만 사실입니다..
단적인 예로 자바로 스타크레프트 만든다면 어찌될지...아마도최소한 10배는 느릴겁니다.
그렇다고 자바가 전혀 쓸모 없는것이란 말은 아닙니다. 누구나 공감하듯 개똥도 약에쓸일이있다고 그리 속도가 중요하지 않은곳에 쓰입니다.
하지만 분명한건 자바하시는분들은 왜그리 속도도 빠르다고 우기시는지..그건 아니라고 봅니다.
아마도 sun 의 자신들의 자바를 홍보하기위해 내놓은 그런 말만믿고 사실믿고 싶겠죠.. 그걸그대로 말하는경향이 있습니다.
이런 말들은 과거에는 없었는데 자바가 나오면서 이런현상이 나타나는것같습니다..
역시 자바때문에 말들이 많네요...
페이지
댓글 달기