Но без подробностей я мало понял. Допустим вы правы. Но есть несколько вопросов.
Зачем сортировать unordered_map? По моему это не имеет смысла с точки зрения самой идеи хэштаблицы.
А нужен ли вам способ сделать "или" в определении дженерика? Как функция должна его использовать? Написать if constexpr и вызвать что-то в зависимости от типа? Тогда я думаю вам нужно две функции.
В раст ведь есть ассоциированные типы. С ними вполне можно реализовать iterator_traits
Вообщем можно долго дискутировать что лучше: интрузивные или не... интерфейсы.
мне лично не хватает какой-то единообразности в описании интерфейсов, а еще слабых дженериков как в раст, а не сильных как в плюсах.
Да, я понимаю, что концепты более общие, чем просто описание интерфейса функций. Но мне все равно, это не так читаемо и, к тому же, это не сочетается с описанием интерфейсов для динамического полиморфизма. Это уже странно. Зачем нам два способа описать интерфейс, чтобы в компайл тайме показать компилятору что какой-то тип ему соответсвует? What?
А слабые дженерики это просто способ не стрелять себе в ногу, когда вдруг решил поменять шаблонный параметр при вызове своей функции. К тому же это еще и способ описать интерфейс типа, который функция будет использовать. А то читать код библиотек, где написано <typename T> не очень приятно.
Не хватает try, хоть и можно заменить макросом (а потом наполучать по шапке ото всех, кого можно). Не хватает единой системы сборки (даже не говорите мне, что cmake... нет, он ужасен). Не хватает функциональщины.
Ну ладно, минутка нытья по поводу C++ закончилась)
Хотелось бы верить вам, но я не думаю что мне поставили минусы тогда по этой причине. Только что закрыл статью, где комментарий "что это было?" набрал под 15 плюсиков. Я думаю, что люди просто так выссказали свое несогласие с моим мнением. И я не против этого. Мне не нравится то, что они не выссказали свое, чтобы мы могли подискутировать)
не понимаю тогда цель комментариев. Одна строка никак не мешает людям читать остальные комментарии, зато она много говорит автору о том, стоит ли ему писать и, возможно, даёт мотивацию. Общепринятые рекомендации это хорошо, это формирует культуру и сообщество. Но (не говорю сейчас о комьюнити Хабра) порой люди начинают им поклоняться и забывают, что они нужны для того, чтобы как раз делать общение лучше. А если они мешают общению, тогда их следует менять.
Впрочем, если люди даже не пытаются объяснить, то и мне все равно на их мнение.
Компилятор может и сможет понять исходя из реализации, но времена жизни тут нужны для программиста, который использует эту функцию. Это просто часть апи.
А более сложные ситуации это объявление типов например, там компилятор никак не угадает что вы хотите). В c++ это остаётся на совести разработчика, а rust строго заставляет написать времена жизни. Я думаю, rust тут прав)
Время жизни, например. Компилятор мог бы и сам догадаться всегда
Как сказал комментатор выше, он сам их ставит чаще всего.
а если вдруг известно что он это сделает неправильно - тогда и указывать
Другой вопрос, а как узнать, что он это сделает неправильно, чтобы поставить их руками? По моему, лучше чтобы он строго выбрасывал ошибку компиляции, если не знает как расставить.
группировать сущности присваивая им одинаковые символы в пределах мизерной области
Не совсем понял что вы имеете ввиду.
Но по сравнению с идеей начинать каждую переменную с доллара
Либо я чего-то не понял, либо вы перепутали rust с bash
Хах) это был сарказм
<opinion> люди на Хабре почему-то такие серьезные </opinion>
Я считаю название не соответствуют содержанию. Я думаю, что прочту про стендапы. Ну, те, на которых шутят. А тут какие-то.. стендапы)
хм, спасибо за ответ.
Но без подробностей я мало понял. Допустим вы правы. Но есть несколько вопросов.
Зачем сортировать unordered_map? По моему это не имеет смысла с точки зрения самой идеи хэштаблицы.
А нужен ли вам способ сделать "или" в определении дженерика? Как функция должна его использовать? Написать if constexpr и вызвать что-то в зависимости от типа? Тогда я думаю вам нужно две функции.
В раст ведь есть ассоциированные типы. С ними вполне можно реализовать iterator_traits
Вообщем можно долго дискутировать что лучше: интрузивные или не... интерфейсы.
в расте почти сочетается и это круто. Хотя я могу ошибаться с этим.
Но с первого взгляда - пишешь <T: Sortable> и dyn Sortable. Довольно хорошо сочетается.
Не понял почему хуже будет библиотеки. Примерно реализацию что там что там я знаю. Объясните, если не затруднит?
Вашу библиотеку видел, спасибо. Мне понравилась.
мне лично не хватает какой-то единообразности в описании интерфейсов, а еще слабых дженериков как в раст, а не сильных как в плюсах.
Да, я понимаю, что концепты более общие, чем просто описание интерфейса функций. Но мне все равно, это не так читаемо и, к тому же, это не сочетается с описанием интерфейсов для динамического полиморфизма. Это уже странно. Зачем нам два способа описать интерфейс, чтобы в компайл тайме показать компилятору что какой-то тип ему соответсвует? What?
А слабые дженерики это просто способ не стрелять себе в ногу, когда вдруг решил поменять шаблонный параметр при вызове своей функции. К тому же это еще и способ описать интерфейс типа, который функция будет использовать. А то читать код библиотек, где написано <typename T> не очень приятно.
Не хватает try, хоть и можно заменить макросом (а потом наполучать по шапке ото всех, кого можно). Не хватает единой системы сборки (даже не говорите мне, что cmake... нет, он ужасен). Не хватает функциональщины.
Ну ладно, минутка нытья по поводу C++ закончилась)
Хотелось бы верить вам, но я не думаю что мне поставили минусы тогда по этой причине. Только что закрыл статью, где комментарий "что это было?" набрал под 15 плюсиков. Я думаю, что люди просто так выссказали свое несогласие с моим мнением. И я не против этого. Мне не нравится то, что они не выссказали свое, чтобы мы могли подискутировать)
не понимаю тогда цель комментариев. Одна строка никак не мешает людям читать остальные комментарии, зато она много говорит автору о том, стоит ли ему писать и, возможно, даёт мотивацию. Общепринятые рекомендации это хорошо, это формирует культуру и сообщество. Но (не говорю сейчас о комьюнити Хабра) порой люди начинают им поклоняться и забывают, что они нужны для того, чтобы как раз делать общение лучше. А если они мешают общению, тогда их следует менять.
Впрочем, если люди даже не пытаются объяснить, то и мне все равно на их мнение.
Вам спасибо за объяснение)
Типичная спорная ситуация -
fn oneof(lhs: &str, rhs: &str) -> &str;
Компилятор может и сможет понять исходя из реализации, но времена жизни тут нужны для программиста, который использует эту функцию. Это просто часть апи.
А более сложные ситуации это объявление типов например, там компилятор никак не угадает что вы хотите). В c++ это остаётся на совести разработчика, а rust строго заставляет написать времена жизни. Я думаю, rust тут прав)
Как сказал комментатор выше, он сам их ставит чаще всего.
Другой вопрос, а как узнать, что он это сделает неправильно, чтобы поставить их руками? По моему, лучше чтобы он строго выбрасывал ошибку компиляции, если не знает как расставить.
Не совсем понял что вы имеете ввиду.
Либо я чего-то не понял, либо вы перепутали rust с bash
минусить за мнение, не оставляя объяснения? - дарю вам своё разочарование
а что, по вашему впечатлению, из себя представляет эта дурь?
del
А что вы предложите изучать?
за coding challenges спасибо.
Раз уж рекламировали свои каналы, то рассказали бы и про /rustlang_ru /rust_beginners_ru
мне нравится, пишите ещё)
хорошо, изменим первую строку и импортируем вымышленную функцию cached_gcd. Получится в разы быстрее.
Все ещё непонятно. Ну ладно, не буду занудой))
Не понял почему в последнем примере абстракция ради абстракции. Вроде бы красиво решили задачу нахождения простых чисел.
Объясните
Звучит как сарказм)
Я думаю даже моя симпатия к iPhone SE 2016 не может считаться старой.
Люди, вы с ума сошли?
А я и сейчас блоки в майнкрафте ломаю)
Отдых есть отдых
Эх, вспомнил старые добрые деньки с виндой. Какое время было...
И порадовался, что они прошли)