Всім привіт, є бажання долучитись до існуючого опенсорс проекту.
Побажання:
1. С++11/14 — обовязково
2. ± добре спроектована архітектура, аби повчитися хорошим практикам, а не афігевати з костилів — обовязково
3. багатопоточність — опціонально
Хто що може порадити з цього приводу.
Коментар порушує правила спільноти і видалений модераторами.
Перелопать кучу, может найдешь что
github.com/fffaraz/awesome-cpp
www.quora.com/…in-clean-C 11-14?share=1
fffaraz.github.io/awesome-cpp
± добре спроектована архітектура, аби повчитися хорошим практикам, а не афігевати з костилів
В книгах пророків, які їх придумали. В реальному світи шукати не рекомендую.
З невеликих і свіжих можеш глянути на
github.com/Microsoft/cpprestsdk
Понимаешь в чем дело — все эти С++ХХ — детище кабинетных теоретиков, поэтому количество полезного кода на них стремится к нулю.
Хочешь поломать голову — займись какой-нибудь Скалой.
Не зовсім погоджуюсь, знаю мінімум дві контори тільки у Львові, де пиляють великі комерційні проекти на 11 плюсах.
Пилят != запилили.
Два проекта это капля в море.
В світі С++ 6 років(відколи з"явився 11 стандарт), це, по суті, доволі незначний період, враховуючи, що більшість плюсових проектів живуть значно більше, тому я б поставив на те, що нові проекти таки будуть з"являтися і доля С++11( а в подальшому 14, 17, 20... стандартів) тільки буде рости.
Нихрена. Обычно, если продукт ждут, то его начинают использовать еще на этапе альфа-версий, а к официальному релизу уже подключаются широкие массы.
С новыми версиями С++ этого не произошло, потому что он заметно усложняет разработку не давая разработчикам взамен сколь-нибудь значимых плюшек.
Вот конкретно — какие бизнес-нужды могут потребовать перевода разработки на новый стандарт?
Ну, наприклад, на проекті використовували boost, з приходом 11 стандарту більшість корисних фіч вже є або необхідність написання аплікацій під сучасні багатоядерні мобільні пристрої, новий стандарт включає вже std::thread, примітиви синхронізації, таймери і багато іншого.
Ну, наприклад, на проекті використовували boost,Библиотеку больше похожую на ящик с секонд-хендом, а не разумно организованный проект, как например, STL.
необхідність написання аплікацій під сучасні багатоядерні мобільні пристрої,что есть для языка общего применения глубоко частным случаем и должно быть вынесено в целевые библиотеки-фреймворки, а не жить в ядре.
новий стандарт включає вже std::thread, примітиви синхронізації, таймери і багато іншого.Спасибо Кэп.
вещи очень зависимые от архитектурыНу кагбе на плюсах завжди писали платформозалежні речі.
и в приципе не должны присутсвовать в ядре языка.Та ну, джава і шарп мають механізми для роботи з потоками а плюси не повинні мати?
Ну кагбе на плюсах завжди писали платформозалежні речі.Например линукс... #trollface
с простынями #ifdef-ов, так себе портабельность
В коде всяких линуксов их не избежать. В прикладном можно совсем без них.
Я вот данный момент сношаю проект с прикрученным внешним boost::threads, чтобы он примерно одинаково работал на Винде, полдесятке Линуксов и всяких BSD/SunOS-ах.
Бог миловал — все только на 64 бита.
В Джаве и Шарпе есть такая штукаб как виртальная машина.
И то говорят — разница чувствуется.
Примитивы синхронизации, а тем более многопоточность и многоядерность это вещи очень зависимые от архитектуры процессора, контроллера памяти и операционной системыА также от напряжения на процессоре и температуры ядра. Только людям пофиг, они как писали CreateThread/pthread_create, так и будут писать. (Люди любят абстрагирование — оно позволяет им не поехать головой от сложности систем, с которыми они работают.)
Т.е. с кросс-платформой серьезно не сталкивались.
жжоте)
Ничего, что многое в STL переходит из буста? Знакома ли Вам, например, скорость работы контейнеров boost.multi_index? Или возможности asio? Странный вы.
А вам знакома концепция — «в ядре языка только минимально необходимое»?
Боюсь, что нет.
Юзали буст и в ус не дули
Можно-нельзя — очень частный случай — решаем по месту, а тянем каждую каку в стандарт.
Что не произошло? Я с 2013 года работал только на С++11/14. То что Вам не повезло попасть на 11/14 проекты не значит что их нет.
С
А «везения» такого мне даром не надо, я и канонического
как вышел 14 стандарт и компиляторы стали его поддерживать, так некоторые проекты и попереходили
а то что стараетесь, это понятно, я к тому что проекты есть и на 14 и на 11 стандартах. просто Вы написали что мол
к официальному релизу уже подключаются широкие массы.— а я утверждаю обратное
С новыми версиями С++ этого не произошло
избегайте дальше, пожалуйста, нам работы больше и меньше конкуренции, а значит выше рейты
Простите, кто на ком стоял?
С того стандарта тока лямбда-функции использую. На остальное нет времени и желания.
Да и ставить Визуал студию 2015 под новые стандарты чето не хочется. У меня все на 2013 все прекрасно работает и, самое главное, не гробит комп.
А auto!? Если всё нет ВСЁ писать как auto выглядит же ж ох... ох как!
і доля С++11 тільки буде рости
тогда в следующей редакции auto сократят
то впилять то випилять, вони хоть знають що хочуть?
це був сарказм, якщо що)
Право, давно бы выучили английский и почитали, кто сейчас программирует на С++ХХ, чтобы немного выйти за пределы IT в Украине.
Так поведай же благую весть Человек-без-Линкедина.
github?
ЗЫ:
2. ± добре спроектована архітектура, аби повчитися хорошим практикам, а не афігевати з костилів — обовязковов опенсорс майже ніде хіба що насправді то «опенсорс» лише формально а фактично було кимось єдиним розробником написане а «комюніті» просто його прийняло (ну а куди їм тупеньким дівацця?) і тоді метод пошуку зміщюється від проектів до людей яких саме і слід відслідковувати от «долучитись» сумнівно але ж завжди можна зробити власний форк і додати фічу якої не вистачає славноруч.
ЗІ: якщо же ж основна ціль «потусить у середовищі крутих чуваків і типу в них повчитися» то не вийде бо опенсорс традиційно г... болото простітє.
«опенсорс» лише формально а фактично було кимось єдиним розробником написане а «комюніті» просто його прийняло
Незавжди. Є проекти, що підримуються (або були створені) організаціями: NASA, Qt, тощо. Яскравий приклад — GSoC там дуже багато проектів на C++, які хостяться на GitHub.
Ну я же ж і кажу «хіба що хтось його написав і вже потім формально опенсорс...» от геть от як Qt саме же ж чудовий же ж приклад.
Набор мини-проэктов. С++11 приветствуется, многопоточность нужна, архитектуры нет. Хотя зря я так, там где GUI, что-то отдалённо похожее на архитектуру прослеживается.
Вау! Цікаво, виходить що дехто навіть перейшов за посиланням.
Насколько помню, в Abiword используется местами новый стандарт.
Chromium очень приятно хачить, хотя костылей хватает. Node.js внутри очень простой (я в V8 не лезу) — но там не очень чистый C++ (ну и регулярно приходится в JavaScript вылазить).
Нюанс в тому, що у проектів типу Chromium або Firefox взагалі свої style guide по C++
developer.mozilla.org/…Using_CXX_in_Mozilla_code
chromium-cpp.appspot.com
Навряд чи топікстартер хоче «вдосконалюватись» в цьому напрямку.
Chromium Style Guide основан на Google C++ Style Guide. Это просто немного обрезанный С++, но многие вещи из С++ 11/14 можно использовать. Большой плюс проекта в том, что можно разрабатывать/собирать на любой операционной системе (Windows, Linux, macOS). Минус в том, что все платформы (кроме iOS) собирается безумно долго.
Этот стайл гайд основан на Гугловском, который достаточно разумный. Я бы настойчиво рекомендовал с ним ознакомится.
Я не зовсім зрозуміло висловився — малося на увазі саме те, що стиль даних проектів накладає деякі обмеження (а-ля do not use try/catch or throw any exceptions). Про гугловський гайд-стиль я взагалі не можу судити, по тій причині, що C++ знаю дуже поверхово (останній раз щось писав ще в епоху Watcom 10.5)
Я сделал пару лет назад эксперимент — написал qsort реализацию, которая в одном варианте возвращала булевое, если натыкалась на дубликат, в другом — бросало исключение. Потом оба варианта скомпилировал одной версией clang и сравнил сортировку массива без дубликатов. Больше вопросов к отказу от исключений не имею.
Ну официально в хромике исключения не используются из-за того, что они сами затянули старый код без исключений, и никто не брался гарантировать его exception safety или переписать все.
из-за того, что они сами затянули старый код без исключений, и никто не брался гарантировать его exception safety или переписать все.
Не поэтому. А вот поэтому:
www.chromium.org/…build/c-exception-support
Хотя, подозреваю, проблема ещё и в косяках с портированием.
П.С. В гугле, по умолчанию, весь «плюсанутый» код — без исключений. Т.к. исключения запрещены гугловским «кодинг гайдлайном».
Сразу видно, люди знают толк в разработке и «плюсоводстве». :)
Постучись к мертвожрачке в личкрафты, скажи что от луннозадого. Удачи.
1. С++11/14 незачем.
2. Ищи проект по теме, которая нравится. Скажем, если нравится контуперная графика — вводи в гугле что-нибудь типа «c++ image processing library» или «c++ computer vision library» и изучай. Найдёшь много и оупенсорсного тоже.
1. С++11/14 незачем.Зможете аргументувати?
У C/C++ осталась определённая ниша:
— высокопроизводительные системы/клиенты
— часто портабельные на разные операционки
— включая портабельность на обделённый ресурсами мобайл и прочий эмбед
Во всех этих пунктах — «11/14» это никому не нужный (и даже мешающий портабельности) костыль.
В принципе, мешают портабельности и производительности уже даже «++» (в частности, исключения, виртуальное наследование, итп продвинутые фичи, не поддерживаемые многими компиляторами) — но из-за части полезных и поддерживаемых фич (типа дженерик, классы) «плюсы» всё-таки пользуют.
В общем, посмотри разные проекты (особенно, крупных систем) — ты сам увидишь, какой стандарт «плюсов» тебе есть смысл осваивать.
Ви написали якісь дуже дивні речі.
— часто портабельные на разные операционки
— включая портабельность на обделённый ресурсами мобайл и прочий эмбедНі, на плюсах пишуть платформозалежні речі, часто, аби витискати максимум з конкретного девайса, а не з прицілом на переносимість.
Во всех этих пунктах — «11/14» это никому не нужный (и даже мешающий портабельности) костыль.Раніше часто доводилось вигадувати свої костилі і приплітати сторонні ліби, новий стандарт дозволює без цього всього обійтись, окрім того, багато речей, які писались руками, тепер оптимізовані.
В принципе, мешают портабельности уже даже «++» (в частности, исключения, виртуальное наследование, итп продвинутые фичи, не поддерживаемые многими компиляторами) — но из-за части полезных и поддерживаемых фич (типа дженерик, классы) «плюсы» всё-таки пользуют.Це ж який компілятор не підтримує експепшини і віртуальне наслідування?
В общем, посмотри разные проекты (особенно, крупных систем) — ты сам увидишь, какой стандарт «плюсов» тебе есть смысл осваивать.та ось вже близько 5 років дивлюсь і приймаю участь в різних вдалих і не дуже комерційних проектах, спілкуюсь з людьми і моніторю вакансії і дійшов висновку, що опановувати новий стандарт таки потрібно.
Ні, на плюсах пишуть платформозалежні речі...
Слушай гуру и не перечь. :)
С++11/14 must have:
-менше кода (lambda, auto)
-більше оптимізація (move, constexpr)
-більше вміє із-коробки (баготопоточність, регулярні вирази, файлова система)
-пофікшені вади старого С++ (auto_ptr, string.data, std::copy)
Повністю згоден і можу додати ще більше.
Але і проблемми теж є, той макс трохи згущає краски, але мислить в правильному напрямку.
От ми на своєму проекті досі не маємо 100% підтримки 11 стандарту. (не вистачє дріниць, тих самих constexpr) просто через те, що на одній з платформ не можемо проапгрейдити компілятор, бо в то впирається робота іншого тіма.
Это вы ещё не добрались до портирования в прекрасный мир консолей. :)
А когда доберётесь до эмбеда — и вовсе получите чудесное. Там под многие процессоры, нет даже компилятора «плюсов» (за сложностью и ненадобностью).
Это вы ещё не добрались до портирования в прекрасный мир консолей. :)Да нет, мы как раз таки недавно из него выбрались.
А когда доберётесь до эмбеда — и вовсе получите чудесное.Вполне себе добрались и много лет назад. Только до ембедеда с нормальным полноценным линуксом.
-менше кода (lambda, auto)На сколько ? Доли процента ?
-більше оптимізація (move, constexpr)Как часто нужны constexpr?
-більше вміє із-коробки (баготопоточність, регулярні вирази, файлова система)Отличная питательная среда для трудноуловимых багов связанных с реализацией на конкретной платформе.
-пофікшені вади старого С++ (auto_ptr, string.data, std::copy)Очень поможет в интеграции с существующим легаси кодом.
Очень поможет в интеграции с существующим легаси кодом.Ну обратна сумісність теж збережена, той самий auto_ptr лишили.
На сколько ? Доли процента ?Ну приведу просто один приклад проходження по мапі:
std::unordered_map< std::string, int > map;
for(const std::pair< std::string, int >& tmp : map)
{...}
VS
for(const auto & tmp : map)
{....}
Чи зменшився обсяг коду — так
чи покращилась читабельність коду — так
окрім того, вдалося уникнути декількох дуже неочевидних моментів( в першому варіанті ви отримаєте вказівник на тимчасовий об"єкт, що буде знищений вкінці ітерації циклу, у випадку з auto ви отримаєте вказівник саме на елемент в мапі).
Знаешь такое слово «синтаксический сахар»?
Ви або йдете в ногу з прогресом (а ще краще очолюєте його), або еволюція вас знищить. Це стосується геть усього, а не тільки версії стандарта конкретної мови програмування.
Прогресс это Scala, Rust, Go.
А С++хх это ара-тюнинг старого жигуля.
Scala, Rust, Go не можуть замінити С++. Тому зараз їздимо на тюнінгованих жигулях.
До речі, в Rust і Go повно своїх проблем (про Scala не знаю).
Скорее попытки навесить абс и есп на старую мощную машину
С++хх это тюнинг Т-74
а Scala, Rust, Go — это китайцы, С++ живы уже 30+ лет и ещё живы будут, а Scala/Rust/Go заменят какие нибудь Z#
Дякую, але, наскільки я зрозумів, там використовують плюси старого 03 стандарту, хоча проекти варті уваги.
Что-то на слуху, активно разрабатываемое, хотя бы на C++11 и с хорошей архитектурой/без костылей — думаю без вариантов =)
«выберите любые два из списка» =)
Власне тому й створив тему, раптом хтось таке щось знає)
Сергей С
Andrii Batyiev
Taras Kushnir
Alex Koshterek
Jorzchyk Pushysty
Леголас Трандуилович
Oleksandr Redko
Eugene Nuribekov
Eugene Nuribekov
Alex Fogol
Alex Koshterek
anonymous
Andriy Kunitsin
Sergei Beloborodov
Danylo Bilyk
Oleksandr Kolosov
flyman
Maksym Ganenko
Alex Fogol
Gluttton
Павлік
Олександр Ілюшенко
Gluttton
flyman
Volodymyr Rudyi
Євген Остроухов
Vitaliy Fedoriv
Eugene But
Євген Остроухов
Denys Poltorak
Katherina Brilliantova
Sergey Podobry
Леголас Трандуилович
Sergiy Matusevych
Illia Khabibrakhmanov
Illia Khabibrakhmanov
89 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів