> Эйййй, двое из ларца .... :))))))))) загибайтеЕсли их заапгрейдить как следует - нормальненько получается.
> типы, структуры это же формальные понятия,
И это хорошо. Помогает мне помнить что я имел в виду, чем оперирую, помогает другим въехать в код. А еще декларация намерений в том числе и машине (компилеру, анализаторам, ...). Чтобы очевидные грубые несоответствия - отловить на этапе компиляции, а не когда программа сделает волшебный хренакс и (в случае управляюшей фирмвари) что-то $%нет, спасибо если никого не убив. Не хочешь на самолете полетать где fly by wire по твоим принципам сделан?
> а машина работает с понятием плоской последовательностью.
Вот прям все? B-деревья в "ненужно" запишем? Такой ли плоский uint32_t points[10][20][30]? Можно и N-мерный.
Более того. Даже С сделает корректный код для итерирования через массив struct'ов по индексу. Ну вот смотри, есть условное меню. Может на дисплее, консольке, еще где, в принципе не важно. Меню состоит из нескольких пунктов. Может быть какой-то хоткей для быстрого вызова конкретного пункта, ну и функция вызываемая когда пункт активирован. При помощи struct и макросни даже на сишке легко сделать (массив struct-ов) заполняемый типа
ITEM('l', "Go Left", go_left()),
ITEM('r', "Go Right", go_right()),
ITEM('f', "Go Forward", go_forward()),
...
и даже код для парсинга array-я struct'ов скроеного таким способом будет корркетный и читаемый, достаточно итерировать массив как обычно. А терь сделай это линейно в культурном виде, м? Могу представить себе какой трэш будет в коде и декларировании и сколько багов там можно будет выкусить. Это в принципе уже не так далеко от ООПшных фокусов, но еще не оно, ибо ничего оопшного, только struct, массивы да указатели на функции, которые ассемблерщика уж точно смущать не должны. Идея не моя, вольное цитирование по памяти мануала GCC, чтоли.
У плюсеров и т.п. есть и штуки даже покруче - итераторы.
> Что значить создать массив из N элементов с точки зрения асм или любую другую структуру?
Ну вон см. выше. Это конечно будет всего лишь генерацией одной большой константы, можно даже наглухо readonly в принципе (rodata). И конечно у нее есть sizeof Но вот ручками ее как плоский регион памяти парсить... придется сперва все абстракции самому запилить, потом, конечно, распарсится :)
> Что из себя представляет тот же C++-ный код в асм листинге? Что мешает писать на асм так
> же как и генерит компилятор?
То что в асме нет вон тех понятий.
> Компилятор лучше сделает? - не согласен.
А таки сделает. Если есть где развернуться. В мелком локальном закоулке обставить компилера можно, но сделать какой-нибудь LTO в более крупном коде да удачи. Он в отличие от - видит всю программу, может ДОКАЗАТЬ что та подветка никогда не вызывается и выпилить ее код совсем, заскипает перегрузки регистров, помня что кило назад уже была потребная константа от которой можно оттанцевать, и так далее. А на современных процах "удобной константой" к тому же может быть адресация вида [Rx+N] где в команду кодируется только (маленькое) N. Для человека же пачка смещений от базы не особо читаема.
> Так для наглядности я могу нарисовать квадратиков прямоугольников, стрелочки указать,
> подписать блоки и т.д. куда нагляднее будет,
Это сильно отдельная возня и к тому же отдельно от программы. Надо еще и переключаться между задачами. Неудобно. В продвинутых прогерских редакторах есть переход к определению. Так что если я забыл что такое wtf_data_t - ну, ок, после 1 хоткея я освежу свой склероз. Быстрее чем задачи переключать.
> чем сидеть и вчитываться в код какого-то непонятного мне формального языка. Да, все что вы
> говорите легче псевдокодом описать, а дальше сесть и написать инструкции к исполнению.
Я бы не сказал что это легче. Особенно под 5 разных архитектур. А чего ради я должен быть прибит на гвозди к одной?
> Допустим, человек умеет читать код (знаком с синтаксисом), но не знает предметную
> область, поможет ли ему "читабельность" кода? Промолчу про то, что "читабельный"
> код якобы не нуждается в комментариях.
Для вызова чужой библиотечной функции вообще не обязательно знать ее реализацию и быть вхожим в ту математику, надо знать лишь что на вход, что на выход и границы применимости. Это называется разделение труда. Это называется "разделение труда". И опять же позволяет реюз кода а также масштабирование далеко за пределы того что сможете лично вы. Можно не быть криптографом, но вызвать вон ту функцию писаную криптографом и она таки сделает все как надо. Более того, если я полезу выписывать это сам, 95% что наломаю дров неочевидным образом, область специфичная довольно. И если ей плотно не заниматься, легко облажаться. Вы наверное даже проверку пароля грамотно не сможете сделать так сразу.
Ну вот покажите псевдокод если есть password[30] который ввел юзер и const correct_password[30] с которым сравниваем, как вы проверите что юзер ввел верный пароль?
> Так сначала надо предметную область изучить, чтоб потом кодить.
Знание предметной области не отменяет того факта что допустим 3-мерное пространство будет удобно адресовать как 3 числа-координаты, а вовсе и не линейным регионом.
> К вопросу "читабельности", всякая ли прочитанная книжка нам ясна с первого прочтения? Но не
> поняв прочитанного, мы грешим на автора.
В случае программ - в идеале код должен быть понятен даже идиоту. Это гарантирует что менее глупые кодеры его поймут именно так как задумано и не облажаются, сделав глупые баги из-за непонимания работы этого кода.
> Усердие надо прикладывать, поэтому рекомендую программистам в первую очередь
> заниматься обратной разработкой, а после программировать на формальных языках.
Не по адресу ремарка. Да и вон то лишь понимание что задумал програмер. Это проще смотреть все же в сорце, увы и ах. Там структура сразу видна и коменты в лучшем случае есть.
> исполнение и отладка, формальные языки вообще отвергают понятие отладки, хотя у них
Вообще, я довольно редко юзаю дебагер. Если не валять дурака, потом все просто работает. Но что за правило без исключения прилетевшего в тыкву...
> есть понятие "покрытие тестами".
Это несколько другое на самом деле, хоть и связано. И да мне это нравится, для понимания правильно ли я вообще логику вон того блока кода оформил и не отъехало ли оно при рефакторе.
> прототипы, соглашение об вызовах все это формальные понятия.
И очень хорошо если это будет описано для компилера и анализатора, что он проверит что все и правда так как задумано. Это спасет от кучи дурных багов.
> плоская модель памяти, конечная, вон Тьюринг описывал бесконечную ленту, что по вашему
> мне мешает реализовать алгоритм с понятием о бесконечной ленте?
Конечность ресурсов? А вообще из одних абстракций неплохо делаются другие, с тем или иным приближением. Ну вон у AVR нет MMU - но некто накодил эмулятор ARMv5 + MMU и все же бутанул на этом убунту. Это проще чем допатчить убунту под AVR как оно есть, абстракции вот так слишком далеки.
> Лениво? а как же усердие? Знаете почему когда берут в ученики в
> Шаолиньский монастырь первые пол года ученик с метлой в руках подметает
> дворы, носит воду и т.д.?
Ну вот шаолиньским монахам и флаг в руки. Особенно если они заодно МакЛауды. А у меня одна жизня и делать 1 работу 5 раз я не хочу. Тем более что сделать 1 раз и 4 раза основательно улучшить - результат скорее всего будет лучше. Не всегда сразу понятен наилучший путь, иногда надо зарубуться с проблемой вплотную чтобы увидеть лучшее решение.
> То что код должен быть написан под все архитектуры это очевидность, а то что код
> должен быть написан на всех языках - маразм?
Я и не собираюсь ВСЕ языки использовать. А вот выписывать на все архитектуры мне не охота, кроме каких-то сильно некоторых случаев когда такой трах окупается.
> баловался с МК на сях и ручками выставлял биты в регистрах, спрашивается
> зачем мне С, если тоже самое я делаю на асм?
На сях это можно делать ничуть не хуже. Более того - с препроцессором можно даже компилтайм все делать, precomputed константами и даже compile-time проверками. Когда просто не получится загнать число 22 в 3-битное поле регистра, которое может быть только 0..7 и компилер меня сразу отлупит при попытке это сделать. И я вижу что лажа вышла. Удачи так на асме... там недостаточно аннотации намерений для такого развлечения.
> а с проблемой ведь сталкиваемся не при прочтении "читабельного" кода, так ведь?
Читабельный код является хорошим бонусом. Вооон те господа получили эвон какие баги, по сути на грани вулнов, а все потому что код был тривиален в чтении и я понял что акелла облажался даже не будучи экспертом в кодовой базе.
> я тоже может и зассу с 5-ю на улице драться, а есть
> же люди которые четверых по углам раскидает, а пятый сам себе угол искать будет.
На асме это не очень хорошо работает. У мозга есть определенные лимиты на число сущностей которые он может удерживать резидентно. Отсюда необходимость оффлоада и партиционирования знания.
> Необходимо усердие, плохой я программист когда отказываюсь писать
> под ту или иную архитектуру? Должен ли я писать код под
> архитектуру которую слабо знаю?
Как бы мой сишный код соберется и будет работать даже на процах про которые я не был в курсе на момент написания проги. Что как бы фича. Все что от них требуется это сишный компилер, и сейчас вообще довольно трудно найти платформу где его не будет.
> почему навигация? описанный вами процесс - отладка (пусконаладка),
Это разные понятия. Обзор кода и его понимание может быть как-то связан с вон тем а может не быть. Может быть и патчингом поведения, реализацией какой-то фичи или чего еще.
> ну и не стоит забывать про профилирование, ибо внесенные изменения после
> обнаружения трабла могут регрессивно повлиять.
Есть случаи когда это важно. А есть случаи когда это просто пофигу. Скажем если юзеру надо 0.2 секунды чтобы вообще нажать кнопку, никто не заметит 100 микросекунд я на это реагировал или аж целые 200. Другое дело если это тугой цикл и куча данных...
> а что представляет из себя struct в плоской памяти?
Да в общем то куча байтов в памяти. Однако нельзя взять да скормить его тому кто не готов это сожрать - надо явно декларить входной тип something_t такой же как вооооон там, так я декларирую что готов понимать именно вот это вот на вход в вон той функции.
Более того - это дает некие проверки. Если скажем при рефакторе выпилили определенное поле решив что оно не так уж надо, а какой-то код попытается его юзать - на асме у вас будут трацыбацки. А тут просто компил завалится с "struct something doesn't haves member something_else". Какой код поддерживать лучше - думаю понятно.
> в асм есть работа с плоской памятью, ваши структуры на сях представлены
> так же в плоской памяти.
Спасибо кэп. Просто это не самая удобная абстракция.
> а вот в С++ в структурах есть методы, классы какие-то, а в сях нет и т.д.
И это как бы некая фича плюсов относительно сей. Но это сильно больше абстракций и побочных эффектов от них. Си в этом смысле куда более тонкая прослойка между мной и железом, там грань очень прозрачна, я могу почти побитово рулить происходящим лишь немного хуже асма. И знаю как арену с ноля собрать. В случае какого нибудь класса все может стать заметно сложнее.
А таки хорошо заходит в геймдеве, допустим. Там понятие объектов весьма недурно маппится на происходящее. Да и в некоторых других вещахю тоже.
> лично для меня всякие макро асмы мерзость, и попытка сделать их подобием
> формальных языков высокого уровня.
Я так то умею в hexspeak, но вот именно прогать так всерьез нафиг надо. Так, поприкалываться немного, скажем "а попробуйте, вообще перетереть мой копирайт вот тут, умники".
> Да легче на формальном языке высокого уровня писать, чем на асм кишащий
> макросами и всеми конструкциями которые реально не отражены в архитектуре.
Тем не менее, я и макроассемблеры встречал и на крупных штуках макросня делала код все же несколько менее мерзотным чем он мог бы быть. Но это не решает вопрос с структурированием данных и т.п. вещей (верификация намерений vs реализация например).
