Здравствуйте, ·, Вы писали:

·>Да и вообще неясно насколько необходимо проверять abrt после каждого readmeml, наверняка это можно сделать после всех чтений.

Это правда необходимо: любое чтение — потенциальное исключение, которое может закончится командой halt.

Ф>> ((SP + 4) & 0xFFFF))
·>Тут явно напрашивается что-то вроде "extract_something(SP + 4)", документации ради как минимум, и не потребуется вертикальное выравнивание.

Зачем????? Посмотри на название функции — это opPOPA, т.е. команда, которая вычитывает регистры, используя ss и ESP. Что тут ещё документировать???!
А вот производительность эмулятора ты вот такими необдуманными действиями легко можешь просадить.

·>Обычно авто-форматтеры позволяют помечать специальными маркерами фрагменты кода, для которых автоформатирование отключается. Что-то типа "// formatter=off".

необычно.

и как тебе макрос поможет в борьбе с закоммиченным малформд кодом?

Здравствуйте, Osaka, Вы писали:

IT>>За автоформатирование руки надо сразу вырывать.
O>УК РФ Статья 111 ч. 2 пункты д, е. До 10 лет.

За такое можно даже смертную казнь восстановить.

Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:

尿Ǥ푙>и как тебе макрос поможет в борьбе с закоммиченным малформд кодом?

Что такое "малформд кодом"?

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:

尿Ǥ푙>>и как тебе макрос поможет в борьбе с закоммиченным малформд кодом?

IT>Что такое "малформд кодом"?

malformed code — код, имеющий проблемы с форматированием: if(...), как ты говоришь. просто интересно, что тут можно сделать когда коммит уже в базе.

Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:

尿Ǥ푙>malformed code — код, имеющий проблемы с форматированием: if(...), как ты говоришь. просто интересно, что тут можно сделать когда коммит уже в базе.

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

Здравствуйте, Философ, Вы писали:

Ф>·>Да и вообще неясно насколько необходимо проверять abrt после каждого readmeml, наверняка это можно сделать после всех чтений.
Ф>Это правда необходимо: любое чтение — потенциальное исключение, которое может закончится командой halt.
Ну это можно в readmem запрятать или для такого исключения — бросать исключение. В общем, неважно, мой поинт в том, что очень часто необходимость выравнивать код по вертикали говорит о том, что code smells и его можно улучшить.

Ф>>> ((SP + 4) & 0xFFFF))
Ф>·>Тут явно напрашивается что-то вроде "extract_something(SP + 4)", документации ради как минимум, и не потребуется вертикальное выравнивание.
Ф>Зачем????? Посмотри на название функции — это opPOPA, т.е. команда, которая вычитывает регистры, используя ss и ESP. Что тут ещё документировать???!
Я имею в виду наложение маски "& 0xFFFF". Полагаю это извлечение значения для 16-битных команд. Ну так сделай метод с таким названием вроде use16bit.
Или сделать два метода readmeml16 и readmeml32 и там эту маску запрятать. В эту же пару методов можно и SP += 4 / ESP += 4 запрятать чтобы всю эту твою копи-паст арифметику не писать.

Ф>А вот производительность эмулятора ты вот такими необдуманными действиями легко можешь просадить.
Если вы пишете на яп, который в тривиальнейшие оптимизации не умеет, вы явно выбрали неподходящий инструмент.

Ф>·>Обычно авто-форматтеры позволяют помечать специальными маркерами фрагменты кода, для которых автоформатирование отключается. Что-то типа "// formatter=off".
Ф>необычно.
Студия умеет, Райдер умеет, vscode умеет, clion умеет. Какой необычный форматтер вы используете?

ну, ок. немного необычное применение. тут главное следить за тем что кто из ваших оппонентов на написал условный макрос, делающий некомпилируемым if{space}(...)

Решения о примелемости или непримелемости — консенсусные по сути, форсировать их макросами, как по мне — перебор. Меня бы бесило, если формально валидный код не компилировался бы только потому, что кто решил, что так "неправильно".

Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ൒, Вы писали:

尿Ǥ푙>Решения о примелемости или непримелемости — консенсусные по сути, форсировать их макросами, как по мне — перебор. Меня бы бесило, если формально валидный код не компилировался бы только потому, что кто решил, что так "неправильно".

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

Здравствуйте, ·, Вы писали:

·>...В общем, неважно, мой поинт в том, что очень часто необходимость выравнивать код по вертикали говорит о том, что code smells и его можно улучшить.

Давай начнём с того, что это не необходимость!? Адекватное форматирование кода просто улучшает читабельность, ВСЕГДА. Притом не важно, форматируешь ли ты код в соотвествии с корпоративным кодстайлом, либо даже вот такое, табличкой.

Далее, здесь ты читаешь оптимизированный код. Смотри: в интеловской документации команда описывается вот так:

if(OperandSize == 32) {
    //Instruction == POPAD
    EDI = Pop();
    ESI = Pop();
    EBP = Pop();
    ESP = ESP + 4; //skip next 4 bytes of stack
    EBX = Pop();
    EDX = Pop();
    ECX = Pop();
    EAX = Pop();
}
else {
    //OperandSize == 16, instruction == POPA
    DI = Pop();
    SI = Pop();
    BP = Pop();
    ESP = ESP + 2; //skip next 2 bytes of stack
    BX = Pop();
    DX = Pop();
    CX = Pop();
    AX = Pop();
}

Обрати внимание на скип 2-х и 4-х байт в зависимости от размера операнда. Можно было бы написать руками инкремент ESP, и описать функцию POP(). Но в конечном машинном коде тоже был бы инкремент, а в данном месте это КРИТИЧНОЕ замедление: вместо семи операций с индексной адресацией в конечном коде было бы 7 операций с индексной адресацией + один лишний инкремент. Учитывая, что топовые современные камни едва тянут эмуляцию i486['*], такие замедления неприемлимы.
['*] без динамической рекомпиляции эмулятор едва ползает, а с ней почти невозможно соблюсти потактовую точной эмуляции.

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

·>Я имею в виду наложение маски "& 0xFFFF". Полагаю это извлечение значения для 16-битных команд. Ну так сделай метод с таким названием вроде use16bit.

Попробуй. Код тут Инструкция по сборке здесь. Чтобы попробовать, тебе будут нужны ROM'ы, они тут.
Сабжевый код находится в src/cpu/x86_ops_stack.h
Покажи потом что получилось.

Ф>>необычно.
·>Какой необычный форматтер вы используете?

Лично я ничего не использую. В этом проекте я вообще код в FAR'е пишу, потому что так и не осилил настроить ни одну из сред разрабоки. Честное слово, крыл благим матом все IDE, которые пытался приспособить для этого проекта. А так — кто во что горазд.

Как запретить автоматическое форматирование в VS (не VS Code) не знаю.

Здравствуйте, Философ, Вы писали:

Ф>·>...В общем, неважно, мой поинт в том, что очень часто необходимость выравнивать код по вертикали говорит о том, что code smells и его можно улучшить.
Ф>Давай начнём с того, что это не необходимость!? Адекватное форматирование кода просто улучшает читабельность, ВСЕГДА. Притом не важно, форматируешь ли ты код в соотвествии с корпоративным кодстайлом, либо даже вот такое, табличкой.
Вертикальное выравнивание создаёт свои проблемы. Так что адекватность конкретно вертикального выравнивания вещь очень сильно спорная.

Ф>Далее, здесь ты читаешь оптимизированный код.
Оппа. Т.е. в качестве док-ва ненужности автоформаттеров ты приводишь кусок оптимизированного кода... Ты не чувствуешь, что адекватность таких аргументов вещь тоже очень сильно спорная?

Ф>Обрати внимание на скип 2-х и 4-х байт в зависимости от размера операнда. Можно было бы написать руками инкремент ESP, и описать функцию POP(). Но в конечном машинном коде тоже был бы инкремент, а в данном месте это КРИТИЧНОЕ замедление: вместо семи операций с индексной адресацией в конечном коде было бы 7 операций с индексной адресацией + один лишний инкремент. Учитывая, что топовые современные камни едва тянут эмуляцию i486['*], такие замедления неприемлимы.
Честно говоря слабо верится, современные компиляторы творят чудеса, код, наверное, очень старый или заточен под какие-то старые/слабые компиляторы. Но проверять лень.
В любом случае, доля сильно оптимизированного кода (читабельность и поддержка которого имеет приоритет меньший, чем быстродействие и заточка под конкретную платформу) составляет доли процентов, для остального кода нет никаких причин не использовать кодстайл и автоформат.

Ф>Если не гнаться за каждой наносекундой, то можно было бы напихать регистры в список — кода было бы меньше, читалось бы замечательно. Однако эмулятор работал бы ещё медленнее.
Если ты гоняешься за наносекундами во всём своём коде, то у тебя скорее всего какие-то очень особые проекты.

Ф>Покажи потом что получилось.
Лень. В лучшем случае, если руки дойдут, я попробую позагонять фрагменыт кода в онлайн-компилятор какой-нибудь...

Ф>·>Какой необычный форматтер вы используете?
Ф>Лично я ничего не использую. В этом проекте я вообще код в FAR'е пишу, потому что так и не осилил настроить ни одну из сред разрабоки. Честное слово, крыл благим матом все IDE, которые пытался приспособить для этого проекта. А так — кто во что горазд.
Причём тут тогда форматтеры?

Ф>Как запретить автоматическое форматирование в VS (не VS Code) не знаю.
Для C++ в смысле? Не знаю точно. Но как минимум можноформаттить выбранные куски, это точно.

Здравствуйте, IT, Вы писали:

尿Ǥ푙>>Решения о примелемости или непримелемости — консенсусные по сути, форсировать их макросами, как по мне — перебор. Меня бы бесило, если формально валидный код не компилировался бы только потому, что кто решил, что так "неправильно".
IT>Этого всего и так полно уже сегодня. Теже сонары и им подобное. Только указание на свой косяк ты получаешь не после билда и в лучшем случае ввиде емэйла, а прямо сразу в коде.
Зачем этим должен заниматься компилятор? Обычно эти правила стилей или сонарна подхватываются в IDE и косяки подсвечиваются в процессе набора кода с возможностью тут же автоматически поправить или пометить как исключение.
Более того, сонарные правила могут быть очень хитрые, типа цикломатической сложности, неправильного использования многопоточки или запутанности зависимостей между модулями. Ты уверен, что всё сможешь покрыть макросами?

Здравствуйте, Silver_S, Вы писали:

S_S>P.S. А почему Kotlin не переводят на .Net? Куча второстепенных языков переведена. А для Kotlin технические нестыковки или идеологические (это не в интересах MS)?
Для котлина что-то было для запуска на дотнете. Но это малоинтересно — там нет никаких дотнетных фишек. Нет, скажем, нормальных генериков и value-типов.

Чего человечеству не хватает — так это отдельного Kotlin-like языка, основанного на CLR, а не на Java.
Джетбрейнс в этом никак не заинтересованы — у них работа поверх JVM была основополагающим решением.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Silver_S, Вы писали:

S_S>>P.S. А почему Kotlin не переводят на .Net? Куча второстепенных языков переведена. А для Kotlin технические нестыковки или идеологические (это не в интересах MS)?
S>Для котлина что-то было для запуска на дотнете. Но это малоинтересно — там нет никаких дотнетных фишек. Нет, скажем, нормальных генериков и value-типов.

S>Чего человечеству не хватает — так это отдельного Kotlin-like языка, основанного на CLR, а не на Java.
S>Джетбрейнс в этом никак не заинтересованы — у них работа поверх JVM была основополагающим решением.

А что там реально такого нужного, чего нет в C# ?
Я на котлине никогда не писал, только документацию бегло посмотрел, мне показалось синтаксически все более-менее тоже самое.
Больше всего мне понравилось, что можно точку с запятой не ставить
Но зато нет таких вещей как value типы, linq, компилятора типа roslyn с открытой моделью кода.

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>А что там реально такого нужного, чего нет в C# ?
В основном мне понравились их функциональные литералы. Собственно, по ссылке как раз был пример DSL на этих литералах, который безо всяких макросов позволяет описывать XML/HTML/Json структуры.
Это сразу несколько отсутствующих в C# языковых фич, использованных совместно.
ЕА>Но зато нет таких вещей как value типы, linq, компилятора типа roslyn с открытой моделью кода.
Value-типов у них нет, но это из-за платформы. Linq — это да, штука уникальная.

Здравствуйте, IT, Вы писали:

尿Ǥ푙>>malformed code — код, имеющий проблемы с форматированием: if(...), как ты говоришь. просто интересно, что тут можно сделать когда коммит уже в базе.

IT>Так в том то и дело, что такой макрос сделает твой код некомпилируемым. Можешь хоть обкоммититься.

Так можно и макрос поправить и закомитить :о))
Пулл реквесты и ревью есть или даже на столько интерпрайз, что все коммитят прям в main? ?

Мне подобное как раз в скором времени предстоит. Я хочу настроить .editorconfig и попробовать сделать так, чтобы сообщения от него влияли бы на успешность билда. Например, вместо Massage становились бы ворнингами или как-то ещё.

В крайнем случае можно юнит-тест (или как его ещё назвать?) сделать, который будет анализировать исходники по этому же .editorconfig и "вдруг что не так" падать. Программист поломал тест — пускай исправляет. Все ревью только после того, как билд собрался без ворнингов и все тесты зелёные. Мёрдж в main после ревью.

Здравствуйте, _FRED_, Вы писали:

IT>>Так в том то и дело, что такой макрос сделает твой код некомпилируемым. Можешь хоть обкоммититься.

_FR>Так можно и макрос поправить и закомитить :о))

Это уже деверсия, причём хорошо задокументированная. Проблема в том, что чел как бы совсем не против следовать общим правилам, он постоянно как бы забывает, т.к. как бы привык к как бы такому стилю. Постоянно его контролировать — это всё равно что постоянно контролировать рост бурьяна в огороде. Ты на это обращаешь внимание раз в месяц, а бурьян растёт постоянно. А макрос переводит такое недоразумение целиком и полностью в проблему чела. А если он подправит макрос, то как было сказано выше, это уже совсем другая статья, это саботаж и деверсия. За это можно и партбилет на стол положит бонуса лешиться.

Здравствуйте, Osaka, Вы писали:

S>>https://devblogs.microsoft.com/dotnet/check-out-csharp-12-preview/
O>Есть хоть что-нибудь полезное, или как обычно только новые средства ребусо-строения?

По ссылке аж три фичи добавили. Две полезных и одну бесполезную.

Primary constructors for non-record classes and structs
Using aliases for any type
Default values for lambda expression parameters

Самое полезное Using aliases for any type — давно такую хотел.

Осталось еще, как в Немерле, сделать подстановку типов не для одного файла, а для всего проекта. Очень удобно. В прочем, если Using aliases for any type можно будет вынести в глобал-юсинги, то и так сойдет. Никогда не понимал почему надо разные огромные типы всегда явно задавать. Бесило дико.

Здравствуйте, IT, Вы писали:

IT>А всё! ООП фичи давно закончились. Из ФП подтянули всё необходимое. Ну может только поддержку монад сделать (хотя...) вменяемую. А так осталось только переходить к реализации полноценного метапрограммирования с блекджеком макросами и шлюхами расширением синтаксиса.

На ФМ им потребовалось более 10 лет. Стало быть на МП нужно еще лет 10.

Пока что генераторы завезли.

Здравствуйте, Serginio1, Вы писали:

S> Есть SG и кстати Generic Math

Что есть? Можно по подробнее и со ссылками?

Ну и объяснение каким боком это к шаблоном С++.