Вы правда думаете что в 99% мне не наплевать на эти аллокации?
Конечно же нет. Однако такие API противоречат самой сути с++ как zerocost-oriented языка. В конце концов, вы всегда можете написать неэффективный код на эффективном языке, но не наоборот.
В стандартной библиотеке дофига классов которые можно написать более оптимально
а можете привести пару примеров? Так, чтобы альтернативная реализация могла бы быть безусловно лучше, без опускания части требований/гарантий.
Так и в C++23 это есть, если лишние аллокации ок:
боюсь std::string{s} (где s - subrange<const char*, const char*>) не скомпилится.
давайте сравним: Qt версия делает на N + log(N) аллокаций больше, то есть выразительность в ущерб производительности. Соответственно, такой версии split не место в стандарте.
Но что еще важнее, Qt это всё еще плюсы. На плюсах вы всегда можете написать библиотеку с любым желаемым соотношением выразительности/производительности, а новички всегда могут начать изучать с++ с того же Qt
Для её реализации требуются глубокие знания текущих rangeй и с наскоку написать так просто ничего не получится.
попробовал с наскоку написать, действительно сложно - интерфейс from_chars пришлось таки на cppreference проверять, всё-таки не пользовался им ни разу, обычно под рукой есть обертки. А вот написать
vector<int> vec;
for (int i : "10.10.0.1"sv
| ranges::views::split('.')
| ranges::views::transform([](auto rv) {
string_view s(rv.begin(), rv.end());
// тут конвертация s в int
return res;
}))
vec.push_back(i);
не составило труда, потребовалась лишь пара подсказок компилятора (печатал в годболте) что то что я ищу не в том неймспейсе. Из "глубоких знаний" почему split возвращает не string_view (хотя проще даже без него), и то, что в ranges в с++20 не добавили метод материализации контейнера (тогда было бы еще проще). Можно было бы еще через back_inserter написать, но зачем выпендриваться?
кто думает что я херню выдумываю и все там «изян», воть
всё-таки та бумага решает проблему того, что ленивое вычисление split не шибко хорошо сочетается с input iterator'ами, а не ту, которую вы пытаетесь привести здесь.
в джаваскрипте чет тоже до недавних пор самые лучшие способы написать replaceAll("foo", "bar") были либо s.replace(/foo/d, "bar") либоs.split("foo").join("bar").
Нет способа понять, как будет соптимизирован атомарный блок (будет ли в нём мьютекс?)
я правильно понимаю, что в конкретном примере он точно должен быть, т.к. TwoInts не выровнен по 8, что в общем случае не дает атомарно прочитать оба инта сразу?
Я просто не понимаю, как реально произойдёт снижение ЗП разработчиков?
Высокий спрос на IT-шников -> высокие ЗП в IT -> растет популярность IT специальностей -> растет число новых IT-шников -> предложение сравнивается (а в какой-то момент из-за перерегулирования начнет превышать) спрос -> ЗП IT-шников падают. Такое уже было с юристами лет 30-20 назад. Нюанс однако в том, что ребята со стажем 1-2 года не шибко конкурируют с ребятами со стажем 5+ лет, и этот разрыв еще какое-то время сохранится.
тут я не понял последний пример - почему ui.reset() для const unique_ptr& OK? Это ведь иммутабельный объект. Плюс к тому, я не совсем понял как propconst должен решить проблему constexpr p = make_unique<int>(); В идеале должна выделиться compile-time память под мутабельный в рантайме int. А записьconstexpr auto p = make_unique<unique_ptr<int>>(make_unique<int>()); [1] - выделять compile-time память под указатель на (внимание!) compile-time память под мутабельный int. То есть в этом случае константность должна пропагандироваться не просто так, а неким нетривиальным образом, учитывающим/перепроверяющим то, будет ли аллоцировавший в compile-time объект перетекать в рантайм. То есть компилятор должен заставить нас преобразовать [1] в constexpr auto p = make_unique<const unique_ptr<int>>(make_unique<int>());
Стандарт дает уклончивый ответ на тему того, когда запись в результат const_cast-а может спровоцировать Undefined Behaviour
не шибко то и уклончиво - запись в const объект всегда ведет к UB. А const_cast лишь преобразует типы ссылок/указателей.
Запрещается использовать полученные данные для любых целей, не связанных с работой приложения (продажа, трэкинг, сбор информации о пользователе, таргетирование рекламы).
сейчас apple еще не признан монополистом настолько, чтобы заставить их разрешить sideloading. Как только это происходит, появятся альтернативные магазины приложений, которые захотят положить болт на все виды ценза: и на возрастной, и на parental control, и на платность приложений, и на мошенничество. Чтобы форсить соблюдение этих правил, apple понадобятся рычаги влияния на альтерсторы, т.е. на своего прямого конкурента, что само по себе является злоупотреблением монополией. Максимум что они смогут сделать - удалять альтерсторы из appstore. Однако это не будет достаточной мерой, ведь при включении sideloading'а appstore перестанет быть единственным способом установки приложения. Плюс, даже само удаление альтерстора из appstore может быть поводом для очередных монопольных исков/регуляций. Более того: под них попадет даже возможность запретить sideloading в настройках родительского контроля, ровно как и безальтернативная предустановка appstore по умолчанию
Если да, то пусть делает с ним что хочет. Если нет, то пусть родитель, купивший этот телефон, отключает там какие угодно функции и настраивает какие угодно контроли. Пусть хоть kiosk mode ставит. Если оно ему надо конечно.
мой аргумент в том и состоит, что с разрешением сайдлоадинга возможность установить некоторые виды контроля пропадет полностью. И никакие "kiosk mode" не будут возможны даже при желании владельца, как минимум законодательно.
А про отвёртку вообще ни про что аргумент. Если натягивать аналогии, то в текущем раскладе выходит так, что ты покупаешь крутую отвёртку, а когда пытаешься ей потом вскрыть какой-то корпус, отвёртка кукожится и говорит что работает только с одобренными производителем винтами
вы не поняли мой аргумент и начали спорить с чучелом... Давайте переформулирую: если вы проектируете отвертку, вы имеете полное право игнорировать мнение людей, желающих использовать её в качестве молотка. И вы даже имеете полное право нанести на рукоять резьбу, чтобы эта отвертка не пролазила куда прям ну совсем не надо.
То, что отвертка - такой же инструмент как и молоток, не делает их взаимозаменяемыми, а принципы их дизайна одинаковыми
но в Apple считают что они дофига умные и лучше пользователя знают, что на этом смартфоне можно запускать, а что нельзя
простой пример: есть такие штуки как родительский контроль, возрастной ценз, вот это вот всё. Разрешив sideloading Apple уже не сможет заставить сторы соблюдать эти правила - оставив себе техническую возможность, apple попадет под монопольные иски. Внимание вопрос: должен ли у ребенка 10 лет быть доступ к порно играм? А это ведь только верхушка айсберга.
ну правильно. Сначала вступает в силу закон, потом apple в соответствии с ним поменяет правила appstore, а уже потом восстанавливается аккаунт/приложение, при условии что приложение соответствует обновленным правилам. Иначе получается телега впереди лошади.
Нет. Вы по итогу глобализации развитыми не станете. Ибо глобализация это тот процесс который приводит к тому что богатые и развитые - становятся ещё более богатыми и развитыми. А бедные и неразвитые соответственно, наоборот.
не так. Причины, почему одни страны бедные, а другие богатые, начинают сильнее проявлять себя в условиях глобализации. У нас же вместо создания стимулов для развития бизнеса и производства правительство играет в плохого танцора.
пятый айфон был толщиной примерно той же толщины что и 13 про. Погоня идет не столько за толщиной телефона (хотя увеличивать её при такой ширине уже особо некуда - в руку перестанет помещаться), сколько за качеством камеры. А тут физику не обманешь - чем больше камера, тем лучше снимки. Меня во всей этой истории больше расстраивает что производители одежды не укрепляют карманы джинс, чтобы они не протирались смартфонами изнутри.
И тем не менее принципиально не готовлюсь к собеседованиям. Людям со мной работать и моими реальными знаниями, а не зазубренными методами библиотек/фреймворков и алгоритмами сортировки (которые через месяц забудутся)
это если людям потом работать именно с вами, а не с абстрактным программистом Петей, который ничем не лучше вас как специалист, но потратил пару дней на подготовку к интервью...
ну учитывая что современному плюсовику крайне не рекоммендуется пользоваться ни первым, ни вторым (имеются в виду просто сырые массивы, даже без VLA), то я даже не уверен, что это прям грандиозный минус кандидату.
Хотя в таких случаях я бы скорее перепроверил что собеседование проходил тот же человек, что вышел на работу.
>Низкоквалифицированный Вася с улицы туда просто не пройдет. А откуда тогда баги в ужасных количествах?
просто: берем нанимаем крутого питониста Джона, садим разрабатывать плюсовый проект, удивляемся как человек, уверенно победивший алгоритмические секции, допускает простые ошибки на едва знакомом ему языке
Не оч понял про "поделившись". Когда вы заходите на новый сайт, вы не делитесь с ним теми куками, которые у вас есть
когда вы заходите на сайт foo.bar, на этом сайте еще будет с десяток трекеров, которые опознают вас по кукам с сайтов, которым принадлежат эти трекеры. На куки foo.bar вы к тому моменту еще даже не согласились
— А как же теперь плыть против течения и выражать мнение, отличное от всех?
— Как и раньше. За спокойное, корректное и аргументированно выраженное мнение ничего страшного с кармой не происходит
очень даже происходит, просто потому, что из 100 согласных плюс в карму поставит максимум один, а от 100 не согласных прилетит пара десятков минусов. Вон @amoralist разок оставил противоречивый комментарий и получил -16 к карме при положительном балансе голосов в этом же комменте. А дальше это только вопрос дистанции, "спокойное, корректное" поведение лишь замедляет процесс слива, а "аргументированно выраженное мнение" никого не интересует. В конце концов, у вас же должны быть счетчики сколько пользователи ставят друг другу прямых плюсов/минусов, из этого же уже можно сделать выводы что ваша система призвана лишь наказывать тех, кто не пишет статьи? В итоге вы стимулируете не хорошие технические статьи, а слабенькие переводы новостных постов, в которых дискуссия в комментах ценнее статьи. Была бы, вот только эффект эхо камеры всё портит, ведь непопулярное мнение всегда будет уменьшать присутствие автора.
Сейчас у каждого пользователя есть «запас прочности» в 30 единиц кармы, которого вполне хватит, чтобы разок «оступиться»
вы хотели сказать "сейчас у пользователя есть запас в 10 кармы". Потому что один комментарий в день это почти нулевое присутствие на ресурсе. И я уже привел пример как более чем 10 кармы теряются всего за один комментарий
Конечно же нет. Однако такие API противоречат самой сути с++ как zerocost-oriented языка. В конце концов, вы всегда можете написать неэффективный код на эффективном языке, но не наоборот.
а можете привести пару примеров? Так, чтобы альтернативная реализация могла бы быть безусловно лучше, без опускания части требований/гарантий.
боюсь std::string{s} (где s - subrange<const char*, const char*>) не скомпилится.
давайте сравним: Qt версия делает на N + log(N) аллокаций больше, то есть выразительность в ущерб производительности. Соответственно, такой версии split не место в стандарте.
Но что еще важнее, Qt это всё еще плюсы. На плюсах вы всегда можете написать библиотеку с любым желаемым соотношением выразительности/производительности, а новички всегда могут начать изучать с++ с того же Qt
попробовал с наскоку написать, действительно сложно - интерфейс from_chars пришлось таки на cppreference проверять, всё-таки не пользовался им ни разу, обычно под рукой есть обертки. А вот написать
не составило труда, потребовалась лишь пара подсказок компилятора (печатал в годболте) что то что я ищу не в том неймспейсе. Из "глубоких знаний" почему split возвращает не string_view (хотя проще даже без него), и то, что в ranges в с++20 не добавили метод материализации контейнера (тогда было бы еще проще). Можно было бы еще через back_inserter написать, но зачем выпендриваться?
всё-таки та бумага решает проблему того, что ленивое вычисление split не шибко хорошо сочетается с input iterator'ами, а не ту, которую вы пытаетесь привести здесь.
в джаваскрипте чет тоже до недавних пор самые лучшие способы написать
replaceAll("foo", "bar")были либоs.replace(/foo/d, "bar")либоs.split("foo").join("bar").я правильно понимаю, что в конкретном примере он точно должен быть, т.к. TwoInts не выровнен по 8, что в общем случае не дает атомарно прочитать оба инта сразу?
А в остальном... ну ладно, ждем pattern matching
Высокий спрос на IT-шников -> высокие ЗП в IT -> растет популярность IT специальностей -> растет число новых IT-шников -> предложение сравнивается (а в какой-то момент из-за перерегулирования начнет превышать) спрос -> ЗП IT-шников падают. Такое уже было с юристами лет 30-20 назад. Нюанс однако в том, что ребята со стажем 1-2 года не шибко конкурируют с ребятами со стажем 5+ лет, и этот разрыв еще какое-то время сохранится.
тут я не понял последний пример - почему ui.reset() для const unique_ptr& OK? Это ведь иммутабельный объект. Плюс к тому, я не совсем понял как propconst должен решить проблему
constexpr p = make_unique<int>();В идеале должна выделиться compile-time память под мутабельный в рантайме int. А записьconstexpr auto p = make_unique<unique_ptr<int>>(make_unique<int>());[1] - выделять compile-time память под указатель на (внимание!) compile-time память под мутабельный int. То есть в этом случае константность должна пропагандироваться не просто так, а неким нетривиальным образом, учитывающим/перепроверяющим то, будет ли аллоцировавший в compile-time объект перетекать в рантайм. То есть компилятор должен заставить нас преобразовать [1] вconstexpr auto p = make_unique<const unique_ptr<int>>(make_unique<int>());не шибко то и уклончиво - запись в const объект всегда ведет к UB. А const_cast лишь преобразует типы ссылок/указателей.
а как они собираются это контроллировать?
сейчас apple еще не признан монополистом настолько, чтобы заставить их разрешить sideloading. Как только это происходит, появятся альтернативные магазины приложений, которые захотят положить болт на все виды ценза: и на возрастной, и на parental control, и на платность приложений, и на мошенничество. Чтобы форсить соблюдение этих правил, apple понадобятся рычаги влияния на альтерсторы, т.е. на своего прямого конкурента, что само по себе является злоупотреблением монополией. Максимум что они смогут сделать - удалять альтерсторы из appstore. Однако это не будет достаточной мерой, ведь при включении sideloading'а appstore перестанет быть единственным способом установки приложения. Плюс, даже само удаление альтерстора из appstore может быть поводом для очередных монопольных исков/регуляций. Более того: под них попадет даже возможность запретить sideloading в настройках родительского контроля, ровно как и безальтернативная предустановка appstore по умолчанию
мой аргумент в том и состоит, что с разрешением сайдлоадинга возможность установить некоторые виды контроля пропадет полностью. И никакие "kiosk mode" не будут возможны даже при желании владельца, как минимум законодательно.
вы не поняли мой аргумент и начали спорить с чучелом... Давайте переформулирую: если вы проектируете отвертку, вы имеете полное право игнорировать мнение людей, желающих использовать её в качестве молотка. И вы даже имеете полное право нанести на рукоять резьбу, чтобы эта отвертка не пролазила куда прям ну совсем не надо.
То, что отвертка - такой же инструмент как и молоток, не делает их взаимозаменяемыми, а принципы их дизайна одинаковыми
простой пример: есть такие штуки как родительский контроль, возрастной ценз, вот это вот всё. Разрешив sideloading Apple уже не сможет заставить сторы соблюдать эти правила - оставив себе техническую возможность, apple попадет под монопольные иски. Внимание вопрос: должен ли у ребенка 10 лет быть доступ к порно играм? А это ведь только верхушка айсберга.
ну правильно. Сначала вступает в силу закон, потом apple в соответствии с ним поменяет правила appstore, а уже потом восстанавливается аккаунт/приложение, при условии что приложение соответствует обновленным правилам. Иначе получается телега впереди лошади.
не так. Причины, почему одни страны бедные, а другие богатые, начинают сильнее проявлять себя в условиях глобализации. У нас же вместо создания стимулов для развития бизнеса и производства правительство играет в плохого танцора.
а вдруг мы тоже развитыми станем? Непорядок же...
пятый айфон был толщиной примерно той же толщины что и 13 про. Погоня идет не столько за толщиной телефона (хотя увеличивать её при такой ширине уже особо некуда - в руку перестанет помещаться), сколько за качеством камеры. А тут физику не обманешь - чем больше камера, тем лучше снимки. Меня во всей этой истории больше расстраивает что производители одежды не укрепляют карманы джинс, чтобы они не протирались смартфонами изнутри.
это если людям потом работать именно с вами, а не с абстрактным программистом Петей, который ничем не лучше вас как специалист, но потратил пару дней на подготовку к интервью...
ну учитывая что современному плюсовику крайне не рекоммендуется пользоваться ни первым, ни вторым (имеются в виду просто сырые массивы, даже без VLA), то я даже не уверен, что это прям грандиозный минус кандидату.
Хотя в таких случаях я бы скорее перепроверил что собеседование проходил тот же человек, что вышел на работу.
просто: берем нанимаем крутого питониста Джона, садим разрабатывать плюсовый проект, удивляемся как человек, уверенно победивший алгоритмические секции, допускает простые ошибки на едва знакомом ему языке
когда вы заходите на сайт foo.bar, на этом сайте еще будет с десяток трекеров, которые опознают вас по кукам с сайтов, которым принадлежат эти трекеры. На куки foo.bar вы к тому моменту еще даже не согласились
очень даже происходит, просто потому, что из 100 согласных плюс в карму поставит максимум один, а от 100 не согласных прилетит пара десятков минусов. Вон @amoralist разок оставил противоречивый комментарий и получил -16 к карме при положительном балансе голосов в этом же комменте. А дальше это только вопрос дистанции, "спокойное, корректное" поведение лишь замедляет процесс слива, а "аргументированно выраженное мнение" никого не интересует. В конце концов, у вас же должны быть счетчики сколько пользователи ставят друг другу прямых плюсов/минусов, из этого же уже можно сделать выводы что ваша система призвана лишь наказывать тех, кто не пишет статьи? В итоге вы стимулируете не хорошие технические статьи, а слабенькие переводы новостных постов, в которых дискуссия в комментах ценнее статьи. Была бы, вот только эффект эхо камеры всё портит, ведь непопулярное мнение всегда будет уменьшать присутствие автора.
вы хотели сказать "сейчас у пользователя есть запас в 10 кармы". Потому что один комментарий в день это почти нулевое присутствие на ресурсе. И я уже привел пример как более чем 10 кармы теряются всего за один комментарий