1. Пост и так получился довольно большим. Всегда приходится балансировать между тем, что можно впихнуть в текст и тем, что следует поместить в текст, чтобы текст оставался интересным и познавательным.
2. Когда ты погружен в тему, не всегда просто понять, какие очевидные для тебя вещи вовсе не являются таковыми для стороннего читателя.
Имхо, как раз комментарии нужны для того, чтобы люди могли задать вопросы к тексту. Например, вопрос «Почему weak_ptr не использовался в качестве прокси-ссылки на агента?» дает мне понять, что именно хочет узнать читатель. Тогда как реплика «weak_ptr же» оставляет меня в недоумении, я не понимаю, что хочет сказать человек, что он понимает, что принимает в расчет, что нет. Отсюда и попытка выяснить, для чего weak_ptr упомянут в комментарии.
Но если проблема решается слабыми указателями, то почему она упоминается?
Еще раз: какая проблема решается?
Вы видите часть проблемы, обнаруживаете какой-то знакомый вам паттерн и пишете в комментарии weak_ptr. Что я должен додумывать за вас дальше?
Вы считаете возможным в качестве условного agent_ref-а отдавать пользователям weak_ptr? Ну OK. Отдадите. Во-первых, тогда вы решите какую-то свою проблему, а не нашу. Во-вторых, вот возьмет пользователь и вызовет weak_ptr::lock и сохранит надолго возвращенный shared_ptr. Фактически это тоже самое, что вы просто будете обмениваться shared_ptr-ами напрямую. В-третьих, у вас реализация будет гвоздями прибита к shared_ptr/weak_ptr. И вы не сможете просто так поменять типы своих умных указателей (например, на указатели без атомарного счетчика ссылок для однопоточного режима работы). Получится, что вам все равно нужно отдать пользователю какой-то собственный agent_ref. Будет ли внутри него weak_ptr или что-то другое — это уже деталь реализации, от которой пользователь зависеть не должен.
А вторую проблему, на первый взгляд, логичней решать создавая специальный актор-повторитель один ко многим и т.п.
Ну решите ее с учетом того, что единственным механизмом взаимодействия акторов является асинхронный обмен сообщениями. Который, в принципе не надежен. Может вам понравится ваша реализация подписки/отписки для broadcasting actor-а исключительно на асинхронных сообщениях.
На маленьких объемах данных std::map эффективнее. unordered_map начинает обгонять когда элементов оказывается от сотни и больше. Тут же не ожидается большого набора элементов.
Вот тут очень хорошая документация, на мой взгляд.
На меня эта документация произвела впечатление сделанной «на отвали». Может, чтобы опакетить какой-нибудь hello_world из одного .cpp-файла она и достаточна, но понимания того, как это все работает не оставляет.
Но вы можете считать это предвзятым мнением автора =)
Именно таким его и остается считать. Если остальные нововведения вполне хорошо объясняются с технической точки зрения и можно наглядно показать, что это ведет к тем или иным выгодам (как в понятности кода и сокращению пространства для ошибок, так и в его эффективности), то данное утверждение является вкусовщиной, не более того.
а вводить постоянно синонимы — в cpp-файлах неудобно, в заголовках неприемлемо.
Да, это еще одна сторона данной проблемы. Где-то это пересекается с проблемой autotools (т.е. определение макросов типа HAVE_something для учета особенностей конкретной платформы). Где-то посредством макросов регулируются фичи самой библиотеки (элементарный пример: сборка в виде статической или динамической библиотеки). В любом случае с этим приходится считаться.
В переводе на русский это означает «не разбираюсь, но мнение имею».
2. Проблема напечатать в стандарте «это деприкейтед»? Охотно верю.
Что вы собрались помечать как «деприкейтед»? Вот в C++11 так пометили std::auto_ptr, а из C++17 вообще уже выбросили. Что никак не отразилось на проектах, которые все еще живут на C++98/03, приносят деньги и в обновление которых владельцы кода не особо хотят вкладываться.
Но интересно, что вы собрались помечать в стандарте как «деприкейтед» касательно систем сборки и управления зависимостями?
3. «Развитие легаси». Делом лучшей займитесь, тогда может и у вас появится система сборки, собирающая любой проект одной командой.
Удивлю вас, но у нас есть и своя система сборки, и своя система управления зависимостями. Свои проекты в итоге собираются одной командой. Главный вопрос при этом: «Что делать с не своими?». Так что я говорю о том, в чем хоть чуть-чуть разбираюсь, в отличии от.
Впрочем прожект-лиду что-то объяснять бесполезно.
Можно ли развернуть подробнее? Если бы в профиле стоял какой-то другой шилдик, вроде «system architect» или «co-founder» — это что-то бы изменило?
По большому счету, проблема не столько в менеджере зависимостей, сколько в том, что в C++ нет де-юре (да и де-факто так же) стандартной системы сборки. Поэтому взять и подтянуть в свой проект исходники нужных зависимостей — это даже не полдела. Это вообще элементарно.
А вот собрать все это с учетом зоопарка компиляторов и платформ — вот это самое печальное. В Rust-е такой проблемы нет, т.к. сам Rust пока:
во-первых, представлен всего одним компилятором, поэтому нет надобности заботиться о скриптах сборки для совершенно разных компиляторов/линкеров с совершенно разными наборами ключей;
во-вторых, не страдает от того, что кто-то вынужден сидеть на компиляторах 3-, 5- или даже 10-ти летней давности. Из-за чего при сборке нужно проверить, какой компилятор в наличии и что он поддерживает. Да и не только компилятор, но и ОС (отчего autotools все еще в ходу на Unix-ах);
в-третьих, Rust пока еще не представлен на таком же спектре платформ, как C и C++. Некоторые из которых весьма специфические и без какого-то аналога autotools там не обойтись.
Так что догонять Cargo в C++ — это в принципе бесполезное занятие. Нужно что-то, чтобы учитывало реалии C++.
А есть какая-нибудь хорошая инструкция о том, как делать пакеты для conan-а? Именно хорошая инструкция, чтобы можно было проштудировать и таки сделать пакет.
PS. С conan-ом дела не имел, поэтому не знаю, насколько хороша их собственная документация.
И вот, когда Степанов придумал как с помощью шаблонов можно сделать плохое, кривое, но… всё-таки, работающее метапрограммирование — язык C++ стал чем-то большим.
Это когда это Степанов придумал метапрограммирование на шаблонах? Степанов реализовал на шаблонах C++ свои идеи по обобщенному программированию, которые у него были еще с начала 1980-х. А метапрограммирование на шаблонах — это, как минимум, 1995-й год, когда STL уже был и его включали в первый стандарт C++.
Во-первых, у вас устаревшая информация о том, как развивается поддержка современного C++ в VC++: инфа от 15-го ноября сего года.
Во-вторых, по сравнению с тем, как быстро появлялась поддержка предыдущих стандартов в VC++ (начиная с C++98) — это все просто огромный прогресс для VC++.
1. Пост и так получился довольно большим. Всегда приходится балансировать между тем, что можно впихнуть в текст и тем, что следует поместить в текст, чтобы текст оставался интересным и познавательным.
2. Когда ты погружен в тему, не всегда просто понять, какие очевидные для тебя вещи вовсе не являются таковыми для стороннего читателя.
Имхо, как раз комментарии нужны для того, чтобы люди могли задать вопросы к тексту. Например, вопрос «Почему weak_ptr не использовался в качестве прокси-ссылки на агента?» дает мне понять, что именно хочет узнать читатель. Тогда как реплика «weak_ptr же» оставляет меня в недоумении, я не понимаю, что хочет сказать человек, что он понимает, что принимает в расчет, что нет. Отсюда и попытка выяснить, для чего weak_ptr упомянут в комментарии.
Вы видите часть проблемы, обнаруживаете какой-то знакомый вам паттерн и пишете в комментарии weak_ptr. Что я должен додумывать за вас дальше?
Вы считаете возможным в качестве условного agent_ref-а отдавать пользователям weak_ptr? Ну OK. Отдадите. Во-первых, тогда вы решите какую-то свою проблему, а не нашу. Во-вторых, вот возьмет пользователь и вызовет weak_ptr::lock и сохранит надолго возвращенный shared_ptr. Фактически это тоже самое, что вы просто будете обмениваться shared_ptr-ами напрямую. В-третьих, у вас реализация будет гвоздями прибита к shared_ptr/weak_ptr. И вы не сможете просто так поменять типы своих умных указателей (например, на указатели без атомарного счетчика ссылок для однопоточного режима работы). Получится, что вам все равно нужно отдать пользователю какой-то собственный agent_ref. Будет ли внутри него weak_ptr или что-то другое — это уже деталь реализации, от которой пользователь зависеть не должен.
Ну решите ее с учетом того, что единственным механизмом взаимодействия акторов является асинхронный обмен сообщениями. Который, в принципе не надежен. Может вам понравится ваша реализация подписки/отписки для broadcasting actor-а исключительно на асинхронных сообщениях.
Утверждалось, что есть две проблемы. И если для решения одной weak_ptr может применяться, то что со второй?
А если для решения второй проблемы weak_ptr не применим, то зачем заводить разговор о weak_ptr?
Это что, была главная и единственная проблема? Или где-то утверждалось, что weak_ptr не может быть такой прокси-ссылкой?
А еще что-нибудь есть?
Еще одно предвзятое мнение автора.
Что вы собрались помечать как «деприкейтед»? Вот в C++11 так пометили std::auto_ptr, а из C++17 вообще уже выбросили. Что никак не отразилось на проектах, которые все еще живут на C++98/03, приносят деньги и в обновление которых владельцы кода не особо хотят вкладываться.
Но интересно, что вы собрались помечать в стандарте как «деприкейтед» касательно систем сборки и управления зависимостями?
Удивлю вас, но у нас есть и своя система сборки, и своя система управления зависимостями. Свои проекты в итоге собираются одной командой. Главный вопрос при этом: «Что делать с не своими?». Так что я говорю о том, в чем хоть чуть-чуть разбираюсь, в отличии от.
Можно ли развернуть подробнее? Если бы в профиле стоял какой-то другой шилдик, вроде «system architect» или «co-founder» — это что-то бы изменило?
Очевидно, что вы даже не представляете себе насколько.
Откуда 99%? Из вашего уютного менямирка? Как вы думаете, какую часть рынка C++ разработчиков сейчас составляет поддержка и развитие легаси кода?
А вот собрать все это с учетом зоопарка компиляторов и платформ — вот это самое печальное. В Rust-е такой проблемы нет, т.к. сам Rust пока:
Так что догонять Cargo в C++ — это в принципе бесполезное занятие. Нужно что-то, чтобы учитывало реалии C++.
PS. С conan-ом дела не имел, поэтому не знаю, насколько хороша их собственная документация.
Во-вторых, по сравнению с тем, как быстро появлялась поддержка предыдущих стандартов в VC++ (начиная с C++98) — это все просто огромный прогресс для VC++.