А вот на самом деле, тут Windows права. Ибо стандарт ISO C11 (Annex K) резервирует функции типа strcat_s, strcpy_s и strcmp_s . Строго следуя стандарту языка языка С, программы не имеют права определять собственные функции с этими именами. В libc для Linux по умолчанию эти функции скрыты. Чтобы gcc с libc их увидел, надо писать #define __STDC_WANT_LIB_EXT1__ 1. В Windows эти функции были давно, до С11, как нестандартные расширения.
И кстати, заявлено, что собирается любым C99/C11 компилятором. Но это не так, например: gcc 16.1.0 на Windows падает с ошибкой, ибо strcat_s это нестандартная функция из состава стандартной C библиотеки под Windows, а перегрузки функций в C нет. Проект, однако, собирается на g++ под Windows, но это компилятор языка C++, а не C.
Памяти много, 4+ GiB не жалко. Распарсить какой-нибудь большой датасет там: раз памяти много, то чтобы быстрее обработать можно загрузить сразу все. Стандартный std::string может содержать '\0' в середине строки. ReadFile из WinAPI или std::fread из <cstdio> спокойно прочитают контент с символом '\0'. WriteFile из WinAPI или std::fwrite из <cstdio> спокойно запишут контент с символом '\0' в середине. Правда, следует проявлять осторожность при подаче результата от .data() в функцию, которая ожидает нуль-терминированную строку типа char*.
Вот кстати не понимаю тех, кто пишет, что школа необходима для социализации. На мой взгляд, для социализации достаточна какая-нибудь спортивная секция (или там художественная или музыкальная школа). Только здесь конечно вопрос в том, как сейчас набирают в спортивные секции: в моем детстве туда хотели набирать только "перспективных".
Если у ребенка в 13-14 лет появится мечта выиграть олимпиаду топового уровня, и он до этого олимпиадами не занимался, то это уже, как правило, слишком поздно: чтобы выиграть олимпиаду топового уровня, нужно начинать заниматься значительно раньше.
Так WebView2 доступен много где: WinUI 3/WinForms/WPF. Почему бы не делать на WPF, там и на C++/CLI можно, и распространение стандартным образом. В WinUI 3 C++ более-менее стандартный, или какой-то нестандартный диалект типа C++/CLI?
1) Это не обозначение, которое очевидно. Его можно понимать как последовательность комплексных чисел. Но некорректность применения готовых формул логарифма для вычисленияэто не снимает. Множестваиразличны. Как определены операции для чисел видане дано. 3) А в статье вы так пишете, не различаяи. 6) Это как раз точные вычисления. 4.0000000000025, 4.0000000000026 и 4 это принципиально разные вещественные числа. Как они получены неважно. С точки зрения определения действительного числа они различны. Ознакомьтесь вначале с определением вещественного числа в математике. У вас приближенные вычисления, а не точные. 8) При том, что это некорректно. Согласно вашему примеру, читатель может подумать, что целая часть числа 1.3 это 2, чтобы целая часть определалась согласованным образом для всех действительных чисел.
1) Какое определение? Редкие источники где это (именно ветвь числа, не ветвь функции) встречается не приведены. Судя по контексту, а. Взятие логарифма определено для, а не. 3) Вы утверждаете, что f и f(z) это одно и тоже, где
def f(x):
return ... #какое-то выражение
5) До вопрос в отсутствии доказательств, то, что приведено -- это не доказательство. Вы вот видели как доказательства оформляются в качественных книгах или статьях? 6) Могут! Я ранее приводил:(главное значение). Действительное число в математике (элемент множества), и типы float/double/long double различаются. 8) Взятие целой части в работе приведено некорректно. 9) Но не понимаете, если там придумываете ветвь, которой там нет.
-- это стандартная запись комплексного числа, так везде пишут. "принимается в любой форме" -- это означает, что принимается работа, оформленная в любом редакторе, но оформленная нормально и качественно. Отдельно стоит упомянуть и про использование косой черты вместо дроби в выносных формулах: такое тоже является дурным тоном.
1) Ветвь компплексного числа не определяется. Ветвь определяется у многозначной аналитической функции. 3)иэто разные понятия. 5) "The numerical experiments showed, in full agreement with the theory, that either expression may be used, yielding the corresponding values" -- где здесь доказательство? Где показано что из каких-то там формул вытекают (6) и (7)? 6) Промежуточные записи можно в приложении писать. И вопрос не в промежуточных записать, а в отсутствии точных вычислений. 8) Вы пишете "It is only necessary to remember that taking the integer part of the number –4.3 yields –4, not –5." Где здесь округление до ближайшего целого? Взятие целой части происходит не так. Округление до ближайшего целого -- это не взятие целой части. 9) Учите просто определения:,,...
Вы вот книги и/или статьи по математике читали? Там нигде не пишут c+d*i вместо, потому что c+d*i неудобно читать. Более того, в математике знак * зарезервирован для свертки. В LaTeX все формулы (даже простые) пишут в специальном математическом режиме. Это стандарт. Более того, вы в прошлом посте писали про желание опубликоваться в бумажном математическом журнале. Номера страниц нужны, чтобы легче ссылаться было.
1) Что такое? Как оно связано с? Определения этого не дано. 3) В том что функция и значение функции при определенном аргументе это разные понятия. 4) В математике так не делают. Чем более общепринятые обозначения, тем лучше. 5) Примеры не могут считаться доказательства, поскольку это частные случаи, и они показывают истинность лишь в частном случае. Доказательства в общем виде (для любых чисел) не дано. 6) Должно быть вот так:(главное значение), а не так: (главное значение). 7) Где доказательство? 8) Есть определение целой части числа. Если вам не подходит стандартное, то вам следует привести то, что вы понимаете под округлением в настоящей работе. Этого в статье не дано. 9) В комплексной области также. Вас с таким оформлением могут отклонить на сервисах публикации препринтов.
P.S. Советовал бы автору вначале ознакомиться с комплексным анализом основательно. Для это могу порекомендовать литературу: 1) Лаврентьев М. А., Шабат Б. В. Методы теории функций комплексного переменного. М.: «Наука», 1973. 2) Зверович Э. И. Вещественный и комплексный анализ. Ч. 6: Теория аналитических функций комплексного переменного. Минск: Выш. шк., 2008.
В силу низкого качества оформления работы ее читать почти невозможно. Замечания по оформлению: 1) Если статья в Word, то все формулы надо набирать в MathType или во встроенном редакторе формул (издательства, которые принимают статьи в Word, требуют набо формул строго в MathType), а не вот это все в духе 'c+d*i'. 2) Нет номеров страниц.
Замечание по сути работы: 1) Не определена величина; -ую ветвь нельзя считать по формулам из [1], поскольку эти формулы определены для, а не. 2) Введенное автором определение главного значения аргумента (которое автор называет аргументом) никуда не годится: ии при этомкак и. Т. е. если модуль числа равен единице, а агрумент нулю, то нельзя однозначно сказать, какое это число. 3) Натуральный логарифм модуля и аргумент это функции от комплексного числа, т. е. в формулах писатьи, а неи, где. Тоже самое относится к модулю и главному значению аргумента комплексного числа. 4) Странные обозначения автора затрудняют чтение работы. Зачем понадобилось обозначение, если для действительных чисел, по словам автора все хорошо (обычного было бы вполне достаточно)? 5) "Практика показала (в полном соответствии с теорией)", "оба варианта дают одинаковый результат" -- утверждения не доказаны. 6) Автор рассматривая извлечение корня, пишет что простейший подход заключается в том, что извлечение корня степени эквивалентно возведению числа в степень. Это не простейший подход, а определение корня в комплексном анализе. 7)-- это число вещественное, но почему-то считается целым по смыслу. Доказательство, конечно, автор не приводит. Аналогичное верно про. 6) Вычисления в статьях по комплексному анализу должны быть точными, тем более что полученные формулы это позволяют. 7) Нет сравнения с известными подходами. В чем конкретно предложенноелучше стандартного, гденомер ветви (в данном случае надо выбрать-- но там, где надо выбрать ветвь, об этом явно говорят) ? 8) Целая часть числа это. Почему так: такое определение. 9) Тригонометрические и гиперболические функции не имеют ветви вообще, поскольку они определены через экспоненту, которая также не имеет ветви и определяется через ряд Маклорена.
Публиковать такую работу я бы не советовал любому журналу.
Я считаю, что нужны. Ибо result.unwrap() паникует, где result это Result<T, E>, если result содержит ошибку. Лучше, чтобы в этом случае бросалось исключение. Ибо панику можно обработать только глобально, а исключение -- локально.
Вообще говоря, да. В частности, если у вас есть библиотека без исходного кода, где есть только .lib/.a + .h.
Еще можно привести вот такой пример: [[nodiscard]] std::expected<std::string, Utf8DecodeError> utf8_to_cp1251(std::u8string_view sv). Мы получаем либо корректную строку в кодировке Windows-1251, или экземпляр класса Utf8DecodeError, который содержит в качестве одно из полей строку std::string -- то, что получилось раскодировать (например, где все непредставимые символы заменены на '?' или строку до первого непредставимого символа -- дизаин здесь может быть разным). При такой реализации составить список всех std::unexpected невозможно.
Заставить при наличии [[nodiscard]] обрабатывать КАЖДЫЙ std::unexpected? Нет.
Это невозможно в силу определения класса std::expected. Как обработать каждый std::expected<T, E>, где E идейно бесконечен, например, строка или вектор (как бы в силу ограничения возможного максимального размера памяти, E, на практике, конечен)?
Странно, вот они привели пример, указанный вами как пример того, что должно быть, но при этом пишут в п. 3.6:
The current wording in [expr.pre] paragraph 4 is clear that any expression that produces NaN has undefined behavior. NaN is neither mathematically defined nor is it defined to be in the range of representable values (even intuitively, it would have to be outside any range).
However, the standard library doesn't seem to care about this, considering that numeric_limits<T>::quiet_NaN and numeric_limits<T>::signaling_NaN have been marked constexpr.
И как такое понимать? Отсюда непонятно, что они, согласно 3.6, считают верным поведением. И только вот пример это поясняет.
Если готовы побороться за payload в nan, то с радостью помогу вам. Но вам придётся проработать основные моменты и написать proposal. Подозреваю что там будут трудности, кажется некоторые платформы не позовляют делать -nan, а что у них с payload для nan не представляю.
Есть std::numeric_limits<T>::is_iec559 -- если он истинный, то nan будет. Я вот также удивлен, что std::to_string не constexpr, хотя сейчас конструкторы в std::string и operator+ для std::string являются constexpr.
Каноничный способ это std::nan из <cmath>, но он не constexpr. UB-реализации (которые тем не менее работают) через union и reinterpret_cast тоже не constexpr. Использование memcpy тоже не constexpr. В g++ для этого есть __builtin_nan, который, по сути, constexpr (но не всегда). Надо признать, что сейчас адекватного способа для этого нет. Более того, __builtin_nan и std::nan принимают на вход строку, а std::to_string (и другие функции преобразования) не constexpr.
Но, предлагается унифицированное поведение, которое ухудшает текущее поведение. Из прочитанного предложения по ссылке предлагается сделать любое выражение constexpr double d = expression невалидным, если expression возвращает неопределенность. Это также относиться также к std::numeric_limits<T>::quiet_NaN() и подобным, что они constexpr сейчас, но предлагается сделать не constexpr.
Теперь если в процессе вычисления на этапе компилирования получится +/-Inf или +/-NaN то будет ошибка компиляции, что положительно влияет на надёжность вычислений.
Так и ЕГЭ для поступления в некоторые вузы это тоже "Эверест", что люди с 305 баллами за ЕГЭ + индивидуальные достижения в пролете (по словам некоторых людей, из-за олимпиадников) не имеют шансов на поступление. А там и русский надо сдавать, и кое где на средний балл аттестата смотрят. Да я не скажу, что олимпиады это про преодоления себя, сам ими занимался. Это больше про "ботать", причем ботать, по моему мнению, надо начинать заранее: в случае информатики это с 6 класса (если позже начать, то будет сложно) и надо сразу ботать C++, а не Pascal и/или Python (Python медленный, а у Pascal бедная стандартная библиотека -- можно, конечно, ботать на Pascal, но в C++ STL и __int128 дает существенное преимущество).
А вот на самом деле, тут Windows права. Ибо стандарт ISO C11 (Annex K) резервирует функции типа
strcat_s,strcpy_sиstrcmp_s. Строго следуя стандарту языка языка С, программы не имеют права определять собственные функции с этими именами. В libc для Linux по умолчанию эти функции скрыты. Чтобы gcc с libc их увидел, надо писать#define __STDC_WANT_LIB_EXT1__ 1. В Windows эти функции были давно, до С11, как нестандартные расширения.И кстати, заявлено, что собирается любым C99/C11 компилятором. Но это не так, например: gcc 16.1.0 на Windows падает с ошибкой, ибо strcat_s это нестандартная функция из состава стандартной C библиотеки под Windows, а перегрузки функций в C нет. Проект, однако, собирается на g++ под Windows, но это компилятор языка C++, а не C.
Памяти много, 4+ GiB не жалко. Распарсить какой-нибудь большой датасет там: раз памяти много, то чтобы быстрее обработать можно загрузить сразу все. Стандартный std::string может содержать '\0' в середине строки. ReadFile из WinAPI или std::fread из <cstdio> спокойно прочитают контент с символом '\0'. WriteFile из WinAPI или std::fwrite из <cstdio> спокойно запишут контент с символом '\0' в середине. Правда, следует проявлять осторожность при подаче результата от .data() в функцию, которая ожидает нуль-терминированную строку типа char*.
Ну мне понадобиться. Прочитать > 4 GiB файл полностью.
А что по OrderBy? Было бы интересно увидеть для OrderBy и его сравнение с Sort.
Вот кстати не понимаю тех, кто пишет, что школа необходима для социализации. На мой взгляд, для социализации достаточна какая-нибудь спортивная секция (или там художественная или музыкальная школа). Только здесь конечно вопрос в том, как сейчас набирают в спортивные секции: в моем детстве туда хотели набирать только "перспективных".
Если у ребенка в 13-14 лет появится мечта выиграть олимпиаду топового уровня, и он до этого олимпиадами не занимался, то это уже, как правило, слишком поздно: чтобы выиграть олимпиаду топового уровня, нужно начинать заниматься значительно раньше.
Так WebView2 доступен много где: WinUI 3/WinForms/WPF. Почему бы не делать на WPF, там и на C++/CLI можно, и распространение стандартным образом. В WinUI 3 C++ более-менее стандартный, или какой-то нестандартный диалект типа C++/CLI?
1) Это не обозначение, которое очевидно. Его можно понимать как последовательность комплексных чисел. Но некорректность применения готовых формул логарифма для вычисления
это не снимает. Множества
и
различны. Как определены операции для чисел вида
не дано.
и
.
. Как они получены неважно. С точки зрения определения действительного числа они различны. Ознакомьтесь вначале с определением вещественного числа в математике. У вас приближенные вычисления, а не точные.
3) А в статье вы так пишете, не различая
6) Это как раз точные вычисления. 4.0000000000025, 4.0000000000026 и 4 это принципиально разные вещественные числа
8) При том, что это некорректно. Согласно вашему примеру, читатель может подумать, что целая часть числа 1.3 это 2, чтобы целая часть определалась согласованным образом для всех действительных чисел.
1) Какое определение
? Редкие источники где это (именно ветвь числа, не ветвь функции) встречается не приведены. Судя по контексту
, а
. Взятие логарифма определено для
, а не
.
3) Вы утверждаете, что
fиf(z)это одно и тоже, где5) До вопрос в отсутствии доказательств, то, что приведено -- это не доказательство. Вы вот видели как доказательства оформляются в качественных книгах или статьях?
(главное значение). Действительное число в математике (элемент множества
), и типы float/double/long double различаются.
6) Могут! Я ранее приводил:
8) Взятие целой части в работе приведено некорректно.
9) Но не понимаете, если там придумываете ветвь, которой там нет.
1) Ветвь компплексного числа не определяется. Ветвь определяется у многозначной аналитической функции. 3)
и
это разные понятия. 5) "The numerical experiments showed, in full agreement with the theory, that either expression may be used, yielding the corresponding values" -- где здесь доказательство? Где показано что из каких-то там формул вытекают (6) и (7)? 6) Промежуточные записи можно в приложении писать. И вопрос не в промежуточных записать, а в отсутствии точных вычислений. 8) Вы пишете "It is only necessary to remember that taking the integer part of the number –4.3 yields –4, not –5." Где здесь округление до ближайшего целого? Взятие целой части происходит не так. Округление до ближайшего целого -- это не взятие целой части. 9) Учите просто определения:
,
,
...
Вы вот книги и/или статьи по математике читали? Там нигде не пишут c+d*i вместо
, потому что c+d*i неудобно читать. Более того, в математике знак * зарезервирован для свертки. В LaTeX все формулы (даже простые) пишут в специальном математическом режиме. Это стандарт. Более того, вы в прошлом посте писали про желание опубликоваться в бумажном математическом журнале. Номера страниц нужны, чтобы легче ссылаться было.
? Как оно связано с
? Определения этого не дано. 
(главное значение), а не так: 
(главное значение).
1) Что такое
3) В том что функция и значение функции при определенном аргументе это разные понятия.
4) В математике так не делают. Чем более общепринятые обозначения, тем лучше.
5) Примеры не могут считаться доказательства, поскольку это частные случаи, и они показывают истинность лишь в частном случае. Доказательства в общем виде (для любых чисел) не дано.
6) Должно быть вот так:
7) Где доказательство?
8) Есть определение целой части числа. Если вам не подходит стандартное, то вам следует привести то, что вы понимаете под округлением в настоящей работе. Этого в статье не дано.
9) В комплексной области также.
Вас с таким оформлением могут отклонить на сервисах публикации препринтов.
P.S. Советовал бы автору вначале ознакомиться с комплексным анализом основательно. Для это могу порекомендовать литературу: 1) Лаврентьев М. А., Шабат Б. В. Методы теории функций комплексного переменного. М.: «Наука», 1973. 2) Зверович Э. И. Вещественный и комплексный анализ. Ч. 6: Теория аналитических функций комплексного переменного. Минск: Выш. шк., 2008.
В силу низкого качества оформления работы ее читать почти невозможно. Замечания по оформлению:
1) Если статья в Word, то все формулы надо набирать в MathType или во встроенном редакторе формул (издательства, которые принимают статьи в Word, требуют набо формул строго в MathType), а не вот это все в духе 'c+d*i'.
2) Нет номеров страниц.
Замечание по сути работы:
;
-ую ветвь 
нельзя считать по формулам из [1], поскольку эти формулы определены для
, а не
. 
и
и при этом
как и
. Т. е. если модуль числа равен единице, а агрумент нулю, то нельзя однозначно сказать, какое это число.
и
, а не
и
, где
. Тоже самое относится к модулю и главному значению аргумента комплексного числа. 
, если для действительных чисел, по словам автора все хорошо (обычного
было бы вполне достаточно)?
эквивалентно возведению числа в степень
. Это не простейший подход, а определение корня в комплексном анализе.
-- это число вещественное, но почему-то считается целым по смыслу. Доказательство, конечно, автор не приводит. Аналогичное верно про
. 
лучше стандартного
, где
номер ветви (в данном случае надо выбрать
-- но там, где надо выбрать ветвь, об этом явно говорят) ? 
это
. Почему так: такое определение.
1) Не определена величина
2) Введенное автором определение главного значения аргумента (которое автор называет аргументом) никуда не годится:
3) Натуральный логарифм модуля и аргумент это функции от комплексного числа, т. е. в формулах писать
4) Странные обозначения автора затрудняют чтение работы. Зачем понадобилось обозначение
5) "Практика показала (в полном соответствии с теорией)", "оба варианта дают одинаковый результат" -- утверждения не доказаны.
6) Автор рассматривая извлечение корня, пишет что простейший подход заключается в том, что извлечение корня степени
7)
6) Вычисления в статьях по комплексному анализу должны быть точными, тем более что полученные формулы это позволяют.
7) Нет сравнения с известными подходами. В чем конкретно предложенное
8) Целая часть числа
9) Тригонометрические и гиперболические функции не имеют ветви вообще, поскольку они определены через экспоненту, которая также не имеет ветви и определяется через ряд Маклорена.
Публиковать такую работу я бы не советовал любому журналу.
Я считаю, что нужны. Ибо
result.unwrap()паникует, где result это Result<T, E>, если result содержит ошибку. Лучше, чтобы в этом случае бросалось исключение. Ибо панику можно обработать только глобально, а исключение -- локально.Вообще говоря, да. В частности, если у вас есть библиотека без исходного кода, где есть только .lib/.a + .h.
Еще можно привести вот такой пример: [[nodiscard]] std::expected<std::string, Utf8DecodeError> utf8_to_cp1251(std::u8string_view sv). Мы получаем либо корректную строку в кодировке Windows-1251, или экземпляр класса Utf8DecodeError, который содержит в качестве одно из полей строку std::string -- то, что получилось раскодировать (например, где все непредставимые символы заменены на '?' или строку до первого непредставимого символа -- дизаин здесь может быть разным). При такой реализации составить список всех std::unexpected невозможно.
Это невозможно в силу определения класса std::expected. Как обработать каждый std::expected<T, E>, где E идейно бесконечен, например, строка или вектор (как бы в силу ограничения возможного максимального размера памяти, E, на практике, конечен)?
Странно, вот они привели пример, указанный вами как пример того, что должно быть, но при этом пишут в п. 3.6:
И как такое понимать? Отсюда непонятно, что они, согласно 3.6, считают верным поведением. И только вот пример это поясняет.
Есть std::numeric_limits<T>::is_iec559 -- если он истинный, то nan будет. Я вот также удивлен, что std::to_string не constexpr, хотя сейчас конструкторы в std::string и operator+ для std::string являются constexpr.
Каноничный способ это std::nan из <cmath>, но он не constexpr. UB-реализации (которые тем не менее работают) через union и reinterpret_cast тоже не constexpr. Использование memcpy тоже не constexpr. В g++ для этого есть __builtin_nan, который, по сути, constexpr (но не всегда). Надо признать, что сейчас адекватного способа для этого нет. Более того, __builtin_nan и std::nan принимают на вход строку, а std::to_string (и другие функции преобразования) не constexpr.
Но, предлагается унифицированное поведение, которое ухудшает текущее поведение. Из прочитанного предложения по ссылке предлагается сделать любое выражение constexpr double d = expression невалидным, если expression возвращает неопределенность. Это также относиться также к std::numeric_limits<T>::quiet_NaN() и подобным, что они constexpr сейчас, но предлагается сделать не constexpr.
А если нужен NaN с нагрузкой?
Так и ЕГЭ для поступления в некоторые вузы это тоже "Эверест", что люди с 305 баллами за ЕГЭ + индивидуальные достижения в пролете (по словам некоторых людей, из-за олимпиадников) не имеют шансов на поступление. А там и русский надо сдавать, и кое где на средний балл аттестата смотрят. Да я не скажу, что олимпиады это про преодоления себя, сам ими занимался. Это больше про "ботать", причем ботать, по моему мнению, надо начинать заранее: в случае информатики это с 6 класса (если позже начать, то будет сложно) и надо сразу ботать C++, а не Pascal и/или Python (Python медленный, а у Pascal бедная стандартная библиотека -- можно, конечно, ботать на Pascal, но в C++ STL и __int128 дает существенное преимущество).