Как можете да правите C++, когато вашият вграден компилатор няма оператор new или STL поддръжка?

Само за протокола, нулирането на битовете в обект няма да повлияе на това дали деструкторът ще бъде извикан (освен ако компилаторът няма специална странност, която позволява това поведение). Просто напишете някои оператори за регистриране във вашия деструктор, за да тествате това.

Структурирането на вашата програма да не разпределя нищо вероятно е начинът, по който е проектирана системата. Не съм работил с вградени системи преди, но прочетох някои опитни магазини за вградени системи, които обезсърчават използването на динамична памет, тъй като средата за изпълнение има оскъдни количества от нея.

Въпреки това, ако трябва, можете да използвате ново разположение. Ако нямате заглавката <new>, ето съответните редове директно от нея в моята версия на GCC:

// Default placement versions of operator new.
inline void* operator new(std::size_t, void* __p) throw() { return __p; }
inline void* operator new[](std::size_t, void* __p) throw() { return __p; }

// Default placement versions of operator delete.
inline void  operator delete  (void*, void*) throw() { }
inline void  operator delete[](void*, void*) throw() { }

Залепете това някъде в заглавен файл, включен във всеки изходен файл, който използва разположение new/delete.

Примерен файл, който тества това:

#include <cstdio>
#include <new>

int
main(int argc, char** argv)
{
    typedef char const* cstr;
    char foobar[16];
    cstr* str = new (&foobar) cstr(argc > 1 ? argv[1] : "Hello, world!");
    std::puts(*str);
    str->~cstr();
}

В моята версия на GCC това изобщо не използва libstdc++ (ако се използва -fno-exceptions).

Сега, ако искате да комбинирате това с malloc (ако вашата платформа предоставя това), тогава можете да направите следното:

#include <cstdio>
#include <cstdlib>

inline void* operator new  (std::size_t n) {return std::malloc(n);}
inline void* operator new[](std::size_t n) {return std::malloc(n);}
inline void  operator delete  (void* p) {std::free(p);}
inline void  operator delete[](void* p) {std::free(p);}

int
main(int argc, char** argv)
{
    typedef char const* cstr;
    cstr* str = new cstr(argc > 1 ? argv[1] : "Hello, world!");
    std::puts(*str);
    delete str;
}

Това ви позволява да използвате стандарта new/delete, с който сте запознати, без да се налага използването на libstdc++.

Късмет!

Не се борете с инструментите си. Ако единственият компилатор, който имате за вашата вградена система, е C компилатор, научете C - не е трудно. Опитът да се създаде някаква копеле версия на двата езика, само за да се реши доста прост програмен проблем, ще завърши само със сълзи.

Погледнато по друг начин, ако вашата вградена платформа дори не поддържа C компилатор, а само асемблер, първият ви импулс ще бъде ли да седнете и да напишете C++ компилатор на асемблер? Надявам се, че не, надявам се вместо това да седнете и да се научите да използвате асемблера, за да завършите задачата си - писането на C++ компилатор (или дори C компилатор) би било напълно неподходящо използване на вашето време и почти сигурно би довело до провал.

Мисля, че подхождате към проблема от гледна точка, която не е оптимална.

Фокусирате се върху компилатора (или липсата на такъв), вместо да се фокусирате върху ХАРДУЕРА.

Най-вероятният отговор на основните ви въпроси е "защото хардуерът не поддържа всички тези C++ неща". Вграденият хардуер (микроконтролери) се отличава с персонализирането на хардуерния дизайн - карти на паметта, манипулатори на прекъсвания, I/O и др.

Според мен ПЪРВО трябва да прекарате известно време с книгата за хардуера за микроконтролера, като научите тънкостите на устройството - т.е. как е проектирано и за каква основна цел. Някои са предназначени за бързо манипулиране на паметта, някои за бързо I/O управление, някои за A/D тип работа, някои за обработка на сигнали. Типът микроконтролер диктува инструкциите за асемблер, които те са написали за него, и това диктува какво всеки компилатор от по-високо ниво може да прави ефективно.

Ако това е важно, отделете малко време, за да разгледате и асемблера - той ще ви каже какво са сметнали дизайнерите за важно. Освен това ще ви каже много за това колко можете да получите от компилатор на високо ниво.

Като цяло микроконтролерите не поддържат C++, защото дизайнът наистина не се интересува от обекти или фантастична работа с памет (от гледна точка на C++). Може да се направи, но често се опитвате да забиете кръгло колче в квадратна дупка, за да накарате конструкторите и деструкторите (и „нови“ и „изтриване“) да работят в микросредата.

АКО имате C компилатор за това устройство, считайте го за благословия. Един добър C компилатор често е "повече от достатъчен" за създаване на отличен вграден софтуер.

наздраве,

-Ричард

Това, че няма тези инструменти, не означава, че не можете да се възползвате от C++. Ако проектът е достатъчно голям, само достъпът до обектно-ориентиран дизайн може да бъде достатъчна мотивация.

Ако не поддържа „ново“, тогава вероятно е, защото няма смисъл да се прави автоматично разграничение между купчина и стек. Това може да се дължи на конфигурацията на вашата памет. Може да се дължи и на това, че ресурсите на паметта са толкова ограничени, че само много внимателно разпределение има смисъл. Ако абсолютно трябва да внедрите свой собствен „нов“ оператор, може да помислите за адаптиране на Doug Lea's malloc. Вярвам, че той е започнал своя разпределител при подобни обстоятелства (преимплементира новото на C++).

Обичам STL, но все още е възможно да правя полезни неща без него. В зависимост от обхвата на проекта може да е по-добре да използвате просто масив.

Имах подобен компилатор, който имплементира странна версия на стандарта Embedded-C++. Имахме operator new, който извикваше конструктори вместо нас, а деструкторите се извикваха в повечето случаи. Доставчикът на компилатора/времето за изпълнение отиде и имплементира try и catch, използвайки setjmp и longjmp като удобство за инженера. Проблемът беше, че те никога не споменаха, че throw няма да доведе до извикване на деструктори на локални обекти!

Както и да е, нашата група наследи кодовата база, след като някой написа приложение, действащо като стандартен C++: използвайки RAII техники и всички останали добрини. В крайна сметка го пренаписахме на това, което някои от нас наричат ​​обектно-ориентирано C вместо това. Може да искате да обмислите просто да ухапете куршума и да пишете на прав C. Вместо конструктори, имайте изрично извикан метод за инициализация. Деструкторите стават изрично наречен метод за прекратяване. Няма много C++, който да не можете да имитирате в C доста бързо. Да, MI е болка в ... но единичното наследяване е доста лесно. Разгледайте този PDF за някои идеи. Това почти описва подхода, който възприехме. Наистина ми се иска да бях записал нашия метод някъде...

Може да намерите полезен код на моя уебсайт с уроци за A*. Въпреки че кодът, който написах, за да поддържа това, използва STL в трябва да бъде лесно премахване на STL поддръжката. В допълнение към него е включен разпределител на пула (fsa.h), който написах за ускоряване на STL на игрови конзоли. Това е C++ код, но го пренесох първоначално от C и не мисля, че би било трудно да го направя по друг начин. Кодът е тестван от над 10 000 души, така че е добра база за започване.

Замяната на STL структурите, които използвам, не е проблем, тъй като е ограничена до вектори. Използвам един от векторите като приоритетна опашка, използвайки функциите на купчина (make_heap и push_heap). Можете да го замените с моя стар C код, който има приоритетна опашка имплементиран в C, който трябва просто да влезе във вашия код. (Което прави само едно разпределение, така че можете да го замените с указател към запазена област от вашата памет.

Както можете да видите в този кодов фрагмент от заглавката, основната разлика в C кода е, че няма този указател, няма обект, така че вашият код обикновено приема указател на обект като първи аргумент.

void PQueueInitialise( PQUEUE *pq, int32 MaxElements, uint32 MaxRating, bool32 bIsAscending );
void PQueueFree( PQUEUE *pq );
int8 PQueuePush( PQUEUE *pq, void *item,  uint32 (*PGetRating) ( void * ) );
int32 PQueueIsFull( PQUEUE *pq );
int32 PQueueIsEmpty( PQUEUE *pq );
void *PQueuePop( PQUEUE *pq, uint32 (*PGetRating) ( void * ) );

Защо не го напишете първо на вашия настолен компютър, като вземете предвид ограниченията на компилатора, да го дебъгвате, да се уверите, че работи перфектно и едва след това да преминете към вградената среда?

когато извършвах вградена работа, веднъж дори не можах да свържа C runtime за ограничения на паметта, но хардуерът имаше инструкция за DMA (динамично разпределение на паметта), така че написах собствен malloc с този хардуер, вашият хардуер вероятно има подобна функция, така че можете да напишете malloc и след това нов въз основа на malloc.

Както и да е, в крайна сметка използвах 99% разпределение на стека и няколко ограничения задават статични обекти, които бих рециклирал, като изграждам на място. Това може да е добро решение за мен.