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

[Dennis_Chikin 3 658]

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

 

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

 

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

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

[Dennis_Chikin 3 658]

Увлеченно читаю про эпическую битву с se_stor. Триллер, однако, качественный.

[Kirgudu 948]

 

 

Увлеченно читаю

Ты свои 5 копеек вставишь или ограничишься выкриком «браво/позор» постфактум?

Этот триллер был бы ещё более качественным, если б у меня была возможность покрутить скрипт (в игре! а не краем глаза в паузах основной работы) самому. Но отпуск только на следующей неделе, а пока единственное, на что хватает времени - это мельком глядеть код и давать наводки. Вполне возможно, где-то я по этим причинам ошибся, написал неправильно.

Изменено 9 Октября 2015 пользователем Kirgudu

[Dennis_Chikin 3 658]

Не, это не про "браво/позор". Не надо искать второе дно.

Что написано - ровно то и написано.

 

Пять копеек не вставлю, по тому как для меня лично все-таки переусложнено. Так что остается только интерес.

[User_X.A.R26 261]

typedef используется для кастомного обзывания стандартных типов. Только вот зачем

Инкапсуляция и ассициативность - пока еще слишком страшные слова

Таки поизучал матчасть на досуге и понял для чего оно изначально было изобретено. Сия штуковина была сделана якобы в качестве одного из механизмов инкапсуляции - средство "намеренного запутывания кода" с целью защиты и/или изоляции от кого-либо/чего-либо. Видел как некоторые юзали эту штуку, ибо "влом писать полный вызов, лучше сокращать" (подобное виделось и в X-Ray). Имхо, для инкапсуляции подобного рода лучше юзать #define, чем typedef, чтобы "наверняка"

Изменено 15 Октября 2015 пользователем User_X.A.R26

[Карлан 1 049]

@User_X.A.R26, ты че употребляешь? Изучи подробнее документацию по c api, и про моменты использования define typedef, какая к черту путаница кода? Аргументируй свою точку зрения, приведи код "с" и "без", я тебе в ответ тоже смогу привести, пока ты переливаешь из пустого в порожнее. Про инкапсуляцию уже поминали.

 

 

Тоже самое с bool и BOOL

Основное инкапсуляция - да. Еще разница в том, что c api не работает с типом boolean, lua_pushboolean принимает int C (в отличии от того же lua_pushnumber который принимает lua_Nubmer), и чтобы не было случайных ошибок при экспорте делают подобное объявление, при неявном преобразовании выдаст как минимум warning. Еще также в ходу двойное отрицание (о котором тут не раз подмечал Nazgool) которое приводит любое значение к булевому (в луа и с++ к разным типам, это стоит учитывать).

 

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

Изменено 15 Октября 2015 пользователем Карлан

[Malandrinus 611]

лучше юзать #define, чем typedef, чтобы "наверняка"

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

typedef же является не конструкцией препроцессора, а частью синтаксиса языка. Особенность языка в том, что новый тип и здесь не создаётся, а только создаётся синоним, но тем не менее полученный синоним является с синтаксической точки зрения корректным типом. Нашёл пример в сети для иллюстрации разницы:

 

typedef int* int_p1;
int_p1 a, b, c; // a, b и c все являются указателями

#define int_p2 int*
int_p2 a, b, c; // только первая переменная будет указателем

Короче, для указанных целей создания короткого синонима длинного типа typedef безоговорочно предпочтительней #define.

 

Если есть желание развиваться, то рекомендую почитать насчёт препроцессора языка С/С++. Что это такое, какое место занимает в процессе компиляции, какие проблемы может вызывать при использовании, как их избегать.

[RayTwitty 486]

Требуется небольшая помощь

Существует условие:

if (!a || (a && (!b || (b && c))))

a,b,c - булевые переменные. Необходимо это условие максимально упростить.

 

У меня пока получилось это:

if (a && (b && c || ! || !a)

больше пока идей нет. Мб кто подкинет?) Изменено 4 Ноября 2015 пользователем RayTwitty

[abramcumner 1 023]

if (!a || !b || c)

[НаноБот 705]

Тоже самое с bool и BOOL, и другими типами.

bool - sizeof 1 byte

BOOL - sizeof 4 bytes

Это особенно важно, если ковыряешь движок в проекте XRay-Extensions.

А для си пляс пляс вроде как, не столь важно. Я не очень понял, почему где-то используется BOOL, а где-то bool, разве только что BOOL побыстрей будет, да наверно ещё от конкретной ассоциации с типами зависит. В общем, ассемблер гораздо проще и одновременно сложней си пляс пляс (нету идиотских заваротов).

Изменено 6 Ноября 2015 пользователем НаноБот

[НаноБот 705]

Интересно, если ЯП типа ассемблера, но в тоже время имеющий синтаксис  высокого уровня. Например:

function primer(int A, B, C);
eqi param1 = 500;
begin
eax = 2000;
ebx = 1000;
eax = eax + ebx;
esi.param1 = eax;
eax = A;
eax = eax + C;
eax = eax + B;
end;

MASM может в какой то мере использовать  синтаксис высокого уровня.

Но вся же почему пишут: mov eax, [esi+param1] а не eax = esi.param1, или даже eax = this.param1, где this заранее определён как esi т.е. указатель на собственный объект.

ЗЫ

Лет 15-18 назад у меня была такая идея, скрестить бэйсик и ассемблер 8080, ещё когда программировал на 8-ми битном Партнере 01.01, то есть, сделать свой собственный ассемблер с синтаксисом бэйсика "микрон", но реализовать мне это тогда было не реально. 

Изменено 2 Декабря 2015 пользователем НаноБот

[Malandrinus 611]

@НаноБот,

все эти идеи идут от совершенно неверного понимания сути ассемблера. Ассемблер лучше вообще не воспринимать как язык, а думать о нём как о буквальном интерфейсе к процессору. Когда я пишу mov eax, ebx, я буквально говорю разместить в памяти совершенно определённую инструкцию процессора, которая составлена из некой фиксированной части, говорящей, что это MOV и части, отвечающей за аргументы, в данном случае eax и ebx. Когда же ты начинаешь писать вещи типа eax = eax + ebx, то ты сразу уходишь от вот такого непосредственного указания. Конкретно eax = eax + ebx конечно можно транслировать в одну инструкцию, а вот уже eax = ebx + ecx - уже нельзя, и теряется весь смысл затеи. А потом я захочу написать eax = ebx + ecx + edx и начну возмущаться, что это в таком "высокоуровневом ассемблере" почему-то невозможно. Тогда уже возьми компилятор любого языка высокого уровня и не парься с ассемблером.

 

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

[НаноБот 705]

@Malandrinus, я наверно не совсем правильно выразился, суть в том что инструкции называются максимально просто и имеют формат близкий к высокоуровневом ЯП.

Можно например и так: eax += ebx, уже не перепутаешь.

Или (xmm0.3 = xmm0.0, xmm0.2 = xmm0.0, xmm0.1 = xmm0.0, xmm0.0 = xmm0.0)(это просто пример, можно и покороче придумать) код ассемблера shufps xmm0, xmm0, 00000000b из нулевого элемента копируем во все остальные, векторная арифметика. Само собой такой ассемблер и нормальные команды должен понимать.

Кстати, более подробное изучения SSE показывает мощную оптимизацию по сравнению С++ кодом, т.е. низкоуровневый Fvector4 (xmm) компилятор студии почему-то не понимает. Есть маза переписать на ассемблер, в точности баллистику, с использованием SSE+SSE2+SSE3 для ТЧ, у ЧН и ЗП алгоритм баллистики слишком сложный и не реальный, переписывать его на асм дело не благодарное, и по этому делаем в виде альтернативы не трогая оригинальные функции, а. в конфигах можно включать баллистику или от ТЧ или новую баллистику на основе ТЧ (более продвинутый алгоритм на основе реальных алгоритмов бал. моделей) ну или пользоваться старой.

В общем, мне не нравится программировать на С++ из-за больших проблем с компиляцией, и сложностей распространения, людям проблематично скачивать огромные студии и компилировать проекты по 40 минут только одна xrGame.dll, да ещё для ТЧ, ЧН, ЗП надо разные студии (2008, 2010, 2013, 2015 для разных проектов), а это около 17-19 ГБ живого веса. Не чета простому проекту XRay-Extesions_portable с жалкими мегабайтами и моментально компиляцией (17 сек для ТЧ для xrGame.dll). Это я про конкуренцию ассемблера и С++ в рамках проекта модинга движка.

Изменено 3 Декабря 2015 пользователем НаноБот

[Malandrinus 611]

@НаноБот,

суть в том что инструкции называются максимально просто и имеют формат близкий к высокоуровневом ЯП.

Да понял я тебя, и могу только повторить уже сказанное. Формат, близкий к языкам высокого уровня, но при этом со всеми ограничениями ассеблера - это ненужный уродец. Если я могу записать конструкцию eax = eax + ebx, но не могу записать что-то вроде eax = ebx + ecx, то ничего мне это не даёт, кроме как запутает. Пойми же, ассемблер - не язык высокого уровня. Его мнемоники тесно связаны с тем, как это всё устроено в памяти. Формат <мнемоника> <операнд1>, <операнд2> - это максимально соответствует бинарному формату в памяти. Кроме того, все остальные мнемоники, а их куда как больше, нежели мнемоник копирования и простых арифметических операций, имеют такую же вышеописанную структуру. Представь себе бедлам, который внесёт разнобой синтаксиса. А вот например есть мнемоника не просто копирования из регистра в регистр, а копирование из регистра меньшей разрядности в регистр большей. При этом надо решить, как заполнять старшие разряды: нулями или знаковыми битами. Для этого есть две разные инструкции копирования, а как ты предлагаешь это оформить в виде высокоуровнего кода? И есть ещё море подобных возражений.
 

Кстати, более подробное изучения SSE показывает мощную оптимизацию по сравнению С++ кодом, т.е. низкоуровневый Fvector4 (xmm) компилятор студии почему-то не понимает.

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

 

Есть маза переписать на ассемблер

=) Я думаю, что тебе стоит попытаться для начала написать на ассемблере какую-нибудь простую программу.
 

В общем, мне не нравится программировать на С++ ...
компилировать проекты по 40 минут только одна xrGame.dll, ...
это около 17-19 ГБ живого веса. ...
Это я про конкуренцию ассемблера и С++ в рамках проекта модинга движка.

Извини, но если подытожить сказанное, то ты просто не представляешь о чём говоришь. Одна строка C++ или другого языка высокого уровня - это в среднем десятки инструкция ассемблера. Добавь к этому на порядки большую сложность программирования на ассемблере, т.е. на написание и отладку аналогичного фрагмента на ассемблере уходит в десятки раз больше времени, чем на любом языке. 17-19 мегабайт кода С++ тогда превратятся в порядка 200-300 Мб, а время разработки сталкира в шесть лет превратится во все 60. Я не шучу.

[abramcumner 1 023]

В общем, мне не нравится программировать на С++ из-за больших проблем с компиляцией, и сложностей распространения, людям проблематично скачивать огромные студии и компилировать проекты по 40 минут только одна xrGame.dll,

Это полная перекомпиляция. Обычная гораздо быстрее, на уровне тех же 17 секунд.

 

да ещё для ТЧ, ЧН, ЗП надо разные студии (2008, 2010, 2013, 2015 для разных проектов), а это около 17-19 ГБ живого веса.

С++ не виноват в бардаке среди разных проектов. Все можно собирать в одной студии.

 

Не чета простому проекту XRay-Extesions_portable с жалкими мегабайтами и моментально компиляцией (17 сек для ТЧ для xrGame.dll). Это я про конкуренцию ассемблера и С++ в рамках проекта модинга движка.

C++ можно использовать и в xray-extesions. Экспортируешь нужные символы в с++, используешь метки и naked-функции. А линкеру неважно какие объектные файлы собирать, полученные из асма или с++.

 

А еще можно баллистику вынести в отдельную статическую библиотеку и компиляция будет те же 17 секунд

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

[НаноБот 705]

А кстати, есть такой ЯП, который высокого уровня и при этом, очень близок к ассемблеру, это С-- сфинкс, жалко что уже не развивается. 

А про модинг движка, если правка простая, то порой проще написать эту правку на асме, чем мучится с С++ и долгой компиляцией, напоминаю, что я в С++ если не дуб дубом, то плохо понимаю его синтаксис и не которые замороченные принципы. Например, есть задача создать новый класс объекта, робота ХЕНа, той самой стальной курицы с пулемётом из билда 1098. Как это сделать в С++ я не очень хорошо понимаю, но я знаю что надо делать на классе сталкера CAI_Stalker и подсоединяем ему класс CCarWeapon для интегрированного оружия. В XRay-Extesions_portable я просто добавлю в класс сталкера возможность отыгрывать анимацию только самого робота хена, пропуская все остальные и придумаю что нибудь на счет оружия, при атачу класс CCarWeapon или ещё что нибудь придумаю. Хотя возможно робота хена надо на классе монстра делать. В билде 1098 у хена класс монстра по ходу был, сталкер то же наследует класс кастоммонстра. Конечно это всё надо делать в С++, класс все же отличается от самого сталкера и существенно, но мне так проще.

Изменено 3 Декабря 2015 пользователем НаноБот

[HESH 64]

@НаноБот, но... как же С11? Не развивается? Язык довольно сложен (имхо - надстройка над asm), да и скиловых программистов на нем не так много, как даже на C++. А "развиваются" в основном языки .NET (C#, VB)и Java.

[RayTwitty 486]

Это полная перекомпиляция. Обычная гораздо быстрее, на уровне тех же 17 секунд.

Зависит от количества измененных заголовков. Поправишь какой-нибудь GameObject.h - будет минут пять собирать.

 

Как это сделать в С++ я не очень хорошо понимаю

Достаточно один раз разобраться и будешь делать это мгновенно. А искать постоянно врезку в асм-листинге - то на релок, то ещё куда-нибудь попадешь. Извращение, имхо. Изменено 3 Декабря 2015 пользователем RayTwitty

[-StalkMen- 159]

Уж простите,

Но использование asm, когда исходникам уже год - мазохизмЪ.

 

Долгая перекомпиляция? Отговорка

При грамотной организации работы -

 

 

на уровне тех же 17 секунд.

[НаноБот 705]

Забавно, я тут малость тупанул из-за не достатка инфы.

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

http://dsmhelp.narod.ru/environment.htm

invoke, .if,.elseif, .else, .endif, .while, .repeat и т.д.

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

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

[Kontro-zzz 70]

Уж простите,

Но использование asm, когда исходникам уже год - мазохизмЪ.

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

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