Re[19]: Carbon
От: CreatorCray  
Дата: 11.04.24 09:48
Оценка:
Здравствуйте, so5team, Вы писали:

S>Тупо опечатался в выражении, но компилятор выдал предупреждение, что у operator+ для std::string возвращаемое значение nodiscard. И ошибка сразу стала очевидна: нужно было commonData += "A". Опечатка дурацкая, хз как допущенная, но незамеченная мной, однако замеченная компилятором. Что избавило от последующего поиска причины неожиданного поведения.


С таким подходом тебе надо его лепить на каждую фукнцию. Но это приводит к началу вот этого истЕрического цикла:
Когда то давно компиляторы ругались на неиспользуемое значение функции, и это всех раздражало. Потом они перестали ругаться на неиспользуемое значение функции и это стало раздражать других... Круг замкнулся.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[11]: Carbon
От: CreatorCray  
Дата: 11.04.24 09:48
Оценка: 2 (1) +1
Здравствуйте, Sinclair, Вы писали:

CC>>Я в курсе что далеко не все компиляторы делают так.

S>Ну, тогда покажите же мне тот волшебный компилятор, который так не делает.
Мне за всё время бешеный компилер попался ровно один раз, и то это был внутренний билд. Аффтарам ногами напихали в панамку всякого неприличного, они утёрлись и откатили свой шЫдевр.

CC>>А то я интелом пользуюсь давно и с удовольствием и никаких проблем с ним не имею.

S>Давайте, я вам покажу, как работает интел: https://godbolt.org/z/jxhxo56bT
А... icx...
ICX это уже не интел, это Clang/LLVM
ICC (AKA Classic) это настоящий интел.
Я этот ICX ещё когда они первый раз его выпустили попробовал и с матами вернулся назад на ICC.
Если будет мне надо clang с его тараканами то я возьму clang.

S> (value+1) < value;

У меня подобный логический трюк прямо сейчас используется в имплементации BigNumber для выяснения есть ли carry после сложения.
Компилируется ICC и правильно работает.

S>Попробуйте найти в бинаре следы "wow".

https://godbolt.org/z/j14heeWbM

7'827'319 = 0x77'6F77 = 1.09684101e-38f = "wow"


Пришлось чутка поменять:
#include <iostream>
#include <limits.h>

template<typename signed_integral> 
bool is_max(signed_integral value)
{
    signed_integral sum = value;
    sum++;
    return sum < value;
}

int main()
{
    std::cout << (is_max(INT_MAX)? "wow" : "oops" ) << std::endl;
    return 0;
}


.text:0000000000000000                 sub     rsp, 28h
.text:0000000000000004                 mov     rdx, 17FEh
.text:000000000000000E                 mov     ecx, 3
.text:0000000000000013                 call    __intel_new_feature_proc_init
.text:0000000000000018                 stmxcsr [rsp+28h+var_8]
.text:000000000000001D loc_1D:
.text:000000000000001D                 lea     rcx, std::basic_ostream<char,std::char_traits<char>> std::cout
.text:0000000000000024 loc_24:
.text:0000000000000024                 lea     rdx, `string'   ; "wow"
.text:000000000000002B loc_2B:
.text:000000000000002B                 or      [rsp+28h+var_8], 8040h
.text:0000000000000033                 ldmxcsr [rsp+28h+var_8]
.text:0000000000000038                 call    std::operator<<<std::char_traits<char>>(std::basic_ostream<char,std::char_traits<char>> &,char const *)
.text:000000000000003D                 mov     rcx, rax
.text:0000000000000040 loc_40:
.text:0000000000000040                 lea     rdx, std::endl(std::basic_ostream<char,std::char_traits<char>> &)
.text:0000000000000047 loc_47:
.text:0000000000000047                 call    std::basic_ostream<char,std::char_traits<char>>::operator<<(std::basic_ostream<char,std::char_traits<char>> & (*)(std::basic_ostream<char,std::char_traits<char>> &))
.text:000000000000004C                 xor     eax, eax
.text:000000000000004E                 add     rsp, 28h
.text:0000000000000052                 retn


Это реально мелочь в сравнении за что мы били ногами Clang чуваков.
Они тогда вообще преисполнились до такой степени что если их сраный компилер думает что где то в глубине функции может случиться null pointer dereference то он весь вызов этой функции заменял на вот такой пц:

    jmp some_label_in_a_galaxy_far_far_away        ; тут была функция

    ; где то на Татуине
...
    nop
    nop
    nop
    nop
some_label_in_a_galaxy_far_far_away:
    UD2
    nop
    nop
    nop
    nop
    ....


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

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

И эти мудаки ещё пытались доказывать что именно так правильно компилировать код, в котором есть потенциальная ошибка.
На вопрос: а какого хера компилер не скажет что там ошибка вместо того чтоб абсолютно молча нагенерить херни, они отвечали что если они сделают ошибку компиляции то их change сломает всем билд и потому его интеграторы никуда не пустят а им ачивку не дадут.
А то что они втихаря срут под коврик и потом где то эта подложенная мина жахает так, что только писюны по стенам и в результате их нововведений сие не debuggable вообще, в отличие от прежнего null pointer access где всё было как на ладони.
На это они только разводили ручонками и пучили глазки, теоретики сраные!

И это хорошо что у нас внутри сломалось и поднялась вонь. А был бы какой сторонний гнусь, который пилит "сообщество", так вообще всем посрать на чужие проблемы.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[4]: Carbon
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.04.24 09:55
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>это очень (и очень-очень) сильно упрощает парсинг исходного кода.

CC>Синтаксис должен быть выразительным в первую очередь для человека.

Это одно и то же — неоднозначности грамматики означают проблемы и у тех, кто изучает язык, и у тех, кто пишет инструмент для него.

S>>Т.е. грамматика с минимумом неоднозначностей заметно облегчает построение инфраструктуры вокруг языка.

CC>Это строится один раз, а код человеки пишут и читают постоянно.

Ага, это вы плагин инсталируете один раз. А пишется это непрерывно, а соответсвенно разработчикам инструмеентов нужно держать это в голове, что бы обновлять код на все изменения в компиляторах разных сортов.
Re[12]: Carbon
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.04.24 10:04
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Пришлось чутка поменять:

CC>
CC>template<typename signed_integral> 
CC>bool is_max(signed_integral value)
CC>{
CC>    signed_integral sum = value;
CC>    sum++;
CC>    return sum < value;
CC>}
CC>


Вы просто сломали ссылочную прозрачность. Собственно icc когда видит, что можно выбросить — выбрасывает. Это факт. А фиксить это нужно вручную, вот таким вот методом как вы показали.
Т.е. когда товарищи из интела сделают оптимизацию на один шаг дальше, ваша стройная система порушится, т.к. компилер точно так же выбросит не ту ветку
Re[20]: Carbon
От: so5team https://stiffstream.com
Дата: 11.04.24 10:13
Оценка:
Здравствуйте, CreatorCray, Вы писали:

S>>Тупо опечатался в выражении, но компилятор выдал предупреждение, что у operator+ для std::string возвращаемое значение nodiscard. И ошибка сразу стала очевидна: нужно было commonData += "A". Опечатка дурацкая, хз как допущенная, но незамеченная мной, однако замеченная компилятором. Что избавило от последующего поиска причины неожиданного поведения.


CC>С таким подходом тебе надо его лепить на каждую фукнцию.


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

И, походу, в C++ придется так и лепить nodiscard, т.к. сделать nodiscard по умолчанию -- это поломать совместимость. Поэтому C++ становится все более и более многословным.

CC>Когда то давно компиляторы ругались на неиспользуемое значение функции, и это всех раздражало.


Я вот что-то не помню, чтобы компиляторы C и C++ всегда ругались на потерянное значение возвращенное из функции.
Re[12]: Carbon
От: so5team https://stiffstream.com
Дата: 11.04.24 10:33
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Пришлось чутка поменять:

CC>
CC>template<typename signed_integral> 
CC>bool is_max(signed_integral value)
CC>{
CC>    signed_integral sum = value;
CC>    sum++;
CC>    return sum < value;
CC>}
CC>


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

int is_max_1(int v) {
  return (v+1) < v;
}

int is_max_2(int v) {
  int v2 = v;
  v2++;
  return v2 < v;
}

должны быть одним и тем же. Первая запись на уровне asm-а должна сводится ко второй. И оптимизироваться они должны были бы одинаково. Что, собственно, тот же GCC и делает.
Re[10]: Carbon
От: Alekzander  
Дата: 11.04.24 11:12
Оценка:
Здравствуйте, so5team, Вы писали:

A>>А в C++ исключения, если их неправильно приготовить, могут стать самостоятельным источником ошибок.

S>Интересно, а это как? Бросать int-ы или экземпляры собственных классов, не производных от std::exception?

Не только. Главная проблема, по-моему, в том, что языковые исключения и исключения платформы — не одно и то же. Но и опциональность всего и вся это тоже большая проблема. В итоге я пришёл к печальному выводу, что исключения без виртуальной машины с максимально жёсткой стандартизацией — солнечные лучи из огурцов.
Re[8]: Carbon
От: Alekzander  
Дата: 11.04.24 11:17
Оценка:
Здравствуйте, CreatorCray, Вы писали:

Ты велик и скромен, но я имел в виду не тебя.
Re[13]: Carbon
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.24 11:18
Оценка:
Здравствуйте, Pauel, Вы писали:
P>Вы просто сломали ссылочную прозрачность. Собственно icc когда видит, что можно выбросить — выбрасывает. Это факт. А фиксить это нужно вручную, вот таким вот методом как вы показали.
P>Т.е. когда товарищи из интела сделают оптимизацию на один шаг дальше, ваша стройная система порушится, т.к. компилер точно так же выбросит не ту ветку
Не, он сломал в другом месте. Там просто compile-time calculations сработали, в итоге в выхлоп попала "нужная" ветка (т.к. в реальности вычисления ведут себя именно так).
А если подать на вход is_max переменную, то такая наивная попытка обмануть компилятор не пройдёт: https://godbolt.org/z/8jz98GEaK
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Carbon
От: so5team https://stiffstream.com
Дата: 11.04.24 11:19
Оценка:
Здравствуйте, Alekzander, Вы писали:

A>Главная проблема, по-моему, в том, что языковые исключения и исключения платформы — не одно и то же.


Какой-такой платформы? Windows далеко не единственная платформа.

A>Но и опциональность всего и вся это тоже большая проблема.


Какая-то очередная загадка.
Re[12]: Carbon
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.24 11:19
Оценка: 3 (1)
Здравствуйте, CreatorCray, Вы писали:

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

CC>ICX это уже не интел, это Clang/LLVM
Это отговорки. Во-первых,

The Intel(R) C++ Compiler Classic (ICC) is deprecated and will be removed from product release in the second half of 2023. The Intel(R) oneAPI DPC++/C++ Compiler (ICX) is the recommended compiler moving forward. Please transition to use this compiler.

CC>ICC (AKA Classic) это настоящий интел.
Во-вторых, ICC (AKA Classic) работает ровно так же.

CC>У меня подобный логический трюк прямо сейчас используется в имплементации BigNumber для выяснения есть ли carry после сложения.

CC>Компилируется ICC и правильно работает.
Гы-гы. Ну, повезло, чо. Завтра в код добавится строчка-другая, и упс, звёзды встанут по-другому.

CC>Пришлось чутка поменять:

Ну, вот он, ключ к успеху. Сначала нужно вообще узнать, что этот код неправильно работает.
Затем нужно понять, что неправильно работает он именно из-за оптимизаций, которые меняют семантику.
Затем нужно шаманить, внося в код случайные изменения в надежде на то, что рано или поздно получится "ожидаемый" результат.

И всё равно, первый же залетевший дятел ломает всю цивилизацию:
https://godbolt.org/z/8jz98GEaK
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Carbon
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.04.24 12:49
Оценка:
Здравствуйте, CreatorCray, Вы писали:


CC>Они тогда вообще преисполнились до такой степени что если их сраный компилер думает что где то в глубине функции может случиться null pointer dereference то он весь вызов этой функции заменял на вот такой пц:

Ну, описанное вами — это прямой баг.
По спецификации, компилятор не имеет права вносить UB туда, где его не было.
В частности, для функции is_max компилятор не может делать "всё, что угодно", для любых значений параметра, кроме XXX_MAX.
Зато когда компилятор уже точно знает, что предстоящий UB неизбежен, он может начинать "что угодно" прямо сразу и немедленно.

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

CC>Как ты туда попал — никто не знает. Что с этой всей радостью делать — тоже.
Если это происходит в той ветке, где был null pointer dereference, то это — легальное поведение компилятора.
Если нет — то это баг, да.

CC>Вся функция и все её промежуточные результаты (включая логгинг) компилятором радостно похерены, ибо ну он то знает что всё это тлен а потому чо это всё париться и выполнять, и потому вообще хз что произошло.

Да, совершенно верно. По спецификации, вот в таком коде компилятор совершенно не обязан хоть что-либо куда-либо выводить:
void fail(int* ptr)
{
   if (ptr == null)
   {
     cout << "I'm going to dereference a null";
     cout << *ptr;
   }
}

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

CC>И это хорошо что у нас внутри сломалось и поднялась вонь. А был бы какой сторонний гнусь, который пилит "сообщество", так вообще всем посрать на чужие проблемы.

Я считаю, что виновата спека. Незачем изобретать UB там, где он не нужен. Вместо него нужен implementation-defined.
То есть — придумал поведение, специфицировал его, и будь любезен придерживаться.
Чтобы все эти фантазии разработчиков можно было обложить #ifdef-ами, и писать единообразно работающий код.
Вот, скажем, у вас пока что не получилось починить функцию is_max, даже на вашем любимом компиляторе
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[7]: Carbon
От: kov_serg Россия  
Дата: 11.04.24 17:30
Оценка:
Здравствуйте, CreatorCray, Вы писали:

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


_>>В виртуально машине можно отслеживать изменение памяти, кто где и сколько

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

_>> хранить мета информацию о участках памяти и ветках выполняемого кода

CC>Нафига?

_>> вызывать разные реализации одних и тех же функций и сравнивать результаты их выполнения

CC>Нафига для этого VM?
CC>Профилирование под виртуалкой похерит измеряемые значения, намеряешь совсем не то, что будет без виртуалки.
Вы не поняли, можно сравнивать результаты выполнения одних и тех же функций для проверки разных гипотез, применяемых для оптимизации.
Например для выявления явной фигни, которую генерит компилятор в случае UB, poison и т.п.

_>> выявляя отклонения, следить за инвариантами, собирать статистику, ставить хуки и еще много больных сценариев.

CC>Это всё называется инструментация
Нет инструментация, это на реальном железе. Тут можно на модели железа, делать разные модели out-of-order построителней графов исполнения и анализа их загруженности (утилизации).

_>> Короче сплошной "позитив" для отладки и анализа кода.

CC>Зачем для этого VM?
Это не для VM, а для анализа кода. Вот зачем вам godbolt, вот примерно за этим же для анализа чужого кода, на наличие UB, фазинга и отслеживания исполнения кода.
Тут не про скорость, а про гибкость анализа, и возможность добавления любых дополнительных фич, которых нет в железе.
Re[2]: Carbon
От: m2user  
Дата: 11.04.24 19:38
Оценка:
T>Библиотеки пишут на чем попало, но в основном C.

Для библиотек какие-нибудь более современные альтернативы C имеются в наличии, кроме Go lang?
Re[12]: Carbon
От: Alekzander  
Дата: 11.04.24 20:41
Оценка:
Здравствуйте, so5team, Вы писали:

A>>Главная проблема, по-моему, в том, что языковые исключения и исключения платформы — не одно и то же.

S>Какой-такой платформы? Windows далеко не единственная платформа.

Так и на C# можно писать не только под Windows. Ну и что? Если приложение исполняется всё-таки под Windows и вылетит SEH, он будет обёрнут в SEHException. (Хотя там есть нюансы: в какой-то момент была выделена группа CSE (Corrupted State Exceptions), для которой нужно явно обозначить своё желание в виде, например, атрибута).

Виртуальная машина тем и хороша, что позволяет всё приводить к единому знаменателю.

A>>Но и опциональность всего и вся это тоже большая проблема.

S>Какая-то очередная загадка.

Ты же сам привёл примеры, а теперь, видите ли, "загадка".
Re[3]: Carbon
От: pagid_ Россия  
Дата: 12.04.24 01:08
Оценка:
Здравствуйте, m2user, Вы писали:

M>Для библиотек какие-нибудь более современные альтернативы C имеются в наличии, кроме Go lang?

Да вроде как Go совсем не годится для библиотек, если они не для использования в самом же Go.
Re[3]: Carbon
От: Разраб  
Дата: 12.04.24 01:18
Оценка:
Здравствуйте, m2user, Вы писали:

T>>Библиотеки пишут на чем попало, но в основном C.


M>Для библиотек какие-нибудь более современные альтернативы C имеются в наличии, кроме Go lang?

zig
☭ ✊ В мире нет ничего, кроме движущейся материи.
Re[13]: Carbon
От: so5team https://stiffstream.com
Дата: 12.04.24 04:12
Оценка:
Здравствуйте, Alekzander, Вы писали:

A>Виртуальная машина тем и хороша, что позволяет всё приводить к единому знаменателю.


Знаменатель, который получился у Java вам, вроде бы, не понравился. Хотя на Java таки можно было написать GUI приложение, которое работало бы и на X-ах, и на Windows.

A>>>Но и опциональность всего и вся это тоже большая проблема.

S>>Какая-то очередная загадка.

A>Ты же сам привёл примеры, а теперь, видите ли, "загадка".


У меня как-то не увязывается возможность бросить int с "опциональностью всего и вся".
Re[3]: Carbon
От: rudzuk  
Дата: 12.04.24 07:14
Оценка:
Здравствуйте, m2user, Вы писали:

m> Для библиотек какие-нибудь более современные альтернативы C имеются в наличии, кроме Go lang?


Delphi, Free Pascal
avalon/3.0.2
Re[14]: Carbon
От: CreatorCray  
Дата: 12.04.24 07:16
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>А если подать на вход is_max переменную, то такая наивная попытка обмануть компилятор не пройдёт: https://godbolt.org/z/8jz98GEaK

Твой пример всё ещё компиляется ICC, который я выставил для демонстрации разницы.
Переключи обратно на ICX и будет "oops" что с переменной что без неё.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.