Меня тут только explicit напрягает. Мол включить некоторые предупреждения по умолчанию это полезно, да, но не для explicit. Это буквально сломает добрую часть С++. Слишком много логики завязано на этой фиче и просто так запретить её было бы странно.
Лучше бы добавили правило в варнинги, мол тип который не является агрегатом должен указывать явно explicit он или нет. Тогда бы вещи типа С-структур бы работали, а вот всякие самописные менеджеры чего-либо - нет. Всё ещё бы потребовало переписывать кучу кода, но зато было бы +- понятным почему так сделано.
С explicit не будет работать часть низкоуровневых либ по софтварной эмуляции чего-то. Так же не будет работать математика, что значит писать так больше нельзя int x = (3.14 + у)*2, и надо будет учитывать все конверсии, что выглядит как лютый заморочь. А ещё с explicit не работает добрая половина способов инициализации перемнной, буквально ограничивая тебя 1-2 способами.
С [[nodiscard]] ты не сможешь пользоваться даже memcpy, ибо он неожиданно возвращает указатель который ты ему же и передал. Многие функции ОС тоже что-то возвращают и придётся писать кучу веток кода по обработке сколько символов в консоли ты написал, иначе тебе варнингов на пол экрана намолюет.
С лямбдами сложно, ибо в целом можно сделать чтоб компилятор сам строил лямбды, но это будет не везде решаемо. Мол как угадать переменная ссылка или значение? А это важно между прочим. Можно было бы сделать новый синтаксис как в С#, но для лямбд без захвата, тогда было бы прикольно, согласен.
С енумами непонятки какие-то, ибо это "отдельная сущность". Но всё же логично что класс означает что это "объект сам в себе с explicit кастом в дефолтный енум или специальный тип". Хотя меня бы устроило если бы дефолтный енум не сыпал своими членами в пространство имён, хотя это может через классы эмулировать, лол.
Ну да, расписали. Творчество работает из контекста, хаоса и уменьшения этого хаоса. Любой художник который абстракции делает это скажет - "в начале фигню намулевал, а тут вот дерево видно, а тут попугайчика. Тяп-ляп и картина готова", а если бы контекст, тн эмоции, были бы негативными, там вместо "дерева" был бы "взрыв бомбы", а "попугайчик" бы превратился в "мусор".
ЗЫ: Прикол нашей сетки лишь в том что она полносвязно-разряженная+активность копится. Мол ты смотришь на стол, что-то там зарядилось, смотришь на стул, бац! "Тут же поесть можно!" Для текущих ИИ такое невозможно, нужно либо память моделировать либо контекст широкий иметь. И из этого же строится потенциально более сложная творческая деятельность у биологических систем.
В крестах, есть моё любимое noexcept, который явно задаёт будет ли функция бросать исключение или нет. Это очень удобно если либа написана "правильно", ты дёргаешь вызов и с рукой у сердца понимаешь что тут ничего упасть не может. (А ещё эта гадость не может вычислится самостоятельно и тебе надо писать трёхэтажные метавыражения чтоб оно считалось правильно)
ЗЫ: ИМХО, исключения на то и исключения что это исключительные ситуации, а узнать открылся файл или нет можно из стейтов-кодов.
Просто в С++ много камней подводных. У тебя долгое время даже std::array мог создать UB на ровном месте, а ты бы даже этого не заметил.
Тут подоспел мем с "Давайте перепишем вселенную на Rust ", ибо они сделали невозможное, запихали всё что может ломаться в unsafe, а наружу торчит красивое и безопасное API и хомячки не переживают что случится отвал жопы в случайном месте (теперь они пытаются обойти тупые ограничения чтобы написать код похожий на С++)
ЗЫ и притом код компилит не хуже плюсов, что тоже плюс.
Самое грустное что существует тьма либ которыми все пользуются где есть UB и всем всёравно. Многие "старые" библиотеки для математики 3D графики используют union не правильно. Но эти либы стали чуть ли не отраслевым стандартом, особенно таких много для OpenGL.
Тут надо прям полностью базовые инструменты менять, чтоб это всё корректно работало, а это много работы.
Я смотрю они весь zerocost увели в такую вещь как compiletime. Теперь ты можешь на этапе компиляции сделать ну ОЧЕНЬ много вещей. Чуть ли не корутину собрать, что тебе только байтики скопировать нужно будет.
Пользуюсь их связью и в целом доволен, но вот денежная политика... Это буквально обдиралово, за такое судится надо.
Я не пользовался связью месяца 3, ибо уезжал. Приезжаю, интернет не работает, висит не оплачено, хорошо. Открываю ЛК там долг на ~4-5 тысячи, а тариф у меня 500р в месяц. Тоесть они заблокировали интернет за месяц неуплаты и начали начислять пени в 100% от суммы дополнительно продолжая добавлять потарифные счета. Прикольно чо могу сказать
Региональные провайдеры периодически показывают жизнь. Если какой-нибудь Ростелеком лежит, то вот сосед с какими нибудь "быстрые связи" нормально работает.
ЗЫ Неожиданно для себя обнаружил что ютуб съедал очень много свободного времени, я даже стал обедать раза в 3 быстрее. Хоть на этом спасибо, лол
Микрософт для этого SAL замутили (не прижилось). Правда оно только варнинги в консоли показывает и выглядит ужасно, зато работает)
Эта та самая штука где ты задаёшь огромную штору при каких параметрах/условиях оно должно работать. Есть те же фичи с in out out_optional и всякое такое. Посмотреть как это безобразие используется можно в исходниках по winapi, которые обычно с вижуалкой идут.
Статья эта какой-то мусор и не объясняет почему оно так работает.
Итак.... Любое чтение тривиального типа который не содержит значения является UB. Значение же приобретается либо в конструкторе(не дефолтном), либо в присвоением уже инициализированного объекта. Если тип это агрегат, в том плане что просто хранит другие тривиальные типы, то если он не до конца инициализирован, то обращение к этим не инициализированым полям или присвоение этого объекта другому тоже UB. И да, все встроенные/фундаментальные типы являются тривиальными по умолчанию.
Допустим, программист читает её умышленно (например, пишет программу-шпион). Тогда что ему делать?
Если до С++20, то копированием сырых байт в уже подготовленный объект. Если после С++20, то использовать bit_cast который по сути копирует уже подготовленные типы, если после С++23, то start_lifetime_as который не копирует а сразу представляет память как объект. В любых других случая молится господу что ваш конкретный компилятор сможет сгенерировать нужный вам код, или попытаться покалдовать с ассемблером или несовершенством линковки TU.
ЗЫ этот язык буквально ментальное оружие. Либо ты освоишь его и сможешь кабанов с одного выстрела убивать, либо тебе оторвёт ноги и ты будешь жаловаться что оно кривое и ваще я капитаном корабля хотел стать)
Ну если после университета идти, то в целом неплохо, соглашусь. Но лично у меня опыта хватает, просто так сложилось что я в серой зоне всё время был и стабильной зарплаты не было. В итоге хоть куда подался и, мягко говоря, был впечатлён как дела на нижних уровнях делаются. Платят чуть ли не как уборщице, а требуют вагон знаний, ибо владелец часто не разбирается что он хочет.
В итоге я соскачив с нестабильной работы и поработав на стабильной опять решил занятся нестабильной, не фриланс так производство оборудования всякого... Эххх
В целом это справедливо и для RISC. У них всё тот же микрокод. Просто там не так много выбора как именно сделать одно действие. У того же х86 просто загрузить данные в регистр можно кучей разных способов, кода у RISC на это всего одна-две команды.
Раньше развлекаясь нашёл забавную вещь. В х86 можно написать банальный for(i) цикл используя 2 байтную команду, но компилятор не использовал её ибо на целевом интуле это команда работала условно 40 тактов, а вот последовательность из +5 команд всего в 3 такта. (некоторые команды могут объединятся на конвейере)
Я в курсе как устроен CPU, писал свои процессоры на досуге.
В целом проблема CISC буквально только в декодере. Если мы берём традиционное представление CISC где команда может иметь переменное количество байт на команду, то выходит что мы просто физически не можем увеличить подачу инструкций на конвейер. Тоесть ограничены условными 3-4 командами на такт. Спасает то что эти команды обычно комплексные и позволяют закодировать 1-4 действия в одну команду, потому отставание не кажется таким уж существенным. Можно строить всякие эвристические декодеры, которые бы просто наугад кэшировали мопы для участков кода, но это буквально костыли)
В итоге потенциальный потолок у RISC архитектур выше, декодеры можно тупо в ряд делать получая свыше 8 инструкций на такт. Но всё же переменное кодирование инструкций очень полезная вещь, в современных RISC есть всякие флаги/режимы позволяющие менять размер команды на кратное двойке значение. Эдакий CISC на минималках. Что в целом является отличным компромисом между этими двумя типами архитектур.
Тоесть получаем CISC с командами переменной длины = зло, а CISC/RISC с командами перемнной длины кратные двойке = спасение. Почему кратные двойки? Вместо оценки длины команды и определения какому декодеры скармливать команду, мы можем тупо сделать матрицу из 16/32/64 битных декодеров и не получать издержек на определение длинн, как в традиционных CISC. В итоге на одном теоритическом декодере можно получить от 4 до 16 инструкций на такт, сильно да?
Боже, я тут шарюсь по помойкам в поисках опыта/стажа, в России тоже такое есть.
Тебя нанимают за 40к₽ на С++ софт написать или проект переписать какой, а в итоге ты -"java,Javascript,python,android,Linux,windows,opencv,ML,opticflow,SQL,qt/qml,rust,c/c++,с#,dsp,delphi" разработчик и желательно чтоб проект был готов завтра. А когда начинаешь намекать что это не норма и надо бы зарплату нормальную платить начинают фыркать "ну ладно, на 5к₽ зарплату поднимем".
Причём такие интересные конторы часто попадаются, и там зачастую сидит один техлид которому платят нормально и пачка студентов. (из рассказов знакомых)
Меня тут только explicit напрягает. Мол включить некоторые предупреждения по умолчанию это полезно, да, но не для explicit. Это буквально сломает добрую часть С++. Слишком много логики завязано на этой фиче и просто так запретить её было бы странно.
Лучше бы добавили правило в варнинги, мол тип который не является агрегатом должен указывать явно explicit он или нет. Тогда бы вещи типа С-структур бы работали, а вот всякие самописные менеджеры чего-либо - нет. Всё ещё бы потребовало переписывать кучу кода, но зато было бы +- понятным почему так сделано.
С explicit не будет работать часть низкоуровневых либ по софтварной эмуляции чего-то. Так же не будет работать математика, что значит писать так больше нельзя
int x = (3.14 + у)*2, и надо будет учитывать все конверсии, что выглядит как лютый заморочь. А ещё с explicit не работает добрая половина способов инициализации перемнной, буквально ограничивая тебя 1-2 способами.С [[nodiscard]] ты не сможешь пользоваться даже memcpy, ибо он неожиданно возвращает указатель который ты ему же и передал. Многие функции ОС тоже что-то возвращают и придётся писать кучу веток кода по обработке сколько символов в консоли ты написал, иначе тебе варнингов на пол экрана намолюет.
С лямбдами сложно, ибо в целом можно сделать чтоб компилятор сам строил лямбды, но это будет не везде решаемо. Мол как угадать переменная ссылка или значение? А это важно между прочим. Можно было бы сделать новый синтаксис как в С#, но для лямбд без захвата, тогда было бы прикольно, согласен.
С енумами непонятки какие-то, ибо это "отдельная сущность". Но всё же логично что класс означает что это "объект сам в себе с explicit кастом в дефолтный енум или специальный тип". Хотя меня бы устроило если бы дефолтный енум не сыпал своими членами в пространство имён, хотя это может через классы эмулировать, лол.
Ну да, расписали. Творчество работает из контекста, хаоса и уменьшения этого хаоса. Любой художник который абстракции делает это скажет - "в начале фигню намулевал, а тут вот дерево видно, а тут попугайчика. Тяп-ляп и картина готова", а если бы контекст, тн эмоции, были бы негативными, там вместо "дерева" был бы "взрыв бомбы", а "попугайчик" бы превратился в "мусор".
ЗЫ: Прикол нашей сетки лишь в том что она полносвязно-разряженная+активность копится. Мол ты смотришь на стол, что-то там зарядилось, смотришь на стул, бац! "Тут же поесть можно!" Для текущих ИИ такое невозможно, нужно либо память моделировать либо контекст широкий иметь. И из этого же строится потенциально более сложная творческая деятельность у биологических систем.
ВК это буквально файлопомойка. При должной сноровке можно найти видео любого уровня "морали"
В крестах, есть моё любимое
noexcept, который явно задаёт будет ли функция бросать исключение или нет. Это очень удобно если либа написана "правильно", ты дёргаешь вызов и с рукой у сердца понимаешь что тут ничего упасть не может.(А ещё эта гадость не может вычислится самостоятельно и тебе надо писать трёхэтажные метавыражения чтоб оно считалось правильно)ЗЫ: ИМХО, исключения на то и исключения что это исключительные ситуации, а узнать открылся файл или нет можно из стейтов-кодов.
В теории да, на практике любая подсистема в сотый-тысячный раз копирует метры таблиц и релокейтов и заново проводит инициализацию.
Когда уже динамические либы станут реально динамическими?
.del
Просто в С++ много камней подводных. У тебя долгое время даже std::array мог создать UB на ровном месте, а ты бы даже этого не заметил.
Тут подоспел мем с "Давайте перепишем вселенную на Rust ", ибо они сделали невозможное, запихали всё что может ломаться в unsafe, а наружу торчит красивое и безопасное API и хомячки не переживают что случится отвал жопы в случайном месте
(теперь они пытаются обойти тупые ограничения чтобы написать код похожий на С++)ЗЫ и притом код компилит не хуже плюсов, что тоже плюс.
Самое грустное что существует тьма либ которыми все пользуются где есть UB и всем всёравно. Многие "старые" библиотеки для математики 3D графики используют union не правильно. Но эти либы стали чуть ли не отраслевым стандартом, особенно таких много для OpenGL.
Тут надо прям полностью базовые инструменты менять, чтоб это всё корректно работало, а это много работы.
Я смотрю они весь zerocost увели в такую вещь как compiletime. Теперь ты можешь на этапе компиляции сделать ну ОЧЕНЬ много вещей. Чуть ли не корутину собрать, что тебе только байтики скопировать нужно будет.
А в данной фиче всё упрётся в реализацию, увы.
Пользуюсь их связью и в целом доволен, но вот денежная политика... Это буквально обдиралово, за такое судится надо.
Я не пользовался связью месяца 3, ибо уезжал. Приезжаю, интернет не работает, висит не оплачено, хорошо. Открываю ЛК там долг на ~4-5 тысячи, а тариф у меня 500р в месяц. Тоесть они заблокировали интернет за месяц неуплаты и начали начислять пени в 100% от суммы дополнительно продолжая добавлять потарифные счета. Прикольно чо могу сказать
Я так понимаю, прям из каропки решений нет. Приходится искать как это работает, что бы сделать хорошо
Региональные провайдеры периодически показывают жизнь. Если какой-нибудь Ростелеком лежит, то вот сосед с какими нибудь "быстрые связи" нормально работает.
ЗЫ Неожиданно для себя обнаружил что ютуб съедал очень много свободного времени, я даже стал обедать раза в 3 быстрее. Хоть на этом спасибо, лол
Микрософт для этого SAL замутили (не прижилось). Правда оно только варнинги в консоли показывает и выглядит ужасно, зато работает)
Эта та самая штука где ты задаёшь огромную штору при каких параметрах/условиях оно должно работать. Есть те же фичи с in out out_optional и всякое такое. Посмотреть как это безобразие используется можно в исходниках по winapi, которые обычно с вижуалкой идут.
Статья эта какой-то мусор и не объясняет почему оно так работает.
Итак.... Любое чтение тривиального типа который не содержит значения является UB. Значение же приобретается либо в конструкторе(не дефолтном), либо в присвоением уже инициализированного объекта. Если тип это агрегат, в том плане что просто хранит другие тривиальные типы, то если он не до конца инициализирован, то обращение к этим не инициализированым полям или присвоение этого объекта другому тоже UB. И да, все встроенные/фундаментальные типы являются тривиальными по умолчанию.
Если до С++20, то копированием сырых байт в уже подготовленный объект. Если после С++20, то использовать bit_cast который по сути копирует уже подготовленные типы, если после С++23, то start_lifetime_as который не копирует а сразу представляет память как объект. В любых других случая молится господу что ваш конкретный компилятор сможет сгенерировать нужный вам код, или попытаться покалдовать с ассемблером или несовершенством линковки TU.
ЗЫ этот язык буквально ментальное оружие. Либо ты освоишь его и сможешь кабанов с одного выстрела убивать, либо тебе оторвёт ноги и ты будешь жаловаться что оно кривое и ваще я капитаном корабля хотел стать)
Ну если после университета идти, то в целом неплохо, соглашусь. Но лично у меня опыта хватает, просто так сложилось что я в серой зоне всё время был и стабильной зарплаты не было. В итоге хоть куда подался и, мягко говоря, был впечатлён как дела на нижних уровнях делаются. Платят чуть ли не как уборщице, а требуют вагон знаний, ибо владелец часто не разбирается что он хочет.
В итоге я соскачив с нестабильной работы и поработав на стабильной опять решил занятся нестабильной, не фриланс так производство оборудования всякого... Эххх
В целом это справедливо и для RISC. У них всё тот же микрокод. Просто там не так много выбора как именно сделать одно действие. У того же х86 просто загрузить данные в регистр можно кучей разных способов, кода у RISC на это всего одна-две команды.
Раньше развлекаясь нашёл забавную вещь. В х86 можно написать банальный for(i) цикл используя 2 байтную команду, но компилятор не использовал её ибо на целевом интуле это команда работала условно 40 тактов, а вот последовательность из +5 команд всего в 3 такта. (некоторые команды могут объединятся на конвейере)
Я в курсе как устроен CPU, писал свои процессоры на досуге.
В целом проблема CISC буквально только в декодере. Если мы берём традиционное представление CISC где команда может иметь переменное количество байт на команду, то выходит что мы просто физически не можем увеличить подачу инструкций на конвейер. Тоесть ограничены условными 3-4 командами на такт. Спасает то что эти команды обычно комплексные и позволяют закодировать 1-4 действия в одну команду, потому отставание не кажется таким уж существенным. Можно строить всякие эвристические декодеры, которые бы просто наугад кэшировали мопы для участков кода, но это буквально костыли)
В итоге потенциальный потолок у RISC архитектур выше, декодеры можно тупо в ряд делать получая свыше 8 инструкций на такт. Но всё же переменное кодирование инструкций очень полезная вещь, в современных RISC есть всякие флаги/режимы позволяющие менять размер команды на кратное двойке значение. Эдакий CISC на минималках. Что в целом является отличным компромисом между этими двумя типами архитектур.
Тоесть получаем CISC с командами переменной длины = зло, а CISC/RISC с командами перемнной длины кратные двойке = спасение. Почему кратные двойки? Вместо оценки длины команды и определения какому декодеры скармливать команду, мы можем тупо сделать матрицу из 16/32/64 битных декодеров и не получать издержек на определение длинн, как в традиционных CISC. В итоге на одном теоритическом декодере можно получить от 4 до 16 инструкций на такт, сильно да?
Как всегда, правда где-то посередине
Боже, я тут шарюсь по помойкам в поисках опыта/стажа, в России тоже такое есть.
Тебя нанимают за 40к₽ на С++ софт написать или проект переписать какой, а в итоге ты -"java,Javascript,python,android,Linux,windows,opencv,ML,opticflow,SQL,qt/qml,rust,c/c++,с#,dsp,delphi" разработчик и желательно чтоб проект был готов завтра. А когда начинаешь намекать что это не норма и надо бы зарплату нормальную платить начинают фыркать "ну ладно, на 5к₽ зарплату поднимем".
Причём такие интересные конторы часто попадаются, и там зачастую сидит один техлид которому платят нормально и пачка студентов. (из рассказов знакомых)
Тоесть в итоге получаем, "теоретический CISC лучше, ибо по-сути представляет из себя сжатый набор команд закодированный по частоте использования"
На практике у нас есть только х86, который уже давно перестал быть оптимальным решением