ЕЦ++

Ugrađeni C++ (Embedded C++, EC++) варијација је програмског језика C++ намењена уграђеним системима. Креирала га је индустријска група предвођена великим јапанским произвођачима ЦПУ-а (централних процесорских јединица) која укључује имена попут НЕЦ, Хитачи, Фуџицу и Тошиба. Они су хтели да укажу на недостатке C++ при креирању апликација за уграђене системе. Циљ им је био да сачувају све најкорисније карактеристике објектно-оријентисаног програмирања које поседује C++ а да при томе минимизују величину кода и максимизују ефикасност приликом извршавања као и да учине конструкцију компајлера једноставнијом. На званичном сајту као њихов циљ стоји реченица: “пружити програмерима за уграђене системе подскуп C++-а који просечан C програмер може да разуме и користи”.

Разлике у односу на C++

Уграђени C++ је подскуп C++-а. Следеће карактеристике C++ су уклоњене:

• вишеструко наслеђивање
• виртуелне базне класе
• информације о типу података приликом изврсавања (тyпеид) (тyпеид)
• нови начини кастовања (статиц_цаст, дyнамиц_цаст, реинтерпрет_цаст анд цонст_цаст)
• мутабле стораге цласс специфиер
• простори имена
• обрада изузетака
• шаблони

Неки компајлери (попут Греен Хиллс и ИАР Сyстемс) дозвољавају поновно омогућавање појединих карактеристика из горе наведене листе по жељи, имплементација позната као “продужен уграђен C++”. Такође, многи корисници Ембеддед C++ избегавају стандардну библиотеку шаблона због њење динамичке алокације меморије.

Компилација

Програм написан у ЕЦ++ може бити компајлиран помоћу било ког C++ компајлера. Али, посебан компајлер за ЕЦ++ може лакше да уради оптимизацију.

Компајлери специфицни за ЕЦ++ пружају компаније попут: ИАР Сyстемс Фреесцале Семицондуцтор, (спин-офф фром Моторола ин 2004 wхо хас ацqуиред Метроwеркс ин 1999) Таскинг Софтwаре, парт оф Алтиум Лимитед Греен Хиллс Софтwаре

• ИАР Сyстемс
• Фреесцале Семицондуцтор, (спин-офф фром Моторола ин 2004 wхо хас ацqуиред Метроwеркс ин 1999)
• Таскинг Софтwаре, парт оф Алтиум Лимитед
• Греен Хиллс Софтwаре

Критике

ЕЦ++ је лоше прихваћен од стране експерата за програмирање у C++. На пример, Бјарне Строуструп је рекао: “ Колико ја знам ЕЦ++ је мртав (2004), а ако није, то се мора десити”. Такође, званичан ЕЦ++ на енглеском није апдејтован од 2002. Упркос томе, ограничен подскуп C++ (заснован на ЕЦ++) је усвојен од стране Аппле, Инц.

Историја - П.Ј. Плаугер о ЕЦ++-у

П.Ј. Плаугер је аутор стандардне C++ библиотеке која је укључена у Мицрософт Висуал C++. Његова колумна “Стате оф тхе Арт” се сваког месеца објављује у Ембеддед Сyстемс Программинг.

Јесени 1997. је одржана Конференција о уграђеним системима у Сан Хосеу која је била огроман успех. Посебна пажња на конференцији је била посвећена ЕЦ++. Само годину дана раније, на истој конференцији, имао сам част да представим овај пројекат публици. Цела идеја је лако могла бити заборављена и нестати без трага, као сто се дешава са многим оптимистичним идејама, али десило се бас супротно. За почетак ћу испричати како сам сазнао за овај пројекат те како је он почео.

Историја

Први пут сам чуо за ЕЦ++ пројекат у новембру 1995. на састанку ИСО и АНСИ комитета за стандардизацију C++. Адванцед Дата Цонтролс Цорп. (АДаЦ) је јапанска компанија са којом сам сарађивао од 1982. године. Узимајући у обзир успех наших претходних пословних сарадњи, врло радо сам продужио свој боравак и присуствовао састанку који су организовали тог петка увече. Састанку су поред људи из АдаЦ-а, присуствовали и девелопери из четири велике јапанске компаније: Тосхиба, Фујитсу, Хитацхи и НЕЦ, као и нас неколико из Америке. Представници све четири компаније су имали један заједнички проблем: њихове муштерије – скоро сви девелопери уграђених система који користе њихове чипове – су почели да захтевају C++ компајлере. Наравно, продавци су желели да удовоље жељама својих купаца. Све четири компаније су или већ понудиле неку форму C++ компајлера или су се спремале да то учине. Међутим, када су купци почели да користе C++, велика већина је била веома незадовољна. Они су били навикнути на C, научили су како да се изборе са потешкоћама приликом његовог коришћења у односу на асемблерске језике, а при томе су били како изненађени тако и задивљени новим карактеристикама које су додате C++. Највећи проблем је међутим био што је сваки комерцијани C++ компајлер имплементирао другу колекцију његових карактеристика. То је била последица тога сто се C++ мењао брзо и стално током година. “Стандардизација”, процес који иначе стабилизује програмски језик, почео је 1989. године, али је у случају C++, процес стандардизације коришћен као прилика да се језику додају важне нове карактеристике па писци компајлера нису могли да прате тај темпо. Али, за програмере уграђених система постаје јос горе. Неке од нових карактеристика цине C++ доста захтевнијим за коришћење, јављају се вишкови и у величини кода и у брзини извршавања. У неким случајевима, ти вишкови се јављају чак и ако не користите експлицитно те карактеристике. Продавци су тако наишли на честу софтверску дилему: како да будемо сигурни да је оно сто купци мисле да желе близу онога сто њима заиста треба? Популарно решење у таквим ситуацијама је дефиниција одговарајућег подскупа. У тај подскуп укључити све сто одговара потребама програмера уграђених система. Избацити све сто се може избацити, да ли због тога сто додаје велике и непотребне вишкове или због тога сто је превише ново да би било шире распрострањено. Окупити људе који це се сложити око тога како тај подскуп треба да изгледа. Ако неколико продаваца буде својим купцима пружало на коришћење исти подскуп, корисници ће моћи да пишу C++ код који је и ефикасан и преносив између различитих имплеметација. Тако је створена идеја о ЕЦ++, варијацији програмског језика C++, чија су циљна група програмери уграђених система. Група која се први пут састала тог петка увече у Токиу је себе незванично назвала Ембеддед C++ Тецхницал Цоммиттее. За шефа комитета је изабран Хиросхи Монден из НЕЦ-а а Др. Киицхиро Тамару из Тошибе за потпредседника. Ми, Американци, смо били само саветници комитету који је све будуће састанке одржавао на јапанском. До септембра 1996. године, Ембеддед C++ Тецхницал Цоммиттее је направио скицу спецификација подскупа који су изабрали, а као што сам рекао на почетку, ја сам га први пут представио јавности на конференцији те јесени у Сан Хосеу.

ЕЦ++ као језик

Можда је најбољи начин да опишемо ЕЦ++ као језик тај да наведемо које су све карактеристике из C++ избачене из њега, а да вас уверимо да је подскуп који је остао приликом тог избацивања потпуно функционалан. На пример:

• вишеструко наслеђивање и виртуелне базне класе: додају језику прилично на комплексности а подижу му експресивност на релативно ниском нивоу.
• информације о типу података приликом извршавања (тyпеид)
• обрада грешака: јаки аргументи се могу изнети и за и против ове одлуке, али што се тиче програмера за уграђене системе, они често више воле да искључе овај механизам и користе неки једноставнији начин
• шаблони: довољно дуго сам радио са шаблонима да бих знао да су они заиста моћна ствар и да су често вредни комплексности која се због њих додаје језику. Први комерцијални компајлери који у потпуности подржавају шаблоне тек постају доступни. Коришћење шаблона такође може да доведе до значајних вишкова. Промените тип једног аргумента у једном позиву шаблонске функције и можете несвесно да дуплирате величину кода који се генерише за имплементацију те функције. Колико год да су корисни, вреди избегавати шаблоне у уграђеним системима.
• простори имена: они су додати у C++ пре неколико година са намером да се подели стандардна C++ библиотека како би после могла бити селективно замењена. Међутим, до данас нисам видео дизајн који остварује тај циљ те сматрам да је њихово избацивање из ЕЦ++ паметна одлука
• нови начини кастовања (статиц_цаст, дyнамиц_цаст, реинтерпрет_цаст и цонст_цаст): ово је била тежа одлука. Оператор за кастовање типа је постојао у C-у скоро од његовог настајања 70-их година. Али, многи програмери се слажу око тога да треба да се предефинише. Од ова четири оператора која су додата C++ , за сада само дyнамиц_цаст ствара вишкове при извршавању. Лично сматрам да су нови начини кастовања избачени чисто због тога јер су нови и треба да прође време да се испита њихов утицај на изврсавање програма

Срећом, био сам само саветник на ово пројекту. Дивим се креаторима на храброст приликом доношења неких од јако тешких одлука. Истовремено, не морам да правдам неке контраверзне одлуке.

Садржај ЕЦ++ библиотеке

ЕЦ++ библиотека је подскуп C и C++ библиотека. Ово је кратак опис онога сто се захтева на бази хеадер-бy-хеадер:

• Тхе хеадер <ццтyпе>:

 functions is*, to*

• Тхе хеадер <церрно>:

 macros EDOM, ERANGE, errno 

• Тхе хеадер <цфлоат>:

 macros DBL_*, FLT_*, LDBL_* 

• Тхе хеадер <цлимитс>:

 macros CHAR_BIT, *_MIN, *_MAX 

• Тхе хеадер <цлоцале>

 type lconv; function localeconv 

• Тхе хеадер <цматх>:

 macro HUGE_VAL; functions (overloaded on float, double, and long double) abs, acos, asin, atan, atan2, ceil, 
 cos, cosh, exp, fabs, floor, fmod, frexp, ldexp, log, log10, mod, pow, sin, sinh, sinh, sqrt, tan, tanh

• Тхе хеадер <цсетјмп>:

 type jmp_buf; macro setjmp; function longjmp 

• Тхе хеадер <цстдарг>:

 type va_list; macros va_arg, va_end, va_start 

• Тхе хеадер <цстддеф>:

 macro offsetof; types ptrdiff_t, size_t 

• Тхе хеадер <цстдио>:

 types FILE, fpos_t, size_t; macros EOF, NULL; functions fclose, fflush, fgetc, fgetpos, fopen, fputc, fsetpos, 
 getchar, gets, printf, putchar, puts, scanf, setvbuf, sprintf, sscanf, ungetc, vprintf, vsprintf; objects stdin, stdout 

• Тхе хеадер <цстдлиб>:

 types div_t, ldiv_t; macros MB_CUR_MAX, RAND_MAX; functions abort, abs, atol, atof, atoi, bsearch, calloc, 
 div, free, labs, ldiv, malloc, qsort, rand, realloc, srand, strtod, strtol, strtoul 

• Тхе хеадер <цстринг>:

 type size_t; macro NULL; functions memchr, memcmp, memcpy, memmove, memset, strcat, strchr, strcmp, strcpy, 
 strcspn, strlen, strncat, strncmp, strncpy, strpbrk, strrchr, strspn, strstr, strtok 

• Тхе хеадер <цомплеx>:

 types double_complex, float_complex; functions (overloaded on float_complex and double_complex) abs, arg, 
 conjg, cos, cosh, exp, imag, log, log10, norm, polar, pow, real, sin, sinh, sqrt, tan, tanh 

• Тхе хеадер <фстреам>:

 types filebuf, ifstream, ofstream 

• Тхе хеадер <иоманип>:

 manipulators resetiosflags, setbase, setfill, setiosflags, setprecision, setw 

• Тхе хеадер <иос>:

 types ios, ios_base; manipulators boolalpha, dec, fixed, hex, internal, left, noboolalpha, noshowbase, 
 noshowpoint, noskipws, nouppercase, oct, right, scientific, showbase, showpoint, skipws, uppercase

• Тхе хеадер <иосфwд>:

 forward references to iostreams classes 

• Тхе хеадер <иостреам>:

 objects cin, cout 

• Тхе хеадер <истреам>:

 type istream; manipulators endl, ends, flush 

• Тхе хеадер <неw>:

 types new_handler, nothrow, nothrow_t; functions operator delete, operator delete[], operator new, operator new[], 
 set_new_handler 

• Тхе хеадер <остреам>:

 type ostream; manipulator ws 

• Тхе хеадер <сстреам>:

 types istringstream, ostringstream, stringbuf 

• Тхе хеадер <стреамбуф>:

 types fpos, streambuf, streamoff, streamsize 

• Тхе хеадер <стринг>:

 type string; function getline

Перформансе

Основна премиса која стоји иза дизајна ЕЦ++ је да језик који представља подскуп оног од ког је настао постиЖе боље резултате када су у питању меморија I ефикасност. Вероватно сам много пута рекао да подрЖавам избегавање нових карактеристика у језику, највиШе из разумевања како према програмерима тако и према имплементаторима. То је пролазан проблем који ће бити решен сам од себе у наредних неколико година како C++ Стандард буде постао званичан и стабилан, компајлери буду почели да прате његов напредак и програмери буду научили како да користе те нове карактеристике. Али, проблеми везани за перформансе ће бити важни за уграђене системе и у много даљем периоду. Оно сто ћу сада представити су неки анегдотични резултати за које сматрам да су репрезентативан узорак за приказивање правог стања у програмирању. Они упоређују релативне величине програма пар малих тестова који су компајлирани на различите нацине и повезани са различитим библиотекама.

Те две библиотеке су Динкум C++ I Динкум ЕЦ++ библиотеке. Прва је комплетна имплементација нацрта Стандард C++ библиотеке, а друга је имплементација коју је направила компанија Динкумwаре за Ембеддед C++ библиотеку. Греен Хиллс Софтwаре је водећи продавац на тржишту уграђених система. Они лиценцирају Динкумwаре библиотеке за дистрибуцију са својим компајлерима. Два тест програма су компајлирана својим ПоwерПЦ компајлером. Моје искуство је показало да модерни микропроцесори овако функционишу: време извршавања највише зависи од броја бајтова у коду који процесор мора да прочита. Изузимајући хот спотс, то је пропорционално укупној величини програма. Чак и на мали програм који на једноставан начин користи I/О библиотеку велики утицај имају последице њеног коришћења. Релативне величине таквих програма су:

 3 — EC++, bez izuzetaka
 5 — EC++, sa izuzecima 
 6 — Kompletan C++, bez izuzetaka
 8 — Kompletan C++, sa izuzecima 

Прво приметите значајну уштеду ако компајлер не мора да брине о обради грешака у коду. Затим приметите ста вам пружа коришћење једноставније библиотеке. Избацивањем непотребне машинерије која се не може избећи у комплетној C++ библиотеци, величина ЕЦ++ програма је дупло мање од величине C++ програма. Узимајући у обзир уштеде које пружају и језик и библиотека, видимо да ЕЦ++ програм има велицину као 8/3 C++ програма.

Разлике су јос значајније за неке веће програме који у већој мери користе I/О библиотеку. У том случају је комплетној C++ библиотеци теже да избегне убацивање велике количине додатног кода. Релативне величине кода су следеће: 3 — ЕЦ++, без изузетака 5 — ЕЦ++ са изузецима 30 — Комплетан C++, без изузетака 45 — Комплетан C++ са изузецима

Да, величина ЕЦ++ програма је 15 пута мања од величине C++ програма. Сетите се да сада живимо у свету у ком традиционалан, тривијалан програм који само исписује “хелло, wорлд” може да заузима читав мегабајт на неким десктоп имплементација C++ програма. Уштеђевине на које се најчешће наилази су углавном мање значајне , али пружени докази су довољни да се види разлика. Постоје заиста велике предности сто се тице перформаси приликом програмирања на ЕЦ++ и коришћењем његовим библиотека.

Бјарне Строуструп о ЕЦ++

Шта мислите о језику ЕЦ++? ЕЦ++ је (скоро) подскуп C++ из ког су избачени изузеци, саблони, простори имена, подршка РТТИ, вишеструко наслеђивање, итд., како је дефинисан од стране “индустријског конзорцијума”. Ја нисам заговорник подскупа и дијалеката програмских језика. Посебно не подржавам подскупе који не подржавају стандардну библиотеку што доводи до тога да корисници тог језика морају сами да измисле своје некомпатибилне основне библиотеке. Плашим се да овако дефинисан подскуп језика C++ мозе да подели корисничку заједницу и узрокује горчину: 31.3.1999. - “Управо сам видео рекламу која користи зивописну графику да би приказала како је ЕЦ++ смањио вишкове (на пример величину меморије) укидањем – између осталог – простора имена, шаблона и стандардне C++ стрингове.” Ја сам напротив велики заговорник тога да се рад на “стандардима” обавља на отвореном форуму (попут ИСО или националне организације за стандардизацију).

Колико сам ја упућен, ЕЦ++ је мртав, а ако није, требало би да буде.

Види још

• Поређење слободног ЕДА софтвера

Спољашње везе

• Званични веб-сајт
• Background and Objectives of the Embedded C++ Specification Development
• Embedded C++ Yields Faster Smaller Code
• Building Bare-Metal ARM Systems with GNU: Part 1 - Getting Started
• Technical Report on C++ Performance