2010-05-28 4 views
3

이전에 다중 상속이 잘못되어 지원되지 않는다고 명시된 임베디드 플랫폼에 대한 C++ 표준을 작성하려는 시도에 대해 약간 읽었습니다. 내가 알기로 이것은 결코 주류로 구현되지 않았고 대부분의 임베디드 C++ 컴파일러는 대부분의 표준 C++ 구조를 지원합니다.임베디드 C++ 컴파일러가 다중 상속을 지원하지 않는 인스턴스?

현재 임베디드 플랫폼 (즉, 몇 년되지 않은 것)의 컴파일러가 다중 상속을 절대적으로 지원하지 않는 경우가 있습니까?

클래스의 두 가지 전체 구현을 가진 자식이있는 의미에서 다중 상속을 실제로하고 싶지 않습니다. 내가 가장 관심을 가지는 부분은 클래스의 단일 구현을 상속 한 다음 인터페이스로만 하나 이상의 순수 가상 클래스를 상속하는 것입니다. 이것은 Java/.Net과 거의 같지만 하나의 클래스 만 확장 할 수 있지만 필요한만큼의 인터페이스를 구현할 수 있습니다. C++에서는 인터페이스를 명확하게 정의하고 클래스를 구현한다고 선언하는 대신 다중 상속을 통해이 모든 작업을 수행합니다.

는 업데이트 :

관심 없어요 그것은 또는 그것이 C 프로그래머가 작은 바이너리를 생성 대처하기 위해 C++ 다운 바보로 시도, 또는 종교 무엇을 얼마나 기술적으로 C++,없는 경우 화제의 사람들이 화염 전쟁을 위해 사용하고 있습니다.

요점 : 개발 목적으로 다중 상속을 지원하지 않는 자체 C++ 컴파일러 (예 : GCC 또는 MSVC를 사용할 수 없음)를 제공하는 현재의 임베디드 플랫폼이 있는지 알고 싶습니다. 임베디드 C++ 표준을 언급하면서 저의 목적은 질문에만 배경을 제공하는 것이 었습니다.

+0

EC++에 대해 읽으셨습니까? 아직 지원되지 않는다고 생각합니다. – Nikko

+1

또는 순수한 <파도 끼기 바람>을 위해 어떤 플랫폼에 C++ 컴파일러가 없지만 C++과 같은 많은 언어를 지원하는 플랫폼은 없습니다. MI를 포함합니다. –

+0

관련성이 있지만 질문에 대한 대답이 아닙니다 : 하나의 C++ 컴파일러 Thumb 명령어 세트 용으로 컴파일 할 때 대상 ARM에서 버그가있는 코드를 생성했습니다 (다른 기본 클래스의 가상 함수 용 썽크는 '슬랙 스페이스'가 아무 지시도 지시하지 않았다, 그러나 때때로 쓰레기로 대신 채우게되었다). 문제는 수정되었지만 당시 우리에게 큰 슬픔을 안겨주었습니다. 내 요점은 컴파일러가 MI를 지원한다고하더라도, 그 기능은 더 작은 시스템에서 많은 사용을 볼 수 없기 때문에, 그것을 잘 테스트하는 것이 현명 할 것입니다. –

답변

1

EC++ 하위 집합에서 부과 된 많은 제한 사항은 모든 신흥 기능을 지원하지 않는 모든 C++ 컴파일러를 지원하지 않는 경우 (예 : GCC가 버전 3까지 네임 스페이스를 지원하지 않는 경우) .x 및 EC++는 네임 스페이스 지원을 생략 함).이것은 ISO C++ 표준화 이전이었으며 많은 종류의 임베디드 프로젝트에서 모든 종류의 표준화가 중요합니다. 그래서 그 목표는 임베디드 시스템에서 C++의 채택을 촉진하는 것이 었습니다 전에 전에 필요한 표준화가 이루어졌습니다.

그러나 시간이 지 났으며, 이는 크게 부적절합니다. C++의 '값 비싼'요소와 '비 결정적'요소에 대해서는 아직까지 관련이 있지만, 많은 부분이 호환성을 목표로 작성되었습니다.

EC++는 C++의 진정한 하위 집합이며 모든 EC++ 프로그램도 유효한 C++ 프로그램이라는 점에 유의하십시오. 사실 그것은 완전한 언어 정의 라기보다는 누락 된 부분에 의해서만 정의됩니다.

Green Hills, IAR 및 Keil은 모두 EC++ 하위 집합을 적용하기 위해 스위치가있는 컴파일러를 생산하지만 대부분이 이식성의 문제이므로 모든 컴파일러가 ISO C++도 지원하므로 전혀 의미가 없습니다. 대부분의 경우 EC++ 사양의 일부는 완벽하게 기능을 갖춘 컴파일러에서 이러한 기능을 사용하지 않아도되므로 간단하게 지정할 수 있습니다.

ISO C++이나 EC++가 아닌 제한된 시스템을위한 C++ 컴파일러가 있습니다. 이전 답변 미안하지만, 믿을 수 없을 정도로 여전히 관련

2

MI를 지원하지 않으면 C++이 아닙니다.

+1

사실,하지만 여전히 실제 * 하위 집합 * 일 수 있으므로 이러한 언어의 코드도 C++로 유효합니다. 그것이 바로 EC++입니다. – Clifford

4

"임베디드 C++"을 말하는 경우 아직 출시 된 상용 구현에 대해서는 알지 못합니다. 솔직히 프로젝트의 목표를 살펴보면 바버 (Barber) 씨가 지적한 것처럼 실제로는 C++로 간주 될 수없는 C++의 패배 일뿐입니다.

그들의 의도는 잘 배치되어 있지만 내 생각에는 잘못된 것입니다. 그들의 주요 동인은 C 프로그래머가 더 쉽게 사용할 수 있도록하고 부 풀기를 제거하는 것입니다. 나는 그 점을 보지 못했다. C 프로그래머는 누락 된 기능을 어쨌든 사용하지 않을 것입니다. "Embedded C++"컴파일러는 동일한 코드를 사용하는 C++ 컴파일러보다 작거나 엄격한 코드를 생성하지 않습니다.

+0

좋은 시도와 나는 그 논쟁에 익숙하다. – Nathan

0

나는, 개발 목적, 자신의 C++ 컴파일러를 제공 현재 임베디드 플랫폼 (나는 GCC 또는 MSVC를 사용할 수 없습니다 예) 다중 상속

없음을 지원하지 않는이 있는지 알고 싶어요 내가 알고 있는게 아니야. MI가 좋지 않다고 생각한 임베디드 플랫폼은 일반적으로 OOP의 오버 헤드가 일반적으로 나쁘다고 생각하고 과거의 C를 제공하지 않을 것이라고 생각합니다.

0

본 적이 없습니다. 예외, 스트림, 템플릿을 생략 한 C++ 컴파일러가 N 이상으로 중첩되어 있지만 다중 상속을 제거하지 않은 템플릿도 보았습니다. 나는 다중 상속이 특정 공간이나 속도 문제가 될지, 아니면 적어도 가상 기능보다 일반적으로 더 많이 볼 수 없다.

0

2014 릴리스로 :

애플 OS X, XNU 커널 컴파일러 커널 수준의 I/O 키트 드라이버 (libkern)는 다중 상속을 지원하지 않습니다. 맥 개발자 라이브러리에서


:

의 I/O 키트는 C++ 사용하기에 적합로드 가능한 커널 모듈에서의 부분 집합에 기록 된 libkern의 C++ 라이브러리의 상단에 내장되어 있습니다. 특히, libkern C++ 환경은 다중 상속, 템플릿, C++ 예외 처리 기능 및 런타임 유형 정보 (RTTI)를 지원하지 않습니다. C++ RTTI 기능은 커널 확장을로드하는 데 필요한 기능인 이름 별 클래스의 동적 할당을 지원하지 않기 때문에 생략됩니다. RTTI는 또한 예외를 상당 부분 사용합니다. 그러나 libkern C++ 환경은 동적로드를 지원하는 자체 런타임 타이핑 시스템을 정의합니다.

비용과 안정성면에서 예외가 커널에서 금지됩니다. 코드의 크기를 증가시켜 귀중한 커널 메모리를 낭비하고 예측할 수없는 대기 시간을 초래합니다. 또한 I/O Kit 코드는 많은 클라이언트 스레드에 의해 호출 될 수 있기 때문에 예외가 포착되는 것을 보장 할 방법이 없습니다. 모든 커널 확장에서 try, throw 또는 catch 사용은 지원되지 않으며 컴파일 오류가 발생합니다. I/O Kit 드라이버에서 예외를 사용할 수는 없지만 드라이버는 항상 적절한 경우 반환 코드를 확인해야합니다.

애플은 매우, 당신은 libkern 기본 클래스, OSObject 및 OSMetaClass에, 장치 드라이버가 포함, 모든 커널 C++ 코드를 기반으로, 그 클래스

그래서


그래 정한 규칙을 준수 할 것을 권장합니다 실제 시스템의 생산 환경에서는 여전히입니다. 많이는 아니지만 존재합니다. 컴파일러의 포트가 아직 완성되지 않았기 때문에 완성되지 않은 하드웨어를 코딩하는 경우가 더 자주 있습니다.

저수준 프레임 워크를 많이 쓰는 분으로서 나는 올해 C11을 사용하게 될 것으로 기대합니다 ... 결코. 야.

관련 문제