Так как понедельник, всё плохо, надо начинать жизнь с чистого листа и всё такое, я решил сегодня сделать тему на эту тему.
Я сейчас пишу проект, где слишком много вещей, разложенных по контейнерам. Приходится много писать кода для обхода этих контейнеров и совершения различных действий. Как правило, три первые строчки очень похожи друг на друга: первый итератор, последний итератор(в случае неизменности контейнера, чтобы его каждый раз в цикле не вычислять, да, я зануда) и, собственно, цикл. Дальше по контексту. Рука тянется написать макрос, но что-то меня останавливает. К тому же я так и не понял, какие выгоды в данном случае мне дают лямбды.
В добавок ко всему, я прочитал триптих Андрея Платова на хабре, и понял, что я не один такой. В общем-то, я это давно понял, когда ещё к ним пытался устроиться на работу, но тут просто все звёзды сошлись.
И поэтому у меня возник вопрос, как оптимизировать разработки на сяхх? Какие бонусы мы получили с С11(14), чтобы можно было разрабатывать быстро? Где и как использовать лямбды? Где и как использовать универсальные ссылки и можно ли их как-то успешно использовать на просто функциях в качестве параметров? Это вопросы, за которые я могу пострадать, но хочется разобраться, почему жить стало лучше? С теми же смартпоинтерами я не ощутил радости, потому что когда их не было, все объекты у меня были спроектированы по их принципу, и я никогда не грел голову, что у меня где-то что-то не освободилось, и я недоумевал по поводу прям яростной ненависти многих Продвинутых Разработчиков к наличию delete(или goto) в коде, тем более, что когда-то без него было вообще никак. Да, мне приходилось расписывать деструкторы, и пару-тройку раз я где-нить да на накосячил, но это было пару раз. Сейчас читаю Мейерса "Эффективный и современный С++" и не ощущаю радости. В основном, книга сводится к "было сказано <%1%>, а я говорю вам <%2%>", иными словами, делайте теперь вот так, вместо того, как вы делали раньше вот так. Да, лямбды сделали работу чуть быстрее и гибче, ключевое слово "чуть" пока что для меня. Да, теперь в шаблонах есть универсальные ссылки, избавляющие нас от дублирования описания, как это было раньше, но кто-то раньше от этого сильно страдал? Я нет, я просто следил, за тем, что я передаю в эти функции и плясал от этого. С теми же смартпоинтерами можно более завуалировано(хрен сразу увидишь) накосячить, чем раньше открыто забыть что-то грохнуть. Т.е. по принципу того же Платова: сложность языка увеличилась, а скорость разработки как-то не очень. Я пока это не вижу. И это не наезд на С++, это попытка понять, как теперь разрабатывать? Потому что если смотреть с т.з. скорости и удобства на книгу Майерса, то... ничего в общем-то и не поменялось... :[
28.06 мне пришла в голову идея проекта, 30-го я начал делать прототип. Так как я читаю Скотта, то решил всё делать по науке, потому что пока тренироваться не на чем, в результате у меня до сих пор нету прототипа, хотя я потратил примерно часов 7-8 на разработку. Меня это печалит, сейчас я занимаюсь тем, что пытаюсь сделать енумератор с произвольным доступом для данных, основанный на контейнерах, и мне нифига не легче, чем лет 3-5 назад.

Т.о, самое главное, ради чего собственно создавалась тема(а не чтобы поплакать): поделитесь технологиями и приёмами, увеличивающими скорость/качество разработки. И как в этом был использован С++11/14?

Btw, есть (кроме буста) какие-то стандартные библиотеки для работы с xml?

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

Возвращаясь к напечатанному, одно время я сильно велосипедил и страдал от самого факта, от того, что велосипедить - это плохо. У меня было много проектов под Win32, для начала я сделал небольшую иерархию классов и заглушек, которая была похожа на MFC, что дало мне возможность использовать студийный класс-виззард. Это ладно, фигня. Больше всего я "страдал" от надстройки над вектором, которая под собой скрывала те самые вещи, в три строки, которые я выше описал. Эти вещи касались сериализации и прочей стандартной обработки, т.е. когда меня надо было контейнер с параметрами скинуть/зачитать из файла/реестра, я не писал циклов, я просто звал 1 соответствующую функцию. Там же внутри были всякие базовые проверки. В результате у меня на этой базе выросло нечто, что позволило мне связать сложные структуры данных с системами хранения, независимо от самих систем, и с GUI. И это было удобно! Кто помнить MFC-шный DDX? Там надо было написать макрос на 1 параметр/контрол, потом в коде звать UpdateData в нужных местах( позже я увидел что-то подобное с событиями в QT, но у меня они были привязаны к Win32, да). У меня была ровно одна строчка для привязки контрола к параметру. При этом можно было 1 параметр привязать к нескольким контролам, и если один из них менялся юзером, система автоматом меняла остальные, без всяких вызовов UpdateData(где надо помнить, TRUE/FALSE - в какую сторону), при этом я получил бонусом, что изменяемые параметры накатывались сразу, прям во время работы с контролами, в программу, и юзер мог видеть, как оно, не нажимая каждый раз OK, чтобы посмотреть, чего и как настроилось, и там же была система отката по кнопке Cancel(правда, надо было ещё одну строчку написать в OnCommad, но не беда), потому что в классе параметра была система для Backup/Restore. Это всё экономило мне уйму времени, вкупе с шаблонами-кубиками для построения приложений, которые у меня появились в процессе разработок.

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

mayton, да, он самый. Придумыватель Силиконовой Тайги.
блин, только сейчас увидел ошибку в первом слове, вот так всегда :(

SiemarglПо топику - эволюция с++ в плане удобства разработчика:
-STL дала безопасность
-лямбды дали удобство там, где получались страшненькие по виду каллбэки
-крупные библиотеки типа буста уменьшили велосипедостроениеа можно про это подробнее?
Остальное меня не затронуло, но я мало пишу на С++, предпочитая из-за удобства разработчика С# Ну вот... о_О
alex_kа как же


? зачем итераторы?Спасибо, надо будет глянуть, что там внутри. Btw, на 2010-й студии всё-таки какой компилятор? Он такую конструкцию не понимает. auto понимает.
alex_kПо моему мнению - оптимизация разработки, это сокращение возможных ошибок. Чем больше ошибок найдет компилятор, тем меньше их найдет пользователь. К тому же компилятор покажет пальцем, а пользователь - нет.

А отсюда - константность, шаблоны, static_assert, override, enum class.Это всё да, но хотелось бы какого-то повышения уровня абстракций :(

alex_kавторСпасибо, надо будет глянуть, что там внутри.
Там внутри begin() и end() контэйнера, которые обязаны вернуть объект, который может ++, != и *.
Для последовательного набора элементов проканает и обычный указатель :)
Вот end() меня напрягает, что его каждый раз оно скрыто считать будет. Метод универсальный, да, но часто end() за весь цикл один и тот же.


MasterZivCEMb,

так используй

for(:)

там не надо никаких итераторов...не понял о_о

У меня ещё вопрос по 11 сямм. Если у меня, например, конструктор принимает r-ссылку, есть 2 оператора =, с r-ссылкой и с константной ссылкой (const Cls& и Cls&&), то почему при вызове из этого конструктора вызывается оператор = для работы с константной ссылкой, а не rvalue-ссылкой? Приходится кастовать заново std::move.

MasterZiv. К тому же я так и не понял, какие выгоды в данном случае мне дают лямбды.

никаких.
для лямбды надо применять не циклы, а функции высших порядков, transform, for_each
и так далее. ясно, надо изучать и пробовать, чтобы разобраться.
И поэтому у меня возник вопрос, как оптимизировать разработки на сяхх?

э... ммм... как это? Может кодирование? для примера: можно вскапывать огород лопатой, а можно взять мотоблок, и всё пойдёт быстрее. Или плуг. Или экскаватор. Или динамит. Вариантов много под разные нужды. А можно вообще руками, да.
Какие бонусы мы получили с С11(14), чтобы можно было разрабатывать быстро?

ну, много их, тот же for(:) а ещё?
Сейчас читаю Мейерса "Эффективный и современный С++" и не ощущаю радости.

Радость - она не здесь, радость - это уйти в открытое море на парусной яхте или с шорохом лететь с вершины вниз по снежной целине на доске, когда вокруг только снег, горы и верные друзья... Хочется от коддинга тоже получать радость. Я вот один проект делаю на стороннем фреймворке, у которого есть "наследование" в классах через динамический eject объектов в класс-ноду. Это даёт возможность быстро и удобно наполнять объекты нужными свойствами и другими объектами, а так же быстро с ними работать. Вот коддинг, а особенно разработка архитектуры в этой среде у меня вызывает радость, хотя бы потому что способствует придумыванию многих интересных решений. Просто потому что архитектура такая.
А тут тебе просто дали новую автоматическую отвертку, чтобы тебе было удобнее крутить шурупы. Чуть больше комфорта, и всё. Хочу больше отвёрток. Как в той же яве.
дальше у тебя непонятно...

Т.е. по принципу того же Платова: сложность языка увеличилась, а скорость разработки как-то не очень.

кто такой Платов, я не знаю, но скорость разработки в общем скорее не этим всем определяется. Не, он приводил в пример Scala, как сильно усложнённый язык, приводил аргумент, что допускает, если усложнение языка даёт ускорение разработки. Как оправдание усложнению. Т.е. зачем делать язык сложнее, если это ничего (кроме понтов) не даёт? Поэтому, почитав про 11/14, я вижу усложнение языка, и задаю вопрос, что мы получили взамен за это усложнение.
Я пока это не вижу. И это не наезд на С++, это попытка понять, как теперь разрабатывать? Потому что если смотреть с т.з. скорости и удобства на книгу Майерса, то... ничего в общем-то и не поменялось... :[

ну, на самом деле очень многое поменялось. с т.з. скорости и удобства?
28.06 мне пришла в голову идея проекта, 30-го я начал делать прототип. Так как я читаю Скотта, то решил всё делать по науке, потому что пока тренироваться не на чем, в результате у меня до сих пор нету прототипа, хотя я потратил примерно часов 7-8 на разработку. Меня это печалит, сейчас я занимаюсь тем, что пытаюсь сделать енумератор с произвольным доступом для данных, основанный на контейнерах, и мне нифига не легче, чем лет 3-5 назад.

Ну, если у тебя личный затык, при чем тут язык и изменения в нем? да, у меня затык, но всё из-за того самого велосипедостроения.
я бы вообще не делал энумераторы, соотнеси множество твоих объектов с множеством натуральных целых, и все пока, а потом, когда все сделаешь, сверху прилепишь итератор.
у меня там мапа. Хочется, чтобы сторонний алгоритм, не задумываясь про индексы и внутреннюю структуру вообще, говорил мапо-содержащему объекту что-то типа GetFirst/GetNext, получал некий объект из мапы и работал с ним, сам решая, брать следующий или нет. Т.е. цикл отвязан от мапы. Но эту проблему я решил, вчера после написания "статьи", я просветлился, взглянул на свой код иначе, и всё переписал, как надо :) так что теперь в случае затыков, буду практиковать тут

maytonРадует твоя способность вносить шум в обычные слова. Коддинг это что? Изучение трудов Эдгара Кодда?Написание кода.
maytonИ кстати, хотел-бы напомнить что разработчик получает деньги за реализацию фич или возможностей а не за
"придумывание интересных решений"Ну я и тем и другим занимаюсь. В том и прелесть, я придумываю всё мне ставят довольно общие, абстрактные задачи, типа "сделать хорошо", я придумываю как, потом это курится с архитекторами и аналитиками, потом после курения я это кодю. Кожу. Кодирую, в общем. maytonВобщем если ты хочешь казаться умным - то бери Scala.
Ну вот у Платова как-то почти ровно так и было сказано. Но я не хочу казаться умным. Мне вообще пофиг, как я кажусь. У меня проблема в том, что скорость генерации идей у меня сильно превосходит скорость их воплощения.

Anatoly MoskovskyВаше стремление оптимизировать код похвально.Не, без фанатизма. Такой вынос итераторов разумен только в коде, близком к real-time, какие-то обработки по несколько тысяч раз в секунду и прочее. На точечных событиях смысла не имеет.
Anatoly MoskovskyВеселит только ваша уверенность что вы это сделаете лучше самого компилятора Ну, когда я с графикой работал, я смотрел код, сгенерённый компилятором, и если мог, заменял сишный кода на асмовые вставки, чтобы было быстрее.

Anatoly MoskovskyCEMbПоэтому, почитав про 11/14, я вижу усложнение языка, и задаю вопрос, что мы получили взамен за это усложнение.
Нет никакого усложнения.
Новые стандарты - 11, 14, 17 это не какие-то фантазии комитета стандартизации, а просто фиксация сложившейся практики. Т.е. сначала это было кем-то реализовано, признано успешным и полезным, и только потом внесено в язык.
Да, это понятно. Это доведение языка до ума.

Anatoly MoskovskyВообще не имеет смысла.
Т.к. компилятор в случае шаблонов видит весь код и выносит за пределы цикла константные конструкции.
Хмм. Не верю :) Внутри цикла могли быть вызовы функций, которые меняют содержимое контейнера. Неужели компилятор будет проверять все вероятные вызовы, вплоть до того, что могут быть указатели на функции и другие нетривиальные вещи, отследить которые на уровне компиляции нереально.

maytonА можешь пример привести что за С++ компиллятор был и что ты заменял на асм-вставки?
Начиналось всё с MS VC6.0. Ну, например, я memcpy/memset заменил себе на dwdcpy/dwdset

но это, наверно, не считается, но работало быстрее.
Ну вот нашёл кусок кода заливки:

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

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

alex_kА еще добавились std::thread, std::mutex, std::lock_guard и т.д.вот! А где хорошие документации на эту тему?

Нашёл на вид неплохую документацию

MasterZivвчера прочитал с трудом все три опуса по ссылке. Это их надо было читать, или это просто ссылка на автора? просто ссылка на автора и на его мысль, с которой всё началось: скорость разработки
ну это не программист, это гопник какой-то...
че его слушать...хмм, но мысль про требование от ЯП скорости (и удобства и простоты) разработки, я считаю, разумная. Всё становится очевидно, когда разрабатываешь продукт сам, тогда время становится одним из ключевых факторов, оно почти всегда против тебя(только после релиза оно на твоей стороне). И чем быстрее ты сделаешь продукт, тем лучше.

MasterZivУже ж удобнее, нет разве ? Ну, на вид вроде удобно. Но верхние два типа теперь можно через std:: описать. Про остальное судить нельзя без взгляда на реализацию и использование. Описание (иерархии) классов одних и тех же вещей может сильно меняться в зависимости от целей и перспектив развития.