Embedded C: вопросы на собеседованиях

Про идиоматичный С++ код никто не говорил. Идиоматичность это вообще больше из области гуманитариев, у каждого она своя. Речь о том, чтобы код компилировался и работал идентично исходному.

На раст примерно столько же времени нужно будет.

чтобы на расте рисовать времена жизни переменных и всякие там владения… это надо понимать логику программы. а переписать на плюсы можно вообще не разбираясь, и потягивая смузи(как тут любят).

а переписать на плюсы можно вообще не разбираясь, и потягивая смузи(как тут любят).

Это будет чистая ИБД, для такого достаточно extern «C».

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

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

Для этого достаточно repr(C) и unsafe повсюду расставить. Можно без включения головного мозга.

Про идиоматичный С++ код никто не говорил. Идиоматичность это вообще больше из области гуманитариев, у каждого она своя.

Тогда смысла в переписывании нет.

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

Для этого достаточно extern «C» без всякого переписывания.

Тогда смысла в переписывании нет.

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

Для этого достаточно extern «C» без всякого переписывания.

При чём тут extern C? Он только включает C-шную передачу параметров.

Этот код не компилируется:

extern "C" {
    void foo(void *v) {
        int *p = v;
    }
}

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

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

Этот код не компилируется:

Сишные исходники так и остаются в си файлах и все прекрасно компилируется.

На stm8 и stm32 достаточно включить тактирование и сам spi, остальные настройки по дефолту (2 линии, дуплекс передача по фронту) оставить для 80% случаев. Сложность появляется на си с кучей разных подходов и префиксов констант, а ассемблер сам по себе проще, там принято 100 раз подумать прежде чем добавить что-то на кристал.

60 устройств На Kintex 7 дев плате, учитывая больше десяти отдельных напряжений питания, активно используется pmbus (i2c для контроллеров питания). Там кажется если больше 3 устройств на шине ставят специальную микросхему-развязку, что-то типа хаба, которая может переназначить адреса в том числе.

Я и сам люблю bottom-up разработку, но нужно владеть обоими подходами. Элементы ООП и математика есть в любом проекте. Главное не зацикливаться на одном, смотреть широко.

действительно, есть такое ощущение что на ассемблере проще, чем на С

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

Так я и пытаюсь смотреть широко. К недостаткам ООП я добавлю еще:

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

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

3. Наследование классов порождает непредсказуемые последствия в потомках при изменениях в родителе спустя годы развития проекта.

4. Программисты привыкают полагаться на уже написанный другими людьми родительский код и довольно сложно побудить людей дотошно разобраться с кодом, а не делать свою работу «тяп-ляп».

Ну, и зачем такое ООП тащить в проект? В прикладных программах этот рак уже поразил отрасль, но в эмеддовке чистота Си имеет еще силу и смысл.

на ассемблере проще, чем на С

а эффективно на ассемблере? ;-)

довольно сложно побудить людей дотошно разобраться с кодом, а не делать свою работу «тяп-ляп»

Зачем разбираться к примеру с кодом stl или boost? Когда все прекрасно работает? И таких библиотек тысячи.

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

from collections import Counter

a = [.........]
b = [.........]
a_counts, b_counts = Counter(a), Counter(b)
res = [a_key for a_key, b_key in zip(a_counts, b_counts)
       if a_counts[a_key] != b_counts[b_key]]

Решила за 4 минуты

Что это за язык?

питон

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

примером возмутительной косности является ношение штанов на ж…, а не на голове.

«классы» это строгая типизация. а объекты - это сущности с внутренним состоянием (потому что сущности без состояния вообще не сущности), «данные» там скрыты, и всего лишь являются состоянием.

не являются обьекты - «данными» и «способами обработки». для «способов обработки» данными являются сами объекты различных классов.

«классы» это строгая типизация. а объекты - это сущности с внутренним состоянием (потому что сущности без состояния вообще не сущности), «данные» там скрыты, и всего лишь являются состоянием.

Так про то и речь. Вместо того, чтобы иметь открытый алгоритм, применимый к самым разным структурам данных, в ООП структура данных является «скрытым состоянием» и алгоритм намертво к нему привязан.

для «способов обработки» данными являются сами объекты различных классов.

Вот есть Mat::operator*(). Как его применить к другому классу?

ООП структура данных является «скрытым состоянием» и алгоритм намертво к нему привязан.

это строгая типизация во всей красе. тип есть скрытые данные и операции над ним. и это правильно.

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

сущности без состояния вообще не сущности

Про stateless class и immutable objects никогда не слышал? А они даже в java есть (вроде).

Про stateless class и immutable objects никогда не слышал? А они даже в java есть (вроде).

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

то есть без классов нельзя ввести единый формализм

А как же map или reduce в функциональных языках, где классами и не пахнет?

А как же map или reduce в функциональных языках, где классами и не пахнет?

классами много где не пахнет, а пахнет совсем по-другому, и обсуждать это смысла нет.

у константы нет состояния, это инвариант не зависящий вообще ни от чего.

Нет позвольте, кто писал «без классов нельзя ввести единый формализм». А получается, что классов нет, а формализм присутствует.

у константы нет состояния, это инвариант не зависящий вообще ни от чего.

константа формально это экземпляр некоего класса. и применять к ней можно все неизменяющие операции этого класса. состояние у нее есть. состояние констант true и false класса boolean - разное.

А получается, что классов нет, а формализм присутствует.

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

состояние у нее есть. состояние констант true и false класса boolean - разное.

Это значение, а не состояние, и не надо их путать.

А состоя́ние — понятие, обозначающее множество устойчивых значений переменных параметров объекта.

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

Операция std::cout << применима к любому объекту. И где тут формализм строгой типизации?

Прямо заинтриговало

Это значение, а не состояние, и не надо их путать.
А состоя́ние — понятие, обозначающее множество устойчивых значений переменных параметров объекта.

А какое же определения тогда значения?

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

Каким образом изменяется множество устойчивых состояний переменных параметров объекта после совершения над объектом некоторого действия? Разве это множество изменится?

Это значение, а не состояние, и не надо их путать.

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

если написано a=b and c, и a=b and true - это ничем не отличающиеся операции. во всех случаях имеется именованный обьект - c или true, класса boolean, от которого можно взять «значение», соотвествующее его внутреннему состоянию.

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

Не юли. Выше приведено строгое определение понятия «состояния», и согласно ему константа состояния не имеет.

Выше приведено строгое определение понятия «состояния», …

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

вы сами себе противоречите таким образом. stateless обьект это обьект, множество состояний которого пусто. константный обьект - состояние у которого есть, но оно не изменяется.

В начале было так:

Это значение, а не состояние, и не надо их путать.

Потом так:

«значение» - это состояние, видимое наружу, оно может вычисляться или не вычисляться при взятии «значения» от состояния.

Т.е. значение это все-таки состояние, получается? Или значение и «значение» это разные понятия?

Это значение, а не состояние, и не надо их путать.

я этого не писал. :)

«описывает переменные свойства объекта»

У объекто может не быть значений видимых снаружи как и состояний. Например выключатель, он только выполняет команды «включить» и «выключить».

У объекто может не быть значений видимых снаружи как и состояний. Например выключатель, он только выполняет команды «включить» и «выключить».

у выключателя есть состояние - выключен и включен. он не может выключить повторно, если уже выключен.

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

Ребята, не заводитесь …

это строгая типизация во всей красе. тип есть скрытые данные и операции над ним. и это правильно.

Это неправильно. Потому что допустимые операции над типом ограничиваются только теми, которые не меняют тип. Из-за этого нельзя передать экземпляр типа «квадрат» туда где требуется «прямоугольник». Или если есть базовый класс Base и его наследник класс Derived, то нельзя массив элементов Derived передать вместо массива класса Base.

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

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

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

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

класс не назначается. рождается обьект запрашиваемого класса. некая сущность с интерфейсом и непонятным снаружи(в общем случае) состоянием.

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

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

сформулируйте класс как многоугольник и пишите туда любые многоугольнике. все в ваших руках.

сформулируйте класс как многоугольник и пишите туда любые многоугольнике. все в ваших руках.

Угу. Потом для операции искривления придётся формулировать как «плоская фигура», потом как «поверхность»…

А потом для треугольника создавать объект типа «поверхность» с явным указанием плоскости, к которой он принадлежит и описанием, что линии, соединяющие его вершина являются прямыми…

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

строгость типизации в том и заключается, что тип не меняется

А если класс параметризуется типом? Все прекрасно меняется.

А если класс параметризуется типом? Все прекрасно меняется.

Как? Если создан объект с классом «массив целых», то его никак не изменить в «массив вещественных». Надо новый объект создавать.

Указатель привести к типу (double*) и работать с ним. Но я про другое class shape может быть кругом, квадратом, треугольником в зависимости от параметра шаблона.

Указатель привести к типу (double*)

От этого int double’ом не станет.

Ну и раньше по тексту:

Операция std::cout << применима к любому объекту.

Просто вопиющая дезинформация. И наверное нужно говорить о применимости операций к типам, а не объектам.