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

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

Прежде чем писать херню подумай, а стоит ли.

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

Прежде чем писать херню подумай, а стоит ли.

Такие вопросы и задачи могут быть на собесе? Сколько времени дают?

Я тут сейчас просто ради прикола взял и написал работу со списком. А вдруг? Там всякие проверки параметров сделал, коды ошибок, etc. Даж на горло собственной песне наступил - без любимых goto. Заняло 3 сигареты и 100гр ее родимой, пара часов.

Только elf получился жирный - 20КБайт (main на C++, остальное C). Ну да это надо повыкидывать лишнее из линковки.

Просто даю на листочке код где обявлен массив из 10-ти элементов и присваивание значения элементу по индексу 10.

в каком языке?

Ну и 2+2*2 того же порядка.

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

Опять же, ответ на оба твои вопроса получается в REPL-е моментально

в хороших языках не было бы UB

TFW согласен с обоими высказываниями

С, оно слишком убогое.

плюсы – переусложнены, и слишом раздуты

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

а что, какие-то проблемы Си плюсам удалось решить нормально?

«классы» это строгая типизация

только не в C++/Java/etc

«данные» там скрыты

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

плохо сделали, короче

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

у меня с головой, к счастью, все нормально, поэтому не работал в компаниях с хоть каким намёком на «гостайну»

плохо сделали, короче.

а никто не мешает работать и «отдельно».

напиши

class Data{
  int _x;
  int _y;
};

///методы работы с data
class Methods1: public Data{
  void f1(){...}
  void ff1() {...}
}

///другие методы работы с data
class Methods2: public Data{
  void f2(){...}
  void ff2() {...}
}

вот тебе данные отдельно, разные группы методов - отдельно.

а что, какие-то проблемы Си плюсам удалось решить нормально?

Ну, строки, например. Хотя к сишным «строкам» довольно быстро привыкаешь и все эти strncmp уже не кажутся дичью какой-то, а без родного printf вообще нигде жизни нет :)

Не знаю.. неймспейсы

Ну, строки, например.

я бы не назвал это «нормально»

неймспейсы

жалкая пародия на нормальную модульность (с которой, заметим, классы и не нужны особо)

ООПГМ не лечится, зачем тут вообще классы?

ООПГМ не лечится, зачем тут вообще классы?

не знаю что там у вас не лечится, но классы тут для красоты.

предложите свой, правильный вариант ооп, кто против-то?

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

я бы не назвал это «нормально»

А что не так с плюсовыми строкми?

жалкая пародия на нормальную модульность (с которой, заметим, классы и не нужны особо)

я тоже считаю что классы особо не нужны, даже с той «молульностью» что есть в сях

но классы тут для красоты.

s/для красоты/лишняя сущность/

s/для красоты/лишняя сущность/

я предлагал напрячь читателю моск самостоятельно.

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

предложите свой, правильный вариант ооп, кто против-то?

зачем? он уже есть

привязанные к структуре функции

а нафига их привязывать?

нет видимости

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

нет виртуальности

а она не нужна

про наследование пока не говорим вообще.

а оно не нужно совсем

А что не так с плюсовыми строкми?

мультибайтовость хотя бы

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

Установить атрибут файла «только чтение» и

пусть пишит

Классы, stl, … - интересные темы.
Ныне их не использую.
Спорить ни с кем не буду, но попробуйте подебажить классы и stl и посмотрите какой оверхед …

Ужас!

Ныне разрабатываю свой API для работы с объектами.
Оверхед много меньше, а функциональность постепенно расширяю.

Написать ТГ код, совсем не сложно, а хороший КУДА СЛОЖНЕЙ ...

… попробуйте подебажить классы и stl и посмотрите какой оверхед …

Когда разрабатывается не умело API, который завязан туго на сотню функций, которые зависят друг от друга, то 2 + 2 превращается в тройной интеграл …

Такие вопросы и задачи могут быть на собесе?

Что знает интервьюер, то и будет спрашивать. По односвязным спискам я приводил пример, приводящий к утечкам при удалении элемента и просил объяснить, какие тут будут проблемы. На это времени много не надо.

Кстати, откопал у себя книжку «Искусство программирования на C. Фундаментальные алгоритмы, структуры данных и примеры приложений», Ричард Хезфилд и Лоуренс Кирби. Там и всякие списки есть, очереди, деревья и т.д.

Установить атрибут файла «только чтение»

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

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

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

и вообще это не о файлах. это о раздаче различных «проекций» на некий твой обьект.

ок, давай подробнее опиши бизнес-задачу, а то вдруг мы с Михаилом чего-то недопонимаем

А что не так с плюсовыми строкми?

Ну покажи код, которым ты переворачиваешь строку. Желательно полную программу, которая читает stdin, можно до EOF, можно до конца строки, как удобней, переворачивает прочитанную строку и печатает её в stdout. Чтобы я мог написать echo test | ./a.out.

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

причем тут вообще какой либо «бизнес»?

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

нет там никаких «бизнес-задач»

ну тогда вообще о чём разговаривать, теоретизировать можно о чём угодно, но важны задачи практические

причем тут вообще какой либо «бизнес»?

при деньгах

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

проверки должны проверять, какая разница, какие они? Ну и как бы вон Хаскель есть, максимальные статические проверки, ООПом там не пахнет совсем.

какие понятия должен поддерживать ЯП, дабы писать защищенный софт

для начала иммутабельность по дефолту (и прочие антистрелялки в ногу)

но важны задачи практические

вот ими и занимайся. а мы тут теоретизируем.

тоже в Яндексе работаешь?

Спасибо, скачал, буду освежать знания.

https://rutracker.org/forum/viewtopic.php?t=4845173

Это ты к чему? К тому что мне либо придётся буфер фиксированной размера делать, либо на каждый байт реаллок?

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

Какие ты там буфера будешь делать, мне вообще плевать.

что в плюсах есть поддержка строк

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

потому, что нет единого стандарта представления строк

Есть. Юникод, UTF-8.

клала винда на твой UTF-8. у нее утф-16

Есть. Юникод, UTF-8.

Legioner поэтому программы на Rust всегда будут тормознее программ на С.

alysnix прав. Сам посмотри, вместо одного системного вызова write, будут исполняться 50 строк кода преобразования utf-8 в utf-16 на каждый вывод в консоль.

https://github.com/rust-lang/rust/blob/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/std/src/sys/windows/stdio.rs#L62-L117

И что?

И что?

и фсе.

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

Нету в винде UTF16, есть юникод и UCF-2 кодировка символов, 2 байта на символ (с UNICODE 3.x вроде появились комбинации и из 4 байтов). UTF-8 мультибайтная, для латинских символов это 1 байт, для несложных языков (например русского) 2 байта - префикс и продолжение, китайский иероглиф какой-нибудь может кодироваться 4-7 байтами.

В UTF-8 нет нулевых байтов посреди строки, но сходу определить ее длину в символах сложно, это не количество байтов до /0.

Ты хоть википедию почитай.

UTF-16 is used internally by systems such as Microsoft Windows …

Что такое UCF-2, я не знаю. Наверное ты имел в виду UCS-2. Нет, в Windows она не используется, это давным давно устаревшая кодировка и она в современном софте нигде не используется, т.к. не способна кодировать больше 65000 символов.

Я на юникоде собаку съел.

UCS-2, я ошибся. Вот все wide-char (тип WCHAR) строки и кодируются им в виндовских прогах, это UNICODE.

Вот файлик с содержимым «Привет world!»

UTF-8

00000000 d0 9f d1 80 d0 b8 d0 b2-d0 b5 d1 82 20 77 6f 72 |???????????? wor|
00000010 6c 64 21 0a                                     |ld!?            |

UNICODE

00000000 1f 04 40 04 38 04 32 04-35 04 42 04 20 00 77 00 |??@?8?2?5?B?  w |
00000010 6f 00 72 00 6c 00 64 00-21 00 0a 00             |o r l d ! ?     |

Тут еще какой-то странный BOM (Byte Order Mark, 1F 04) влепил kwrite для обозначения Little-Endian 16. Notepad лепит FE FF.

«😀» вот этот символ закодируй и увидишь, что один символ кодируется несколькими UTF-16 знакоместами.

То бишь UTF-16 это ровно тот же UTF-8 в плане сложности работы с ним. Разница только в том, что UTF-8 не жрёт лишнего места для типовых ASCII-строк.

00000000 ff fe 3d d8 00 de 0a 00

Как я и говорил, в Unicode после версии 3 появились 4-байтовые комбинации. Этот символ кодируется [0xd83d,0xde00] в Unicode.

Загляните в энциклопедию молодых сурков msdn.com, и там никакой ереси про UTF-16 не найдете, всюду упоминается только Unicode-строки. Может UTF16 где-то глубоко internally и присутствует.

Ну кстати, сохранил как UTF-16 и получились те же байты. Так что это вы так наш Unicode называете ))). И это только с версии 3.0, см. unicode.org

никакой ереси про UTF-16 не найдете, всюду упоминается только Unicode-строки.

https://docs.microsoft.com/en-us/cpp/text/support-for-unicode?view=msvc-160

A wide character is a 2-byte multilingual character code. Tens of thousands of characters, comprising almost all characters used in modern computing worldwide, including technical symbols and special publishing characters, can be represented according to the Unicode specification as a single wide character encoded by using UTF-16. Characters that cannot be represented in just one wide character can be represented in a Unicode pair by using the Unicode surrogate pair feature. Because almost every character in common use is represented in UTF-16 in a single 16-bit wide character, using wide characters simplifies programming with international character sets. Wide characters encoded using UTF-16LE (for little-endian) are the native character format for Windows.

Ну и что? WCHAR-ы кодируются UTF-16LE. А Unicode строки состоят из WCHAR и если не хватает «can be represented in a Unicode pair by using the Unicode surrogate pair feature». Те самые 4 байта, 0xDE00 никакого символа не кодирует вне Unicode строки, это костыль, префикс, как костыли в UTF-8. В Windows используются Unicode строки, а не отдельные UTF-16 WCHAR-ы. Большинству эти смайлы по барабану, в API куча функций с Unicode в названии, и в их реализации наверняка наплевали на все эти 4-байтные извраты.

Так кто-нибудь покажет класс на C с разворотом utf-8 строки? ;) Только без if(*s>=0x80) то ждем 2 байта. В utf-8 смайл кодируется 4-мя.

00000000 20 f0 9f 98 80 0a

Так кто-нибудь покажет класс на C с разворотом utf-8 строки? … В utf-8 смайл кодируется 4-мя.

тебе и смайл развернуть надо?

Это угроза? =(

пока только вопрос… угрозы будут потом