AVR на Си++

[Ярослав555]

Аlex писал(а):

Таблицы создаются указателей на методы, а не самих методов

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

[mazda]

ARV, при всём уважении, но вы написали дикую сушённую херь.

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

Гибкость ооп вообще не в том что вы изменяете код на лету, это не java или дрогой байт код.

И при чём тут виртуальная таблица? Ну не создавайте вы виртуальные методы и её не будет, и да она всегда в оперативке на авр, а адреса объектов никогда не могут быть константами и параметрами шаблонов, по крайней мере до с++11, дальше не пробовал.

Не понимаю ваше удивления о том что оказывается объекты распологаются в озу? А где же ещё? Допускаю что вы путаете сами методы и поля данных, это так?


Если что, поправляйте, я сам не мастер по плюсам, и не программист.



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

[ARV]

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

самая большая проблема в том, что для встраиваемых систем на "слабой аппаратуре" вроде AVR категорически нельзя применять подходы, дающие хороший результат на "больших ПК". например, на большом ПК при нехватке памяти можно выдать сообщение пользователю завершить лишние процессы или даже аварийно завершиться... но что делать в системе, где даже средств вывода сообщений может быть не предусмотрено? в таких системах принципиально не должно возникать ситуации, когда чего-то не хватает. соответственно, приходится принципиально не использовать решения, постоянно в чем-то нуждающиеся - в памяти ли, во времени ли, в неожиданном вводе-выводе ли...

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

так что фрагментация кучи - не первая в списке проблема.

P.S. я в курсе, что случаи бывают разные.

[mazda]

ARV писал(а):

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

посмотрите выше, я там расписал конкретный пример где это допустимо. Никто и не применяет подходы с ПК к МК, тем более к авр8, иначе этой темы не было бы, потому что vector или list или любой подходящий контейнер объектов подошёл бы.

[Ярослав555]

mazda писал(а):

Гибкость ооп вообще не в том что вы изменяете код на лету, это не java или дрогой байт код.

Ненене. Лично я под гибкостью имел возможность для программиста быстро адаптировать код под ту или иную ситуацию. Не гибкость скомпилированного кода, а собственно текста программы, его прозрачность для понимания другим человеком. Я предположу, что большинство здесь присутствующих (на форуме) не являются профессиональными программистами. В том смысле, что Вы не работали в команде, Вы не знаете (собственно как и я) что текст программы пишется по неким правилам - есть правила как писать дефайн, как правильно пишутся имена переменных, функций, классов, экземпляров классов, переменных классов... Лично я читал статью на хабре, не скажу что всё запомнил(надо бы перечитать), но многое в стиле изменилось. Вот Git недавно установил, приучаюсь пользоваться. Без знания системы контроля версий ни в одной команде не поработаешь.

[mazda]

Ярослав555 писал(а):

mazda писал(а):

Гибкость ооп вообще не в том что вы изменяете код на лету, это не java или дрогой байт код.

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

так я то же это и имел ввиду, то что вы вывели на цитату было ответом для ARV который удивлялся что объекты в озу располагаются

[ARV]

для ARV который удивлялся что объекты в озу располагаются

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

[mazda]

я вас научу работать

[Jack_A]

я вас научу работать

..., вы все у меня умоотводы напялите !
viewtopic.php?f=57&t=149935
Похоже, форуму срочно требуется админ с дипломом психиатра.
ARV, у Вас же такового нет? "Не навреди!" - любил говаривать старик Гиппократ.

Последний раз редактировалось Jack_A Вт ноя 21, 2017 17:45:44, всего редактировалось 2 раз(а).

[mazda]

Jack_A писал(а):

я вас научу работать

это регулярно звучащая фраза нашего директора

[Siarzhuk]

mazda писал(а):

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

Дело в том, что "другие" находятся в порочном плену у типовых паттернов, и уже смирились с тем, что для организации простейшего списка придётся расплачиваться оперативкой в количестве sizeof(T*) на экземпляр объекта. А для разнородных объектов ещё и +sizeof(VMT*) в лучшем случае. И весь комфорт с new по умолчанию полагается на динамическую память [если никто не рассказал про placement new]. Поэтому ваше утверждение что удалось обойтись без первого, второго и третьего и вызвало фуррор в определённых кругах и ожидание [несбывшегося впрочем] раскрытия деталей такой реализации. В общем случае 1) информация об объекте должна где-то храниться; 2) информация о следующем объекте в списке должна иметься в наличии - либо явно [в указателе], либо косвенно [размер данного объекта в пуле]. Как только сумма затрат на это сравнивается с sizeof(T*) [+sizeof(VMT*)] время потраченное на доморощенную упаковку можно считать потраченным впустую.

mazda писал(а):

не много про количество параметров привода, 70 с хвостиком это не много, посмотрите сколько у частотников на шпиндели, за сотню бывает.

Вопрос не о количестве свойств объекта, вопрос о количестве параметров шаблона по которому строится объект. Свойства инициализируются при конструировании и модифицируются методами во время исполнения. Параметры шаблона определяют объект во время компиляции. И если от 70 параметров шаблона типа int& ни структура данных объекта, ни методы с ней работающие не меняются - с таким-же успехом эти ссылки могли отправиться в список параметров функции-конструктора. Если-же это попытка избежать затрат на разыменование this и затрат на передачу параметров в функции прямым обращением к глобальным данным - почему-бы и нет? Правда одна из основных черепах на которых стоит слон ООП - инкапсуляция, в этом случае будет смертельно обижена на такое ваше "Си с темплейтами".

Добавлено after 1 minute 6 seconds:

mazda писал(а):

это регулярно звучащая фраза нашего директора

А вторая по популярности фраза часом не "А зачем вам столько денег?"

[mazda]

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

со спискос вы ошиблись, на создание односвязного списка уйдёт память на объекты и на адреса, а при односвязных списках разных классов - размер объекта + размер адреса ( 2 байта) + размер адреса функции позволяющей обратиться правильным образом к объекту класса для которой эта функция предназначена( 2 байта озу и чуток флэш), она же статический метод класса, принимает int16 и представляя его как указатель на объект своего класса вызывает интрфейсный метод, если нужно то с параметрами, например с номером обращения

new - у меня компилятор не знает что это, он знает это ключевое слово, но его ОБЯЗАТЕЛЬНО НУЖНО ПИСАТЬ САМОМУ, компилятор GCC4... для АВР new не знает, как и placement new

следующая фраза "ну как так то"