Беседка для программистов, или «Бутерброд с кодом»

@R4kk00n, всё что написано - глюкалово, бажное и говнокод. Кто писал - пофиг. Потому что всегда есть причина.


Менеджер по набору персонала разговаривает с начальником отдела разработки:
- Рид, почему ты уволил того талантливого программиста, которого я с таким трудом переманил к нам ? Он даже недели не продержался !
- У него был не тот языковой акцент.
- Только не говори, что ты делишь людей по языковому признаку... - менеджер в шоке.
- А по какому же мне их ещё делить ?! - возмущается Рид, - особенно, когда они в FORTH говнокодят, как на C/CPP ?
- О !

 

Что лучше, Си или Си++?
Чооооо!!!!
По мне, если проект сложный то лучше С++, например, игровой движок.
Класс худовый объект -> базовый класс оружия -> базовый класс огнестрельного оружия -> класс гранатомёт -> класс ПЗРК.
Если всё это делать без ООПа то получится спагетти(скажем офигенные switch'и).
А так, всё понятно, уже есть классы до гранатомёта включительно, надо добавить класс ПЗРК. Ну и делаем собственно сам ПЗРК.
А не пытаемся переделать кучу кода, чтобы новые свойства этого самого ПЗРК получить.
А если переезд на совершенно новый движок? И надо этот самый ПЗРК, портировать без переделок.
Если ООП, то это сделать гораздо легче, чем выдирать код из спагетти.
Это всё по опыту модинга сталкера.
ЗЫ
И да, на С++ можно кодить как на Си, без всяких всячин, просто Си с классами. Код получается достаточно быстрый и компактный.

 

Что лучше, C или C++ ?
Неужели до сих пор непонятно кому-то, что этот спор не имеет смысла? Всё хорошо в меру и в своей целевой нише.

 

Эти люди не понимают, что лучше всего Ruby... Ибо он используется в лучшем движке на свете - RPGMaker.

 

Кхм, возможно я влезаю сейчас не в тему, но... Вы изучали в школе Pascal?

 

Я изучали, давно было.

 

А кто-нибудь из вас пользовался парсингом? Я вот год назад начал.
Сначала парсил по заданию одного из бывших моих руководителей данные из сайта одной из научных библиотек - файлы .pdf .
А сейчас я решил спарсить из каких-нибудь посещаемых или раньше которые я посещал картинки.
В частности, я с помощью парсинга скачал парочку скриншотов из игр, выложенных на old-games. Я надеюсь никто не против. Ведь я не собираюсь использовать в коммерческих целях. Так, для коллекционирования.

 

Кто силён в программировании для 8-битных ПК?

Не могу понять концепцию работы с кодом при переключении банков памяти (в частности, для атари- и спектрумоподобных, но и общая теория подойдет).

Вот у меня Спектрум с 64 кБ. Всё линейно, шина адреса - 16 бит, адресуюсь от 0 до FFFFh.

Теперь берем ПК со 128 кБ памяти.

Шина адреса - всё еще 16 бит, максимально доступный адрес - FFFFh (первые 64 кБ).

Допустим, у меня условно два банка памяти (хотя на практике их почему-то больше) - первый с 0 до 64 кБ, второй - с 64 кБ до 128 кБ.

Механизм переключения обычно такой - я пишу в определенный порт 1 или 2 (хотя используют опять-таки почему-то всякие FF-FC) и ПК понимает, что я выбрал для работы банк памяти "1" или "2" соответственно.

Дальше я что-то не понимаю, как оно работает.

1. Вот я выбираю банк памяти 1. Делаю, условно, говоря:

MOV [0000], FFh

2. Затем переключаюсь на банк памяти 2 (засылаю в порт нужное значение, мол переключить на банк 2). Делаю опять:

MOV [0000], FFh

Теперь, глядя на непрерывную карту памяти (от 0 до 128 кБ), у меня значение FFh записано дважды - по абсолютному адресу 0000h и по абсолютному адресу 10000h (FFFFh+1).
Так?

Если код у меня в первых 64 кБ, а данные - в первом и во втором банке (с 0 до 128 кБ) - это еще понятно, структура программы будет самая обычная (линейная), а при выборке данных я должен сначала указывать, что переключаюсь на нужный мне банк памяти (то есть как-то сам должен за этим следить).

Неясно, как должна быть построена программа, занимающая больше 64 кБ?

Смутно догадываюсь, что примерно так же работает сегментная модель памяти в 8086 и есть что-то схожее с форматами .EXE и .COM, но на этом пока всё.

P.S. О, всё несколько сложнее...

 

Решил тему возродить.
По обсуждать, скажем кеш процессора. А то тут два дня назад набрёл на тему, на геймедеве, там про кеш, эксперементы, с 2д массивами. И при ширине 1024, провал производительности...
Про кеш промахи, и что по памяти прыгать на большие участки - плохо, я как бы знал. Но что именно на степени двойки наибольшие проблемы будут. Спросил у Гугла - всё так и есть. Хотя на моём, уже древнем процессоре, разница ничтожная. Попробовал вариант, как в видеопамяти данные лежат - кривая мортона, или что-то близкое... Как индексацию сделать (формулу не осилил, но нашёл в инете), попробовал, результат заметный, но на массивах где то от 4000х4000. На маленьких массивах полный провал. Видимо, проблема многих волновала, и Интел уже давно озаботился, поддержкой команд, чтобы сделать в 2-3 инструкции такую индексацию, Амд лет 8 назад.
Поискал в сети, поспрашивал у ИИ. есть еще вариант, это разбить как бы всё на маленькие блоки, чтобы в памяти данные лежали не длинными строчками, или столбцами, а блоками по 8х8 или 16х16...

--- добавлено 6 мар 2026 в 14:59, предыдущее сообщение размещено: 6 мар 2026 в 14:46 ---

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

 

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

 

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