Pull to refresh
-11
0
Руссков Андрей @Antervis

Разработчик

Send message

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

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

если программа хреново написана, то да. Просто потому, что увеличение числа ядер ничего не даст

вы забываете что с++ куда лучше масштабируется по числу ядер чем языки с GC. Из-за самого GC, собственно

Но это от языка не зависит вообще; я-то говорил о ситуациях, когда ваше аккуратное использование памяти легко бьется покупкой доп планок (если совсем примитивно), или доп. виртуальных машин

когда нагрузка несущественная или распределяется идеально - тогда да, мб и бьется...

Ткнул в firefox, открылась новая вкладка firefox с сообщением, что не может отобразить эту ссылку. Кстати, если эту ссылку принудительно открыть через ShellExecute (Win+R), открывается Edge, но не показывает сайт Хабра

да, видимо тут еще нужна "превью сборка windows 11" и чтобы хабр не заменял зачем-то ссылку вида microsoft-edge://foo.bar на microsoft-edge//foo.bar (убирает двоеточие)

в отличие от вас, который путает А и Б целенаправленно, требуя запретить А, обосновываясь на ложном Б?

требуя запретить обеспечение безопасности? - да ровно наоборот. Основываясь на ложном утверждении что МС злоупотребляет монополией? - вам сколько доказательств надо что МС злоупотребляют монополией?

Хм, МС завели свой протокол, в который ДЛЯ своих программ делает возможность открывать только в конкретно протестированном на работу сервиса браузере ...

так проблема в том, что не только для своих. Ткните сюда: microsoft-edge://habr.com и скажите в каком браузере открылось то, что не является ни сервисом МС, ни ссылкой, взятой из сервиса МС.

Гугл перехватывает ВСЕ обращения даже в браузере напрямую к сайту ютуба и выводит террористическое требование установить приложение гугла, причем являясь монополистов по всем долям (ос, браузер, поисковик, рекламный бизнес, видеохостинг) — да нормально, что ты возмущаешься.

погодите. Я не оправдывал гугл, а сделал конкретно две вещи: 1. переспросил откуда именно приходят уведомления (чтобы разобраться где именно вы видите злоупотребление гугла) и 2. сказал что такое происходит и в ситуациях, где гугл совершенно не при делах.

Да-да, классическое «ЭТО ДРУГОЕ».
Ну так, конечно, навязывается реклама.

поэтому я сам смотрю ютуб из сафари с адблоком, и приложения youtube у меня в телефоне даже нет. На андроиде можно сделать так же?

То есть вы сейчас заявляете, что согласны с тем, что виндоуз должен быть закрыт на уровне АйОС, где никакие приложения вне магазина Эпл купить и поставить нельзя, так?

Навеяло

Не, серьезно, как вообще эти утверждения взаимосвязаны? Я сказал "майкрософт не обеспечили должную безопасность, и безусловно в этом виноваты", в контексте безопасности механизма выбора пользователем приложения по умолчанию для конкретных ссылок/файлов. Как вы вообще умудрились исковеркать это в "у винды должен быть закрытый магазин приложений"?

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

Такой уровень подмены не нормален даже для вас, с вами всё хорошо?

и вскоре подоспеют результаты опроса как 53% индусов хотят уехать из России... А оставшиеся 47% даже не знают как они вообще здесь оказались

Речь не идет о высокопроизводительном софте, которого проценты от общего. 90% софта вполне попадают под "общее"

откуда вы взяли цифру в 90%?

доп дев обойдется конторе в 70-100 тыс в год (это в нашем небогатом квебеке, например), нарастить облако будет сильно дешевле

а с чего вы взяли что доп разраб обязательно потребуется? И с чего вы взяли что он не окупится? И с чего вы взяли что дешевле? Из вашего конкретного случая или из головы?

так тут либо а) прокся просто криво написана б) либо да, затык по производительности.

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

Я б поставил на первое, особенно если выяснится, что данные хреново параллелятся на эти самые 4 ядра

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

потому что я не согласен с вашим утверждением. Да, собственно, это уже давно общее место, что железо дешевле софта, и соответственно, труда программистов

"в среднем" - может быть, "в общем" - нет.

Может, и что? Дешевле и быстрее заплатить за железо, чем за дополнительную разработку

опять же, это "иногда" а не "всегда".

Если комплексно о разработке, то сильно экономит ресурсы; человеческие, в первую очередь

ну вот буквально сегодня я словил факап на проде потому что, как оказалось, кеширующая прокся на go не способна держать жалкие 2k rps на 4-х ядрах. Чтобы достигнуть такого уровня производительности на с++ даже задумываться не приходится. Как думаете, сколько человеческих ресурсов мне и моим коллегам бы сэкономило если бы всё просто работало?

что адлеры

почему вы "alder lake" называете "адлерами"?

наоборот В общем случае железо дешевле

как у вас частное перестало быть подмножеством общего?

наша контора продает, например, десктопный софт, ...

и этот частный пример по-вашему задает общие тенденции?

Если же речь об онлайне, там еще проще, там амазоновское облако, например, которое отлично скейлится за очень небольшие деньги

как раз там линейная зависимость стоимости аренды от потребляемых ресурсов. В зависимости от дистанции и масштабов проекта эта стоимость может дорастать до весьма существенной.

мне кажется, это вы должны были что-то вынести, т.к. совсем себе не представляли, как работает выделение/освобождение памяти в хотя бы дотнете

вы просто не поняли обоснование того, как GC даже теоретически не способен экономить ресурсы по сравнению с автоматическим освобождением

Да, как вариант; я сразу сказал, что труд погромиста сильно дороже железа

в частном случае да, в общем - нет. По факту совсем не париться о производительности обычно могут позволить себе только фронтендеры (потому что за железо платит пользователь) и ML специалисты (потому что их код всего лишь вызывает тяжелую обработку на с++). Ну либо если проект маленький и бесперспективный.

по размеру памяти - возможно. Чисто как числодробилка - где как, и совсем не "сильно" производительнее;

класс приложений-"числодробилок" куда меньше класса приложений, работающих с текстом.

да и скорость выделения в managed/unmanaged heap мы уже обсуждали

и кажется вы из этого обсуждения ничего не вынесли

другие-то тоже на месте не стояли:)

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

вопщем, с моего имха я б не замыкался в рамках одного языка

да, я всё не могу выделить время поучить раст. А то даже глупо знать про UB в языке больше чем про синтаксис...

Предположим что M2/M3 будут на 15/40% производительнее M1. Примерно в такой пропорции чипы apple и наращивают производительность, плюс M3 скорее всего будет уже на tsmc 3nm. Тогда чтобы выполнить своё обещание qualcomm'у за полтора-два года нужно хотя бы удвоить одноядерную производительность своих чипов, отмасштабировать их вширь, и еще и урвать производственные мощности tsmc 3nm. Такие заявления как минимум амбициозны. Как и например про "very well positioned to be the preferred platform for PCs, in the inevitable transition to ARM" - переход PC на ARM неизбежен только если кто-то представит ARM чип, заметно превосходящий x86 конкурентов и нормально их эмулирующий, а не телега впереди лошади

Эм, ну вот, обеспечили, а вы недовольны. Чем? Непонятно…

вы следите вообще за диалогом или нет? А. не обеспечили, Б. они всё еще злоупотребляют монопольным положением, чем я и недоволен.

То есть убивать уже нельзя, ведь всего-то изнасиловать хотели?

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

То есть, когда все запросы на ютуб в моём андроиде оповещения вызывают «установите приложение ютуб» — это ж, понимать надо, совершенно другое, да?

эти оповещения идут от андроида, браузера (если да, то какого?) или самого ютуба?

А ведь в них, вроде, даже не было этого протокола «открывать данную ссылку в ютуб», просто всё нахрен перехватывается.

вы определитесь: либо плохо и то и другое, по одним и тем же причинам, либо вы терпимо относитесь и к тому и к другому. Или по-вашему майкрософту злоупотреблять можно а другим нет?

Опять же, ютуб, предлагающий открыться в приложении ютуба, это всё-таки немного другой случай - вы и так и эдак пользуетесь продуктом/сервисом, навязывается лишь альтренативный способ доступа к нему. Точно так же условный reddit.com предлагает перейти в приложение и на safari в ios, и гугл тут вообще не при делах.

Ну да, ведь хаки нужны, чтоб не пользователь подтверждал что действительно «сам», да?

как я и говорю: майкрософт не обеспечили должную безопасность, и безусловно в этом виноваты. Однако если бы MS не прибегали к монопольным практикам, у конкурентов было бы меньше стимулов пользоваться такими хаками.

Это разговор из разряда, должна ли Apple всем кому попало разрешать ставить в систему свои магазины приложений. А если не пускает кого попало, то Apple надо судить за монопольные злоупотребления.

собственно, их за это судят...

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

То, что MS не могут обеспечить нормальную безопасность, не значит, что их монопольные посягательства не надо пресекать. Это как превышение пределов самообороны при попытке отбиться от изнасилования.

Завтра MS сделают так, что все их сайты начнут редиректить на microsoft-edge: ссылки. Послезавтра - настроят редирект в балансере azure. Еще через пару дней сделают что edge при попытке скачать браузер конкурента начнет предупреждать что это небезопасно. Ах, погодите, этот пункт мы уже проходили...

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

предполагается что пользователь сам выставил подделку вместо стима.

Хоть один компилятор имеет в своей документации фразу «даже невалидный по стандарту код, компилируемый сегодня нашим компилятором, будет компилироваться и иметь то же поведение всегда»?

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

Я не могу вспомнить ни один такой случай...

"не могу вспомнить" и "не было" это разные категории.

... который при этом не считался бы багом

"считается багом с точки зрения компилятора" и "считается багом с точки зрения стандарта" это тоже разные категории. В других языках просто нет последней инстанции в виде стандарта, и в них вас совершенно устраивают гарантии компилятора. Допустим завтра появится стандарт rust - ринетесь ли вы переписывать весь свой код чтобы он стал conformant?

Например?

ну с тем же rust простейший пример - каст & в &mut это сразу UB. А языки более высокого уровня либо в принципе не дают контроля над памятью, либо проще уж писать на плюсах, чем скажем на джаве, но не пользуясь GC.

Как это не потерял? Ваш вариант применяет функцию к аргументам в прямом порядке, мой — в обратном

я не то имел в виду

Зависит от вашего опыта с шаблонным метапрограммированием, тащем-та. Для значимой части людей всё это — нечитаемые трюки.

для людей, которые не освоились с с++11 то? Ну хз, хз. Да, я знаю что fold ввели в с++17, но его можно эмулировать в с++11

Помогают не думать о том, есть ли у какого-то другого поля в variant'е неявное преобразование из инта, и как variant с этим будет работать, особенно если я завтра поменяю int на uint64_t — плюсы не настолько дружественны к механическому рефакторингу, чтобы не думать об этом наперёд

это можно делать либо type alias'ом, либо, на совсем худой конец, через enum class foo : int; - создает distinct type. Точно так же как class ObjectString : public std::string;. И без бойлерплейта

Тем более, что с точки зрения производительности (раз мы уж тут о плюсах говорим) вполне разумно ожидать, что такие обёртки не дадут никакого оверхеда по сравнению с голым интом.

в теории могут - это ведь описывает даже не компилятор/стандарт, а x64 ABI.

Потеряли логгинг о ненайденном экстмарке в этом и двух следующих случаях.

Кидать исключение ради лога странно, лучше вставить логгирование перед return {}.

В каком случае вам нужно больше напрягаться, чтобы понять, что происходит?

в хаскеле, потому что я его не знаю, и потому что в нём логика задом-наперед.

Ловите все исключения, включая те, которые должны пробрасываться наверх. Недружественно к рефакторингу на будущее.

во-первых, вы выше заявили что функция должна возвращать optional и не кидать исключения. Во-вторых, я повторил поведение оригинала (ну, кроме логгинга). В-третьих, ну будет там тогда два разных catch блока с std::bad_variant_access и std::out_of_range вместо одного с std::exception, неужели это так принципиально?

О, а это интересно. По логике там никогда не должно оказаться пустого указателя, но на плюсах я не могу это выразить, поэтому приходится добавлять проверки (кто там что говорил про производительность)?

блин вы могли сказать "вот видите, я же допустил ошибку", на что я бы ответил "а вдруг специально?", но нет же, надо в дебри... Вы очень даже можете это выразить, просто не через shared_ptr, а сделав другой класс с необходимой семантикой. Единственное destructive move в с++ всё еще нет, поэтому сделать non-null unique_ptr будет проблемно.

В хаскеле таких ограничений тоже нет, там вы тоже можете кидать исключения, это не идрис и не агда. Просто исключения не видно в типах

где конкретно я вижу тип исключения в операции 5 / 0? Как это поможет по пунктам 1, 2, 3?

Поэтому их в любом языке лучше избегать.

удачи избегать их в доброй половине ЯП, ага

я потому и предлагаю смотреть на 10-15 летние тренды. То, что сейчас поднялся - ну ок, но до уровня его массовости в начале 2000х, например, куда как далеко

а потом мощности компьютеров стали позволять писать даже на языках с GC

ну и в вашей ссылке речь о С :)

вчитайтесь

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

Во-первых, с++ сильно производительнее большинства из этой массы современных языков. Экономить ресурсы на высокоуровневом ЯП куда сложнее, например, память в джаве или cpu в питоне. Во-вторых, я же никогда не пытаюсь доказать что с++ - самый безопасный и самый выразительный язык. Мой посыл как раз в том, что с годами он стал сильно удобнее и дал больше средств для обеспечения надежности. Настолько, что размен производительности на выразительность/безопасность становится куда менее очевидным. Большая часть ошибок, с которыми лично мне доводится иметь дело, чисто логические, которые я или мои коллеги допустили бы в любых ЯП. Что до меньшей части - ну буду я не дебажить краши, а оптимизировать боттлнеки, в общем случае это не быстрее.

Ну вы посмотрите на тренд за последние лет 10-15

Использование плюсов неуклонно снижается.

так уж прям неуклонно снижается? По данным stackoverflow доля с++ опять же заметно выросла за последние лет пять.

Правда, как и гугловская ставиться из каждого утюга, в том числе под видом драйверов асуса, и в тихую подменять браузер по умолчанию без явного подтверждения пользователем (через скрытые галочки, ага).

не только гугловская, эту тему почти все переняли. Я в этом виню лишь неспособность M$ сделать нормальный магазин приложений. В 10-ке кстати это поменяли - там браузер может максимум перенаправить пользователя в тот пункт настроек, который предлагает выбрать браузер по умолчанию. А в 11-й поменяли аж так, что пользователю должен настроить браузер программой по умолчанию для кучи видов ссылок/файлов. То есть еще более крутой заход в монополию - компьютерно-неграмотный пользователь попросту не сможет поменять браузер.

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

чтобы конкретный виджет перенаправлял в конкретный браузер можно просто запускать окно браузера в режиме "открой конкретно эту страничку". Вводить для этого отдельный ссылочный протокол, который доступен только M$, во-первых совершенно необязательно, а во-вторых, позволит перенаправлять в edge отовсюду, а не только из конкретного виджета. И в третьих, что важнее всего, это единственный протокол ссылок, для которого нельзя настроить программу-обработчик

PS. Я согласен на то, что подобные защиты должны наказываться. Но сразу после активного наказания тех, кто устанавливает свои браузеры и страницы пользователя основными путем обмана, как это делает гугл.

ну например у нас никогда не примут подобный закон, ведь он будет препятствовать "импортозамещению" браузеров.

Как справедливо заметили, transmute_copy принимает параметром не указатель, а ссылку, и это всё меняет.

приведение указателя к ссылке считается dereference'ом?

Ещё в списке не упонимается pointer provenance - тоже формально не описанное (или недоописанное) UB, но хорошо известное и принимаемое во внимание теми, кто пишет unsafe код. В остальном, список полный.

так pointer provenance и является причиной почему такой каст может приводить к UB...

Information

Rating
Does not participate
Location
Томск, Томская обл., Россия
Date of birth
Registered
Activity