Как можно сделать C++, когда встроенный компилятор не имеет оператора новым или поддержка STL?

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

Чтобы взглянуть на это иначе, если ваша встроенная платформа даже не поддерживает компилятор C, а только ассемблер, будет ли ваш первый импульс сидеть и писать компилятор C ++ на ассемблере? Я надеюсь, что нет, я надеюсь, что вы бы вместо этого сесть и научиться использовать ассемблер для выполнения вашего задания - написание компилятора C ++ (или даже компилятора C) будет совершенно неуместным использованием вашего времени и почти наверняка приведет к неудаче.

I think you are approaching the problem from a viewpoint that is less than optimum.

You are focusing on the compiler (or lack thereof) instead of focusing on the HARDWARE.

The most probable answer to your main questions is "because the hardware doesn't support all that C++ stuff". Embedded hardware (microcontrolers) are noted for the customization of the hardware design - memory maps, interrupt handlers, I/O, etc.

In my opinion, you should FIRST spend some time with the hardware book for the microcontroller, learning the ins and outs of the device - i.e. how it was designed and for what primary purpose. Some were designed for fast memory manipulation, some for fast I/O handling, some for A/D type work, some for signal processing. The type of microcontroller dictates the assembler instructions they wrote for it, and that dictates what any higher-level compiler can do efficiently.

If this is important, spend some time to look at the assembler as well - it will tell you what the designers considered important. It will also tell you a lot about how much you can get from a high-level compiler.

Generally, microcontrollers don't support C++ because the design really doesn't care about objects, or fancy memory handling (from the C++ perspective). It can be done, but you are often trying to pound a round peg in a square hole to get constructors and destructors (and 'new' and 'delete') to work in the micro environment.

IF you have a C compiler for this unit, consider it a blessing. A good C compiler is often "more than enough" to create excellent embedded software.

Cheers,

-Richard

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

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

Мне нравится STL, но все еще возможно делать полезные вещи без него.

У меня был похожий компилятор, который реализовал причудливую версию стандарта Embedded-C ++ . У нас был оператор new , который для нас вызывал бы конструкторы, а деструкторы назывались в большинстве случаев . Поставщик компилятора / среды выполнения выполнил try и catch , используя setjmp и longjmp для удобства инженера ]. Проблема заключалась в том, что они никогда не упоминали, что бросок не вызовет деструкторы локальных объектов!

В любом случае, наша группа унаследовала кодовую базу после того, как кто-то написал приложение, работающее так, как будто это был Стандартный C ++: используя методы RAII и все остальное добро. В итоге мы переписали его так, что многие из нас вместо этого называют объектно-ориентированным C . Возможно, вы захотите просто укусить пулю и написать прямо на C. Вместо конструкторов используйте явно вызванный метод инициализации. Деструкторы становятся явно вызванным методом завершения. В C ++ не так много всего, что вы не можете имитировать в C довольно быстро. Да, МИ - это боль ... но одиночное наследование довольно легко. Взгляните на этот PDF для некоторых идей. Это почти описывает подход, который мы выбрали. Я действительно хотел бы, чтобы я где-то записал наш метод ...

Большая часть C ++, которую вы не можете имитировать в C довольно быстро. Да, МИ - это боль ... но одиночное наследование довольно легко. Взгляните на этот PDF для некоторых идей. Это почти описывает подход, который мы выбрали. Я действительно хотел бы, чтобы я где-то записал наш метод ...

Большая часть C ++, которую вы не можете имитировать в C довольно быстро. Да, МИ - это боль ... но одиночное наследование довольно легко. Взгляните на этот PDF для некоторых идей. Это почти описывает подход, который мы выбрали. Я действительно хотел бы, чтобы я где-то записал наш метод ...

Вы можете найти полезный код на моем A * учебном веб-сайте . Хотя код , который я написал для поддержки этого, использует STL, должно быть легко исключить поддержку STL. Кроме того, в него включен распределитель пулов (fsa.h), который я написал для ускорения STL на игровых приставках. Это код C ++, но я портировал его изначально из C, и я не думаю, что было бы трудно сделать это другим способом. Код протестирован более чем 10000 человек, так что это хорошая база для начала.

Замена структур 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 * ) );

Why not write it first on your desktop computer, taking into consideration the limitations of the compiler, debug it, make sure it works perfectly and only then move to the embedded environment?

когда я выполнял встроенную работу, я однажды не мог даже связать среду выполнения C с ограничениями памяти, но у оборудования было Инструкция DMA (динамическое распределение памяти), поэтому я написал свой собственный malloc с этим оборудованием, ваше оборудование, вероятно, имеет аналогичную функцию, так что вы можете написать malloc, а затем новый, основанный на malloc.

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