Как вы можете использовать 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++». Встроенное оборудование (микроконтроллеры) отличается индивидуальной настройкой аппаратного обеспечения — карты памяти, обработчики прерываний, ввод-вывод и т. д.

На мой взгляд, вы должны СНАЧАЛА провести некоторое время с аппаратной книгой для микроконтроллера, изучая все тонкости устройства - то есть, как оно было разработано и для какой основной цели. Некоторые из них были разработаны для быстрой работы с памятью, некоторые для быстрой обработки ввода-вывода, некоторые для аналого-цифрового преобразования, некоторые для обработки сигналов. Тип микроконтроллера диктует инструкции ассемблера, которые они написали для него, и это диктует, что может эффективно делать любой компилятор более высокого уровня.

Если это важно, потратьте некоторое время на то, чтобы посмотреть и на ассемблер — он подскажет, что дизайнеры считали важным. Это также расскажет вам многое о том, как много вы можете получить от компилятора высокого уровня.

Как правило, микроконтроллеры не поддерживают C++, потому что дизайн действительно не заботится об объектах или причудливой обработке памяти (с точки зрения C++). Это можно сделать, но вы часто пытаетесь вбить круглый колышек в квадратное отверстие, чтобы заставить конструкторы и деструкторы (а также «новый» и «удалить») работать в микросреде.

ЕСЛИ у вас есть компилятор C для этого модуля, считайте это благословением. Хорошего компилятора C часто бывает «более чем достаточно» для создания отличного встраиваемого программного обеспечения.

Ваше здоровье,

-Ричард

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

Если он не поддерживает «новый», то, вероятно, это связано с тем, что не имеет смысла проводить автоматическое различие между кучей и стеком. Это может быть из-за вашей конфигурации памяти. Это также может быть связано с тем, что ресурсы памяти настолько ограничены, что имеет смысл только очень осторожное распределение. Если вам абсолютно необходимо реализовать свой собственный «новый» оператор, вы можете рассмотреть возможность адаптации Doug Lea's маллок. Я полагаю, что он начал свой распределитель в аналогичных обстоятельствах (повторно реализовав новый С++).

Я люблю 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 состоит в том, что здесь нет указателя this, нет объекта, поэтому ваш код обычно принимает указатель объекта в качестве первого аргумента.

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 для ограничений памяти, но аппаратное обеспечение имело инструкцию DMA (динамический распределитель памяти), поэтому я написал свой собственный malloc с этим аппаратным обеспечением, ваше оборудование, вероятно, имеет аналогичную функцию, поэтому вы можете написать malloc, а затем новый, основанный на malloc.

В любом случае, в конце концов, я использовал 99% выделений стека, а несколько ограничений устанавливают статические объекты ОС, которые я бы перерабатывал, создавая на месте. Это может быть хорошим решением.