Инновации и инсайты в мире Java из первых уст. Новая конференция Java Fest — 21 марта >>
×Закрыть

С++ open source проекти

Всім привіт, є бажання долучитись до існуючого опенсорс проекту.

Побажання:
1. С++11/14 — обовязково
2. ± добре спроектована архітектура, аби повчитися хорошим практикам, а не афігевати з костилів — обовязково
3. багатопоточність — опціонально

Хто що може порадити з цього приводу.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Перелопать кучу, может найдешь что
github.com/fffaraz/awesome-cpp

www.quora.com/…​in-clean-C 11-14?share=1
fffaraz.github.io/awesome-cpp

± добре спроектована архітектура, аби повчитися хорошим практикам, а не афігевати з костилів

В книгах пророків, які їх придумали. В реальному світи шукати не рекомендую.

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

Не зовсім погоджуюсь, знаю мінімум дві контори тільки у Львові, де пиляють великі комерційні проекти на 11 плюсах.

Пилят != запилили.
Два проекта это капля в море.

В світі С++ 6 років(відколи з"явився 11 стандарт), це, по суті, доволі незначний період, враховуючи, що більшість плюсових проектів живуть значно більше, тому я б поставив на те, що нові проекти таки будуть з"являтися і доля С++11( а в подальшому 14, 17, 20... стандартів) тільки буде рости.

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

Ну, наприклад, на проекті використовували boost, з приходом 11 стандарту більшість корисних фіч вже є або необхідність написання аплікацій під сучасні багатоядерні мобільні пристрої, новий стандарт включає вже std::thread, примітиви синхронізації, таймери і багато іншого.

Ну, наприклад, на проекті використовували boost,
Библиотеку больше похожую на ящик с секонд-хендом, а не разумно организованный проект, как например, STL.
Ну ладно, из boost можно было взять необходимый минимум. А теперь это все потянется прицепом, даже если тысячу лет не надо.
необхідність написання аплікацій під сучасні багатоядерні мобільні пристрої,
что есть для языка общего применения глубоко частным случаем и должно быть вынесено в целевые библиотеки-фреймворки, а не жить в ядре.
новий стандарт включає вже std::thread, примітиви синхронізації, таймери і багато іншого.
Спасибо Кэп.
Примитивы синхронизации, а тем более многопоточность и многоядерность это вещи очень зависимые от архитектуры процессора, контроллера памяти и операционной системы и в приципе не должны присутсвовать в ядре языка.
вещи очень зависимые от архитектуры
Ну кагбе на плюсах завжди писали платформозалежні речі.
и в приципе не должны присутсвовать в ядре языка.
Та ну, джава і шарп мають механізми для роботи з потоками а плюси не повинні мати?
Ну кагбе на плюсах завжди писали платформозалежні речі.
Например линукс... #trollface

с простынями #ifdef-ов, так себе портабельность

Если писать код, применяя голову по назначению, то количество #ifdef можно сильно уменьшить.
Но, сейчас редко кто пишет код, применяя голову по назначению.

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

Избежать (не в абсолюте). Но это потребует продумывания архитектуры.
А в прикладном вообще можно без них почти полностью обойтись.
#ifdef лепишь обычно тогда, когда нужно сделать вчера.
А уже лет как 15 пишу кроссплатформено всё, но если цейтнот, то быстрее #ifdef влепить, чем подумать — это время.

Я вот данный момент сношаю проект с прикрученным внешним boost::threads, чтобы он примерно одинаково работал на Винде, полдесятке Линуксов и всяких BSD/SunOS-ах.
Бог миловал — все только на 64 бита.

В Джаве и Шарпе есть такая штукаб как виртальная машина.
И то говорят — разница чувствуется.

Примитивы синхронизации, а тем более многопоточность и многоядерность это вещи очень зависимые от архитектуры процессора, контроллера памяти и операционной системы
А также от напряжения на процессоре и температуры ядра. Только людям пофиг, они как писали CreateThread/pthread_create, так и будут писать. (Люди любят абстрагирование — оно позволяет им не поехать головой от сложности систем, с которыми они работают.)
Не вижу ничего плохого в замене этих конструкций на унифицированный std::thread, во имя абстрагирования. Для платформоспецифических конструкций, которые нужны в 1% случаев, всегда можно взять платформоспецифический идентификатор с помощью std::thread::native_handle().

Т.е. с кросс-платформой серьезно не сталкивались.

жжоте)
Ничего, что многое в STL переходит из буста? Знакома ли Вам, например, скорость работы контейнеров boost.multi_index? Или возможности asio? Странный вы.

А вам знакома концепция — «в ядре языка только минимально необходимое»?
Боюсь, что нет.

Юзали буст и в ус не дули

Буст — это тоже универсализация со своими накладными и ограничениями.

Это я написал к тому. Что Нурбеков приводит задачи, когда без платформо-зависимого кода не обойтись по причине оптимизации.

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

Нет, ты не прав. Просто в плюсах нынче мало смузихлебов и используют обычно то, что удобно и нужно в конкретном проекте и никто не гонится за модой.
Есть удобная новая фича и поддерживается всеми компиляторами в проекте юзают. Нет фичи или не поддерживается не юзают.
Например, если мне достаточно openmp и он поддерживается там, где мне нужно я не буду юзать потоки std::thread, не достаточно заюзаю. Не достаточно std::thread будет посмотрю на boost, не достаточно буста полезу к системе и рисованию своего велосипеда.

Что не произошло? Я с 2013 года работал только на С++11/14. То что Вам не повезло попасть на 11/14 проекты не значит что их нет.

С 13-го года на 14-м стандарте?
А «везения» такого мне даром не надо, я и канонического 99-го стараюсь избегать.

как вышел 14 стандарт и компиляторы стали его поддерживать, так некоторые проекты и попереходили
а то что стараетесь, это понятно, я к тому что проекты есть и на 14 и на 11 стандартах. просто Вы написали что мол

к официальному релизу уже подключаются широкие массы.
С новыми версиями С++ этого не произошло
 — а я утверждаю обратное

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

Простите, кто на ком стоял?

С того стандарта тока лямбда-функции использую. На остальное нет времени и желания.
Да и ставить Визуал студию 2015 под новые стандарты чето не хочется. У меня все на 2013 все прекрасно работает и, самое главное, не гробит комп.

А auto!? Если всё нет ВСЁ писать как auto выглядит же ж ох... ох как!

і доля С++11 тільки буде рости

тогда в следующей редакции auto сократят

то впилять то випилять, вони хоть знають що хочуть?

це був сарказм, якщо що)

Право, давно бы выучили английский и почитали, кто сейчас программирует на С++ХХ, чтобы немного выйти за пределы IT в Украине.

Так поведай же благую весть Человек-без-Линкедина.

github?

ЗЫ:

2. ± добре спроектована архітектура, аби повчитися хорошим практикам, а не афігевати з костилів — обовязково
в опенсорс майже ніде хіба що насправді то «опенсорс» лише формально а фактично було кимось єдиним розробником написане а «комюніті» просто його прийняло (ну а куди їм тупеньким дівацця?) і тоді метод пошуку зміщюється від проектів до людей яких саме і слід відслідковувати от «долучитись» сумнівно але ж завжди можна зробити власний форк і додати фічу якої не вистачає славноруч.

ЗІ: якщо же ж основна ціль «потусить у середовищі крутих чуваків і типу в них повчитися» то не вийде бо опенсорс традиційно г... болото простітє.

«опенсорс» лише формально а фактично було кимось єдиним розробником написане а «комюніті» просто його прийняло

Незавжди. Є проекти, що підримуються (або були створені) організаціями: NASA, Qt, тощо. Яскравий приклад — GSoC там дуже багато проектів на C++, які хостяться на GitHub.

Ну я же ж і кажу «хіба що хтось його написав і вже потім формально опенсорс...» от геть от як Qt саме же ж чудовий же ж приклад.

github.com/Gluttton/PslRK

Набор мини-проэктов. С++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 ви отримаєте вказівник саме на елемент в мапі).

Для показательности мог бы привести старый вариант со стандартным for и полной записью.

Знаешь такое слово «синтаксический сахар»?

Ви або йдете в ногу з прогресом (а ще краще очолюєте його), або еволюція вас знищить. Це стосується геть усього, а не тільки версії стандарта конкретної мови програмування.

Прогресс это Scala, Rust, Go.
А С++хх это ара-тюнинг старого жигуля.

Scala, Rust, Go не можуть замінити С++. Тому зараз їздимо на тюнінгованих жигулях.
До речі, в Rust і Go повно своїх проблем (про Scala не знаю).

Скорее попытки навесить абс и есп на старую мощную машину

С++хх это тюнинг Т-74
а Scala, Rust, Go — это китайцы, С++ живы уже 30+ лет и ещё живы будут, а Scala/Rust/Go заменят какие нибудь Z#

Дякую, але, наскільки я зрозумів, там використовують плюси старого 03 стандарту, хоча проекти варті уваги.

Что-то на слуху, активно разрабатываемое, хотя бы на C++11 и с хорошей архитектурой/без костылей — думаю без вариантов =)
«выберите любые два из списка» =)

Власне тому й створив тему, раптом хтось таке щось знає)

Подписаться на комментарии