Оратор рассуждал об реализации? Я критикую реализацию — в чём суть претензий?
Далее, я критиков не только реализацию, но и сам язык(отсутствие у шаблонов вменяемых возможностей необходимых для реального метапрограммирования, впендюривание всяких кастылей вместо вменяемых вещей) — если кто-то несогласен — пусть отвечает, а пока я вижу только минусование от бессилия.
Если же вырезать стандартную библиотеку из крестов — останется си с классами. Здесь говорится именно о современном С++ суть которого именно в этой стандартной библиотеки. Вырезать её можно и из си.
Любые операции требующие реаллокации — та же конкатенация. Аллокатор сам по себе. Алгоритмы, которые в гцц/шланге просто циклы(допустит тот же реплейс на строке есть for вместо вменяемой лоулетенси реализации memchr()) — да куда не глянь везде засада.
А уж если у тебя не glibc, нынче модная musl(или что там щас модно) — замедление всех string/mem-функций гарантированно, да и сами глибцешные имплементации хоть и лучшие, но не идеальные.
Если попроще. Допустим, все string/mem-функции в том же глибц представляют из себя набор реализаций для разных случаев и рантайм диспатчер — который спокойно бы свёртывался компилятором если бы функции были инлайн. Далее благодаря всяким концептам можно было бы узнать выравненные-ли и как данные, приоритетные типы операций. str.find(«test») — оно мне в компилтайме посчитает префикс-функцию? Вернее тут она не нужна, но всё же. Сгенерирует оптимальную оптимальную реализацию для данного паттерна?
Я уж не говорю о том, что всё это спокойно экспортируется и в рантайм + прикручивается жит.
Для всего этого и нужно серьёзное мета-программирование, а не для max() и интерфейсов — там достаточно генерик-типов. Ничего из этого нет, но всё это бальные основы оптимизации. И их нет.
Люблю хабр. Теги(цитаты, а они были и в предпросмотре были.) пропадают, изменить нельзя, ответить никто по-существу не может, а минусовать — дак всегда пожалуйста. Ну уличите меня в неправоте — это же так просто, если вы не просто от бессилия минусуете.
Ещё один «не осиливший».
Естественно не осилившие.
Наверное, поэтому весь STL заоптимизирован по самые гланды, чтобы при каждом удобном случае вызвать наиболее эффективную операцию.
Это не правда. Если мы говорим об имплементациях стл — основная оптимизация там — уход от обобщенных имплементаций. Это основной признак того, о чём забыли упомянуть в статье, но что является устойчивым мифом в среде пользователей шаблонных интерфейсов — обобщенные реализация не состоятельны.
Возьмём гццешную стл(одно из самых, если не самая) — является не более, чем генерик-интерфейсом к glibc. Т.е. все оптимизации сводятся к выпиливанию любого обобщения. Во всём остальном, что не является интерфейсом в glibc — никакими оптимизациями и не пахнет, ибо они попросту невозможны.
Я не заметил разоблачения этого мифа в статье, но он очень популярен среди пользователей генерик-интерфейсов — они верят в оптимальные генерик-имплементации. Основан он на вере в мистическую силу компилятора, т.е. по-факту компилятор должен предоставить нам все имплементации оптимальные для каждого конкретного типа. Что опять же противоречит убеждению в том, что обобщенная реализация состоятельна как оптимальная.
Стандартный сишный аллокатор во всех либц(который является основой С++ аллокатора во всех известных мне реализациях) очень плох. Но не это самое главное — плох и сам интерфейс, который не поддерживает реалок — т.е. его даже заменить нереально. Даже вменяемая конкатенация строк просто невозможна в рамках этого интерфейса.
Глибцешный маллок — это тонна оверхеда по памяти, это дыры и адское месиво в хипе, ибо инстанс один на тред. Т.е. все контейнеры спископодобные обречены. Залил туда 10килло чистых данных — решил получить лентенси л1д — stl подарит тебе нежданчик с летенси л2. А т.к. инстанс один, то между элементами будут дырки от других аллокаций и лучшем случае получишь нежданчик ввиде летенси stlb, а в худшем вылезешь за stlb.
Далее — реализация того же «O(1)» хешмапа обладает адских оверхедом по памяти — там не 10, не 100, не 1000 крат оверхеда. Хотя пользователи stl редко видят больше килобайта чистых данных.
Вектор может поставить раком целый тред(на штеуде поставит раком и соседние треды, ибо выжрет 70%трупута рамы) на полсекунды из-за реаллокации чисто из-за того, что не умеет в реаллок(да, да, в реальном мире реаллок не копирует память, даже если возвращает другой адрес).
Поэтому об оптимизации в стл говорить не приходится — этим никто не занимается, да и это невозможно.
Наверное, именно поэтому в C++11 ввели возможность переноса и пробрасывания.
Почему в С++ вообще существует разница между копирование объекта и полей? Правильно — причина в самом С++, а вернее в raii. Т.е. перемещение является кастылём для raii, но никак не какой-либо оптимизацией.
Да и сам новый тип ссылок решает 2проблемы — отсутствие возможности передать r-value по не константной ссылки, а так же новая перегрузка операторов/конструкторов. Всё это нужно из-за всяких раишных понятий владения.
В сишке передаётся копия полей, указатель — никаких проблем. Нераишный вектор передаётся спокойно копией полей безо всяких кастылей.
А сама raii показала свою полную несостоятельность — привет никакущие строки в С++, а так же все попытки создать нераишные строки(привет string_view).
Наверное, именно поэтому думают о введении сопрограмм.
Это очередной кастыль для реализация ассинхронных интерфейсов в крестах, при этом адски тормазной.
Он просто не имеет смысла, а тот кто его проталкивает — использует его для обёртки над сишными интерфейсами, т.е. для разделения одной функции на множество калбеков, хотя ничего не мешает их написать руками. Т.е. функции типа: f() {data = read(); write(data);} будут преобразованы к read((data d){write(d);}); А там уже есть aio, epoll и уже с ним. Если использовать классы — там нет никаких проблем с контекстом — он хранится в самом объекте.
Но насколько я понял — такая техника у майкрософт не осилилась(да и она не возможна в С++) и они решили пойти путём стеков и контекстов, что есть адский оверхед.
В современных реализациях стандартной библиотеки короткие строки хранятся прямо внутри указателя. То есть память не выделяется в куче, а скопировать такую строку — всё равно, что скопировать целое число.
Чё? Это невозможно. Можно пруфцы?
Показательно, что автор говорит не только о вариативных шаблонах, но и об обыкновенных.
Обожаемая мною, как и автором, вера в шаблоны верующих. Выше я уже объяснил почему обобщенные имлементации несостоятельны.
Если ещё один миф о шаблонах, как о рантайм вычислениях, рантайм аргументах и иже с ним. Это не имеет смысла для современных компеляторов без которых С++ не существует. Миф о «метапрограммировании» так же является мифом в связи со скудными возможностям шаблонов — допустим, ещё никто не смог написать рантайм-принтф. Нет понятия «рантайм-память». В связи с этим тонна кастылей, которые еле-еле работают и собираются тыщу лет.
Осталось только «шаблонный аргумент» и «вычисления crc в рантайме», но как я уже сказал — это умеет делать любой компилятор. godbolt.org/g/15h2UV — поиграйся.
В конечном итоге шаблоны имеют смысл только для написания генерик-интерфейсов, но написание сих интерфейсов адская боль в районе пятой точки. Шаблонны самое неудобное из того, что можно придумать.
Вместо того, чтобы ввести вменяемый интерфейс к f(...) {} и рефлекшн — выкатывают адские кастыли на шаблонах. f(… -> struct arglist {}) {for(arg: arglist) {} }.
Современный C++ позволяет писать как никогда простой, понятный и быстрый код.
Современный С++ позволяет писать быстро. Всё остальное враньё.
При этом просто и быстро там только тогда, когда применение С++ ограничено использованием интерфейса. Когда дело доходит до реализации этих самых интерфейсов проявляются все особенности крестов.
Вот и основная мотивация, которую пытаются скрыть под «доступом к знаниям» и прочему. Конкурентоспособность на внешнем рынке труда — всё остальное в подавляющем большинстве случаев враньё и притворство.
Это почему это инженер/ученый/разработчик в компьютерном мире не может быть профпригодным без языка? Какие основание для этого есть, кроме отсутствия локальной школы(которую ничего не мешает создать на базе любого языка)?
Носитель языка находится в более выгодном положении на этом рынке труда, а основе мотивации всех этих рассуждений лежит обида, желание, недовольство сим фактом — т.е. желание получить на халяву то, что потом можно продать подороже. Получение доступа к информации, которая не доступна, либо не существует на родном — это то же причина, но более редкая и необходимая в основном высокому профессиональному уровню. Для рядового программиста это не особо нужно.
В рашке есть множество хороших школ где можно учиться языку самому, либо учить детей — это не такая уж непосильная ноша.
Далее, почему поднятие с колен именно через подражание и догонялки(в лучшем случае интеграцию), а не через создание альтернативы? При этом в первом случае любой «подниматель России с колен» будет в проигрыше(не сейчас, а в будущем) и решить её можно только став носителем языка(т.е. заведя трактор).
Каким образом ученики-не носители будут читать литературу на английском, даже если они его учат со школы — когда они его выучат в полной мере для коммуникации с носителями и чтения сложной литературы? Только через англофицирование всей страны, а оно надо?
А почему именно историю росссии изучать не надо, а другую надо? Какие такие «часы» на патриотизм, какая-такая «военная» подготовка и что за «примыкающая к ней» литература?
Прям воняет ангажированностью, да и вообще — завёл трактор, что-то имеешь против — имей дальше, зачем изливать свои безучастные потуги нагадить?
Опять же, недальновидность и балабольство. Хорошо — все будущие солдаты, режим против не солдатов, а собственно что уже опять каменный век, где «солдат» бегает с дубиной? Или колбаса на деревьях растёт вместе с калашами? Получается так, наверное. Ладно — оставим логику, т.е. ваши потуги с нею не совместимы, но всё же.
Проблема в рендере не в том, чтобы нарисовать, а в том, чтобы двигать. То, что эту анимацию сняли с человека — толку с этого? Как это поможет в данной теме?
https://www.youtube.com/watch?v=zPw1PNErON8
Типичное доказательство того, что на нулевом(уровне находится рендер)
Далее, я критиков не только реализацию, но и сам язык(отсутствие у шаблонов вменяемых возможностей необходимых для реального метапрограммирования, впендюривание всяких кастылей вместо вменяемых вещей) — если кто-то несогласен — пусть отвечает, а пока я вижу только минусование от бессилия.
Если же вырезать стандартную библиотеку из крестов — останется си с классами. Здесь говорится именно о современном С++ суть которого именно в этой стандартной библиотеки. Вырезать её можно и из си.
А уж если у тебя не glibc, нынче модная musl(или что там щас модно) — замедление всех string/mem-функций гарантированно, да и сами глибцешные имплементации хоть и лучшие, но не идеальные.
Если попроще. Допустим, все string/mem-функции в том же глибц представляют из себя набор реализаций для разных случаев и рантайм диспатчер — который спокойно бы свёртывался компилятором если бы функции были инлайн. Далее благодаря всяким концептам можно было бы узнать выравненные-ли и как данные, приоритетные типы операций. str.find(«test») — оно мне в компилтайме посчитает префикс-функцию? Вернее тут она не нужна, но всё же. Сгенерирует оптимальную оптимальную реализацию для данного паттерна?
Я уж не говорю о том, что всё это спокойно экспортируется и в рантайм + прикручивается жит.
Для всего этого и нужно серьёзное мета-программирование, а не для max() и интерфейсов — там достаточно генерик-типов. Ничего из этого нет, но всё это бальные основы оптимизации. И их нет.
Естественно не осилившие.
Наверное, поэтому весь STL заоптимизирован по самые гланды, чтобы при каждом удобном случае вызвать наиболее эффективную операцию.
Это не правда. Если мы говорим об имплементациях стл — основная оптимизация там — уход от обобщенных имплементаций. Это основной признак того, о чём забыли упомянуть в статье, но что является устойчивым мифом в среде пользователей шаблонных интерфейсов — обобщенные реализация не состоятельны.
Возьмём гццешную стл(одно из самых, если не самая) — является не более, чем генерик-интерфейсом к glibc. Т.е. все оптимизации сводятся к выпиливанию любого обобщения. Во всём остальном, что не является интерфейсом в glibc — никакими оптимизациями и не пахнет, ибо они попросту невозможны.
Я не заметил разоблачения этого мифа в статье, но он очень популярен среди пользователей генерик-интерфейсов — они верят в оптимальные генерик-имплементации. Основан он на вере в мистическую силу компилятора, т.е. по-факту компилятор должен предоставить нам все имплементации оптимальные для каждого конкретного типа. Что опять же противоречит убеждению в том, что обобщенная реализация состоятельна как оптимальная.
Стандартный сишный аллокатор во всех либц(который является основой С++ аллокатора во всех известных мне реализациях) очень плох. Но не это самое главное — плох и сам интерфейс, который не поддерживает реалок — т.е. его даже заменить нереально. Даже вменяемая конкатенация строк просто невозможна в рамках этого интерфейса.
Глибцешный маллок — это тонна оверхеда по памяти, это дыры и адское месиво в хипе, ибо инстанс один на тред. Т.е. все контейнеры спископодобные обречены. Залил туда 10килло чистых данных — решил получить лентенси л1д — stl подарит тебе нежданчик с летенси л2. А т.к. инстанс один, то между элементами будут дырки от других аллокаций и лучшем случае получишь нежданчик ввиде летенси stlb, а в худшем вылезешь за stlb.
Далее — реализация того же «O(1)» хешмапа обладает адских оверхедом по памяти — там не 10, не 100, не 1000 крат оверхеда. Хотя пользователи stl редко видят больше килобайта чистых данных.
Вектор может поставить раком целый тред(на штеуде поставит раком и соседние треды, ибо выжрет 70%трупута рамы) на полсекунды из-за реаллокации чисто из-за того, что не умеет в реаллок(да, да, в реальном мире реаллок не копирует память, даже если возвращает другой адрес).
Поэтому об оптимизации в стл говорить не приходится — этим никто не занимается, да и это невозможно.
Наверное, именно поэтому в C++11 ввели возможность переноса и пробрасывания.
Почему в С++ вообще существует разница между копирование объекта и полей? Правильно — причина в самом С++, а вернее в raii. Т.е. перемещение является кастылём для raii, но никак не какой-либо оптимизацией.
Да и сам новый тип ссылок решает 2проблемы — отсутствие возможности передать r-value по не константной ссылки, а так же новая перегрузка операторов/конструкторов. Всё это нужно из-за всяких раишных понятий владения.
В сишке передаётся копия полей, указатель — никаких проблем. Нераишный вектор передаётся спокойно копией полей безо всяких кастылей.
А сама raii показала свою полную несостоятельность — привет никакущие строки в С++, а так же все попытки создать нераишные строки(привет string_view).
Наверное, именно поэтому думают о введении сопрограмм.
Это очередной кастыль для реализация ассинхронных интерфейсов в крестах, при этом адски тормазной.
Он просто не имеет смысла, а тот кто его проталкивает — использует его для обёртки над сишными интерфейсами, т.е. для разделения одной функции на множество калбеков, хотя ничего не мешает их написать руками. Т.е. функции типа: f() {data = read(); write(data);} будут преобразованы к read((data d){write(d);}); А там уже есть aio, epoll и уже с ним. Если использовать классы — там нет никаких проблем с контекстом — он хранится в самом объекте.
Но насколько я понял — такая техника у майкрософт не осилилась(да и она не возможна в С++) и они решили пойти путём стеков и контекстов, что есть адский оверхед.
В современных реализациях стандартной библиотеки короткие строки хранятся прямо внутри указателя. То есть память не выделяется в куче, а скопировать такую строку — всё равно, что скопировать целое число.
Чё? Это невозможно. Можно пруфцы?
Показательно, что автор говорит не только о вариативных шаблонах, но и об обыкновенных.
Обожаемая мною, как и автором, вера в шаблоны верующих. Выше я уже объяснил почему обобщенные имлементации несостоятельны.
Если ещё один миф о шаблонах, как о рантайм вычислениях, рантайм аргументах и иже с ним. Это не имеет смысла для современных компеляторов без которых С++ не существует. Миф о «метапрограммировании» так же является мифом в связи со скудными возможностям шаблонов — допустим, ещё никто не смог написать рантайм-принтф. Нет понятия «рантайм-память». В связи с этим тонна кастылей, которые еле-еле работают и собираются тыщу лет.
Осталось только «шаблонный аргумент» и «вычисления crc в рантайме», но как я уже сказал — это умеет делать любой компилятор. godbolt.org/g/15h2UV — поиграйся.
В конечном итоге шаблоны имеют смысл только для написания генерик-интерфейсов, но написание сих интерфейсов адская боль в районе пятой точки. Шаблонны самое неудобное из того, что можно придумать.
Вместо того, чтобы ввести вменяемый интерфейс к f(...) {} и рефлекшн — выкатывают адские кастыли на шаблонах. f(… -> struct arglist {}) {for(arg: arglist) {} }.
Современный C++ позволяет писать как никогда простой, понятный и быстрый код.
Современный С++ позволяет писать быстро. Всё остальное враньё.
При этом просто и быстро там только тогда, когда применение С++ ограничено использованием интерфейса. Когда дело доходит до реализации этих самых интерфейсов проявляются все особенности крестов.
Это почему это инженер/ученый/разработчик в компьютерном мире не может быть профпригодным без языка? Какие основание для этого есть, кроме отсутствия локальной школы(которую ничего не мешает создать на базе любого языка)?
В рашке есть множество хороших школ где можно учиться языку самому, либо учить детей — это не такая уж непосильная ноша.
Далее, почему поднятие с колен именно через подражание и догонялки(в лучшем случае интеграцию), а не через создание альтернативы? При этом в первом случае любой «подниматель России с колен» будет в проигрыше(не сейчас, а в будущем) и решить её можно только став носителем языка(т.е. заведя трактор).
Каким образом ученики-не носители будут читать литературу на английском, даже если они его учат со школы — когда они его выучат в полной мере для коммуникации с носителями и чтения сложной литературы? Только через англофицирование всей страны, а оно надо?
Прям воняет ангажированностью, да и вообще — завёл трактор, что-то имеешь против — имей дальше, зачем изливать свои безучастные потуги нагадить?
Опять же, недальновидность и балабольство. Хорошо — все будущие солдаты, режим против не солдатов, а собственно что уже опять каменный век, где «солдат» бегает с дубиной? Или колбаса на деревьях растёт вместе с калашами? Получается так, наверное. Ладно — оставим логику, т.е. ваши потуги с нею не совместимы, но всё же.
Типичное доказательство того, что на нулевом(уровне находится рендер)