Стандарт C++17 официально сегодня

Со все большим и большим распространением header-only библиотек, особенно шаблонных, это далеко не так просто.

1. Так и шаблоны нужно использовать только там, где они нужны.
2. Модули, полагаю, и должны решить проблему header-only.

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

месье пишет свой стл на каждый проект ? или приватная реализация ?

Купи себе уже терабайтный диск. Или ты один из тех, что верит, что вся вся либа в каждый проект вкомпилячивается намертво?

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

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

ааа я понял. Ты послдний раз С++ видела в 1998 году верно? Вопрос-детектор. На сколько try catch замедляет исполнение?

Так у вас игры что - шашки.

А вы их видели? :)

Вот если бы вы хотели AAA и мощу и чтоб летало, вот тогда бы на чистом Си писали, да.

Пойду расскажу разработчикам unreal engine, что они ошиблись с выбором языка. На си у них работало бы все быстрее и его поддержка была бы проще.

Точно-точно. И под каждую систему - своя реализация. А так - фьють полный, а не игры.

Код игры один и тот же, движок тот же (да, все на абстракциях). Ресурсы могут отличаться из-за разной ориентации или разрешения экрана.

1. Так и шаблоны нужно использовать только там, где они нужны.

Ну вот std::vector<T> в публичном интерфейсе какого-то класса? Или shared_ptr<T>? Или, допустим, какой-нибудь json_document<default_encoding>?

2. Модули, полагаю, и должны решить проблему header-only.

Так Iron_Bug говорит, что все это суета и тлен.

Ты послдний раз С++ видела
видела

мля серьезно? Всегда думал, что это просто хипарь с длинными волосами. Тогда вопросов вообще нет, все вдруг стало ясно-понятно.

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

Android, Android TV

А разница-то? Адаптировать гуй и научить игру пользовать геймпады. ИМХО, это можно даже не включать в список.

Да, пожалуй разницы особой и нет. Как и в случае с iOS и tvOS. Очень мелкие отличия.

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

man сарказм

1. Так и шаблоны нужно использовать только там, где они нужны.

Ну вот std::vector<T> в публичном интерфейсе какого-то класса? Или shared_ptr<T>? Или, допустим, какой-нибудь json_document<default_encoding>?

Потому я и сказал - только там, где нужно.

Так Iron_Bug говорит, что все это суета и тлен.

Да она вообще какую-то хню несет.

я последний раз С++ видела, когда писала онлайн тарификацию для ОПСОСа. было это лет шесть назад. и try catch в таких проектах не используются. вероятно, один был, где-то снаружи всего процесса. но такие проекты не швыряют исключения без необходимости. и там никто не измеряет замедление от оператора, который может сработать раз в год.

да, ещё как-то я писала систему трассировки и упаковки корешков на Гознаке. работает там как часы. и там тоже не было try-catch'ей (может, был один, и то вот не припоминаю). в серьёзных проектах это не нужно. аварийные ситуации там означают неправильно написанный софт.

man сарказм

Ну хз, видимо слишком тонко для меня.

Потому я и сказал - только там, где нужно.

Ну так вот достаточно в каком-то проекте заюзать что-то вроде boost-овых flat containers или чего-то аналогичного, но шаблонного, как окажется, что следы какого-нибудь flat container-а видны чуть ли не в каждом заголовочном и cpp-файле. Как только внесешь правку в этот flat container так и получай полный ребилд.

При этом не сказать, что шаблоны здесь не по делу :(

я последний раз С++ видела, когда писала онлайн тарификацию для ОПСОСа. было это лет шесть назад.

В свете этого ваши высказывания по поводу C++, сделанные на этом форуме за последние 2-3 года, начинают выглядеть совсем уже феерично.

а что мешает его изучать? я его не использую в работе, но это не значит, что я на нём не пишу.

я его не использую в работе, но это не значит, что я на нём не пишу.

я последний раз С++ видела, когда писала онлайн тарификацию для ОПСОСа. было это лет шесть назад.

Кто-то либо болен, либо путается в показаниях.

нет. серьёзным использованием языка я считаю использование его в больших проектах. в этом смысле многие тут вообще на С++ никогда не писали :)

я писала довольно крупные проекты в своё время. файловый обмен Сбербанка, Таможни. софт для Гознака (припахали меня в соседний отдел для помощи, хотя я больше работала с драйверами, микроконтроллерами и библиотеками низкого уровня), софт для телекома. этого достаточно, чтобы знать С++ не просто хорошо, а очень хорошо.

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

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

Простите мне мой французский, но с хрена ли?

Ладно бы вы libstdc++ или libc++ разрабатывали, или разрабатывали компилятор C++, ну или были бы автором той же Boost.Lambda... Тогда еще можно было бы поверить в «очень хорошо».

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

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

ну, приглашали писать такое. но я что-то не хочу сейчас плюсами заниматься.

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

а вся ваша типобезопасность - это для студентов. шаблонная магия туда же. шаблоны - примитив, так-то. хотя, у меня была одна поделка: скриптоязык для создания стендов для тестирования харда. на плюсах. вот там была шаблонная магия кое-где. там как раз мне были нужны variadic templates. а их тогда ещё не было в маздае. поэтому я перешла в gcc под mingw. зато эта софтина нам потом очень помогала создавать стенды и прототипы машин для гознака, для банковских сортировщиков и многого другого. удобная шняга получилась. и я потихоньку пилю её расширенный аналог, чисто из любопытства. более усовершенствованный. это так, просто свой домашний проектик.

Джавистам и прочим она покажется ещё маленькой. Да и выбор? Писать кривые велосипеды в каждом проекте, как сишники или плюсовики из девяностых?

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

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

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

Какие еще страшные слова вы знаете? Блин, либо у вас ЧСВ чрезмерное, либо вы действительно не можете поверить в то, что здесь кроме вас еще кто-то со всем этим сталкивался и не считает это чем-то из ряда вон.

Ну и главное: как из всего этого следует хорошее знание именно C++? Например, тонкости выбора подходящей перегрузки. Или знание argument dependent lookup.

нет, но я вижу, что вас почему-то пугают шаблоны. я этого не понимаю. есть вещи действительно трудные. а есть просто семантика языка. это как умение читать. так вот шаблоны - это основа. а всё сверху: алгоритмы, сложная обработка данных - это уже программирование. вы пока что тут обсасываете алфавит со всех сторон и утверждаете, что в нём малабукаф. но всем С++93 хватало за глаза, и всё работало. и вдруг стало мало. так что речь тут не о программировании. тем более, что я везде вижу слово «легко», которым вы ловко подменяете тормоза в софте и рост потребления ресурсов. и я этого не понимаю и не принимаю.

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

Ну так вот достаточно в каком-то проекте заюзать что-то вроде boost-овых flat containers или чего-то аналогичного, но шаблонного, как окажется, что следы какого-нибудь flat container-а видны чуть ли не в каждом заголовочном и cpp-файле. Как только внесешь правку в этот flat container так и получай полный ребилд.

Ну так это весьма печальная организация проекта. Нужно стараться избегать таких зависимостей.

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

нет, но я вижу, что вас почему-то пугают шаблоны.

Да, некоторые я тупо не понимаю.

но всем С++99 хватало за глаза,

Отучаемся говорить за всех.

и всё работало.

Так оно работало и задолго до C++98, что для вас может быть удивительно. Даже под MS-DOS-ом и Borland Turbo C++. Вопрос был лишь в стоимости телодвижений.

тем более, что я везде вижу слово «легко», которым вы ловко подменяете тормоза в софте и рост потребления ресурсов. и я этого не понимаю и не принимаю.

Пример вас не затруднит привести? Где я что подменяю?

А то пока это вы сливаетесь на простых вопросах. Например, когда opendir стал доступен в Visual C++?

Вставлю 5 копеек: C++ 2003 не хватало много кому. Variadic templates и стандартизованная модель памяти, как минимум, были нужны как воздух. Стандартные умные указатели (не smart_ptr) тоже были нужны всем, кто не Линус Торвальдс. move-семантика, встроенная в язык, позволила избавиться от кучи жутких костылей. Короче, C++11 привнес кучу изменений и все они так или иначе нужны многим программистам. А С++14 и С++17 довольно минорные обновления стандарта, никаких особых революций.

Ну так это весьма печальная организация проекта.

С чего бы? Вас же не смущает, когда у вас std::string используется для интероперабильности между модулями проекта? Или std::set<std::string>. А потом обнаружили, что вам выгодно в каких-то случаях использовать some_library::flatset<std::string>.

Что в этом печального?

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

С чего бы? Вас же не смущает, когда у вас std::string используется для интероперабильности между модулями проекта? Или std::set<std::string>. А потом обнаружили, что вам выгодно в каких-то случаях использовать some_library::flatset<std::string>.
Что в этом печального?

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

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

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

зачем мне opendir? я его не использовала. и тем более не помню, когда он стал доступен в маздае. я не маньяк, я программист. и мне не нужно учить историю появления каких-то частных вызовов в каких-то библиотеках. а вы сейчас задаёте идиотские вопросы. опять же, нубские. потому что только нуб учит наизусть стандартные вызовы и может гордиться тем, что он помнит, когда они там появились. программист думает над другими задачами. да и маздай я видела в последний раз в 2007-м. почему я это помню: я переписывала дрова для 64-битной семёрки и очень материлась по этому поводу. там уродливая архитектура. с тех пор больше к маздаю я не возвращалась ни на работе, ни, тем более, дома, чему очень рада.

зачем мне opendir? я его не использовала.

Поделитесь секретом, как кроссплатформенно рекурсивно обойти иерархию директорий?
Понятно, что в виндовс есть свои FindFirstFile/FindNextFile. Но мне интересно ваше кроссплатформенное решение.

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

но вопрос ведь в том, что это просто не нужно!

Я фигею, дорогая редакция.

в реальной жизни это не будет нужно на 99.99%

Вопрос только в чьей реальной жизни.

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

зачем мне opendir? я его не использовала.

Тогда зачем вы себе позволяете вот такое:

внезапно, они там есть, со времён posix. есть абсолютно всё, что требуется более-менее постоянно.

opendir — это как раз то, что требуется более-менее постоянно. Только вот с кроссплатформенностью у него так себе.

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

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

ВОТ ЭТО ТЫ МАТУШКА ОТОЖГЛА

Хотя... всё можно свалить на «юзерский софт». Вот, например, mpd, который рекурсивно сканирует медиаколлекцию - это юзерский софт? А это, внезапно, сервер, управляемый по сети.

А веб-сервер, разруливающий кучу HTMLек?

Это уже какой-то тупняк, мадам.

«Правильное» (в вашем смысле) дерево include возможно только для непосредственной бизнес-логики программы.

Всё остальное — различные контейнеры, логгеры, таймеры, обработчики ошибок и пр. инженерщина — неизбежно будет пускать свои корни в каждый первый объектник.

Обычно эта инженерщина составляет очень существенную часть программы (80%, если по Парето), потому что C++ это вам ни разу не DSL, а ровно наоборот. А учитывая, что часто такие вещи как раз пишутся header-only, постоянная перекомплиция становится суровой реальностью.

opendir — это как раз то, что требуется более-менее постоянно

вот мне он ни разу не был нужен. серверные приложения не шарятся по винту. они получают конфиг и начинают работу. всё прописано жёстко. конфиг лежит известно где. там не нужно лазить по ФС и что-то сканировать, если ты не rsync. но rsync я не писала.

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

как кроссплатформенно рекурсивно обойти иерархию директорий?

<trollmode>QDir</trollmode>

но это закрытый код и я его не распространяю.

Про закрытый код все понятно. Я думал, может где открытый код есть. При такой школе вряд ли вы для себя говнокодите лучше, чем для Сбербанка.

вот мне он ни разу не был нужен. серверные приложения не шарятся по винту.

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

Поделитесь секретом, как кроссплатформенно рекурсивно обойти иерархию директорий?

fts_open() же.

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

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

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

нуб сам себе портит жизнь и обвиняет в этом компилятор. и ради ЭТОГО тащат в стандарт какие-то модули-шмодули, всякую муету.

Отсутствие модулей порождает отсутствие контроля над элементарными вещами.

К примеру, если в паскалевском uses пропустить какой-то нужный модуль, компилятор гарантированно отругается на первом неизвестном символе. А пропущенный #include в C/C++ может на одной версии включаемой библиотеки вызвать ошибку, а на другой нет (ну просто на другой в этом заголовочнике случайно оказалось то, что нам нужно). Ошибка «undefined reference to vtable for...» - это вообще пир духа, она может возникнуть по 6 или 8 причинам, и совершенно не там, где кроется её причина.

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

Это с вами нет смысла продолжать разговор. Полное непонимание преимущества кроссплатформы налицо