Си++: быть или не быть

Pingvin

Netzschlange писал(а):

Использование "плюсов" для маленьких МК типа ATmega328, STM32, имеются в виду с оперативой 2-8 кБ и flash 8-64 кБ, просто избыточно. А с компилятором GCC и AVR-ми ещё и словите проблем, если будете пользоваться виртуальными функциями. Не знаю как с STM32 дела обстоят, но в AVR-ках таблица виртуальных функций за каким-то хреном копируется в оперативу, что на заре освоения этих МК мне доставило не мало проблем.

Да конечно, за AVR-ки никто не говорит, но слава Богу - я от них ушёл на ARM.
У меня 64 Кило оперативки и 512 Кило флеша - есть где развернуться.
Во всяком случае мне 64 КБ пока хватило на все задумки.
Будет мало (я же ещё виртуальную машинку планирую запихать для работы с байт кодом) - поставлю камень с 96 Кб оперативки и 796 Кб флеша, печатку при этом менять не надо.

Что касается дефрагментации кучи...
Я её не боюсь.
Дефрагментация получается если дергать разные по размеру куски, у меня же кусочки одинаковые.
А тем более сейчас у меня память выделяется только при создании экземпляров класса (до запуcка main()), а при работе прошивки нет обращений для выделения/удаления блоков из кучи.

Pingvin

Netzschlange писал(а):

Pingvin, а как Вы исправили ошибку?

Поскольку у меня не должно быть в векторе пакетов с одинаковым ID, то не стал заморачиваться, просто добавил return после удаления элемента

Код:

void remove_waiting_package(PackageId packageID){
   for (auto it = m_waitingPackages.begin(); it != m_waitingPackages.end(); it++)
      {
         if ((*it).package.details.packageId == packageID){
            m_waitingPackages.erase(it);
            return;
         }
   }

}

Pingvin

При всей критике крестов чувствуется, что интерес к теме есть... ;-)

Pingvin

О плюсах динамического выделения памяти...
Представьте, что Вам нужно работать с думя очень большими структурами (классами - что в С++ одно и то же, по сути).
Причем они не нужны Вам одновременно.
Вы хотите работать с ними поочерёдно.
У Вас, к примеру - 32 Кб оперативки, а для каждой структуры нужно 30 Кб минимум.
Как Вы решите такую задачу статическим выделением?
Да никак!
Только брать камень "пожирнее".
А динамическое выделение прекрасно справится.
Создал одну структуру, поработал с ней, затем удалил и создал другую...

Netzschlange

Pingvin писал(а):

При всей критике крестов чувствуется, что интерес к теме есть... ;-)

Критика-то обоснованная. По сути C++ впитал в себя большую часть проблем C (как наследник) и добавил ещё своих.
Взять те же итераторы (cheblin в общем оказался прав) -- они "оторваны" от коллекции, которую итерируют. Иными словами итераторы живут своей жизнью, а коллекция своей. В итоге легко можно выстрелить себе в ногу и одновременно отстрелить обе.
Учитывая это, а так же избыточность применения C++ в МК, как-то отпадает желание им пользоваться.

Netzschlange

Pingvin писал(а):

У Вас, к примеру - 32 Кб оперативки, а для каждой структуры нужно 30 Кб минимум.
Как Вы решите такую задачу статическим выделением?
Да никак!

Если структура живёт не долго, то можно решить с помощью стека.
А если долго, то в сторону union можно покопать.
В общем, динамически проще, но и статически то же решаемо.

Pingvin

Netzschlange писал(а):

Pingvin писал(а):

При всей критике крестов чувствуется, что интерес к теме есть... ;-)

Критика-то обоснованная. По сути C++ впитал в себя большую часть проблем C (как наследник) и добавил ещё своих.
Взять те же итераторы (cheblin в общем оказался прав) -- они "оторваны" от коллекции, которую итерируют. Иными словами итераторы живут своей жизнью, а коллекция своей. В итоге легко можно выстрелить себе в ногу и одновременно отстрелить обе.
Учитывая это, а так же избыточность применения C++ в МК, как-то отпадает желание им пользоваться.

Тут не соглашусь.
Не вижу никакой избыточности.
Ну у каждого свое мнение, спорить бессмысленно.

Pingvin

Netzschlange писал(а):

Pingvin писал(а):

У Вас, к примеру - 32 Кб оперативки, а для каждой структуры нужно 30 Кб минимум.
Как Вы решите такую задачу статическим выделением?
Да никак!

Если структура живёт не долго, то можно решить с помощью стека.
А если долго, то в сторону union можно покопать.
В общем, динамически проще, но и статически то же решаемо.

Структура может иметь свои методы (функции).
Как их в стек запихать?
Без конструктора - никак.
Не... можно методы сделать статическими, но там начнутся проблемы при обращении к нестатическим полям - к ним попросту нельзя обратиться напрямую (без указателя на экземпляр структуры) из статического метода.

Netzschlange

А зачем их (методы) в стек пихать? Они живут там, где живёт весь код. И живут там всегда (если их слинкуете), не зависимо от того будете вы вообще создавать структуру и как создавать -- динамически или статически.

Pingvin

Netzschlange писал(а):

А зачем их (методы) в стек пихать? Они живут там, где живёт весь код. И живут там всегда (если их слинкуете), не зависимо от того будете вы вообще создавать структуру и как создавать -- динамически или статически.

Как Вы из кода, который живет "где живёт весь код" обратитесь к полю структуры, которую создадите в стеке?
Хочется конкретики, я что то не понимаю...

Pingvin

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

Вторую аналогичную функцию пишем для другой структуры - так?
В принципе - да, не ООП, конечно, но сработать может.
Насколько удобно?
Мне кажется - не очень.

Pingvin

Ну хорошо, пример не удачный.
Другой...
Есть два буфера, которые нам нужны постоянно но заполнение которых происходит в "противофазе", то есть при опустошении одного происходит заполнение другого.
При статическом выделении мы просто отдадим каждому половину доступной памяти, таким образом максимальная емкость будет равна 1/2 от свободной памяти.
При динамическом выделении это величина составит единицу.
То есть буфера как бы в два раза больше получаются каждый.
Память используется более рационально.

Netzschlange

Pingvin писал(а):

Netzschlange писал(а):

А зачем их (методы) в стек пихать? Они живут там, где живёт весь код. И живут там всегда (если их слинкуете), не зависимо от того будете вы вообще создавать структуру и как создавать -- динамически или статически.

Как Вы из кода, который живет "где живёт весь код" обратитесь к полю структуры, которую создадите в стеке?
Хочется конкретики, я что то не понимаю...

Конкретика простая.
Если говорить простым языком (ну очень простым), то все методы из классов и структур при компиляции превращаются в код. Примерно такой же какой получается при компиляции C исходников. При определённом желании код скомпилированный C++ компилятором можно слинковать с Сишным кодом и из Сишных методов вызывать C++-ные методы (но это извращение).
В этом контексте можно выделить два отличия С++ от С: имена методов подвергаются изменениям (Name mangling -- забыл как по-русски) для возможности переопределения функций (хотя в С это тоже иногда делают) и в функции не явно добавляется первым параметром указатель на данные класса или структуры.
Поэтому, если знать как компилятор обозвал метод класса или структуры при компиляции и знать адрес данных структуры и класса в памяти при работе программы, то можно вызвать этот метод для данного класса и это будет выглядеть как вызов метода класса или структуры.

И немного с другой стороны. Когда вы создаёте объект класса или структуры (динамически или статически), то память выделяется только под поля класса или структуры, которые не статические. Память выделяется одним куском и указатель на первый байт и есть указатель, который называется this. А функции и всё остальное храниться в другом месте.

Netzschlange

Pingvin писал(а):

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

Да, это передача через стек недолго живущей структуры. Это удобно потому, что не надо следить за очисткой памяти -- она очистится самостоятельно при завершении работы функций.

Pingvin писал(а):

Ну хорошо, пример не удачный.
Другой...
Есть два буфера, которые нам нужны постоянно но заполнение которых происходит в "противофазе", то есть при опустошении одного происходит заполнение другого.
При статическом выделении мы просто отдадим каждому половину доступной памяти, таким образом максимальная емкость будет равна 1/2 от свободной памяти.

Для этого можно использовать union (как ранее сказал). Одна и та же память будет использоваться либо одной структурой, либо другой. Правда есть проблема -- будет выделена память в соответствии с потребностями структуры наибольшего размера.

Netzschlange

Pingvin писал(а):

Как Вы из кода, который живет "где живёт весь код" обратитесь к полю структуры, которую создадите в стеке?
Хочется конкретики, я что то не понимаю...

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

Pingvin

Netzschlange писал(а):

Pingvin писал(а):

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

Да, это передача через стек недолго живущей структуры. Это удобно потому, что не надо следить за очисткой памяти -- она очистится самостоятельно при завершении работы функций.

Pingvin писал(а):

Ну хорошо, пример не удачный.
Другой...
Есть два буфера, которые нам нужны постоянно но заполнение которых происходит в "противофазе", то есть при опустошении одного происходит заполнение другого.
При статическом выделении мы просто отдадим каждому половину доступной памяти, таким образом максимальная емкость будет равна 1/2 от свободной памяти.

Для этого можно использовать union (как ранее сказал). Одна и та же память будет использоваться либо одной структурой, либо другой. Правда есть проблема -- будет выделена память в соответствии с потребностями структуры наибольшего размера.

Не не!
Не пройдет! :-)
Мы договорились - используем оба буфера одновременно, а в union данные будут затераться, так как union, по сути - два имени для одного блока памяти.
Буферы как бы будут наложены друг на друга.

Netzschlange

И по поводу объектно-ориентированности языка С++. Она (ОО) присутствует только до момента компиляции. На выходе компилятора мы получаем код, который мало чем отличается от Сишного кода.
Правда это не касается LLVM. Но LLVM это уже виртуальная машина на подобии Java или dotNET. С помощью этой виртуалки получается сохранить подобие ОО при работе C++ программы.

Вот и получается, что при использовании C++ получаем то же, что и при использовании C, но с большей вероятностью возникновения головной боли при разработке.

Pingvin

Netzschlange писал(а):

И по поводу объектно-ориентированности языка С++. Она (ОО) присутствует только до момента компиляции. На выходе компилятора мы получаем код, который мало чем отличается от Сишного кода.
Правда это не касается LLVM. Но LLVM это уже виртуальная машина на подобии Java или dotNET. С помощью этой виртуалки получается сохранить подобие ОО при работе C++ программы.

Вот и получается, что при использовании C++ получаем то же, что и при использовании C, но с большей вероятностью возникновения головной боли при разработке.

Нет!
LLVM - это никакая ни виртуальная машина, хоть так и называется.
Я бы сказал, что это специфический язык, особое промежуточное представление кода со своими правилами.
Эти правила позволяют хорошо оптимизировать код.
То есть пишем на любом языке, затем транслируем в LLVM представление, тут уже происходит оптимизация и компиляция.
То есть не нужно писать оптимизацию под каждый язык.
Ничего общего с Java и .NET
С Си вроде CLang транслирует в LLVM.

Netzschlange

Pingvin писал(а):

Создал одну структуру, поработал с ней, затем удалил и создал другую...

Pingvin писал(а):

Мы договорились - используем оба буфера одновременно

Как-нибудь определитесь.

Pingvin

Netzschlange писал(а):

Pingvin писал(а):

Создал одну структуру, поработал с ней, затем удалил и создал другую...

Pingvin писал(а):

Мы договорились - используем оба буфера одновременно

Как-нибудь определитесь.

Это же разные примеры!
Я сказал, что первый пример неудачный и привел второй.
Не мухлюем! ;-)

sdv_cyborg

Pingvin писал(а):

Не не!
Не пройдет! :-)
Мы договорились - используем оба буфера одновременно, а в union данные будут затераться, так как union, по сути - два имени для одного блока памяти.
Буферы как бы будут наложены друг на друга.

Начать надо с того, какие требование в плане риалтайма.
Если этими двумя буферами, настолько большими, что с трудом влезают в ОЗУ, оперируют какие-то низкоуровневые процедуры, критичные к времени исполнения и привязанные к жестко заданным интервалам времени - то, возможно, лучше взять камень пожирнее. Либо оптимизировать процедуры, чтобы им не нужен был такой большой буфер. Потому что в риалтайме может оказаться так, что обе эти процедуры вдруг заходят работать "внахлест" (одна в фоновом цикле, другая - в прерывании) - не херить же одной из них буфер в процессе работы методами динамического выделения памяти. Это все особенно актуально для разного рода DSP-систем.

Ну а ежели мы плевать хотели на риалтайм, у нас все событийно-ориентированное и вообще никому ничего не обязанное - так тут действительно все-равно, есть буфер или нет прямо сейчас. Но при таком раскладе уже можно брать не МК, а какой-нить одноплатник - риалтайма-то все-равно нет, зато памяти - хоть обвыделяйся.

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

Netzschlange

Pingvin писал(а):

Это же разные примеры!
Я сказал, что первый пример неудачный и привел второй.
Не мухлюем! ;-)

Проблема в том, что Вы пытаетесь доказать обоснованность применения динамического выделения памяти, а так же, что оно может быть лучше статического.
В контексте программирования МК этого Вы сделать не сможете. По той простой причине, что сколько бы Вы примеров не приводили всегда можно найти решение проблемы и без динамического выделения памяти. Вот только для этого нужно понимать конечную цель. Вот это пример:

Pingvin писал(а):

Есть два буфера, которые нам нужны постоянно но заполнение которых происходит в "противофазе", то есть при опустошении одного происходит заполнение другого.

это не конечная цель. Может при анализе конечной цели и не придётся именно так её решать. Но всё же эта задача решается статически ещё проще, чем динамически -- я создам статический массив с размером равным размеру наибольшего буфера из двух и организую доступ к нему через функции, которые будут в "противофазе" данные наполнять и очищать, следя при этом за корректностью работы с массивом. И не нужно здесь ни чего динамического.

cheblin

при приёме пакетов невозможно предугадать скорость их получения, и сответственно требуемый объем памяти для их хранения перед обработкой.

выделение памяти на стеке отлично работает в однопоточных примитивных приложениях.поток получил пакет, обработал полученное, получает дальше...

как только начинаешь задумываться о разделении пакетов между потоками приёма, отправки и обработки... всё. приплыли.
без кучи никак.

Цитата:

всегда можно найти решение проблемы и без динамического выделения памяти

верно, можно.
и это будет называться переизобретением динамического выделения, памяти уже встроенной в С, только на статическую область.... Но зачем?

и кстати если говорить именно о буфере для временногог хранения пакетов лучше использовать примитивный RingBuffer

типа такого проверенного в боях

Код:

#define RBUF_INIT(TYPE, LENPOW2 ) volatile struct { \
   uint32_t wr; \
   uint32_t rd; \
   TYPE data[ 1 << (LENPOW2)]; \
}
#define RBUF_PUT( RBUF, INN)  \
  { if((RBUF).rd == (RBUF).wr ) { \
      (RBUF).wr = 0; \
        (RBUF).rd = 0; \
   } \
       (RBUF).data[ RBUF_MASK(RBUF) & (RBUF).wr++] = INN; }
#define RBUF_MASK(RBUF) ( sizeof((RBUF).data)/sizeof((RBUF).data[0]) -1)
#define RBUF_ISEMPTY(RBUF) ((RBUF).rd == (RBUF).wr)
#define RBUF_ISFULL(RBUF) ((RBUF).rd + RBUF_MASK(RBUF) == (RBUF).wr)
#define RBUF_GET( RBUF)  (RBUF).data[ RBUF_MASK(RBUF) & ((RBUF).rd++)]

Pingvin

cheblin писал(а):

при приёме пакетов невозможно предугадать скорость их получения, и сответственно требуемый объем памяти для их хранения перед обработкой.

выделение памяти на стеке отлично работает в однопоточных примитивных приложениях.поток получил пакет, обработал полученное, получает дальше...

как только начинаешь задумываться о разделении потоков на поток приёма, отправки и обработки... всё. приплыли.
без кучи никак.

Цитата:

всегда можно найти решение проблемы и без динамического выделения памяти

верно, можно.
и это будет называться переизобретением динамического выделения, памяти уже встроенной в С, только на статическую область.... Но зачем?

С языка сняли!
Те же яйки вид сбоку.
Это то же динамическое выделение, по сути, только в качестве кучи - наш массив.
Зачем изобретать велосипед?
Все придумано за нас! :-)

Reflector

cheblin писал(а):

и кстати если говорить именно о буфере для временногог хранения пакетов лучше использовать примитивный RingBuffer

типа такого проверенного в боях

Если упростит и оставить только минимум:

Код:

volatile int buf[16];
volatile int wr = 5;
buf[wr++ & 15] = 55;

То gcc для M4 генерит такое:

Код:

movs r3, #5
str r3, [sp, #4]
ldr r3, [sp, #4] 
add r1, sp, #136
and.w r2, r3, #15 
add.w r2, r1, r2, lsl #2 
adds r3, #1 
movs r1, #55
str r3, [sp, #4] 
str.w r1, [r2, #-64]

Тут запись в буфер выполняется в последней строке, а запись проинкрементированного wr - в предпоследней, т.е. если прерывание произойдет между этими строками, то при обращении к буферу будет казаться, что данные в нем есть, хотя они туда еще не записаны.

Easyelectronics.ru

Си++: быть или не быть

Кто сейчас на конференции