4KB의 RAM과 같이 리소스 가 매우 제한된 대상의 경우 순수한 ANSI C 구현으로 쉽게 다시 이식 할 수없는 많은 노력을 기울이기 전에 몇 가지 샘플로 물을 테스트했습니다.

임베디드 C ++ 워킹 그룹은 언어의 표준 하위 집합과 표준 라이브러리의 표준 하위 집합을 제안했습니다. 불행히도 C 사용자의 저널이 죽었을 때 그 노력을 잃어 버렸습니다. 거기에서 기사 것 같습니다 위키 백과 하고 있다고 위원회는 여전히 존재합니다.

임베디드 환경에서는 메모리 할당에주의해야합니다. 이러한 관리를 시행하려면 사용 operator new()되지 않음을 알 수 있도록 연결될 수없는 무언가에 전역 및 그 친구 를 정의해야 할 수 있습니다. new반면에 안정적이고 스레드 안전하며 지연 시간이 보장되는 할당 체계와 함께 신중하게 사용하면 배치 는 친구가 될 수 있습니다.

인라인 함수는 애초에 진정한 함수 여야 할만큼 충분히 크지 않는 한 많은 문제를 일으키지 않습니다. 물론 매크로를 대체하는데도 동일한 문제가있었습니다.

인스턴스화가 제대로 실행되지 않는 한 템플릿도 문제를 일으키지 않을 수 있습니다. 사용하는 템플릿에 대해 생성 된 코드 (링크 맵에 충분한 단서가있을 수 있음)를 감사하여 사용하려는 인스턴스화 만 발생했는지 확인하십시오.

발생할 수있는 또 다른 문제는 디버거와의 호환성입니다. 다른 방법으로 사용 가능한 하드웨어 디버거가 원본 소스 코드와의 상호 작용을 매우 제한적으로 지원하는 것은 드문 일이 아닙니다. 어셈블리에서 효과적으로 디버그해야하는 경우 C ++의 흥미로운 이름 변경으로 인해 작업에 추가 혼란이 추가 될 수 있습니다.

RTTI, 동적 캐스트, 다중 상속, 무거운 다형성 및 예외는 모두 사용에 대해 어느 정도의 런타임 비용과 함께 제공됩니다. 이러한 기능 중 일부는 사용되는 경우 전체 프로그램에 비해 비용이 많이 드는 수준이고 다른 일부는 필요한 클래스의 가중치를 증가시킵니다. 차이점을 알고 최소한 간단한 비용 / 이익 분석에 대한 완전한 지식을 가지고 고급 기능을 현명하게 선택하십시오.

작은 임베디드 환경에서는 실시간 커널에 직접 연결하거나 하드웨어에서 직접 실행합니다. 어느 쪽이든 런타임 시작 코드가 C ++ 특정 시작 작업을 올바르게 처리하는지 확인해야합니다. 이는 올바른 링커 옵션을 사용하는지 확인하는 것만 큼 간단 할 수 있지만 전원 켜기 재설정 진입 점에 대한 소스를 직접 제어하는 ​​것이 일반적이므로 모든 작업을 수행하는지 확인하기 위해 감사해야 할 수도 있습니다. 예를 들어 제가 작업 한 ColdFire 플랫폼에서 개발 도구는 C ++ 이니셜 라이저가 있지만 주석 처리 된 CRT0.S 모듈과 함께 제공되었습니다. 상자에서 바로 사용했다면 생성자가 전혀 실행되지 않은 전역 개체에 의해 미스터리되었을 것입니다.

또한 임베디드 환경에서는 하드웨어 장치를 사용하기 전에 초기화해야하는 경우가 많으며, OS 및 부트 로더가없는 경우이를 수행하는 것이 코드입니다. 전역 개체에 대한 생성자 는를 호출 하기 전에 실행 main()되므로 전역 생성자가 호출 되기 전에 하드웨어 초기화를 완료하려면 로컬 CRT0.S (또는 이에 상응하는 항목)를 수정해야합니다 . 분명히, 정상은 main()너무 늦었습니다.