C로 웹 개발하기

feanor의 이미지

최근 "자바와 C 어쩌구" 하는 재밌는 쓰레드가 계속되고 있는데요,

개인적으로 정말 궁금합니다. C로 웹 개발하시는 분들은 어떤 라이브러리를 사용하고 계신가요? 구체적인 예를 들겠습니다.

* HTTP GET/POST 쿼리 파싱
* HTTP 쿠키, 세션 관리
* HTML 템플릿
* 데이터베이스 연결
* ORM 내지는 SQL 생성

기타 C로 웹 개발할 때 유용한 라이브러리도 소개해 주시면 감사하겠습니다.

C++은 C가 아니니까 해당 사항 없다고 하려다가, C++ 라이브러리도 알아두면 좋을 것 같아 포함합니다. 다만 C++이라는 사실을 적어 주세요.

neogeo의 이미지

"농담삼아서" PHP 라는 라이브러리를 사용합니다. 4가지 경우 전부 유용했고요, C 로 전부 작성된 아주 유용한 웹용 라이브러리 입니다.

Neogeo - Future is Now.

Neogeo - Future is Now.

hongminhee의 이미지

PHP 창시자인 Rasmus Lerdorf는 그런 얘기를 진지하게 합니다;

홍민희 (VLAAH, LangDev)

cyberowl의 이미지

저는 Java라는 라이브러리를 사용......... 전부 C로 작성된 아주 유용한 범용 라이브러리입니다.

hongminhee의 이미지

당장 떠오르는 것으로는 libcurl이 있군요.

홍민희 (VLAAH, LangDev)

hongminhee의 이미지

다시 보니 서버사이드 웹 개발을 얘기하는 것이었군요; libcurl은 그럼 엉뚱한 답이 되겠네요.

홍민희 (VLAAH, LangDev)

khris의 이미지

좀 지옥같군요;;

왕년에 날렸던 이지보드가 C로 작성된 웹 어플리케이션이었는데... 지금도 C/C++로 웹 어플리케이션 제작하는곳이 있나요?

───────────────────────
yaourt -S gothick elegant
khris'log :: http://khrislog.net

───────────────────────
yaourt -S gothick elegant
khris'log

lifthrasiir의 이미지

먼 옛날(대략 10년 전?)부터 비교적 지금까지 관리가 되고 있는 라이브러리로 qDecoder가 있습니다. OKWS라고 C++로 만든 웹 프레임워크 및 서버 엔진도 있고요. (OkCupid인가에서 쓴다고 들었는데 좀 기가 막히게 생겼습니다.)

ironiris의 이미지

저도 qDecoder 로 개발한 적이 있었는데 사용하기는 어렵지 않더군요.

논외지만 예전에 슈퍼보드인가요? 게시판을 무료로 제공해주던 시절..
처음엔 웹용언어로 개발했다가 유저가 너무 많아지고 부하가 가중되자 나중에 C버전으로 바꿨던 기억이 있네요.
-확실한 기억도 아니고 CGI래퍼를 썼던 것 같기도 하구요.-

neogeo의 이미지

음 어떤 보드였는지는 기억안나는데 부하를 줄이기 위해 DB 를 없애고 직접 파일 시스템으로 만든 경우가 있었으며, 이런 경우엔 다른 언어보다도 C 가 빨라질 가능성이 높습니다. 결국 DB 쿼리 타임을 줄이려고 한것이지요. 그리고 C 언어가 파일을 '직접' 잘~ 다룰때는 다른 언어보다 훨씬 빠르니까요.

Neogeo - Future is Now.

Neogeo - Future is Now.

김동수의 이미지

부하를 줄이기 위해 파일시스템으로 만든 보드였다면, 아마 테크노트가 맞을겁니다.
그 테크노트는 지금 부하를 줄이기 위해 DB를 사용합니다. :D

-------------------------------------
김동수 - Prototype for Evolution

김동수 - Prototype for Evolution

khris의 이미지

제가 질문자는 아니지만 직접 사용하시거나 맛이라도 보신 분은 성능 부분에 대해서도 좀 언급해주셨으면 합니다.

C/C++로 웹 어플리케이션을 작성하면 얼마나 성능 향상이 있을지 궁금하네요.

───────────────────────
yaourt -S gothick elegant
khris'log :: http://khrislog.net

───────────────────────
yaourt -S gothick elegant
khris'log

neogeo의 이미지

웹 어플리케이션의 종류에 따라 천차만별입니다만,

대부분 웹 어플리케이션의 경우에는

시간은 "DB 쿼리 하는데" 잡아먹기때문에 유저가 엄청 몰리는 경우가 아니면 C/C++ 로 짠다고 해도 특별히 PHP 나 perl , JAVA 보다 빠를리가 없습니다. 병목은 서버사이드의 app 가 아니라 DB 처리나 파일 전송이죠. ( DB 쿼리를 안하더라도 이미지 파일 전송 하는데 CPU 사용량이 더 높을지도 모릅니다. 물론 이미지 파일 서버를 분산해두는게 얼마든지 가능하지만요. )

웹 app 에서 성능을 운운해야할 정도의 문제가 어떤 것인지 짐작은 잘 가지 않습니다만, 웹 기반 게임서버 라도 운영하시지 않는 이상 언어간의 성능차로 웹 어플리케이션 성능차를 논하기는 매우 매우 어려울 듯 합니다.

좀 더 구체적으로 이야기 해보면, 물론 웹 어플리케이션이 하는일의 대부분은 html 이던 template html 이던 간을 문자열을 뿌려주는게 최종적인 목표이므로 문자열을 다루는데 빠른 언어가 유리하지 않겠느냐 라는 의문을 던지실 수 있습니다만, 문자열을 다루는게 보통하고는 다른게 console 로 뿌리는게 아니라 socket 으로 뿌리는 것이므로 C 언어같이 system call 을 직접할 수 있는 언어가 성능적 우위점을 얻기가 상당히 힘듭니다.

Neogeo - Future is Now.

Neogeo - Future is Now.

khris의 이미지

아, 성능 이야기는 순수한 호기심에서 나온 것입니다; (근데 게임계에 종사하고 있긴 합니다;;; )

그렇다면 특별한 케이스가 아닌경우에는 C/C++ 같은 언어로 웹 어플리케이션을 작성해서 얻는 성능 향상은 별로 없겠군요. 문자열을 쉽고 편하게 다룰수 있는 언어들이 주류가 된 것도 이해가 가네요.

자세한 답변 감사드립니다.

───────────────────────
yaourt -S gothick elegant
khris'log :: http://khrislog.net

───────────────────────
yaourt -S gothick elegant
khris'log

fender의 이미지

약간 부언을 드리자면, 보통 웹에서 말하는 '성능'의 의미는 언어 자체의 성능과 조금 다른 측면에서 보는 경우가 많습니다. 중요한 이유는 이미 neogeo님께서 I/O 오버헤드가 훨씬 크다고 말씀해주셨습니다. 저도 예전에 비슷한 글타래에서 예로 든적이 있는데, 고속도로가 막히는 명절에 서울에서 부산까지 차를 타고 간다면 F1 레이싱카를 탄다고 일반 승용차보다 몇배씩 빠르게 갈 수 없다는 논리입니다. 설사 과장해서 C가 자바보다 10배 빠르다고 쳐봐야 전체 리퀘스트를 처리하는 시간에서 순수하게 코드가 도는 시간이 자바가 0.1초, C가 0.01초인데 쿼리가 0.5초, 네트워크가 0.5초 걸린다면 양쪽의 응답시간 차이는 1.1초와 1.01초입니다. 이 경우 사용자 입장에서 무의미한 값이죠.

아무튼 그런 이유로 웹에서의 성능은 보통 마이크로 벤치에서 특정 알고리즘을 몇번 반복했을 때 얼마 걸리더라 하는 것 보다는 얼마나 늘어나는 로드에 효과적으로 대응이 가능한가를 말하는 경우가 많습니다.

간단하게 말하면, 동시접속이 10명일 때 평균 응답속도가 이런데 100명이 되면 어떻게 될 것이냐 하는 것이 단일 리퀘스트가 얼마나 빨리 처리되는지보다 중요하다는 것이고, 만일 동시접속 10명에 0.1초 응답속도를 보장하지만 100명이 되면 10초로 늘어나 버리는 구조 보다는 10명일 때 0.2초 걸리지만 10명일 때도 0.5초 쯤에 처리가 되는 편이 바람직하다는 것입니다.

같은 알고리즘을 얼마나 빨리 처리하느냐는 한 건의 요청에 대해 얼마나 빠른 응답을 보일지를 나타낼 수는 있어도 로드가 증가할 때 응답 속도가 어떻게 될 것이다를 나타내진 않습니다.

물론 알고리즘이 빠르다면 당연히 결과도 조금 빠르겠지만 위의 고속도로 예에서 처럼 성능을 결정하는 가장 큰 병목('막히는 고속도로')이 언어 자체('차의 최고속도')가 아니라면 그런 병목이 되는 자원을 어떤 방식으로 관리하느냐가 성능을 직결하는 문제가 되는 것입니다.

그래서 이 부분은 기본적으로 구조와 설계의 문제이고 그렇다보니 그런 문제를 풀기위해 많은 시간과 돈, 인력을 투자한 쪽이 더 효과적인 해법을 들고 있는 것 뿐입니다.

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

----------------------------
[서명] 그놈 한국 사용자 모임 - 그놈에 대한 모든 것! - 게시판, IRC, 위키, 갤러리 등등...

feanor의 이미지

잠시 구글 검색한 결과

LibCGI
http://libcgi.sourceforge.net/
GET/POST, 쿠키, 세션, HTML 이스케이프 등 지원하는 듯 합니다.

Clearsilver
http://www.clearsilver.net/
많은 대규모 웹사이트에서 사용하는 pure C 템플릿 라이브러리입니다.

youlsa의 이미지

윈도우에서는 요즘에도 예전 코드들 재활용 하느라 ISAPI로 DLL 만들어 올리는 경우가 가끔 있습니다.

=-=-=-=-=-=-=-=-=
http://youlsa.com

=-=-=-=-=-=-=-=-=
http://youlsa.com

keke111의 이미지

C로 개발한적이 있는데
요즘은 공유기 정도 되야지 c로 개발할거 같고

참고로 c로 개발하게되면 php의 echo문에 엄청나게 감사할겁니다.
문자열 처리가 아주 골때립니다. replace같은거....

제가 예전에 c로 하다가 php로 하면서 echo문 보고 기절하는 줄 알았어요.

Tony의 이미지

C로 문자열 처리를 할때엔 libpcre

소타의 이미지

C로 웹서버를 베이스로 한 개발을 몇 번 했는데요.
HTTP 헤더 파싱부터 인증 등을 직접 처리했고 외부 라이브러리 연동은 DB연결, SSL 정도였습니다.
SQL생성은 snprintf 로................ >_<;;;;;;
HTML템플릿 같은건 없고 snprintf로.............. -_ )y~

1. 이미지 URL을 넘기면 자동으로 썸네일을 주는 웹서버
2. 논리적인 경로의 파일을 요청하면 DB에 존재하는 물리적인 정보를 가지고 파일을 서빙해주는 웹서버
3. sqlite 기반의 멀티 게시판을 처리하는 웹서버
4. GET/HEAD 요청에는 static 파일 처리, POST 요청에는 sqlite -> XML 처리, OPTION 요청에는 sqlite prepared statement -> XML 처리, PUT/DELETE 요청에는 WebDAV 처리를 하는 웹서버

말씀하신 것 중에 가장 가까운 놈이 3번이 되겠는데요.
만들 당시에 "C로 이 짓을 하면 이번 세기(당시에도 21세기)에 완성할 수 있을까??" 라는 생각이 들었습니다......
근데 만들고 나면 성능은 좋았습니다.

[결론] 다 필요없고 할 짓이 못 된다.

소타의 이미지

제가 유일하게 들고와서 쓰는 놈은 APR(Apache portable runtime)인데요.
http://apr.apache.org/
APR, APR-Util 정도 조합하면 꽤 쓸만합니다. 단점은 APR 특성상 프로그램 처음부터 끝까지 APR로 도배를 해야만 할 것 같다는 압박을 주는데요.
이런 저런 부분만 쓰자니 뭔가 켕기고 도배하자니 찝찝하고 뭐 그런 기분입니다.

실 서비스에 올릴 때 APR 버전이 OS 기본 패키지랑 안 맞으면 APR을 컴파일해서 서버마다 배포하느니.. 걷어냅니다 =_=;;

[결론] 쓰나 안쓰나 귀찮긴 매한가지

select99의 이미지

옛날에 사용했던건데 몇년전에 FastCgi 와도 접목해봤더니 잘되더군요.

물론 필요한 오라클등 DB 들과도 무난히 붙습니다. 당연히 C가 호환되는모든것과 호환됩니다.

간단한 예제 하나보여드리면..

소스 : test1.c

#include <stdio.h>
#include <kcomm.h>
 
char Date[128];
int main( void )
{
	Reg_value( Date, "%s" );			/* 변수등록	*/
	sprintf( Date, "%d", get_today() );
	html_print( "test1.html_" );		/* 출력할 html 문서 */
	return 0;
}

디자인 : test1.html_

[geshifilter-html]&#10;테스트 ... 오늘은 $cgi_value( Date, &quot;xxxx년 xx월 xx일&quot; )$ 입니다.&#10;[/geshifilter-html]

결과

테스트 ... 오늘은 2009년 06월 23일 입니다. 

대충사용법이 이런 lib도 있습니다.
라이브러리 자체는 비교적 작고 가벼운라이브러리입니다. DB 와 연동하여 토론게시판을만들어보니 (기능에따라다르겠지만대충) C소스가 2000 라인안쪽에 할수 있을정도입니다.

더구나 FastCgi 아시는분 다아시겠지만.. 말그대로 매우빠릅니다.

리소스또한 최소한의 리소스만먹습니다.

물론 Pro*C로의 제작도 가능합니다.

초기 수행시의 부하도 매우작습니다....등등.

Php사용해보면 명령어들이 많은데 그러한명령어들조차 제공명령외에..프로그래머가 새로 재작등록 기능이있어 마치 새로운스크립트언어처럼 사용 될수도 있습니다..

죠커의 이미지

헤더 정보가 다 누락이 되었네요.

오픈소스 라이브러리를 사용하였다면 링크를 달아주십시요.

- 죠커's blog / HanIRC:#CN

jj의 이미지

요즘은 웹개발은 안합니다만, 이글보다가 뜸금없이 개그프로가 생각나네요...

"영광인줄 알아 이것들아!~ 우리땐 GET할때, url 파라미터 다 파싱해서 썼다..."

"그만해라, 얘네들이 printf로 HTTP헤더를 찍어봤겠니 쿠키를 날려봤겠니..."

저도 나이가 많이 들었나봅니다.
--
Life is short. damn short...

--
Life is short. damn short...

Jun92의 이미지

쓰신 글보고 한참 웃었네요..
동감도 되면서 한편으론 씁슬해지는게... 저도 나이가 많이 들었나봅니다. ㅎㅎ

=============================
야후!

소타의 이미지

분장실 강선생에 씁쓸한 인생까지..
대세는 개콘

youlsa의 이미지

아~ 웃겨서 미티겠네요. ^^

=-=-=-=-=-=-=-=-=
http://youlsa.com

=-=-=-=-=-=-=-=-=
http://youlsa.com

지리즈의 이미지

여전히 이짓하는 사람도 있죠. -_-;;;

이를테면, google desktop search 같이
인터페이스의 일부분이 webbrower 컨트롤을 통해서 제공되어야 하는
로컬 어플리케이션을 만들 때 같은 경우죠.

이 경우는 http 서버부터 cgi 까지 올인원으로 다 개발해야 합니다. -_-;;;
그래받자 동접 4~5개만 지원하는 세미 웹서버긴 하지만요.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

phonon의 이미지

지금 생각하면 자원의 낭비가 극심한 C-CGI가 있었기에, 그것을 개선하고져 여러 방법론이 나오고 스크립트 언어에 의한 웹개발이 시작되었다고 봅니다.
당연히 개발시간이나 수정하면 반드시 컴파일를 해야한다는 것은 다른 문제점이고 하더라도.

C-CGI, PerlCGI, ISAPI(DLL), ASP, PHP, JSP, Servlet, flex등으로의 발전이 이루졌지만, 웹2.0의 지원이 있다고 하더라도 HTTP의 범위 안에서의 웹의 발전은 이 이상은 힘들지 않을까 생각이 듭니다.

segfault의 이미지

Qt에서 영향을 받은 것처럼 보이는 Wt도 있습니다.
C++ 기반이며 Qt와 마찬가지로 signal과 slot을 활용하고 있습니다.
예제를 보면 아시겠지만 웹 개발 툴킷이라기보다는 GUI toolkit의 접근 방식을 가지는데, 덕분에 HTML 코드 한 줄 안 쓰고 웹 개발이 가능합니다.

http://www.webtoolkit.eu/wt

----
http://www.planetmono.org

namsuni의 이미지

qDecoder 를 한번 사용해보세요~
qDecoder로 나머지는 다 구현이 될 듯 싶고~
DB는 sqlite를 연동해서 사용하시면 되지 않을까요?
짧은 의견이나마 도움이 되시길...~^^

지리즈의 이미지

라이브러리 도움없이 어셈블로 짜보자는 말이 나올듯.

There is no spoon. Neo from the Matrix 1999.

There is no spoon. Neo from the Matrix 1999.

charsyam의 이미지

예전에 C로 웹메일을 만들어본적이 있습니다. -_-

그리고 C로 검색 관련 CGI를 만들어본적이 있는데

이 때 아마 PHP가 3.0 초기 버전이던가 그럴껍니다.

이때, 제 실수인지도 모르겠지만, 거의 비슷한 코드로

C를 PHP로 옮긴 코드로 -_-

같은 머신에서 20배 정도 성능 차이가 나더군요.

쿨럭... 결국 웹메일 C로 만들었다는 T.T

=========================
CharSyam ^^ --- 고운 하루
=========================

=========================
CharSyam ^^ --- 고운 하루
=========================

foxip의 이미지

결과물의 중간 단계 정도의 데이터를 메모리에 모조리 올리고 웹 말고도 다른 프로그램에서도 같이 사용해야 할 경우 관련 모듈(웹 포함)을 C/C++로 만들면 편하겠죠. 결과물 생성/관리는 웹에서 한다거나 하는 경우도 있고... 필요한 부분만 cgi 만드시거나 하면 될것 같고...

저는 리눅스로 게임서버 만드는 개발자인데 웹 스크립트 수준에서 구현 가능하다면 그렇게 하는게 좋고...
스크립트로 안될경우엔 C/C++이나 다른 언어로 작성하게 된답니다.
하다보면 인라인 어셈 코드 정도는 넣어야 할 경우도 생길 수 있지요.ㅎㅎ
아무튼 내가 만들고 싶은게 생기면 수단과 방법을 가리지 않고 만들면 됩니다.

위에 읽다보니 성능 관련 이야기가 잠시 있어서... :)

게임 개발자 포럼: http://www.vogie.net

istree의 이미지

몇년전 문득 남들 다 하는 싸이나 블로그를 저도 해보고 싶다는 생각이 들어서 고민하던중

'명색이 개발자인데 내 주 언어인 C++로 직접 해보자'라고 재미삼아 만들어본적이 있습니다.

Post/Get 및 Multipart하고 쿠키까지 했는데 세션은 좀 까다로워서 패스 하고 그냥 쿠키로 모두 처리했습니다.

개인적인 재미 또는 특별한 이유가 없다면 cgi로 만드는건 좀 비추입니다.. 디버깅 및 유지보수가 까다롭죠..(뭣좀 고칠때마다 컴파일을 새로해야하니..)

---------------------------------------------------------------------
너의(yours) 프로그램 : 똑똑한체하는 트릭과 부적절한 주석이 넘치는 혼란 그자체.

나의(my) 프로그램 : 간결하며 효율적인 측면과 다음 개발자들을 위해서 완벽하게 주석을 단 최고로 균형잡힌 정교한 코드의 결정체

- Stan Kelly-Bootle

너의(yours) 프로그램 : 똑똑한체하는 트릭과 부적절한 주석이 넘치는 혼란 그자체.

나의(my) 프로그램 : 간결하며 효율적인 측면과 다음 개발자들을 위해서 완벽하게 주석을 단 최고로 균형잡힌 정교한 코드의 결정체

- Stan Kelly-Bootle

hongminhee의 이미지

Grantlee라는 템플릿 엔진이 있군요. Django 템플릿 문법과 유사합니다.

홍민희 (VLAAH, LangDev)

ageldama의 이미지

JAVA + Flex/AIR 애플리케이션을 개발합니다만, C++(의 M$스런 subset-_-)으로 Flex/AIR에서 제공하지 못하는 클라이언트 시스템 연동과 관련한 부분을 작성하고 있습니다. 종전의 ActiveX/COM을 그대로 브라우져에 임베딩하는 방법 대신에 나름의 크로스플랫폼을 위한 격벽으로서도;;

좀 ㅂㅌ스럽게도-_-;; Flex/AIR측과 Native Agent와의 연동은 HTTP/JSON으로 하고 있습니다;;; =3=3

Mongoose HTTP server: http://code.google.com/p/mongoose/

왠만한것들은 다 해주고, IPC정도의 역활로 HTTP/JSON을 이용하는것이라 특별히 많은 HTTP관련 라이브러리는 이용하지않고 있습니다. (추가적으로 native agent 배포시 용량/호환성/dll의존성등의 문제로 light-weight하게-_-;;;)

정통파 웹개발은 아니지만(서블릿만들고, 웹프레임웍 만들고;;;), C/C++을 이용하여 HTTP나 그런 웹개발의 기반을 다른데 적용한다능... =3=3=3

----
The future is here. It's just not widely distributed yet.
- William Gibson

----
The future is here. It's just not widely distributed yet.
- William Gibson

monovision의 이미지

qDecoder 로 서버제어 솔루션을 만들어본 적이 있는데....
qDecoder 를 사용하기는 어렵지 않으나 솔직히 그닥 추천은 하지 않습니다. ㅡ.ㅡ;;;;
페이지 확인할 때마다 컴파일해야하고 디버깅도 어렵고...

그래서 C 로 만들었다가 php 로 다시 바꾸어버렸습니다.
서버 제어는 데몬 하나 만들어서 소켓 통신으로 제어하는 방식으로 수정해 버렸구요....

참고로... qdecoder 의 설명 중 일부를 첨부합니다.

http://www.qdecoder.org/ko-about.qsp

Quote:

근래의 JSP, ASP, Perl, PHP와 같은 언어는 웹 프로그램을 더욱 손쉽게 함이 사실입니다. 이러한 저작 언어들은 간략한 코드로 데이터베이스 연동을 손쉽게 하며 CPAN 등을 통해 풍부한 라이브러리 또한 제공 됩니다. 이러한 상황에서 우리는 때때로 ``어렵고 복잡한 C/C++ 언어로 굳이 웹 어플리케이션을 개발 할 필요가 있을까?''라는 생각을 하게 됩니다.

실로 많은 일반적 경우에 우리는 PHP와 같이 빠른 개발속도를 보장해주는 손쉬운 도구를 선택하여 개발에 임하게 되지만 몇몇 크리티컬한 요구 사항이 충족되어야만 할 경우에 많은 개발자들은 여전히 산업계 표준 언어인 C/C++을 개발 언어로 선택하고 싶어합니다.

동시 다발적인 프로세스로 인한 레이스 컨디션 상황에서의 파일 잠금 기법과 같은 임계 영역 처리, 프로세스간 통신 및 파이핑 처리, 병목 루핑 코드에 대한 퍼포먼스 보장, 저수준 컨트롤, 캐릭터/비트 단위 조작 등은 한 예가 될 수 있습니다. 또한 C/C++로 제작된 프로그램은 가장 넓은 플랫폼에 별다른 의존성 없이 손쉽게 이식이 가능하다는 장점을 갖습니다.

그 선택의 가장 큰 갈림길은 무엇보다 C/C++ 언어 특유의 까다로움으로 인한 개발 지연과 구현의 번거로움에 대한 두려움일 것입니다. 언어는 창조를 위한 도구일 뿐인데, 필요에 의해 만들어진 도구가 역으로 창조성에 제약을 준다면 이는 실로 주객이 전도된 상황이 아니라 할 수 없겠죠.

1996년 초 NCSA의 ``util.c''를 비롯해 공개된 몇몇 C/C++ CGI 라이브러리를 접하며 마음에 꼭 맞는 라이브러리를 찾지 못하던 즈음에 작성하기 시작한 qDecoder의 초벌 코드는 5.0에 접어들며 이제 어느정도 기본 골격을 갖추어 웬만한 프로그램은 C/C++ 만의 장점을 최대한 살린체 PHP나 Perl처럼 빠르게 프로그램할 수 있을 정도가 되었습니다. (아직 보강되어야 할 부분이 많이 남아 있지만, 적어도 저자에게는 틀림없는 사실 입니다.)

손쉬운 저작 도구는 계속 발전 할 터이이지만, C/C++만의 영역은 여전히 존재할 것입니다. 그것이 qDecoder가 존재하는 의미이며 지속적으로 개발되고 유지되는 이유입니다.

자, 우리가 C/C++ 옹호자가 아니며, 왜 JSP와 같은 편리한 도구가 있음에도 여전히 qDecoder와 같은 C/C++ 웹 어플리케이션 인터페이스가 필요한지에 대해서는 충분히 설명을 한 듯 합니다. 귀하의 개발이 C/C++의 특성을 필요로 할 때 qDecoder가 조그마한 도움이 될 수 있고, 우리가 배운 Free Software의 교훈을 미약하나마 실천할 수 있다면, qDecoder는 환호할 것입니다.

brianjungu의 이미지

98년이었는데, 이걸로 Polling하는 CGI만들었다가, 삼백명 들어올때 마다
한번씩 서버가 서는 경험을 했습니다.(SUN/Solaris/Oracle/Apache구성이었습니다.)

그래서 물어물어 PHP로 만들었는데, 정말 좋더군요...
그걸로 만명 넘을때까지 완전히 신경쓰고 살았습니다.