тикток это рекламная площадка, такая же как инстаграм, vk, facebook и т.д. Когда челы с роботами будут приносить такую же прибыль то и стоить будут соответствующе но к сожалению пока это не так. В тоже время вся криптовалюта это дибильнейшая трата ресурсов и это не только энергия на майнинг, но и затраты на производство железа и рост отходов связанных с их быстрым износом…
как же достала эта тупая и бессмысленная трата ресурсов, которая не даёт ни какого профита, я бы понял если эти вычисления хоть пользу какую то несли, но нет просто расчёт бессмысленных хешей черт пойми для чего, век идиотизма…
эмм… я скорее ожидал что саркастический тон будет очевиден, но видимо ошибся. У меня есть предположение что это за чел, не так уж много хаскелистов на плюсовых конференциях, но я его акк на habre не знаю. Но если я угадал, то он сам тот ещё «троль», и не думаю что мой вопрос был воспринят всерьёз.
ты вообще на C++ пишешь? если результат не может быть сконвертирован в А, то ты вывалишься так же на этапе поиска шаблона, так как твоя функция уже говорит о том что результат сложения должен быть типом A или приводимым к нему.
Так добавь эти проверки там где они нужны, из-за то того что они нужны тебе не значит что они нужны всем и везде, язык не для кого то одного создаётся у каждого свои задачи и потребности.
Что тип T поддерживает те операции, которые от него требуются в теле функции.
И что же мешает это сделать?
template <typename A>
concept Summable = requires(A a, A b)
{
a + b;
};
template<Summable T>
T sum(T a, T b){
return a + b;
}
Компилятор плюсов не требует использовать sfinae (которые, к слову, не совсем для этого) и концепты
Во-первых зачем он их должен требовать, они далеко не везде нужны? Во-вторых он проверит ровно то что ты от него требуешь. В-третьих что ты вообще пытаешься проверить тут?
template<typename T, typename = decltype(declval<T>() + declval<T>())>
T foo(T a, T b)
{
return a + b;
}
Именно, ключевое слово "работают", этого в языке нет.
От нечего делать спрошу, каким временем жизни можно управлять через типы в rust по мимо расположения на стеке, в куче и в одном из "умных" указателей? И чего там можно проверить до мономорфизации? В c++ для этого есть концепты и sfinae которому уже "сто" лет
тут вопрос не про необходимость этого или полезность вообще, а про мощную "систему типов" которая выросла в полноценный язык и где rust нервно курит в сторонке со своей типизацией. Так что, что даты сравнивать что фичи, rust и C++ даже не в одной весовой категории, это разговор ни о чём. IMHO его гораздо лучше бы восприняли не пытайся rust comunity делать абсурдные заявления в стиле "rust новая замена C++"
а вот с этого поржал) начиная с того что "компилятор" раста это всего лишь фронтенд на llvm и заканчивая тем что последний стабильный релиз gcc вышел неделю назад
Для tex у vs code есть плагин котрый не только отлично автодополняет и подсвечивает синтаксис ещё может сразу билдит и показывает pdf в параллельной вкладке и в каком месте vim тут выигрывает?
> В том, что для std::mutex гарантируется, что обращение к ресурсу защищённому мютексом компилятор не сделает до взятия мьютекса, а для boost::mutex — это не гарантируется.
не могу сказать что согласен подобным определением, но это прояснило для меня что подразумевалось под «С++98 не многопоточный».
ок 2 вопроса
С99 это многопоточный язык ведь для него вообще ни чего не изменилось?
в чём отличие std::thread/std::mutex/… от boost::thread/boost::mutex/...?
зависимость от pthread в gcc ни куда не делась и даже не перекочевала в сам stdlib так что же поменялось в «языке»?
вот auto, decltype, variadic templates это изменения в «языке» которых раньше не было и они реализовывались хаками. Но вызов системного api это часть языка и она ни куда не делась и не поменялась, просто завернули это в красивый «фантик»
> платформ зависимые штуки, которые на каждой платформе работают по-разному
они и сейчас работают по разному тут ни чего не поменялось
Вот в js нет «многопоточности» и ни какими средствами языка не создать поток без добавления этой возможности в интерпретатор.
Ну так реализация блокировок и запуска потоков как была в системных libpthread или в WINAPI так и осталась, ни чего "нового" 11 стандарт касаемо многопоточности не принёс ровно эта же обёртка над системным api уже была в boost за долго до STD11. Так почему же некоторые считают что c++98 с boost::thread или любой другой плюсовой оберткой или без нее не многопоточный, а c++11, в котором фактически полностью перенесли реализацию из boost::thread, стал многопоточным?
Уже не первый раз встречаю подобное мнение и мне оно до сих пор не понятно. Просто любопытно, создать поток в с++98 можно? можно, да в std98 нет сущностей для работы с потоками но там до сих пор нет ни чего и для работы с сетью что же теперь будем говорить что c++ не может в сетевое взаимодействие?
Я подумал что это отсылка к мему про "скучные обои" и намёк на то что ни чего существенно не поменялось
ты вообще на C++ пишешь? если результат не может быть сконвертирован в А, то ты вывалишься так же на этапе поиска шаблона, так как твоя функция уже говорит о том что результат сложения должен быть типом A или приводимым к нему.
Так добавь эти проверки там где они нужны, из-за то того что они нужны тебе не значит что они нужны всем и везде, язык не для кого то одного создаётся у каждого свои задачи и потребности.
И что же мешает это сделать?
Во-первых зачем он их должен требовать, они далеко не везде нужны? Во-вторых он проверит ровно то что ты от него требуешь. В-третьих что ты вообще пытаешься проверить тут?
Именно, ключевое слово "работают", этого в языке нет.
От нечего делать спрошу, каким временем жизни можно управлять через типы в rust по мимо расположения на стеке, в куче и в одном из "умных" указателей? И чего там можно проверить до мономорфизации? В c++ для этого есть концепты и sfinae которому уже "сто" лет
тут вопрос не про необходимость этого или полезность вообще, а про мощную "систему типов" которая выросла в полноценный язык и где rust нервно курит в сторонке со своей типизацией. Так что, что даты сравнивать что фичи, rust и C++ даже не в одной весовой категории, это разговор ни о чём. IMHO его гораздо лучше бы восприняли не пытайся rust comunity делать абсурдные заявления в стиле "rust новая замена C++"
И давно система типов в rust стала фактически самостоятельным языком для compile time как шаблоны в c++?
а вот с этого поржал) начиная с того что "компилятор" раста это всего лишь фронтенд на llvm и заканчивая тем что последний стабильный релиз gcc вышел неделю назад
Для tex у vs code есть плагин котрый не только отлично автодополняет и подсвечивает синтаксис ещё может сразу билдит и показывает pdf в параллельной вкладке и в каком месте vim тут выигрывает?
не могу сказать что согласен подобным определением, но это прояснило для меня что подразумевалось под «С++98 не многопоточный».
С99 это многопоточный язык ведь для него вообще ни чего не изменилось?
в чём отличие std::thread/std::mutex/… от boost::thread/boost::mutex/...?
зависимость от pthread в gcc ни куда не делась и даже не перекочевала в сам stdlib так что же поменялось в «языке»?
вот auto, decltype, variadic templates это изменения в «языке» которых раньше не было и они реализовывались хаками. Но вызов системного api это часть языка и она ни куда не делась и не поменялась, просто завернули это в красивый «фантик»
> платформ зависимые штуки, которые на каждой платформе работают по-разному
они и сейчас работают по разному тут ни чего не поменялось
Вот в js нет «многопоточности» и ни какими средствами языка не создать поток без добавления этой возможности в интерпретатор.
Ну так реализация блокировок и запуска потоков как была в системных libpthread или в WINAPI так и осталась, ни чего "нового" 11 стандарт касаемо многопоточности не принёс ровно эта же обёртка над системным api уже была в boost за долго до STD11. Так почему же некоторые считают что c++98 с boost::thread или любой другой плюсовой оберткой или без нее не многопоточный, а c++11, в котором фактически полностью перенесли реализацию из boost::thread, стал многопоточным?
По моему невозможно стать танцором без чувства ритма или музыкантом без слуха.
Уже не первый раз встречаю подобное мнение и мне оно до сих пор не понятно. Просто любопытно, создать поток в с++98 можно? можно, да в std98 нет сущностей для работы с потоками но там до сих пор нет ни чего и для работы с сетью что же теперь будем говорить что c++ не может в сетевое взаимодействие?