Цитата:
Сообщение от Robus
Откуда взялся этот стереотип "велосипеда" ? Если пишется !!!нормальная!!! программа одного и того же автора, то в ней повторяется лишь стиль, а не процедуры.
Конечно, есть одинаковые процедуры, но их можно пересчитать по пальцам. Как правило ZX'ер пытается максимально ускорить свой код, а это значит, что лишний раз он не будет делать CALL, и простая процедура умножения может уменьшиться на один-два цикла, ради скорости.
Я знаю одну процедуру быстрого умножения. Родившуюся путём
объединения кода от нескольких разных людей. Уверен, никто такое
из головы запросто так вот сразу не выдумывает. И процедур таких
немало. А кроме вопроса оптимального кодирования ещё есть
АЛГОРИТМЫ. Оптимизация алгоритма зачастую даёт выгрыш
не сравнимый с выжимкой жалких тактов. И это тоже не из головы
за 5 минут выдумывается.
А что касаетя CALL -- это вообще сильно притянуто за уши. Для
этого существуют (я знаю, что на спектруме, по сути, это только ALASM) существуют МАКРОАССЕМБЛЕРЫ. Хочешь call, хочешь
"inline" функция. НЕТ тут проблемы. НЕТ.
Другое дело, что процедуры вида "расчёт адреса в экране" и т.п.
действительно бессмысленны. Нужна математика, строки, ввод-вывод...
Вот ещё пример: печаталка 64 символа в строке без развёрнутых
шрифтов ужатая Михаилом Жаровым до каких-то смехотворных
тактов и байтов. Аналогов не существует. Оптимизировалось несколькими людьми в течении достаточно длительного времени.
Хрен сам ты её за 5 минут напишешь.
Цитата:
Если всё строить на готовых библиотеках, то в итоге код обростает торможением. После чего библиотека пригодна для написания "карт" или "минёров", и да же в них карты будут дёргаться или вообще просто появляться.
Бред.
Цитата:
а с вас никакого спроса, как и с автора библиотеки. А представьте себе, - делаешь прибор, пишешь софт, и всего-то соединяешь прибор по простому COM'у. Его ставят на завод, запускают бумагоделательную машину, и через час вдруг завис "дрюйвер" COM-PORT'а.
Да бывает. Нужно использовать правильные библиотеки.
К которым даётся исходный код. Именно на этот случай.
День ковыряний в коде выявляет, что ioctl(TIOCSBRK) не
поддерживается драйвером moxa, но поддерживается
обычным писишным портом. После чего в библиотеке
вписывается нормальный tcsendbreak() и всё сразу работает.
Ибо поддержка юнихов доисторических версий нафиг не нужна
и можно смело требовать соответствие современному IEEE-1003.
Хотя в целом я согласен. Минимум лишнего и разумная простота конструкции в целом только добавляет надёжности.
Цитата:
И, соответственно завод больше не приобретёт прибор нашей компании. Вот так было, когда на нашей фирме работали программисты, закончившие институты и имеющие учёные степени.
Программный продукт -- технически исключительно сложное изделие. Со всеми вытекающими последствиями.
Цитата:
Сколько я не писал проектов, всегда всю обвязку делал сам, начиная от COM-PORT'а, кончая USB, ETHERNET, VIDEO, KEY и всё остальное
Да, да. Не имея документации ты напишешь USB и ethernet драйвера,
напишешь свой tcp/ip стек, свою графическую подсистему, отладишь
это всё, нигде не наделаешь ошибок... Фантастика научная.
Цитата:
... Не было ни одного отказа ... И главное, не нужен лицензионный виндовс, не нужно платить всем подряд за использование !!!очень!!! не качественных компонентов и тех же SDK. И после этого вы
Есть полно не очень качественных компонентов, но абсолютно
нахаляву и со всеми исходными текстами. В условиях, когда абсолютно качественных компонентов нет, а очень качественные --
это $$$$$ -- это не так уж плохо.
[quote
говорите, что не нужно изобретать велосипед. Конечно, если делать "мышки(манипулятор)" или писать "смотрелку картинок" этого хватит. А более серьёзное ? Хотя каждую программу нужно писать на 100%, не смотря на то, что она делает.
[/quote]
И писать даже не на ассемблере (вдруг он глючит), а исключительно
в машинных кодах.
Цитата:
А для чего я писал свой компилятор? Он именно это и делает! Всё,
Компилятор чего? И уверен ли ты, что не облажался больше,
чем профессионалы занимающиеся этим второй десяток лет?
По-моему ты перегибаешь.
Цитата:
Но, этот опыт привёл к разделению на тех, кто пишет в основном на библиотеках, и тех, кто пишет в основном на “велосипедах”. Я отношусь к тем, кто любит прилеплять реактивный двигатель к велосипеду. И мне для разработки нужно:
Мой опыт показывает -- сам всего не прилепишь, банально времени
сил, энтузиазма, времени и опыта не хватит. А у самодельного велосипеда никакого запаса прочности и потенциальных возможностей для дальнейшего развития. Ну их нафиг, велосипеды.
Цитата:
Всяческие процедуры с мышками, FDD, HDD – хорошая идея. Хотя, например FDD. Тянет за собой обработку системных переменных. Так же менеджер памяти, а вдруг и это очень вероятно, что я захочу его поместить начиная с 23296, да бы была возможность выделять всю память до байтика. Ну и после всё это соединю, думаю, что библиотеки начнут ссориться.
Нужен унифицированный интерфейс.
А работу с HDD ты вообще не напишешь. Потому что их много и
разных. Ты просто протестировать на всех вариантах для всех
программ не сможешь. Тут именно тот случай, когда позарез как
необходим сторонний код. Который протестирован и отлажен.
И позарез как нужна динамическая компоновка. Потому как
протестировать и отладить до конца невозможно, хотя бы поэтому.
А автору каждый раз пересобирать софт тоже невозможно.
Цитата:
Это дело, но всякие печати символов, часы, отображение курсоров, наложение спрайтов лично мной бы вряд ли использовалось. Разве что посмотреть как делают другие.
Если тебе нужно что-то уникальное -- ты прав. Для демо не сойдёт.
Если тебе нужно не важно с какой скоростью, но выводить текст
и иметь приличный редактор в окошке -- лучше взять готовый.
