현대 도서관에서 OOP를 사용하지 않는 이유

20

저는 초급 C ++ 프로그래머이지만 언어의 개념을 상당히 잘 알고 있습니다. SDL과 같은 외부 C ++ 라이브러리를 배우기 시작했을 때 OpenGL (아마도 다른 것)은 놀랍게도 C ++ 개념을 전혀 사용하지 않는다는 것을 알게되었습니다.

예를 들어, SDL이나 OpenGL은 함수와 오류 코드를 선호하는 클래스 나 예외를 사용하지 않습니다. OpenGL에서 glVertex2f와 같은 함수를 보았습니다.이 함수는 2 개의 부동 변수를 입력으로 사용하고 아마도 템플릿으로 더 좋습니다. 또한 이러한 라이브러리는 때때로 marcos를 사용하지만 매크로를 사용하는 것이 좋지 않다는 일반적인 동의 인 것 같습니다.

대체로 C ++ 스타일보다 C 스타일로 더 많이 작성된 것 같습니다. 그러나 그것들은 완전히 다른 언어가 아닙니다. 그렇지 않습니까?

문제는 현대 도서관이 작성된 언어의 장점을 사용하지 않는 이유는 무엇입니까?

— 세이지
소스

1

Timo가 귀하의 질문에 잘 대답했다고 생각합니다. 다른 이유 (다른 라이브러리의 경우)는 C로 작성되어 이식 된 라이브러리 일 수 있습니다. 또는 C 개발자가 작성했습니다.

— Jeanne Boyarsky

5

그 외에도 OpenGL도 그들이 젊거나 최소한 새로운 멋진 기능을 채택 할 수 있다는 점에서 "현대적인"것도 아닙니다. 둘 다 오랜 역사 (OpenGL 1.1 : 1997; SDL : 1998)와 이전 버전과의 호환성 제약 조건이 있습니다.

1

DirectX는 훨씬 더 객관적입니다.

— cHao

1

stl 및 Boost와 같은 기본 C ++ 라이브러리는 낡고 구식이며 쓸모없는 OOP 개념도 사용하지 않습니다.

— SK-logic

5

SDL과 OpenGL이 많은 "현대 라이브러리"를 대표한다는 오해가 있다고 생각합니다. 예를 들어 매우 인기있는 Qt 라이브러리는 완전히 객체 지향적입니다. 질문 제목이 "SDL과 OpenGL이 OOP를 사용하지 않는 이유"가 더 낫습니다.

— Doc Brown

31

OpenGL과 SDL은 모두 C 라이브러리이며 C 인터페이스를 전세계에 공개합니다 (거의 모든 언어는 C와 인터페이스 할 수 있지만 반드시 C ++와 인터페이스 할 수는 없음). 따라서 C가 제공하는 절차 인터페이스와 C가 데이터 구조를 선언하고 사용하는 방법으로 제한됩니다.

C 인터페이스가 제공하는 "다른 언어와의 인터페이스"측면을 넘어 서면 C는 일반적으로 C ++보다 이식성이 뛰어나므로 플랫폼 코드에 의존하지 않는 라이브러리 코드를 쉽게 얻을 수 있습니다. 다른 OS 또는 하드웨어 아키텍처에서 작동하는 것과 같습니다. 거의 모든 플랫폼에는 괜찮은 C 컴파일러가 있지만 C ++ 컴파일러를 제한 한 일부 또는 여전히 좋지 않은 컴파일러가 여전히 있습니다.

C와 C ++는 매우 다른 언어이지만, "호환되지 않습니다". 실제로 C ++은 C의 수퍼 세트입니다. 비 호환성이 많지만 많지는 않지만 C ++의 C 인터페이스를 사용하는 것은 매우 쉬운 일입니다 할 것.

— 티모 게 우스
소스

아, 알겠습니다 그렇다면 다음 질문은 OpenGL만큼 효과적인 C ++ 용 그래픽 라이브러리가 있습니까? 아니면 C ++의 모든 장점을 사용하고 리소스를 잘 관리하는 OpenGL에 대한 래퍼일까요? API는 훨씬 깨끗해 보이며 메모리 / CPU 오버 헤드가 너무 높지 않을 것이라고 생각합니다.

— Saage

효과 또는 효율적? 어느 쪽이든, SDL 또는 OpenGL에 대한 C ++ 래퍼를 찾는 것이 상당히 쉬워야합니다. 빠른 구글은 OpenGL을 위해이 래퍼 (wrapper)를 가져 왔습니다 : oglplus.org- 그것이 얼마나 좋은지 모르겠지만 그것을 사용하지 않았습니다.

— Timo Geusch

1

예, 더 많은 C ++ 인터페이스로 OpenGL을 포장하려고 시도하는 프로젝트가 꽤 있습니다 (많은 기능을 삼가고 대부분 오버로드 등을 추가하지만 나 자신도 가지고 있습니다). 필자는 인상적인 OpenGL 스 니펫을 번역하기 어렵고 표준 최적화를 적용하기가 더 어려워 짐을 많이 넣는다는 인상을 받았습니다 (데이터 지향 디자인, 일부 게임 개발자는 맹세합니다). 그러나 결코 그것을 막지 마십시오. 또는 단순한 그래픽 API가 아닌 전체 게임 엔진 (예 : Irrlicht 또는 Ogre)을 사용하면 더 많은 행운을 얻을 수 있습니다.

좋아, 나는 내가 찾고있는 모든 대답을 가지고 있다고 생각한다. 모두 감사합니다!

— Saage

또한 그래픽 하드웨어는 클래스에 대한 계산을 이해하거나 수행하지 않습니다. 당신은이 float3모든 하드웨어가 수레의 배열입니다과 관련되어 있기 때문에들. "클래스"구조 (벡터가 2, 3 또는 4 개의 부동 소수점이라는 개념)는 카드가 메모리 힙에 액세스하도록 지시하는 방식에 모두 내재되어 있습니다. 그래픽을 프로그래밍 할 때 클래스에서 시도하고 생각하는 것이 좋을 수도 있지만, 제 생각에는 그러한 종류의 작업은 구현의 더러운 세부 사항을 추상화하는 데 도움이되는 것보다 번거로운 하드웨어에 가깝습니다.

— David Cowden

10

"라이브러리 작성"과 "API 외부 노출"을 혼동하고 있다고 생각합니다. 나는 당신이 언급 한 라이브러리에 대해 구체적으로 알지 못하지만 (내부 C로 작성되었을 수도 있음) 다른 많은 사람들도 포함되어 있으며 모든 종류의 멋진 OOP 사례 / 패턴을 완전히 활용하는 C ++ 라이브러리 / 프레임 워크를 작성했습니다 C 스타일 API를 외부 세계에 노출했습니다.

C와 C ++는 완전히 다른 시스템이 아닙니다. C ++은 C 위에 구축되었으며 a) C 코드를 쉽게 소비 할 수 있으며 b) C 스타일 API를 완벽하게 제공 할 수 있습니다.
C 인터페이스의 장점은 다른 세계에서도 매우 쉽게 소비 할 수 있다는 것입니다. C ++ 인터페이스는 거의 모든 언어 (python, java, c #, php ...)에서 C API를 사용할 수있게하는 interop 레이어가 있습니다. 다른 컴파일러, 동일한 컴파일러의 다른 버전으로 인해 문제가 발생할 수 있습니다)

과거에는 작업중인 프로젝트 중 하나의 실험으로 C ++ DLL에서 "OO"인터페이스를 공개하기로 결정했습니다. 내부 세부 정보를 숨기고 다른 많은 것을 피하기 위해 Windows COM (구성 요소 개체 모델)을 거의 다시 개발했습니다. 그 프로젝트 후에, 나는 사람들이 COM이 나쁘지 않다는 것을 깨달았다. 왜냐하면 a) OOP 인터페이스를 노출시키고, b) 내가 겪은 모든 문제를 처리하고 c) 여러 다른 언어.

그러나 COM은 여전히 수하물이 없습니다. 많은 경우, 정기적 인 계획 C 스타일 API가 여전히 훨씬 더 나은 대안입니다.

— DXM
소스

7

OpenGL과 SDL은 모두 C ++ 라이브러리가 아닌 C 라이브러리입니다. C ++에서 사용할 수 있지만 C로 작성되었으며 C API가 있습니다 (다른 언어에서도 액세스 할 수 있습니다. C ++은 FFI를 통해 액세스하기가 어렵습니다). 보세요 부스트 범용의 큰 배열 (일부 전문) C ++ 라이브러리에 대한 SFML 는 C ++ 멀티미디어 라이브러리를.

3

OpenGL과 관련하여 OpenGL은 원래 API 스택의 일부였습니다. OpenGL은 C (또는 Fortran)에서 액세스 할 수있는 저수준의 성능 지향적 API를 제공했으며 OpenInventor는 설계된 고급 수준의 객체 지향 API를 제공했습니다. C ++에서 사용되며 고급 장면 그래프 API와 파일에서 장면을 저장 / 읽기위한 추상화 및 GUI 통합을 모두 제공합니다.

OpenGL은 OpenInventor보다 훨씬 더 멀리 나아갔습니다 (비디오 하드웨어 제조업체에 최적화 할 무언가를 제공하고 3D 가속 하드웨어를 직접 처리하는 대신 대상이 될 수있는 일반적인 저수준 API 제공). 그러나 OpenInventor는 여전히 존재하며 Unix / X11, Windows 및 MacOS X / Cocoa를 지원하는 훌륭한 오픈 소스 구현 인 Coin3D가 있습니다.

— 짐 와이즈
소스

-2

그 도서관은 전혀 현대적이지 않습니다. 그것들은 C API이며 나쁜 것입니다. 전제에 결함이 있습니다.

— 데드 MG
소스

OpenGL은 어떻게 현대적이지 않습니까?

— James

1

나는 실제로 이것에 동의해야한다. OpenGL은 관리 상태에 액세스하고 조작하기위한 모델이 1990 년대 초의 하드웨어를 기반으로한다는 점에서 현대적이지 않습니다. 텍스처를 특정 유닛의 특정 대상에 바인딩하는 것과 같은 작업을 수행해야하고 VRAM에있는 텍스처 수에 관계없이 사용 가능한 수의 제한 만 갖는 것은 그리 현대적이지 않습니다.

— user1118321