대부분의 일반적인 웹 브라우저 (Firefox, Chrome, Safari)는 C ++를 사용하여 개발 된 것 같습니다. 왜 그렇습니까?

질문을하는 또 다른 방법은 브라우저에 어떤 종류의 지원이 필요한가? 짧은 목록은 다음과 같습니다.

• 구문 분석 지원 ([X] HTML, CSS 및 [ECMA / Java] 스크립트를 이해해야 함)
• 나무 걷기 / 통역 기능 (구문 분석 및 건물 UI의 일부)
• 가속 그래픽 지원
• 빠른 네트워킹
• 고급 브라우저 : 프로세스 제어 및 페이지 간 메모리 분리
• 지원되는 모든 플랫폼에서 작동해야합니다

대부분의 언어에는 일종의 구문 분석 지원이 있습니다. C, C ++, C #, Java 등을위한 파서 생성기가 있습니다. 그러나 C와 C ++는 다른 대안을 시작하기까지 수년이 걸렸으므로 알고리즘과 구현이 더욱 성숙해졌습니다. Java로 가속화 된 그래픽에 액세스하면 작동하도록 기본 확장 기능이없는 한 계속 사용할 수 있습니다. C #의 WPF는 가속화 된 그래픽에 대한 액세스를 제공하지만이 기술을 사용하여 심각한 브라우저를 구축하기에는 너무 새롭습니다.

네트워킹은 실제로 Java 또는 C # 대신 C ++를 선택해야하는 최소한의 이유입니다. 그 이유는 통신이 페이지를 표시하기 위해 진행하는 나머지 처리보다 몇 배 느리기 때문입니다. 와이어의 원시 속도는 제한 요소입니다. Java와 C # 모두 C ++과 마찬가지로 비 차단 IO 지원을 제공합니다. 따라서이 분야에서 확실한 승자는 없습니다.

왜 Java가 아닌가? Java로 UI를 구축하려고 시도한 적이 있습니까? 그것이 있기 때문에 다른 것에 비해 성 가시고 느리게 느낍니다. 가속 그래픽도 큰 부정적인 점은 없습니다. Java의 샌드 박싱은 실제로 훌륭하며 브라우저가 올바르게 사용되면 브라우저의 보안을 향상시키는 데 도움이 될 수 있지만 구성 및 작업이 어려워집니다. 그래픽 형식 지원은 대부분의 최신 브라우저보다 뒤쳐져 있습니다.

왜 C #이 아닌가? 유일한 대상이 Windows 인 경우 C #은 실제로 잘 표현 될 수 있습니다. 다른 것을 지원하려고 할 때 문제가 발생합니다. Mono는 특히 그래픽 지원과 WPF가 가속화되면서이 작업에 충분한 크로스 플랫폼으로 간주되기에 충분하지 않았습니다. 얼마나 시간이 오래 걸릴지 누가 알 겠어요.

왜 C가 아닌가? 임베디드 장치를 포함하여 거의 모든 플랫폼을위한 C 컴파일러가 있습니다. 그러나 C가 당신을 위해 하지 않는 것이 많이 있습니다. 모든 최저 수준의 API에 액세스 할 수 있지만 대부분의 C 개발자는 GUI를 수행하지 않습니다. C GUI 라이브러리조차도 객체 지향 방식으로 작성됩니다. UI 대화를 시작하자마자 객체 지향 언어가 더 이해하기 시작합니다.

목표 C가 아닌가? 당신의 유일한 목표는 애플이라면, 많은 의미가 있습니다. 그러나 대부분의 개발자는 Objective-C를 알지 못하며 배우는 유일한 이유는 NeXT 또는 Apple 상자에서 작업하는 것입니다. 물론 Objective-C와 함께 모든 C 라이브러리를 사용할 수 있으며 많은 플랫폼에 대한 컴파일러가 있지만 작업 할 사람을 찾는 것이 더 어려울 것입니다. 누가 알아? 아마도 애플은이 부족한 결함을 돌릴 수있을 것이다.

왜 C ++인가? 거의 모든 플랫폼을위한 C ++ 컴파일러가 있습니다. 거의 모든 GUI 라이브러리에는 C ++ 인터페이스가 있으며 때로는 더 좋으며 때로는 다른 경우도 있습니다. 예를 들어, Microsoft의 ATL은 win32 C 함수 호출 또는 MFC 라이브러리보다 훨씬 낫습니다. 유닉스에 GTK를위한 C ++ 래퍼가 있는데 누군가 Apple의 Objective-C GUI 라이브러리에 대해 C ++ 래퍼를 가지고 있지 않은 경우 놀랍습니다. C ++에서 프로세스 관리는 Java 또는 C #보다 쉽습니다 (자세한 내용은 추상화되어 있음). 인식 된 속도는 기본 성능보다 하드웨어 가속에서 비롯됩니다. C ++은 원시 C (예 : 바운드 문자열)보다 더 많은 것을 처리하지만 여전히 자유롭게 조정할 수 있습니다.

당분간 C ++은 대안을 능가합니다.

나는 사람들이 그것에 대해 광택을 내고 나를 찬양하기를 희망하여 이것에 관한 소설을 쓰기로 결정했습니다. 아니, 농담이야! 나는 모든 말로 고생했다. 모든 단어, 나는 당신에게 말한다!

'왜'전에 '언제'물어보기

모든 주요 웹 브라우저는 그 기원을 90 년대로 추적 할 수 있습니다. Konqueror는 Safari와 Chrome이되었습니다. Netscape는 Firefox가되었습니다. IE와 Opera는 여전히 IE와 Opera입니다. 이 브라우저는 모두 기존 기업에서 15 년 동안 시작됩니다.

최신 브라우저가 시작된 1995 년경에 사용 가능한 허용 가능한 크로스 플랫폼 (Windows / Mac / Unix 및 더 나쁜 언어)의 이름 을 지정 하는 것이 좋습니다 . C / C ++ 이외의 코어를 구축하려면 컴파일러와 플랫폼 라이브러리를 구축하거나 구입하고 수정해야 할 것입니다.

오늘은 어때요? 대안은 무엇입니까?

재미를 위해 오늘 문제에 대해 생각해 봅시다. 예, 대안이 있지만 여전히 큰 문제가 있습니다.

언어 선택은 적어도 다음과 같은 문제를 나타냅니다.

1. 지식 문제-개발자 고용 / 훈련 또는 참여자 유치
2. 조직 / 사회적 문제-언어 수용
3. 언어 구현 : 속도, 플랫폼 지원, 툴링
4. 언어 능력

1 : 지식 문제

언어를 알고 있거나 배울 수있는 사람들을 어디서 구할 수 있습니까? 이것은 OCaml, F #, Haskell, Common Lisp 및 D와 같은 언어에는 브라우저를 멋지게 작성하기에 충분할 정도로 빠르지 만, 10k-100k 범위에서 팔로어가 거의없는 경우에도 방해가됩니다. 모든 애호가와 학자를 계산하십시오.

2 : 사회 / 조직 문제

위의화물 컬트 답변에 대한 추론 :

• C, C ++, C # 또는 자바를 사용하지 않는 오픈 소스 브라우저는 것이다 가정 기여자에 어려움이있다.
• C, C ++, C # 또는 Java를 사용하지 않는 독점 브라우저는 대부분의 조직에서 프로젝트 관리자에게 큰 소리를 지 릅니다.

3. 기술적 문제

현대에도 페이지 렌더링 및 Javascript 실행의 계산 집약적 부분을 위해서는 상당히 빠른 언어가 필요합니다. GUI 요소 등을 빌드하기위한 고급 언어 (예 : C ++ 및 Javascript의 Firefox 접근 방식)를 보완하도록 선택할 수 있지만 언어 간 밀접한 통합이 필요합니다. "좋아, C #과 루아"라고 말할 수는 없어 C 또는 C ++를 기본 언어로 선택하지 않는 한 브리지를 직접 빌드하고 디버깅해야합니다.

크로스 플랫폼 개발은 또 다른 웜 백입니다. C # 또는 F #을 사용하고 미래에 GTK # 및 Mono에서 살아남을 수 있습니다. Common Lisp, Haskell, OCaml ...을 사용해보십시오. Windows 및 Mac 및 Linux 에서 모든 작업을 수행하는 것이 좋습니다 .

4. 언어 능력

그 후에는 엄청난 양의 기능을 구축해야하므로 저수준 언어를 선택하면 이전보다 훨씬 큰 코더가 필요합니다. 약 15 년 동안 브라우저를 처음부터 새로 구축 한 사람은 아무도 없습니다. 그것은 부분적으로 (놀랍습니다!) 어렵 기 때문입니다.

특히, Javascript 인터프리터를 갖는 것은 문제 3 (하나를 획득) 또는 문제 4 (하나를 빌드)입니다.

결론:

오늘 (2011 년 초) 3 개의 플랫폼 (Windows / Mac / * nix) 브라우저를 개발 한 경우 어떤 선택이 있습니까?

• C : (2)를 참조하십시오. 모두가 C ++을 요구합니다. 크로스 플랫폼 툴킷을 선택하거나 하나 (1, 2, 3 및 4)를 빌드하는 것을 즐겁게하십시오. (4)도 참조하십시오. 안정적이고 안전한 브라우저를 구축하는 재미가 있습니다.
• C ++ : 크로스 플랫폼 툴킷을 선택하거나 하나 (1, 2, 3 및 4)를 빌드하는 재미가 있습니다. 안정적이고 안전한 브라우저를 구축하는 재미 (4)가 있습니다.
• C 또는 C ++ 및 HLL : 최선의 방법. 역동적 인 언어로 독을 선택하십시오. (1)과 (2)를 참조하십시오. 좋은 언어가 너무 많고 각각의 추종자가 너무 적습니다. 툴킷에서 (1, 2, 3 및 4).
• 자바 : 중간 관리를 기쁘게해야한다면 두 번째 최선의 방법입니다. (4) 참조; Java로 거대한 것을 구축하려면이 목록의 다른 것보다 훨씬 많은 코드가 필요하지만 아마도 C입니다.
• 스칼라 : (4)에서 Java를 제치고; (1)과 (2)하지만 따라 잡고 있습니다.
• C와 자바 스크립트 : 특별한 경우, 이미 자바 스크립트 인터프리터를 구축하거나 입수하고 동화해야하기 때문에 이는 매력적입니다. 툴킷의 (따라서 Firefox.) (1, 2, 3 및 4); 모질라 사람들은 자신의 IIRC를 만들었습니다.
• C # : (3)을 즐기십시오. GTK #에 갇혀있을 수도 있지만 GTK # 및 Windows Forms 위에 자체 레이어와 렌더러를 구축하는 것이 좋습니다.
• Ruby / Python / Perl / Racket / Lua / Erlange 등 : 크로스 플랫폼 위젯 라이브러리와 속도에 대해 (3) 있습니다. 무어의 법칙은 당신과 함께합니다 (4). 브라우저에 대한 수요가 증가하고 있습니다.
• OCaml, Haskell, Common Lisp, Smalltalk : (1) 및 (2) 스페이드 아마도 속도 문제는 없지만 (3) 크로스 플랫폼 개발을 위해서는 자체적으로 모든 것을 구축하거나 C / C ++ 라이브러리에 연결해야합니다.
• Objective-C : (3) 크로스 플랫폼 개발이 어떻게 진행되는지 잘 모르겠습니다.

향후 몇 년 동안 또 다른 주요 브라우저가 등장 할 경우 오픈 소스이든 독점이든 C 또는 C ++로 작성되고 동적 언어 (Firefox처럼)로 작성 될 것입니다.

편집 (2013 년 7 월 31 일) : Hacker News의 논평자는 Rust and Go (특히 내 대답과 관련이 없음)를 언급하는 것으로 보이며 "기타 빠른"버킷에 모호합니다. 이 언어 목록을 평등하고 최신 상태로 유지하는 것은지는 싸움이 될 것이므로 글을 쓰고 떠날 때를 대표 샘플이라고 부릅니다.

속도

추악한 것처럼, C ++은 빠른 ​​응용 프로그램과 코드에 대한 완전한 제어를 원할 때 여전히 사용하는 것입니다.

Office의 게임, 비 핵심 부분 (예 : 파일 가져 오기) 등이 여전히 C ++로 작성된 이유입니다.

MSalters의 응답을 포함하도록 편집

이식성

추측 할 수는 있지만 여러 플랫폼을 대상으로하는 소프트웨어 제품을 언급하고 있으며 C ++을 모든 플랫폼으로 컴파일 할 수 있습니다.

(저는 약 5 년 동안 Firefox에서 일해 왔습니다.)

문제는 많은 Firefox 코드가 C ++이며 실제로 코드 줄로 계산하면 C ++이 가장 많다는 것입니다 (우리가 JavaScript를 많이 가지고 있기 때문에 전체 이야기를 알려주지는 않지만 JS는 더 많습니다) C ++보다 간결합니다).

그러나 실제로 Firefox는 다양한 언어로 작성되었습니다.

• C ++
• C (NSS, NSPR, 우리가 가져온 다양한 라이브러리)
• x86 및 ARM 어셈블리
• 자바 스크립트
• XUL (HTML 유사 마크 업 언어) 및 CSS
• 목표 C (MacOS 전용 코드)
• 자바 (Android 전용 코드)
• 여러 사용자 정의 인터페이스 정의 언어 (XPIDL, IPDL)
• WebIDL (다른 인터페이스 정의 언어이지만 코드 생성기는 있지만 사용자 정의가 아님)
• 파이썬 (코드 생성기)

나는 확실히 일부를 잊고있다.

이 목록은 웹 브라우저 뒤에있는 매우 복잡한 복잡성을 암시하므로 중요합니다.

예, Firefox에는 많은 C ++ 코드가 있으며, Netscape가 설립 될 때 C ++이 이런 종류의 언어에 가장 적합한 언어라는 사실과 관련이 있습니다. 그러나 나는 또한 오늘날 우리가하는 많은 일을위한 더 나은 언어가 없다고 주장합니다.

다른 언어는 라이브러리의 생태계만큼 강력하지 않습니다 (외부 코드에 크게 의존 함). C ++과 같은 전체 스택 제어를 제공하는 다른 언어는 거의 없습니다 (우리는 정기적으로 사용자 정의 힙 할당자를 조정하고 모든 종류의 메모리 안전하지 않은 것들을 더 빠르거나 메모리를 덜 사용합니다). 대부분의 표준 라이브러리를 제정신 방식으로 다시 구현할 수있는 다른 언어는 거의 없습니다 (필요에 따라 조정 된 자체 문자열 및 컬렉션 구현이 있음). 다른 언어로는 자신 만의 가비지 수집기를 구현할 수 있습니다. 등등.

C ++이 우리가하는 많은 일에 대한 확실한 선택이지만, Java로 브라우저를 작성하고 필요한 경우 자체 JVM을 작성할 수 있다고 제안하는 사람들은 무언가에 있습니다. 이것은 본질적으로 우리가하는 일이지만 Java 대신 JavaScript를 사용합니다. 물론 많은 브라우저가 JavaScript로 작성되지 않았습니다. 그러나 놀라운 금액입니다.

글쎄, 당신이 얻을 직접 해당 제품의 개발자에게 문의해야 할 것 대답을하지만, 나는 그것이 친숙의 조합 용의자 (바이트 코드와 달리 네이티브 바이너리로 컴파일), 성능, 그리고 (그것은 그 개발자가 가장 알고 무엇) 도구 (C와 같은 언어와 비교할 때 C ++에는 STL과 같은 멋진 노동 절약 가제트가 가득합니다).

역사

각 브라우저에는 언어 선택에 영향을 미치는 몇 가지 역사가 있습니다.

예를 들어 Chrome과 Safari는 모두 KDE 프로젝트의 KHTML 부분에서 시작된 WebKit을 기반으로합니다. KDE는 원래 Qt GUI 툴킷의 데모로 부분적으로 작성되었으므로 KDE는 전체적으로 C ++ 프로젝트입니다. 당시 모든 새로운 KDE 프로젝트는 전적으로 C ++로 작성되었으므로 KHTML의 논리적 선택이었습니다. 이후 다른 GUI 툴킷을 사용하도록 포팅되었습니다.

Opera의 Presto 엔진은 성능과 작은 바이너리 크기를 염두에두고 작성되었습니다. C ++이 논리적 선택이었습니다.

Microsoft의 IE는 ActiveX 구성 요소 모음으로 작성되었습니다.이 구성 요소는 COM 바인딩이있는 모든 언어로 작성 될 수 있지만 대부분의 코드베이스가 이미 해당 언어로 작성 되었기 때문에 C ++의 하위 집합으로 작성되었을 수 있습니다.

Netscape의 Mozilla는 이식성이 주요 관심사 였기 때문에 C ++로 작성되었습니다. C 및 C ++ 컴파일러는 (가상적으로) 어디에나 존재하므로 논리적으로 선택되었습니다.

이러한 선택에 대한 기술적 인 이유는 없습니다 . 그것은 단지 "당시 좋은 생각처럼 보였다."

원하지 않는 경우 라이브러리를 사용할 필요가 없으므로 C 및 C ++의 네트워킹은 최적화하기 쉽습니다. C ++이 C의 장점을 허용하기 때문에 C ++이 선택한 언어라고 생각합니다.

• 속도
• 최적화
• 어느 정도의 휴대 성
• 컴파일되지 않은 언어, 해석되지 않음

OOP의 장점과 결합 :

• 확장 성
• 보다 쉬운 시각화
• 문자열 처리 및 데이터 구조와 같은 중요하지 않은 작업에 대한 향상된 라이브러리 지원

첫 번째 라운드의 브라우저에 대한 첫 번째 코드 줄을 작성할 때 C # 및 Java가 존재하지 않았습니다. 루비도 마찬가지였습니다. 파이썬은 주변에 있었을 지 모르지만, 그 시점에서 여전히 소규모 사제 프로젝트였습니다.

기본적으로 C ++ 이외의 다른 선택 사항은 실제로 여러 플랫폼에서 빠르고 실행되는 브라우저를 빌드 할 수있게했습니다.

왜 그들은 C ++로 작성 되었습니까? 그것이 쓸 수있는 유일한 언어 였기 때문입니다.

다른 언어로 작성된 브라우저 (예 : Java로 작성된 HotJava)는 실질적으로 어느 정도의 시장 승인 / 투과율을 달성 한 적이 없습니다.

HotJava 의 현재 반복 (또는 가장 최근에는 꽤 오래 업데이트 되지 않은)에 대해 아무 말도 할 수 없지만 시도했을 때 시장 침투력 부족은 이해하기가 매우 쉽습니다 (적어도 나에게는) -그것은 추악하고 느리고 꽤 많은 웹 페이지와 호환되지 않았습니다. 궁극적으로 웹은 절대로 전개되지 않은 전제에 기반한 것처럼 보였습니다. 웹은 주로 Java 애플릿으로 구성되며 HTML은 애플릿이 표시 할 위치를 알려주는 랩퍼에 지나지 않습니다.

그것의 일부는 아마도 역사적인 것입니다 : 대부분의 큰 웹 브라우저는 오랫동안 사용되어 왔습니다. C ++은 "새로운"언어 였으므로 많은 새로운 개발에 사용되었습니다. 브라우저는 가장 많이 사용되는 소프트웨어가되었으며, 그 이후로 많은 브라우저가 망각으로 사라졌습니다.

나는 언어의 표시된 "태도"도 효과가 있다고 생각한다. C ++ (이전의 C와 같은)은 항상 실용성과 실용주의를 강조했다. 이러한 기본적인 태도는 실용적 인 프로그래머를 끌어들이는 경향이 있습니다. 다른 많은 언어들은 우아함과 같은 것에 중점을두고 있습니다. 그렇게함으로써 그들은 같은 방식으로 생각하는 프로그래머들을 끌어들입니다. 그 문제는 내가 "Lisp effect"라고 부르는 것입니다. 증상은 다음과 같습니다.

1. 가장 사소한 것의 가장 우아한 구현에 대한 끝없는 논쟁 .
2. 기능을 고정하고 배송 할 수있는 물건을 완성 할 수 없음 (결함이있는 경우에도)
3. 타협 할 수 없습니다. 나와 동의하지 않는 사람은 틀린 것이 아니라 어리 석거나 사악해야합니다.

더 많은 것이 있지만 일반적인 아이디어를 얻습니다 (그리고 나는 어느 정도 과장하고 있지만 어느 정도까지는 과장하고 있습니다). 예, 얻는 코드 중 일부는 놀라 울 정도로 아름답습니다.하지만 6 개월 늦었고 시스템의 모든 다른 코드 조각과 호환되지 않을 가능성이 높습니다. 꽤 공정한 기회는 전혀 사용할 수 없을 정도로 다른 것이 변했습니다.

의심의 여지없이 잘 작동하는 언어도 있지만 (올바른 또는 잘못 된) 누구나 브라우저를 작성한 적이있는 시장 점유율을 갖지 못하거나 중요 시점에 없었습니다. 완전한 브라우저의 크기와 복잡성을 감안할 때 많은 사람들과 브라우저 개발에 많은 시간이 걸립니다. 이런 종류의 투자로 많은 사람들이 개발 도구와 같은 것들에 대해 상대적으로 보수적입니다.

화물 컬트 프로그래밍. "C ++가 빠르다"는 인식은 여전히 ​​남아 있고 (물론 느리게 작동하는 개체가 깨지는 개체 모델과 같이 잘못 생각한 언어 수준의 기능에도 불구하고) 사람들은 브라우저가 빠르기를 원하기 때문에 C ++로 작성합니다. .

제정신의 세계에서 네트워크 대면 소프트웨어를 작성하는 사람들은 C의 모든 고유 보안 문제로 둘러싸인 언어를 사용한다는 생각만으로도 끔찍할 것입니다. 실제로 그렇게하는 것은 범죄 과실이 될 것입니다. (지난 15 년 동안 다양한 브라우저에서 발견 된 버퍼 오버플로 악용 사례를 살펴보십시오!이 코더가 수백만 달러의 피해를 입었습니까?)

빠른 바이너리를 만들 수있는 다른 컴파일 된 언어가 있습니다. 문제는 그들이 C 가족과 같은 노출을 가지고 있지 않다는 것입니다. 우리 모두는 그것을 겪어야합니다.

재미있는 사실 : 모리스 웜이 1988 년 인터넷에 등장하면서 C 언어로 OS와 네트워크 소프트웨어를 작성하는 데 문제가 있다는 결론을 내 렸습니다. 애플은 파스칼 (Pascal)로 작성된 몇 년 전부터 지금까지 세계에서 가장 진보 된 운영 체제를 발표했다.

시스템 레벨 API에 액세스

모든 브라우저는 어느 시점에서 OS와 인터페이스해야하며 대부분의 주요 OS는 잘 확립 된 C 및 C ++ API와 라이브러리를 가지고 있습니다. 일반적으로 래퍼를 작성하는 대신 C 또는 C ++에서 해당 API로 작업하는 것이 더 쉽습니다.

제어 및 이식성

대부분의 속도 논증은 어느 쪽이든 갈 수 있지만 어떤 일이 어떻게 수행되는지에 대한 정확한 통제가 필요한 모든 곳에서 많은 고급 언어가 퍼레이드에 비가 올 것입니다. 여기에는 예외가 있지만 대부분 브라우저와 같은 것으로 계산하기에 충분한 크로스 플랫폼이 아닙니다.

레거시 호환성-이전 코드를 버릴 수 없음

C ++과 다른 언어의 장점과는 아무런 관련이 없습니다. Haskell과 같은 언어로 더 나은 브라우저를 처음부터 새로 작성할 수 있습니다. 이 중요한 프로젝트는 성능 특성을 보장해야하는 경우 자체 JVM을 구현할 수도 있습니다. Facebook이 자체 PHP 컴파일러 / 최적화기를 작성한 방식과 같습니다.

비표준 마크 업을 위반하는 브라우저는 쓸모없는 것보다 나쁩니다. 레거시 compat은 매우 중요하고 너무 복잡하여 재 작성이 옵션이 아닙니다. 전투 테스트를 거친 보안 등에 많은 돈과 시간이 투자됩니다. 그 투자를 버릴 수는 없습니다. 다시 말하지만, 페이스 북이 여전히 PHP로 작성된 방식과 같습니다 .