왜 임베디드에서 C++보다 C를 많이 쓸까요?
글쓴이: mjhan / 작성시간: 목, 2005/08/11 - 2:58오후
요즘 임베디드에 관하여 조사하고 있는 학생입니다.
조사를 하다 보니 특히 개발자들이 C++보다 C를 선호하는 경향이 있더구요
조사를 하면서 임베디드에 과연 C의 어떤 점 때문에 선호되는 건지?
그리고 어떤 측면에서 C가 C++보다 좋은건지? 좋다면 이유 때문인지... 등의 의문이 생기더군요
저의 소박한 지식(아직 임베디드 프로그램을 접하지 못하고 단지 일반 어플리케이션이나 파일럿 프로젝트에서의 C와 C++를 접해본 상태)에서는 분석및 설계시 C의 경우 SSAD에 대한 툴이나 자동화 부분이 미약한 반면에 C++은 UML을 이용한 OOAD의 툴이 많이 활성화 된 것 같고
그리고 재사용적인 측면에서도 C++의 장치가 C의 장치를 모두 포함할 수 있는 것 같으며..
생산적인 측면에서도 찾아본 자료에 의하면 LOC/FP의 비용이 C보다 C++가 앞서는 것을 봤습니다.(레퍼런스는 생략했습니다 ㅡㅡ;)
위와 같은 이유에 저의 생각에는 C++가 좋을 것 같은데...
현재 업계나 임베디드를 한 학생들은 C를 더 선호하더군요
물론 언제나 그렇지만 일부 학생들은 그냥 대세이가에 C를 선택한 경우가 있더군요. 하지만 단순히 대세이기 때문이나 예전 부터 해왔기 때문에란 말은 왠지 업계에서 일하시는 분들의 생각은 아니라고 봅니다(제가 업계분과 얘기를 못해봐서 .. ㅡㅡ;;)
저의 궁금점에 대해서 여러분들은 어떻게 생각하시나요?
Forums:
C++보다 C를 지원하는 환경이 더 많아서 그런 것 아닌가요?저도
C++보다 C를 지원하는 환경이 더 많아서 그런 것 아닌가요?
저도 업계 사람은 아니지만요. KLDP에서 줏어들은 바론...
----------------------------
May the F/OSS be with you..
임베디드에서 개발환경은 프로그래머가 결정하는 것이 아닙니다.H/W 가
임베디드에서 개발환경은 프로그래머가 결정하는 것이 아닙니다.
H/W 가 결정 나면 그 안에 들어가는 S/W 들을 C 나 C++ - 물론 가능하다 라는 전제 조건에서 - 로 프로그램을 만드는 것이지요.
프로그래머가 난 C++ 써야 겠으니 H/W 이렇게 만들어라... 라는건 --;
실제로 기초적인 integer 처리도 직접 handle 해야 되는 경우도 있습니다. 닭이 먼저냐 달걀이 먼저냐라는 논의는 여기선 통하지 않는 것 같습니다. ^^;
Too Many Sceret is in your heart.
We must break it and don't forget it.
Until no more secret remains in your soul
옛날에 일하던 회사에서 쓰던 플랫폼은C++ 컴파일러 자체가 없었답니다
옛날에 일하던 회사에서 쓰던 플랫폼은
C++ 컴파일러 자체가 없었답니다.
----
Let's shut up and code.
전에 이런기사를 본적이 있습니다.어떤 업체가 임베디드 시스템에 리
전에 이런기사를 본적이 있습니다.
어떤 업체가 임베디드 시스템에 리눅스를 포팅하여 설치를 하였는데...
C++을 지원을 할수 없다고 하였습니다.
가장큰 이유가..C라이브러리에 비해 C++라이브러리가 방대하다는 것입니다.
그리고 상대적으로 무거워 적합하지 않는다는 것이었죠..
물론 2년전쯤에 본기사이기때문에 요즘은 달라 졌을수도 있지만..
적은 리소스를 가지고 개발해야되는것이 임베디드 시스템이니
무시할수 없다고 생각 됩니다..^^;
아~~
Re: 왜 임베디드에서 C++보다 C를 많이 쓸까요?
UML을 이용한 자동화툴이 얼마나 믿을 만 한지는 모르겠지만 임베디드 환경에 적합한 성질 (실시간성, 최적화등)은 아직 반영하지 못한 걸로 알고 있습니다.
C++가 많은 부분에서 우수하지만, 사실 재사용성에 관련된 부분은 언어 보다는 개발 패턴에 많이 좌우되는 것 같습니다. C로도 재사용성이 높은 코드를 만들 수 있지요.. 그런건 일단 넘어가고요
뭐 그보다 가장 큰 문제는 비용의 문제죠, 하드웨어 비용
동일한 기능을 수행할 수 있다면 최대한 단가를 낮추는 것이 마진의 폭이 가장 크겠죠 아무리 소프트웨어가 많은 비중을 차지한다고 하지만 그래도 결국은 하드웨어 장사 단가 문제가 크겠죠 C++은 아무래도 C보단 느리고 덩치 큰 코드를 생성하고 라이브러리 까지 생각하면 C와는 비교가 되질 않죠 그리고 기존의 임베디드 시스템이 하는 일이 비교적 단순하기 때문에 C를 이용하여 최적화된 시스템을 만드는게 마진면에서 크기 때문에 C를 선호 한 것입니다. (그 이전에는 어셈블러가 대세였고 C로 옮기기 위해서 이런 과정을 거쳤지요)
하지만 최근 들어 핸드폰, PDA등 단가가 비싸, 좋은 컴퓨팅 파워를 가지고 거기에 프로그램도 많이 올라가는 시스템들은 그런 유지보수나 개발의 편의성을 위하여 C++이나 Java등을 사용하고 있습니다.
UML까지 연동해서 하는지는 잘 모르겠지만 아마 시간이 지나고 낮은 비용으로 높은 컴퓨팅 파워를 구현할 수 있고 소프트웨어가 복잡해진다면 바꾸지 말라고 해도 바꿀 겁니다.
:-)
C 도 못쓰는 경우가 있습니다.한때 S모사 CDROM 의 firm
C 도 못쓰는 경우가 있습니다.
한때 S모사 CDROM 의 firmware 가 거의 512KB(256KB인가?) 에 육박하던 시절, L모사 CDROM 은 128KB(64KB인가? 하여튼 4배정도의 차이) 도 안되는 크기를 자랑하는 바람에, S 모사 개발부서가 뒤집어 진 적이 있습니다. 이유를 알고봤더니 L 모사가 어셈블리를 적극적으로 활용했다고 합니다. (물론 S 모사 소스코드에 삽질이 많았지만...) 결국 L 모사 의 개발자를 데려왔다고 합니다.
1MB 도 안되는 것 가지고 뭘 그러냐고 하실 분들도 있고 1KB에 식은 땀이 흐르는 분들도 있고... 임베디드는 그런 거 아닌가요.
민법 제 2 조 제 2 항 - 권리는 남용하지 못한다.
범용 컴퓨터는 디스크를 달아서 쓰기 때문에 라이브러리 크기의 제약이 별로
범용 컴퓨터는 디스크를 달아서 쓰기 때문에 라이브러리 크기의 제약이 별로 없지만 임베디드 시스템에서는 롬이나 플래시 메모리에 모든것을 탑재해야 합니다. 물론 그래야 하는 이유는 단가, 크기, 소모전력 등 여러가지가 있을 수 있겠지만, 대부분의 임베디드 시스템은 디스크가 없습니다.
그래서 임베디드 시스템은 프로그램을 롬 이미지로 만들어서 넣습니다. 요새는 플래시값이 많이 싸져서 리눅스 기반 임베디드 시스템들도 꽤 많지만 아직 임베디드의 대세는 VxWorks같은 RTOS들입니다. (구동 환경의 크기면에서 10배쯤 차이가 나고, 이건 그대로 단가로 직결되므로..)
아, 그리고 컴퓨터와는 달리 임베디드 기기들에는 컴파일러를 탑재할 필요가 없기 때문에 shared library의 설치가 까다롭다는 문제가 있습니다. 복잡한 C++ 링킹을 지원하게끔 C++ 라이브러리를 임베디드 시스템의 롬 이미지에 넣기가 그리 수월하지도 않죠.
아뭏든 임베디드 시스템에 C++을 사용하는 데에는 현실적으로 적지 않은 제약이 있습니다. 임베디드 시스템은 운용환경상 장시간 리셋 없이 동작해야 하는 경우도 많아서, C++처럼 메모리 리크가 쉽게 발생하는 언어는 아무래도 꺼리는 점도 있죠.
you must know the power of dark side.
핸폰 개발할때...
그리 오래전도 아닙니다만...
임베디드중에서 나름대로는 빵빵한 스펙을 자랑한다는 핸드폰...
싸구려폰도 아니고 최신폰이였는데...
개발하다보면 메모리 넘쳐서 메모리맵 조정하고...이미지 크기 줄이고
고정으로 잡힌거 동적으로 잡게 바꾸고...
하여간 몇 kbyte땜시 고생하는 적 많습니다.
mjhan님이 얘기하신 정도의 파워풀한 환경도 있기는 하지만...
극소수라고 보시면 됩니다
There is more than one way to do it...
제일 큰건 일단 C++을 지원 하지 않는 언어가 더 많고.. 이부분은 위
제일 큰건 일단 C++을 지원 하지 않는 언어가 더 많고.. 이부분은 위에서 많은분들이 말씀하셨으니...
둘째론 C와 C++의 개발 속도와 생산성에따른 비용 문제라고 하셨는데
대부분 좀 찍는다하면 1천개 1만개 따위가 아닌 수십만~수천만개씩도 찍어 냅니다 제품을... 거기서는 10원도 안하는 저항이나 콘덴서 등도 상당히 큽니다
한 천만개 찍었다 놓고 10원짜리 저항하나 덜쓰면 1억원 이익이죠...
여기서 위에서 말한 S모사와 L모사 펌웨어로 가보면
그때쯤이면 512kb플래쉬는 상당히 비쌌으리라고 보여집니다만
현재 일단 64kb짜리 플래쉬 소매가가 대략 2천원 선입니다... 128 kb짜리 플래쉬 소매가가 대략 3천4백원이군요...
이정도로 1천만개를 찍어 봅시다 ㅠ_ㅠ
L모사는 20000000000원의 플래쉬 값을 S모사는 34000000000원의 비용이 듭니다 140억 차이가 나는군요 맞나요? 돈잘 못세서.. 14억인가 -_-a 어쨌던 이정도면 개발속도고 생산성에따른 비용이고 뭐고 없이 회사 뒤집어 질만 하겠지요 한 1~2억 들여서 그 개발자 데리고 오고 같은값에 팔아먹으면...
결국엔 돈이네요... 돈..
결국엔 돈이네요... 돈..
작은 크기로 프로그래밍을 해야 돈이 덜드는 임베디드 환경에서는 C++ << C << Assembly 순으로 높은 스킬을 가지고 있는 것이 좋다는 것이군요.
임베디드 ==(비슷) 하드웨어 라고 생각해도 될까요? ^^;;
아는 동생이 있는데... 그냥 장난감(?)만들때, 프로그램으로 안되면 코딩으로 하고 코딩으로 안되면 하드웨어 붙여서 때운다고 하네요. 이 것이 산업적으로 생각해보면.. 당연.. 프로그램 잘 짜는 사람이 좋겠네요.
-------------------------
모든것에 감사합니다.
http://bubicom.winmir.com
Re: 결국엔 돈이네요... 돈..
그렇죠 ....
아직도 4bit 컨트롤러가 나오고
AVR tiny시리즈가 나오고...
아직도 화려한 스폿라이트는 못받더라도 시장의 대세는 8bit 컨트롤러인 이유는 돈때문이죠 ㅡ.ㅡ;;
8bit 2천원짜리로 될껄 만원짜리 같다가 하면 망하죠 -_-;;
요즘 16bit도 많이 싸져서 어느정도는 16bit으로 옮겨가는듯도 싶지만(정말 싸지요... T모사에 M모 시리즈... 1달러대도 존재...) 8bit쓰는데는 대부분 그정도의 컴퓨팅 파워만 요구하기에 그냥 그대로 8bit시장의 아성은 건재 한듯 싶습니다
성능도 뭐 요즘 막나가자는건지 8bit짜리도 100MIPS가까이나오는 칩들도 있으니까요 -_-;; 100mips였나 50mips였나 중얼중얼...
예전에 L모사에서 펌웨어 쪽 일을 한 적이 있었습니다. 그 때는 16/3
예전에 L모사에서 펌웨어 쪽 일을 한 적이 있었습니다. 그 때는 16/32 bit 마이컴을 썼습니다만, 그래도 어셈을 사용했는데요... 제 생각은 이렇습니다.
앞서 여러분께서 지적해 주신 이유도 타당한 것 같고, 그 외에도 임베디드 쪽의 프로그램들 특성이 다른 쪽과 성격이 매우 다르기 때문이 아닐까요. 동작하는 프로그램들이 얼마나 유연하냐 보다는 얼마나 정밀하게, 이상없이 수행되느냐가 더 중요하다고 생각합니다.
핸드폰이나 smart device들 처럼 전용 OS 상의 어플리케이션이라면 OS의 서비스를 이용하면 되기 때문에 SE적으로 생산성이 높은 C++나 Java도 훌륭한 환경일 것입니다. 하지만 펌웨어라든가 하드웨어를 직접 제어하는 소프트웨어의 경우는 그 특성상 C나 어셈이 유리할 수 밖에 없다고 생각합니다. 실시간 처리는 말할 것도 없고, 하드웨어 제어나 인터럽트 처리 수행 시간이 runtime마다 차이가 발생한다거나 unpredictable하다면 매우 곤란할 것입니다. device driver를 oop로 작성하는 사람은 없을테지요.
제가 작업 했던 부분은 각 제어 시퀀스마다 정밀한 제어 시간을 필요로 했기 때문에 C 혹은 어셈으로 super loop 처리할 수 밖에 없었습니다. RTOS가 올라간 상황이었다면 그 서비스들만 사용하면 그럴 필요는 없었겠지만요.
케케케~
저의 경우엔, 임베디드 리눅스에서 C++코드를 써보려고 하다가 라이브러
저의 경우엔, 임베디드 리눅스에서 C++코드를 써보려고 하다가 라이브러리 크기가 너무 커서 포기한 적이 있습니다. C lib도 작은 걸 구해 써야 하는데 C++은 좀...(몇년 전 얘깁니다)
rommance.net