Курилка программистов

[Dennis_Chikin 3 658]

Судя по регулярно происходящему в других темах - таки нужна.
Вот здесь как раз можете спросить про "зачем создали эту тему ?"

 

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

 

Но таки да, пп 2.0, 2.1 и даже 2.5 правил здесь вполне таки действуют.

Изменено 30 Января 2015 пользователем Dennis_Chikin

[-StalkMen- 159]

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

Эм... Исполняемые файлы? Ну наверно. Но кто ж так делать-то будет

Если репозиторий с интересующей правкой открыт, то в чём проблема сходить туда и сделать Ctrl + C ?..

КПД разработки на asm меньше. Не зря же все более менее большие проекты пишут в средах разработки, а не в "блокноте".

Да, мелкиемелочи© (порой очень полезные) делать можно (продуктивно), но мы в 2015 году... Правки аля "прицел, как билдах" или "стопицот коллбеков" уже не катят...

*Я занимался ковырянием сталкера аля asm, больше не хочу (и всем светлым головам того-же желаю)

Изменено 4 Декабря 2015 пользователем -StalkMen-

[Forser 47]

@-StalkMen-, для скилла можно поковырять ассемблером, это имхо конечно, ибо С++ удобеней.

[Kontro-zzz 70]

 

 

Если репозиторий с интересующей правкой открыт, то в чём проблема сходить туда и сделать Ctrl + C ?..

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

[Карлан 1 049]

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

 

@Kontro-zzz, речь совершенно не о геймерах.

[Forser 47]

 

 

я чувствую себя законченным идиотом

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

[Malandrinus 615]

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

...

То есть, можно делать то же что на С++

Объясни пожалуйста, а что мешает тогда просто взять СИ и его использовать? Я не говорю про С++ с его классами, шаблонами и т.п., а только про старый добрый процедурно-ориентированный  СИ. Вот застрели, а я не вижу ни малейшего преимущества в ассемблере перед обычным СИ. Тем более, что ты хочешь использовать там макросы, превращающие его в некое подобие нормального языка. Но все ограничения то останутся: с гулькин нос регистров, ограничения по набору операций, никаких типов и соответственно контроля, даже с этими макросами элементарные действия требуют жуткого геморроя по сравнению хоть с каким угодно языком и т.д.

 

Я более скажу. Твои слова насчёт того, что дескать проще распространять и собирать - это ты на самом деле принимаешь за эффективность элементарную неразвитость средств разработки для ассемблера по сравнению со средами для языков высокого уровня. Формально говоря, этапы сборки программы для ассемблера ровно такие же, как и для СИ: компиляция, линковка. Если ты такой эстет, то ничто не мешает и на СИ разрабатывать в блокноте и пользоваться сборкой из командной строки. Будет тебе точно такая же "эффективность и простота".

 

 

А метод ХЕ или ассемблерных вставок-правок так и останется универсальным для ориг. версий.

О боги геймостроя! Да если бы у меня пять лет назад были исходники, я бы и думать не стал ни про какой ассемблер. А сейчас проект ХЕ для меня лично актуален только постольку постольку к нему привязан ОГСЕ. Обратная совместимость - страшная штука. Так бы забыл уже как страшный сон.

 

[RayTwitty 492]

А сейчас проект ХЕ для меня лично актуален только постольку постольку к нему привязан ОГСЕ. Обратная совместимость - страшная штука. Так бы забыл уже как страшный сон.

Ну, на самом деле, перенести все правки ХЕ в исходники не такая уж большая задача, учитывая, что половину правок можно вообще нормально переделать без экспорта костылей. По крайней мере, это касается xrGame-библиотеки.

 

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

 

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

 

И кстати, ответь в ЛС на последнее сообщение - буквально один момент ведь осталось разобрать

Изменено 5 Декабря 2015 пользователем RayTwitty

[Desertir 202]

Кстати об ассемблере.

[Kontro-zzz 70]

речь совершенно не о геймерах

 

Действительно, не объяснил причем тут геймеры.

Как-то с Макроном попытались сделать интерфейс для патчера, для ОЛР. При установке или после установки мода, геймер мог выбрать кое-какие настройки, то бишь правки.

 

Правки там конечно слишком простецкие тогда были.

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

Изменено 6 Декабря 2015 пользователем Kontro-zzz

[Malandrinus 615]

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

function fff()
    if cond1 then
        if cond2 then
            if cond2 then
                if cond3 then
                    if cond4 then
                        --do_something
                    end
                end
            end
        end
    end
end

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

В своей практике я взял за правило всегда заменять этот код, насколько это возможно, на эквивалентный ему в таком стиле:

function fff()
    if not cond1 then return end
    if not cond2 then return end
    if not cond3 then return end
    if not cond4 then return end
    --do_something
end

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

Это конечно отступление от Истинно Структурного Программирования, но на это как-то и начхать.

 

Есть ли какие-то мысли по этому поводу?

 

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

Изменено 10 Декабря 2015 пользователем Malandrinus

[Murarius 10 531]

 

 

после проверки тысячи условий уползает куда-то вправо и теряется где-то в середине функции

Еще в юности у меня волосы дыбом вставали от такого. Чуть упрощается понимание, если есть... ммм... как они называются, вот эти линии-связки вертикальные? Но все равно дичь, особенно когда эти линии разноцветные и их много.

То, что ты описываешь, это как раз и есть тот Сакральный Рефакторинг. Меня в секту его свидетелей тоже запишите, пожалуйста.

[Struck 61]

@Malandrinus, для действительно полного использования подобного стиля в луа нужен continue. Я тут наверное скажу, что подобные блоки нужно стараться совмещать в один посредством логических операций, это в скриптах, а в движке да, можно использовать то что ты предлагаешь, это явно прослеживается в изменениях движка. Изменено 10 Декабря 2015 пользователем Struck

[Kirgudu 1 187]

Использование граничного оператора для уменьшения степени вложенности условий описано, емнип, Фаулером в его «Рефакторинге», а может и ещё раньше кем-нибудь, например тем же МакКоннелом.

Хотя вот у нас в компании негласно принято (большинством; так их учили) писать в стиле «одна точка входа - одна точка выхода», и меньшинству приходится подстраиваться. Поэтому лично у меня скрипты для Сталкера получаются в этом плане двойственными, в зависимости от того, что сработало - привычка или личное предпочтение.

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

[Serge! 127]

Есть ли какие-то мысли по этому поводу?

Если дело только в "лесенке" и таких "лесенок" много, то я бы определил вот такую функцию:

function checkbool(...)
  local t = arg and arg or {...} -- чтобы работало и в чистом Lua и в "Сталкере"
  rez, i = true, 1
  while rez and i<=#t do
     rez = rez and t[i]
     i = i + 1
  end
  return rez
end

после чего, основная будет выглядеть так:

function fff()
    if checkbool(cond1, cond2, cond3, cond4) then
       -- do_something
    end
end 

Изменено 10 Декабря 2015 пользователем Serge!

[_Призрак_ 11]

 

 

local t = arg and arg or {...} -- чтобы работало и в чистом Lua и в "Сталкере"

А можно узнать сакральный смысл двойного arg? Почему не local t = arg or {...} ?

[Serge! 127]

А можно узнать сакральный смысл двойного arg?

Конечно можно. Никакого. Просто привычка.

Изменено 10 Декабря 2015 пользователем Serge!

[RayTwitty 492]

Это конечно отступление от Истинно Структурного Программирования, но на это как-то и начхать.

Собственно, из-за концепции структурного программирования и делают, как ты говоришь "лесенкой". Но в обычных условиях, таких простынь вряд ли получится - лично я привык некоторые повторяющиеся действия (а они чаще всего повторяются (вызываются) где-то ещё), оборачивать в отдельные функции, вроде "return a and b and c". Впрочем, само использование return, break, continue и т.д. уже не есть структуры, так что на эти формальности можно забить. Где-то удобнее сделать выход в начале функции, где-то построить лесенку, зависит от случая.

 

Кое-где я у себя даже goto юзаю 

 

А можно узнать сакральный смысл двойного arg? Почему не local t = arg or {...} ?

arg and arg or {...}

эквивалент

arg ? arg : {...}

Изменено 10 Декабря 2015 пользователем RayTwitty

[RayTwitty 492]

Помнится когда-то был тоже лестничный код с кучей условий (использовалось для модуля сна в инвентаре, если интересно), структура такая:

 

function()
	if not cond1 then
		if not cond2 then
			if cond3 then
				if cond4 then
					SLEEP -- call external func
				else
					-- show message4 (CUIStatic)
				end
			else
				-- show message3 (CUIStatic)
			end
		else
			-- show message2 (CUIStatic)
		end
	else
		-- show message1 (CUIStatic)
	end
	level.start_stop_menu(level.get_inventory_wnd(), true) -- hide inventory window
end

 

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

Изменено 10 Декабря 2015 пользователем RayTwitty

[Desertir 202]

@Malandrinus, хм, а куда делся оператор and?

Тут же несколько вариантов, если просто каскад условий, если после некоторых или каждого вычисляется какое то выражение и самый плохой вариант, когда такое в цикле.

Еще надо сказать, что мы говорим о субъективной вещи. Кому то лесенка вполне читаема. У нас было принято, что однострочников в духе "if not cond_1 then return end" не писать, обязательно перенос строк. Так что тут зависит от предпочтений конкретного кодера или стандартов компании.

Изменено 10 Декабря 2015 пользователем Desertir

[TIGER_VLAD 361]

 

 

Кое-где я у себя даже goto юзаю 

 

Вот все ругают оператор goto. Не пойму чем он так плох?