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

Что-то такое как я понмаю в rust сделать нельзя: template <int WIDTH> class ap_int { ino64_t val; public: template <int OTHER_WIDTH> auto operator* (ap_int<OTHER_WIDTH> other) { ap_int<OTHER_WIDTH+WIDTH> res; res.val = val + other.val; } };

Что-то такое как я понмаю в rust сделать нельзя: template <int WIDTH> class ap_int { ino64_t val; public: template <int OTHER_WIDTH> auto operator* (ap_int<OTHER_WIDTH> other) { ap_int<OTHER_WIDTH+WIDTH> res; res.val = val + other.val; } };

Non-type template arguments там действительно нет, но говорить из-за этого что там нет шаблонов как минимум странно.

Отсутствие variadic генериков намного более сильное ограничение как по мне :)

Ну т.е. в плане compile-time вычислений C++ пока что сильнее

В расте мне пришлось бы сделать отдельное поле для хранения ширины

Т.е. в данном случае C++ в два раза эффективнее по памяти

Ну т.е. в плане compile-time вычислений C++ пока что сильнее

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

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

Второе как я понмаю попытаются пофиксить частично в c++20

И первое возможно тоже

1. Модули

2. Концепты

Основной минус C++ это арахичный синтаксис из Си. Но с другой стороны совместимость с Си это и плюс

Второе как я понмаю попытаются пофиксить частично в c++20

Частично, но будет все равно не совсем то. Раст гарантирует что если подстановка удовлетворяет требованиям то все скомпилируется, в C++ такой гарантии не будет. Страуструп говорил на кейноуте CppCon что эксперименты ставились по строгой гарантии, но для обратной совместимости ее не будет.

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

В общем больше всего в C++ бесит легаси и UB, остальное не так больно

Надеюсь статические lifetime и bounds чекеры со временем снизят боль от UB

Непонятно почему в концептах нет "implements" или чего-то похожего

Непонятно почему в концептах нет "implements" или чего-то похожего

А что вы подразумеваете

хотя наверное получилось бы монструозно: class MyType implements Hashable, Swappable...

ну чтобы при создании класса сразу указать какие концепты он реализовывает

хотя наверное получилось бы монструозно: class MyType implements Hashable, Swappable...

это пишется статик ассертом

В общем больше всего в C++ бесит легаси и UB, остальное не так больно

Ну вот, в расте нет ни того ни другого :) UB надо санитайзерами лечить, остальное полумеры.

это пишется статик ассертом

да, можно. Но тогда нужно IDE научить генерить методы по static ассертам

да, можно. Но тогда нужно IDE научить генерить методы по static ассертам

непонятно, концепты же не связаны с методами класса

ну в смысле функции

члены класса и свободные

т.е. если написано static_assert(Hashable) IDE должна автоматически генерить специализацию

наверное можно сделать

Не получится, там произвольные выражения могут быть в требованиях.

т.е. проверить можно, а удовлетворить нельзя?

NP полная проблема

в google coding guidelines вроде написано, не используйте преобразования типов из C++, они все говно ) используйте сишные

Гугл кодстайл полное говно

т.е. проверить можно, а удовлетворить нельзя?

инклуды находить научиться надобно

Гугл кодстайл полное говно

использовал его тогда, когда это ещё не стало мейнстримом )

сейчас чот посмотрел и там всё поменяли

использовал его тогда, когда это ещё не стало мейнстримом )

В 90-х даже в стд говнл пихали, смотреть на стек ввода вывода

Ну гугл кодстайл убил эксепшоны в C++, за это спасибо

в 90-х по-моему не было его

Ну гугл кодстайл убил эксепшоны в C++, за это спасибо

ну это многие понимали что не надо их юзать

Но там было явно написано что нельзя. Плюс авторитет Гугла

У гугла есть какойто авторитет в сообществе си++ чтоль?

Они же го изобрели ваще

вообще как бэ в мире

Они же го изобрели ваще

это недоразумение уже после получилось

у себя кстати они его используют вместо bash / perl / python

Хотя Саттер сейчас вроде пытается починить эксепшоны : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf

это недоразумение уже после получилось

Это продолжение идеологии отупления программистов ака гугл кодстайл

с другой стороны хорошо когда твой код тупой

приятно читать )

Хотя Саттер сейчас вроде пытается починить эксепшоны : http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r1.pdf

Исключения починить нельзя

В чем проблема? Опять кто-то решил что выброс это легитимный результат?

Исключения починить нельзя

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

Зачем их чинить

Зачем их чинить

Чтобы можно их было юзать. Сейчас по Гугл стайлу все компилируют с -fno-exceptions

Чтобы можно их было юзать. Сейчас по Гугл стайлу все компилируют с -fno-exceptions

Класс, чиним чтобы работало после того как специально отключили

Аутизм

Саттер не для этого делает это есличто

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

Не важно, какой дизайн, expected

On platforms that use the [Itanium ABI], exceptions are required to be allocated on the heap (modulo potential optimizations that are not actually implemented today, such as the proposed LLVM optimization in [Glisse 2013]). Heap allocation requires unpredictable time, even on allocators that avoid global synchronization in the memory allocator

кто-то ещё использует Itanium?

кто-то ещё использует Itanium?

У меня на работе есть один живой вроде

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

core i5 какой-нибудь будет быстрее

Это же надо мигрировать бережно настроенную 15 лет назад систему со всеми самопальными сервисами, и всеми БД.

кто-то ещё использует Itanium?

Это просто историческое название abi. Сейчас оно используется на всех архитектурах

да ладно?

Itanium очень отличался же архитектурно от x86 и всяких там RISC

Ну да, и clang и gcc используют itanium abi под x86

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

ну, будут концепты и модули, ведь уже вмержили первые и будут мержить два варианта модулей и мержить их в стд

Ну да, и clang и gcc используют itanium abi под x86

хм

хотя наверное получилось бы монструозно: class MyType implements Hashable, Swappable...

кхм, кхм, жава, кхм

Не важно, какой дизайн, expected

Expected такой же ресурсоемкий как эксепшон. Если я правильно понимаю.

у себя кстати они его используют вместо bash / perl / python

про питон это сильно сказано) см. Gyp, GN и прочие го-вна

Я думал они все на bazel переводят

gyp и gn - это же build systems

а все равно питоноскриптов по кодбазам навалом

Я думал они все на bazel переводят

чем он лучше cmake ?

cmake говно )

чем он лучше cmake ?

Cmake говно

почти всё что угодно лучше чем cmake

Cmake говно

так и bazel говно, только еще и на жабе

так и bazel говно, только еще и на жабе

такие дела

Expected такой же ресурсоемкий как эксепшон. Если я правильно понимаю.

Дело не в ресурсоемкости, дело в том, что идеи expected со строгими спецификациями позволяют писать адекватно код

"Функция может вернуть что угодно" просто грубо нарушает всю типизацию возвращаемого значения

Дело не в ресурсоемкости, дело в том, что идеи expected со строгими спецификациями позволяют писать адекватно код

Ну если почитать саттера то получится что в 90% случаев эксепшн это не то что вам нужно

Ну если почитать саттера то получится что в 90% случаев эксепшн это не то что вам нужно

Я не могу перетипизировать variant

Т.е. фактически большинство эксепшонов в легаси коде на самом деле являются ошибками а не эксепшонами.

А в тех случаях где они полезные они являются control flow конструкцией, а не способом работы с исключительными ситуациями

Вот смотрите, у меня есть функция, возвращает string, называется "load_string", читает весь файл целиком

у меня есть файл 1Tb

ты проиграл

Вот смотрите, у меня есть функция, возвращает string, называется "load_string", читает весь файл целиком

Этот пример как раз есть у саттера в статье, и там bad_alloc полезен

Дело не в bad_alloc

Команда MS Office это решает именно с помощью эксепшона

Дело не в bad_alloc

?

Да памяти хватит

Раз в жизни загрузчик ресурсов не найдет файл

Как я должен описать ошибку чтения?