Такое легко решается путем введения некоторого периода, типа 2-х недель. Посмотрите правила сервисов, типа музыки, стим (не уверен, что именно их, но точно где-то видел). Там будет написано, что если 2 недели в другой стране - то норм, а если больше - то чтото произойдет (контент обрежут например)
И для быстрого поиска, и для перебора подойдет один int. Поиск можно делать через битовый &, перебор - через перебор значащих единиц в двоичном виде, который наверняка можно сделать через sse какой-нибудь, а потом кастуя к enum
Я думаю, и сейчас нету никакого разнообразия в виде контейнеры * алгоритмы. Зачем например нужен std::find для unordered map? Почему std::min_element не может определить, что перед нами например set и выполнить поиск за логарифм? И т.д.
Логика в том, что каждый тип данных решает свои задачи, и не факт, что такое комбинаторное произведение возможности в принципе нужно.
Т.е. когда мы компилируем пользовательский код, мы уже должны знать и размер объекта, и выравнивание для него.
Вроде как пимпл можно сделать и со знанием размера, если сильно постараться (основная идея - прикинуть размер объекта в заголовочнике и выделить нужное колво данных, а в cpp файле добавить проверку)
Так ведь индексация не для всех типов будет эффективной.
Я понимаю, естественно. Могу лишь повторить вашу фразу, что "обобщенное программирование - не серебрянная пуля". Без алгоритмов stl она была бы еще чуть-чуть менее серебрянной
Хоть я изначально и ограничил обсуждение тривиальными алгоритмами, но давайте вернемся к нетривиальному алгоритму, например sort. Для него в листе отдельный метод, ибо как обычный не работает. Ну возможно что-то похожее будет, невелика потеря.
Возможно. Просто мысль была такая (только сейчас ее смог сформулировать).
Вот возьмем управление памятью: сборщик мусора в большинстве языков, деструкторы (то бишь, unique_ptr, shared_ptr и т.п.) в C++. Вродебы очевидно, что если все эти подходы взять и выбросить и заставить программистов писать в стиле C, с ручным управлением памятью, то будет сильно-сильно больно. Тоесть все эти идеи и правда дают какую-то пользу. А вот если также взять, и выбросить все stl-и, range, linq и т.п., что изменится? Ну да, первую неделю программисты будут хмыкать, не найдя любимой функции, а потом, никто и не вспомнит об этом, или что-то да изменится?
Ну, контейнеры меняются не так часто, по крайней мере по моему опыту. Если меняется контейнер с vector на list например, или наоборот, то проблем оказыватеся больше, чем просто отследить все места, где он используется.
Просто по моему ощущению, stl алгоритмы очень хороши на учебных примерах, а в реальной жизни довольно часто сталкиваешься с какими-нибудь ограничениями, и нужно или долго и мучительно выдумывать, как скомбинировать алгоритмы друг с другом, или плюнуть и написать свой for.
Сколько лет потом люди вместо std::find/find_if или std::accumulate вручную for-ы выписывали?
А интересно, действительно ли нужны все эти тривиальные стандартные алгоритмы, которые не делают какую-нибудь нетривиальную вещь типа бинарного поиска? Может, и правда иногда проще написать for руками? Тоесть да, понятно, что на пиар этих функций ушло довольно много ресурсов, но как бы повернулась история, если бы этого всего не было бы? (Причем я не только в рамках C++ это рассматриваю)
Почему бы и не простить человека за СВОЮ ошибку? Вроде компании так часто делают.
Ну или аналог человека по ошибке посадили в бизнес класс самолета
Такое и правда бывает? Нет, ладно если попросили освободить, например, если мест и правда нет и человек занял чье-то чужое место, но попросить доплатить...
Когда ты работаешь ради практического результата предназначенного для потребителя
Ага, а потом начинается все это "а точно ли потребителям нужна эта функция? Должен ли я спрашивать пользователей о новых функциях? Или они попросят только лишь более быструю лошадь? А должен ли я рефакторить этот модуль, ведь после рефакторинга наверняка что-то сломается и юзер будет недоволен? А должен ли я вообще что-то делать, если юзер всегда (конечно, это всегда разный юзер, но) недоволен, и если я чтото сделаю, то он все равно останется недовольным? А не было бы лучше, если бы этого приложения вообще небыло (например, если это корпоративное приложение, и конечные пользователи не могут от него отказаться из-за начальства, даже при наличии доступных альтернатив)?" и т.п. Знаю-знаю, проходил
Ну вот видите, чтото отмирает, что-то остается. Нормальный процесс в этом мире. И распространение чтото время от времени получает, несмотря на аналоги. Не понятно, что вы отрицаете.
Несмотря на это, както им всеже пользуются. И весьма успешно для нужных категорий людей. Значит, это возможно. И причем тут база данных, реплики, консенсус с точки зрения обычного юзера не понятно
Ну я про то, что такой механизм есть, и уже работает. И еще я только щас заметил, что откомментил не тот комментарий (хотел комментарий выше)
Такое легко решается путем введения некоторого периода, типа 2-х недель. Посмотрите правила сервисов, типа музыки, стим (не уверен, что именно их, но точно где-то видел). Там будет написано, что если 2 недели в другой стране - то норм, а если больше - то чтото произойдет (контент обрежут например)
И для быстрого поиска, и для перебора подойдет один int. Поиск можно делать через битовый &, перебор - через перебор значащих единиц в двоичном виде, который наверняка можно сделать через sse какой-нибудь, а потом кастуя к enum
Нифига не понятно, но очень интересно
Вообще, это довольно частый кейс. Неужели до сих пор нету никакого нормального решения для этого, и приходится все время выдумывать свои велосипеды?
Я думаю, и сейчас нету никакого разнообразия в виде контейнеры * алгоритмы. Зачем например нужен std::find для unordered map? Почему std::min_element не может определить, что перед нами например set и выполнить поиск за логарифм? И т.д.
Логика в том, что каждый тип данных решает свои задачи, и не факт, что такое комбинаторное произведение возможности в принципе нужно.
Вроде как пимпл можно сделать и со знанием размера, если сильно постараться (основная идея - прикинуть размер объекта в заголовочнике и выделить нужное колво данных, а в cpp файле добавить проверку)
Я бы уж лучше подождал плашки "РКН сайт нарушает закон РФ" без двоеточия
Я понимаю, естественно. Могу лишь повторить вашу фразу, что "обобщенное программирование - не серебрянная пуля". Без алгоритмов stl она была бы еще чуть-чуть менее серебрянной
Хоть я изначально и ограничил обсуждение тривиальными алгоритмами, но давайте вернемся к нетривиальному алгоритму, например sort. Для него в листе отдельный метод, ибо как обычный не работает. Ну возможно что-то похожее будет, невелика потеря.
И итераторы не нужны, итерироваться по индексам.
Ну вы это про типы данных. А я именно про тривиальные алгоритмы
Возможно. Просто мысль была такая (только сейчас ее смог сформулировать).
Вот возьмем управление памятью: сборщик мусора в большинстве языков, деструкторы (то бишь, unique_ptr, shared_ptr и т.п.) в C++. Вродебы очевидно, что если все эти подходы взять и выбросить и заставить программистов писать в стиле C, с ручным управлением памятью, то будет сильно-сильно больно. Тоесть все эти идеи и правда дают какую-то пользу. А вот если также взять, и выбросить все stl-и, range, linq и т.п., что изменится? Ну да, первую неделю программисты будут хмыкать, не найдя любимой функции, а потом, никто и не вспомнит об этом, или что-то да изменится?
Ну, контейнеры меняются не так часто, по крайней мере по моему опыту. Если меняется контейнер с vector на list например, или наоборот, то проблем оказыватеся больше, чем просто отследить все места, где он используется.
Просто по моему ощущению, stl алгоритмы очень хороши на учебных примерах, а в реальной жизни довольно часто сталкиваешься с какими-нибудь ограничениями, и нужно или долго и мучительно выдумывать, как скомбинировать алгоритмы друг с другом, или плюнуть и написать свой for.
А интересно, действительно ли нужны все эти тривиальные стандартные алгоритмы, которые не делают какую-нибудь нетривиальную вещь типа бинарного поиска? Может, и правда иногда проще написать for руками? Тоесть да, понятно, что на пиар этих функций ушло довольно много ресурсов, но как бы повернулась история, если бы этого всего не было бы? (Причем я не только в рамках C++ это рассматриваю)
Почему бы и не простить человека за СВОЮ ошибку? Вроде компании так часто делают.
Такое и правда бывает? Нет, ладно если попросили освободить, например, если мест и правда нет и человек занял чье-то чужое место, но попросить доплатить...
Ага, а потом начинается все это "а точно ли потребителям нужна эта функция? Должен ли я спрашивать пользователей о новых функциях? Или они попросят только лишь более быструю лошадь? А должен ли я рефакторить этот модуль, ведь после рефакторинга наверняка что-то сломается и юзер будет недоволен? А должен ли я вообще что-то делать, если юзер всегда (конечно, это всегда разный юзер, но) недоволен, и если я чтото сделаю, то он все равно останется недовольным? А не было бы лучше, если бы этого приложения вообще небыло (например, если это корпоративное приложение, и конечные пользователи не могут от него отказаться из-за начальства, даже при наличии доступных альтернатив)?" и т.п. Знаю-знаю, проходил
Ну вот видите, чтото отмирает, что-то остается. Нормальный процесс в этом мире. И распространение чтото время от времени получает, несмотря на аналоги. Не понятно, что вы отрицаете.
"Блокчейн мертв с рождения. Я сказал"
Несмотря на это, както им всеже пользуются. И весьма успешно для нужных категорий людей. Значит, это возможно. И причем тут база данных, реплики, консенсус с точки зрения обычного юзера не понятно
В таком случае, в такой постановке вопроса не вижу сильного отличия. Чем тогда мешает еще плюс одна технология.
А ARM?
А наличка? А (извините) блокчейн? А крышки Nuka-cola?
Да здравствует монополия? Ну, может вы и правы. Но в таком случае блокчейн возможно будет наименьшей из проблем
Нигде вроде не упоминал, что нужна массовость