Як ефективно опанувати C++
На жаль, не існує книги чи якогось єдиного ресурсу, після оволодіння яким початківець запрограмує на C++ легко та високооплачувано.
Але існують напрями докладання зусиль, які гарантовано дозволять вийти на бажаний рівень професіоналізму, за наявності відповідного освітнього та природного підґрунтя, безумовно.
Цими напрямами є: практика програмування, взаємодія з професійною спільнотою C++ та використання специфіки C++ у контексті інших мов програмування.
Розглянемо зазначені напрямки більш детально.
Найголовніший напрям докладання зусиль
Найголовніший напрям докладання зусиль — це програмування. Опановувати C++ слід через програмування, не через читання.
Найкраще почати з програмування застосунку, що зможе особисто вам полегшити життя. Якщо таких ідей немає, то починайте з програмування месенджера. Там буде все, що може знадобитися: Networking, Concurrency, IPC, GUI, бази даних і т.і.
Але читання теж допоможе освоювати C++.
Для формування здатності використовувати C++ best practices, необхідно буде обов’язково регулярно читати C++ core guidelines.
Також обов’язковим є вміння читати та розуміти чужий код. Найкраще цьому вчитися на коді експертів світового рівня у таких проєктах як The Beman Project, Folly, Abseil, ASIO.
Для охоплення думкою, переважної більшості того з чого складається сучасний C++, стане в нагоді цей дороговказ.
Як джерело дуже добре структурованої інформації по окремим темам C++ варто звернути увагу на hackingcpp.com. Як, наприклад, std::vector, std::deque, std::map, std::unordered_set.
Якщо треба більш детально розібрати якусь тему, то прохайте ШІ знайти відповідні презентації на CppCon або CppNow. Як, наприклад, ось ця по Move semantics.
Або прохайте ШІ знайти відео по потрібній темі у YouTube архівах таких конференцій по C++ як CppCon, ACCU, CppNow, С++ on Sea, Meeting C++, NDC.
Другий ефективний напрям нарощування професіоналізму
Другим ефективним напрямком нарощування професіоналізму, є участь або перегляд чи прослуховування виступів на профільних конференціях. Оскільки це дає можливість за лічені години отримати розуміння специфіки і нюансів застосування C++ на які б пішли роки особистого досвіду, або взагалі не сталося б ніколи.
Тому регулярне ознайомлення, особливо з останніми матеріалами перелічених конференцій, істотно допоможе у актуалізації знань по C++.
Крім того, прослуховування вмісту зазначених конференцій у mp3 форматі, буде корисною альтернативою FM-радіо під час хатніх справ, механічної роботи, переміщення у просторі або вимушеного очікування.
З’явиться змога почути важливі ідеї, концептуальні речі і напевне зрозуміти на що варто витратити час щоб подивитись на екрані.
І як приємний бонус отримаєте можливість практикування англійської мови з користю для професійного розвитку.
С++ у контексті інших мов програмування
Деякі цитати з інтернету про що є C++:
«C++ was designed with systems programming and embedded, resource-constrained software and large systems in mind, with performance, flexibility, and reliability of use as its design highlights.»
«What is C++? Uncompromised performance. Achieved by: living with UB, accepting a safety trade-off.»
Які концептуальні вади має C++?
Забаганість компіляторів та складність коректного використання існуючих і створення нових абстракцій.
Так само еволюція C++ найперше спрямовувалась і спрямовується на додавання доволі низькорівневого інструментарію, порівняно з тим як розвиваються мови базовані на Garbage collection.
Що обмежує присутність C++ у таких доменах розроблення програмного забезпечення як enterprise, web і mobile.
C++ є мультипарадигмовою мовою програмування загального призначення, що спеціалізується на максимізації швидкодії згенерованого кода.
C++ успадкувала мінімалістичну доцільність C через Zero-overhead principle і філософію дизайну «Leave no room for a lower-level language».
Базовими принципами розвитку мови, якими керується Комітет із стандартизації C++, є: безкомпромісна швидкодія, зворотна сумісність і стандартизування лише перевіреної успішної практики.
Починаючи зі стандарта C++11, було відпрацьовано механізм оновлення стандарту C++ кожні три роки, що створило можливості для конкурентоспроможної еволюції C++.
Невпинне ускладнення задач, що розв’язуються за допомогою C++, спричиняє її поступове неуникне зростання та ускладнення.
Оскільки неможливо спрощувати C++ як мову, то Комітет зі стандартизації C++ обрав стратегію спрощення використання C++. Зокрема через замовчування, які в більшості випадків є коректними, та інтерфейси, які легко використовувати правильно і важко використовувати неправильно.
C++ підтримує всі притомні парадигми програмування і дає можливість зосередитись на вирішуваній проблемі, незалежно від її складності та масштабу. І при цьому не відволікатись на специфіку співіснування з Borrow checker або на подолання Garbage collection performance penalty.
Вже зараз C++ розробники, за допомоги Dynamic Sanitizers та Static Analyzers, можуть з високою імовірністю вирішувати більшість проблем, які беруть на себе Borrow checker та Garbage collector. І вирішувати ті проблеми, які Borrow checker та Garbage collector не призначені вирішувати, як наприклад діагностування buffer overflow чи integer overflow.
Натомість Garbage collector лише частково гарантує відсутність memory leaks, повністю гарантує відсутність dangling pointers, і повністю не гарантує відсутність data races.
Borrow checker Rust-а, на свій пай, може гарантувати відсутність dangling pointers і data races у safe коді. І може дати ще більш слабку гарантію відсутності memory leaks у safe коді ніж Garbage collector.
Також наявність Borrow checker не дає Rust повною мірою підтримувати OOP парадигму програмування.
Проте, Rust — це надзвичайно корисний і важливий проєкт, як джерело ідей та мотивації для прискорення і підвищення якості еволюції C++.
За аналогією з garbage collector-based мовами програмування (Java, JavaScript, C#, Python, Go), з нетерпінням чекатимемо на появу нових borrow checker-based мов програмування.
Важлива примітка
Наостанку варто зауважити, що рівень складності задач у сучасному ІТ досяг позначки, коли вартісний результат можуть показати лише злагоджені команди досвідчених талановитих експертів. Саме з цієї причини софт-скіли є такими важливими для сучасного ІТ.
Тому здатність до взаємоповаги є ключевою необхідною умовою успіху у сучасному ІТ, адже без неї ніколи не буде нічого путящого за жодних обставин.
З цієї причини варто запам’ятати правильні слова Дейва Абрахамса, одного із засновників The Boost C++ Libraries project: «Collegial respect and kindness are fundamental to getting great results».
306 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівзалишу тут
www.youtube.com/watch?v=Ww8MzcBJUd4
І чому ffmpeg не на С++?
Бо ffmpeg з’явився за десять років до того як у С++ додали move semantics та розумні вказівники.
Крім того, у той час C++ компілятори були відчутно більш забаганими ніжC-ївні.
Тому STL, який за замовчуванням через copy assignment та copy construction копіював все, що треба і не треба, не давав ніякої переваги.
ну да, чекаєм взльоту на 26 стандарті, в космаz
В C++26 з’явились Contracts та Static Reflection. Отже стає цікавіше.
З тих же причин на C писались Linux, Python і Ruby.
А зараз, хто заважає танцюристу (тоді в нього були «неправильні яйця із неправильною мувсемантикою») ?
Зараз Python пишеться на Python, а Ruby — на Ruby.
І Лінус теж зрозумів, що без RAII-powered абстракцій не зможе далі нормально розвивати Linux Kernel, тому запустив до себе Rust.
Як на мене, вкатуватись у плюси вже запізно. Поїзд пішов і ви його просто не наздоженете. Специфікація пішла в рознос і з кожним новим апдейтом стає все більш схожою на брейнфак.
P.S. Я завжди вважав плюси невдалим експериментом, а зараз батьки-засновники роблять усе, щоб підтвердити дану тезу. Не гайте час, вивчіть нормально чисту сішечку, а далі переходьте одразу на іржавого чи взагалі на managed (в залежності від ваших цілей).
Ще залишаєтся невеликий шанс, що С++ поверне свої позиції, але з кожним новим стандартом він все менше.
Взагалі погоджуюсь, варіантів заробити на шматок хліба з С++ все менше, особливо для новачків.
Чи можна попрохати обґрунтувати думку пана?
C++23 (ISO/IEC 14882:2024): 2,104 pages
C++20 (ISO/IEC 14882:2020): 1,853 pages
C++17 (ISO/IEC 14882:2017): 1,605 pages
C++11 (ISO/IEC 14882:2011): Over 1,300 pages
C++98 (ISO/IEC 14882:1998): 879 pages
Задачі які розв’язуються за допомогою C++ не стають простішими з часом. Тому неможливо спрощувати чи зменшувати C++ з плином часу, що стосується будь-якої життєздатної мови програмування.
Натомість докладаються зусилля на спрощення використання C++.
Не зрозумів
— Розумні вказівники замість замість складного помилко-провокуючого програмування роботи з raw pointers;C-подібного програмування;
— lambdas для спрощення програмування складної логіки;
— std::filesystem та std::jthread замість системнозалежного бойлерплейта;
— auto, decltype замість ручного прописування типів;
— structured bindings для спрощення програмування складної логіки;
— C++20 ranges замість ітераторного бойлерплейта;
— C++20 concepts замість складного SFINAE;
— C++20 modules замість «header hell»;
— uniform initialization замість ініціалізації у циклі;
— std::chrono замість
— std::format і std::print замість printf та std::cout;
— std::stacktrace для спрощення пошуку помилок;
— C++ Core Guidelines для зручності використання найкращих практик програмування на C++.
Пан забув про RAII, на котрому десятиріччями будували складні системи.
Без котрих написали мільйони рядків Хроміума.
Котрі з’явилися через скільки років панування С++ на ринку мов програмування?
Це реально допомогло зробити С++ більш популярним?
Я взагалі не знаю, що це. Хоча маю 10 років досвіду з С++.
Це допоможе С++ проти Расту?
Якось обходилися. Або ставили GCC де воно давно з коробки.
При цьому операційні системи, де усе висить на таймерах, чомусь написані на С.
Останній взагалі приклад помилки дизайну мови. Котру їжачки намагалися двадцять років їсти, хоч і боляче було.
А він на big endian MIPS працює, і без оверхеда?
При тому, що популярність мова отримала без них, а втрачає — з ними.
Гарантована GC відсутність проблем з dangling pointers та наявність в екосистемі мови зручного package manager-а приваблює силу не дуже просунутих розробників. І це з часом виявилось суперсилою GC-мов.
«Просунутих розробників» не вистачає на більшість продуктів. Тим не менш, в 90х купу всього писали на С++. Чи це тому, що розробники з роками потупішали? Чи, може, С++ з роками спортився, і ті, хто були достатньо розумні для нього в 90х, наразі стали недостатньо «просунутими»?
Нещодавно в лнкеді написав коммент під постом — типу краще, за можливості, використовувати розумні вказівники, типу юнік-птр, якщо шарити не треба...
На мене якийсь топ-лід-сіньор спп помідор з гугля чи амазона накинувся — типу, кто в С++ рав поінтери не юзає, а всякі модні юнік/шаред/віак поінтери — гнати вас з С++ треба, ви навіть на джунів не тянуть..
Так що в цьому «цирку» явно щось пішло не туди і не то.
Чи була ще якась аргументація проти розумних вказівників окрім того, що ті хто ними користується на джунів не тягнуть?
P.S. Що тоді казати про користувачів Borrow checker та Garbage collector?
ну, від равпоінтерів нікуди не дінешся, якщо використовуються пуреС бібліотеки, яких немало, а далі починається врапінг їх в С++ поінтери і магія та правило трьох/п"яти і танці з бубнами, а якщо з самого початку проекту це було невідом і равпоінтери появилися десь по-середині чи під кінець проекту, то редизайн класів що від гори до низу, якщо получиться, або мемліки або інша втрата за контролем пам"яті
Іншими словами, починається все красіво із писанини на ваніла С++, а потім вжух, і С бібліотека із сирими вказівниками на об"єкти і вжуххх всьо завєртє .....
В аналогічній ситуації у Rust-а почнеться unsafe. То чим це краще?
не факт, може бути крате на пуре Руст, а не стороння С бібліотека
Це я розумію, що там до виклики С api, чи якогось легасі, починаются танці з бубном.
Але, «використовувати розумні вказівники максимально, по можливості» — я це писав.
Але щоб їх використовувати максимально по можливості, ви не ховаєте «під капот» біндінги із пуре С, чи як? І менедити скрізь С раупоінтери вручну? Я так розумію «С++ клін дізайн»?
В делітер шареда чи юніка передаєш лямбду, в яку загорташ С виклик, типу -
{
// lambda body
::freeThisCShit(void *shitPtr)
}
ладно, не збираюсь пояснювати загальиний дизайн, так як треба розписусати контекст проблеми, коли починаєш ваніла С++, а потім появляється пуреС із равпоінтерами, проблема не в деліт юніка, а в загальному дизайні системи, коли ти робиш один есампшен (чіста С++ праект), а реаліті потім інша (або робити глобал обжект для контроля життя раупоінтерів, що фуфу, або ж маєш 100500 інітіделіт при старті апп коли вона там щось сканує і створює інстанси класів), і «ефективно оволодіти С++» не так ефективно, як здається навіть із найновішим 26 стандартом.
Ну обгортати усі зовнішні ліби шаром абстракції — це взагалі добрий стиль, бо тобі потім може буде треба лібу змінити. І якщо підклав соломки — то переписати лише цей шар абстракції.
І в такому випадку трохи пофіг, там під капотом ліба на С, С++, чи прямі виклики до ОС.
все «так», тільки іноді «ні» якщо ти обгортаєш равпоінтери
Чому ні? Пойнтерна математика з тим, що овнить стороння ліба?
вище писав, що починається із ваніла С++ (і «апрувнуті» С++ ліби), а закінчується «сторння Сліба із равпоінтер арифметикою, бо ’такої’ на плюсах нема», і початковий C++ дезінг не такий красівий, як без пуреС,
і С++26 це не вирішує
Ну зазвичай, здається, ліба овнить власні пойнтери. Себто є пара create()/release() на кожний тип ресурсу, включно з буферами.
В цьому випадку ресурс (буфер, конекшн, файл...) загортається в клас. Консруктор викликає create() а деструктор — release().
Чи я щось не розумію?
вище описав кейс
dou.ua/...rums/topic/59811/#3087188
спробую пояснити далі.
в один момент добавили JQ, а потім вирішили «покращувати перформанс», шляхом зберігання прекомпілед JQ об"єктів (це для роботи із JSON)
Я його не розумію. Може працював на іншого типу проектах.
розписав трохи детальніше, як то кажуть, сам таке перший раз побачив (сайдефект),
Резюме: пуреС равпоінтери в С++ зло
Ну насправді були і в мене схожі «історії» і навіть гірше (C++/cli), де крім рав поінтерів (прикручена С ліба) та смарт поінтерів ще була мєнейджмент .Net частина, куди все це протягнути треба...
Але трохи з,їду з теми.
Головна проблема цієї «цікавої мозгоєблі»,,, ще до початку AI буму, було те що за нього платили (і зараз плаиять) +/- копійки...
Ну, так за ембедед ще від совітів платили не як за 5в1, (елекроніка, розводка РСВ, ЦОС, програмування, радіотехніка, і що там ще ...), а навпаки: много знаній — много пєчалі
так що с++26 цього не вирішує, а
додаєцця
Ну чого. За бази даних норм платять.
Єдине за що норм платять, гарно платять в С++ це HFT.
Щодо «баз даних» на С++, то єдине де він ще використовуєтся це DBMS, і з того що я чув — там платять +/- херню, але троооооошки більше ніж за ємбеддед.
Ну вже майже як Жавісту чи Пітоністу, що буде ту DB юзати, але менше.
SingleStore нормально платив. DragonflyDB, кажуть, також. Це з того, що є в Україні.
HFT, котре висить на ДОУ та Джині, обмежене 7К зверху. Це менше, ніж бази даних.
ЕС, не в Україні.
DBMS, Якась контора з Канади — 6 к євро, Інша з Німетчини 6.2 к
HFT в Лондоні/Дубаях — 10k-15k євро в середньому.
П.С.
Спробую в лінкеді пошукати контори, що ви написали.
Ну наші коли тікали до Португалії — там інший офіс СінглСтор — то хотіли там легалізувати українську зарплатню. Сказали — фіг вам, в Португалії такої зарплатні не буває.
Цікаво, що ім там зараз платять...
Бо в Португаліях хати в 3 рази вище за українські, податки в 4.
А сама зп менша.
А що тут обґрунтовувати? Код із використанням новітніх фіч перетворюється на типовий write-only, по типу регекспу.
Дуже добре видно, як автори відчайдушно намагалися впихнути нові мовні конструкції у існуючий синтаксис нічого при цьому не зламавши. Результат вийшов об’єктивно фіговий, і дедалі стає все гіршим.
Перепрошую, але стало ще більш незрозуміло про що саме йдеться і за якими метриками провадиться оцінка.
Мабуть зауваження і критика мають бути конкретними. Взагалі можна хібащо хвалити, коли немає за що.
Ну була така мова як Перл. От С++ перетворюється на Перл.
Те що написано, в принципі виглядає достовірно, проте у С++ є інша сторона правди, і вона полягає не скільки у мові, а в тому, а для чого ви її застосовувати будете, себто — доменна область, або ж домен (все ж С++ десь у embedded, HFT відрізняється від написання застосунків під ПК), це по-перше
А по-друге, не одним С++ єдині, тому що на додачу до нього треба знати ще так званий ланцюжок інструментів (він же Toolchain), тобто CMake, фреймворки (на кшталт Qt, дуже універсальна річ), архітектура (чомусь я ніде не бачу, щоб згадували такі поняття як HLD та LLD в цьому питанні), шаблони проєктування, і вміти їх правильно адаптувати під С++ і ще насправді багато чого
Тобто однією мовою не наїстеся ви, до того ж Ші справляється з С++ ну... не сказати погано, але ціна помилки і незнання в даному випадку буде куди більшою ніж з іншими мовами
Імхо — треба знати / розуміти і С++, і навіть базові принципи роботи асемблеру навіть в епоху ШІ, але конкретно зараз точно ніхто не скаже — що буде більш вигідним вкладенням часу: витратити N годин на вивчення кодингу через ШІ або ті ж самі N годин — на С++ — це стане більш зрозумілим лише згодом
Пишу на С++ і мені ще за це гроші платять. Так не тільки С++, так це особливий C++ — no RTTI and no exceptions. Але я з тих, хто вважає, що сучасний C++ звернув не туди: модулі це якийсь mess, Coroutines — я не осилив, це неможливо використовувати, треба чекати коли розумні дяді типу Christopher Kohlhoff дороблять свій фреймворк для networking, а стоп C++20 випустили 6 років назад! Хтось пише асінхронний код на плюсах тут? Може є якась defacto стандартна ліба на networking з coroutines? Щось рівня Tokio? Немає... Велика частина networking коду на C++ сьогодні libuv використовує, тільки б не ASIO. Коротше, я люблю C++17 (а якщо ще додати span/expected з boost), але якщо сьогодні мені знов випаде честь писати хайлоад сервер з 0, я б робив це на Rust або навіть Go, отака фігня з сучасним C++
так, С++17 норм тема.
здається тоді static inline додали.
Перепрошую, а що не так з ASIO, яку двадцять років всі хвалять?
Спробуй на ньому щось написати із API під С++ 03.
Коли його подали на тех репорт — там навіть я писав протест і він пішов тоді на гору до авторів. Пішли переробляти, BTW те що зараз вже там вже трохи більш адекватний фреймверк github.com/...oroutines/echo_server.cpp
таким принаймні можна вже користуватись.
Насправді ASIO хороша бібліотека, хоча в С++17 завеликий callback-hell (я не уявляю як люди цим користувались в C++03, коли не було ні переміщення, ні лямбд). Coroutines це майже виправили, але всеодно — з усіх сучасних async фреймворків на різних мовах, ASIO найскладніша для використання і легше всього дозволяє прострелити собі коліно
Повір не панеция от зовсім. Просто спробуй зробити Hello World на Rust із рекомендованим GTK+, для тієї же вінди і стикнись із тим, що воно тут же падаеє з крешем на рантаймі. Це елементарний Hello World! Із С++ як MinGW64 так і Clang — жодних проблем при цьому. І т.д. і т.п. Hello World а Vulkan API або Metal для MAC написати теж стає челенджем. Подивись на код Moby/Docker — там пів репозиторію це біндінги до системного API типу Win32 або GTK.
Коротше ейфорія новомодних супер мега мов якось спала. В тому же Firefox — еталонному Rust проекті, коду на Rust не так і багато. Rust займає свою нішу як і Go lang, це крипта та вискоко навантажені мікросервіси із Rest або Kafka і т.п. коммунікативним інтерефейсом.
Усе можливо, просто це штука не для прикладного використання, а швидше для авторів фреймверків. Подивись на С++ 20 приклади Boosy Asio наприклад. Так само можуть бути зроблені запити в бази данних і це сильно покращіть ситуацію в IO Bounds задачах. Так в Rust з коробки це зроблено в рази елегантніше, тут питань нема.
1. тобі про хайлоад сервера, ти про гуйню 🤷♀️
2. хто тобі рекомендує GTK під вінду, хоч на расті, хочь на С/С++ — він тебе ненавидить, задумайся
Мабуть одного лише std::jthread достатньо щоб перейти на C++ 20.
Я просто виходив з основного потоку (exit(0)), не джойнячи усе, що наспавнилось, і не знищуючи квазістатичні об’єкти (компоненти системи). Дуже швидко працює, проблем не бачив.
Проблема в тому, що немає гарантії, що код в інших потоках встигне виконатись.
Перед цим гасився меседжінг: основний потік розсилав на інші запит на завершення роботи, ті ставили флаг, котрий відмовляв у виконанні будь-яким наступним запитам. Себто, система вже нічого не робила. І в цьому стані безпечно просто вийти, і нехай ОС одною командою анмапить усю виділену пам’ять і приб’є усі потоки.
На рівні перевірки компілятором. Потпіьні ранитйм санітайзери. Так в Rust дійсно перевірка беззпосередньо компілятором. Хочуть виправити саме в С++ 26.
Так
це ж не фіча мови! Це класний патерн, але його можна в С++11 використовувати, boost::scoped_thread давно існує, я думаю є такі самі сторонні хедеронлі ліби з інтерфейсом std::hthread. Так само optional, expected, filesystem можна використовувати в C++11/14. Фіча мови це модулі і корутини, і заради них я б на C++20/23 не переходив би
std::jthread — це частина STL, яка не є частиною C++, але є частиною стандарта C++.
Поясню простіше, що хотів сказати: нового компонента в STL не достатньо, що б перейти на новий стандарт C++ (тобто змінити версію компілятора, а можливо і мінімальну версію OS де програма може працювати). Оскільки цей компонент можна замінити сторонніми бібліотеками. Що справді може спонукати на перехід на новий стандарт це фічі самої мови, типу concepts, modules, coroutine. Наприклад std::format, його додали в C++, а я продовжую використовувати fmt і нормально вирішуються тіж проблеми
ні, треба шоб вендор додав у sdk відповідний компілятор
Ще бува що ті нові компілери глючать на нових стандартах та фічах.
Є такий The Beman Project, до якого запрошували доєднуватися всіх бажаючих довести корутини до ума.
Чуваче от ти розумієш, те що ти сам написав —
... гроші платять за —
(підозрюю що ще без шаблонів та стл)
Оце вже означає, що -
скоріше за все це означає що він пише для якого мікроконтролера із обрізаним STL, microcpp чи як її там (ucpp), думаю що ця cxx.uclibc.org/index.html
Я це розумію.
Питання в іншому, нафіга взагалі, в таких випадках кастрірований С++...
Чого С шку не заюзати ?
Бо сішка не надає ієрархічної роботи зі складністю. Ти не можеш зробити великий об’єкт, в нього запхати кілька менших об’єктів, а в кожного з них — ще менші.
metapatterns.io/...ers/#building-a-hierarchy
можна, але прийдеться багато навелосипедити багато чого, що вже є готове в С++ і std lib
Воно по коду розмажеться. По суті є лише файли, і ти не вкладеш в один файл інший файл. Інтерфейсні структури з вказівниками на функції також не супер зручні, і займають більше місця в коді, ніж класи. І гірша підтримка в ІДЕ.
Мова C концептуально відрізняється від C++ тим, що в C ніколи не буде підтримки user-defined data types with automatic construction and destruction semantics. Бо тоді C перетвориться на ще одну C++, що нікому не треба.
Так само в стандарт C++ ніколи не буде включено Garbage Collector або Borrow Checker. Бо C++ тоді перестане бути C++ і перетвориться на ще одну Garbage Collector-based або Borrow Checker-based мову програмування.
std::unique_ptr ?
Там трохи складніше.
У C++ використовується non-destructive move semantics. Це коли після move moved-from об’єкт залишається у unspecified but valid state і з ним можна далі працювати як зазвичай.
У Rust використовується destructive move semantics. Через це якщо після move спробувати доступитись до moved-from об’єкта, то буде compile-time error.
А std::unique_ptr — це RAII обгортка над будь-яким ресурсом, який треба автоматично звільнити після виходу за область видимості.
Останній раз я писав на C++, та знайшов лібу у стилі Java — POCO. Там C++ 17, але я писав ще коли C++ 11 використовувався. Для мене лише питання, що мені робити у C++, якщо я давно на Go, та думаю про Rust?
Бляяяя.
Цєж не ліба, це С++ фрєймворк.
Ми ще в 2011 його юзали на проекті.
// Обрали замісь Буст
Qt is a cross-platform application development framework
POCO is powerful cross-platform open-source C++ libraries
дик отож
Ага, бібліотеки, а не фреймворк.
Але ми між ним та буст обирали.
С++ опановується перші 2 роки на проекті, а потім починаєш заново на новому.
Порада для тих, хто хоче роками писати один і той самий гівнокод. Найбільший буст розуміння С++ я отримав читаючи код інших проектів, особливо хроміума
Є ще гугловський С++ Style Guide
Ага, після того, як пропатчиш і підключиш сторонні ліби, напишеш кучу бойлерплейт коду, налаштуєш смейк і помолишся, щоб воно все збілдилось
Чому не Boost, POCO або QT ? IMHO — насправді має сенс читати того же : Саттера, Александреску, Страуструпа та звісно Скотта Маєрса. С++ реально складна мова в перешу чергу через свою певну відносну низкорівність. А от сам дизайн якій на 60% агностік щодо мови програмування — це реально складно і вимагає практики, зокрема і практики саме написання коду теж.
Це бібліотеки, а не продукт. Аналогія: в школі на інформатиці усі пишуть сортування масивів, але навіть вміючи сортувати масиви тетріс фіг напишеш.
Його, здається, закрили, а Хромік все ще опенсорс.
Qt ніколи не закривали повністю. більша частина завжди була відкрита.
github.com/qt
В Сromium насправді самі цікаві штуки, як то кодеки для відео — насправді закриті через патентні лімітації від інститута Фраунгофера. Якщо збираєш фрішний Chromium — там є галка викортстовувати шим до системних кодеків типу FFmpeg десь із «non free» репозіторія , або із якимось Kligth Codeck Pack або з те, що ставиттся із драйвером відеокарти (тоді буде літати якщо відео дивитись). Якось на минулій роботі усім покупцям на сапорті із гибридними аплікаціями усім то було треба. І ще їх GPU акселерація дуже не дружелюбна до Linux.
У QT — подвійне ліцензування, за комерційні продукти вони хочуть грощі. Так там код на високому рівні відносно і чудова документація та інструментарій.
Ну в Хроміку цікава взаємодія між парсером та рендерером, наприклад. Швидкісний IPC. Чи сам рендерер з тайлами, котрі підвантажуються до того, як область екрану на них потрапить. Але то довго курити.
І з пам’ятью біда :) Як не дивно якось зписувались із чувачком коли я працював на FireFox в чаті подібному до цього. Там зайшла розмова як можна убезпечити всю програму від крешу, коли закрешився браузер компонент головною причиною cтатистично тоді були плагіни типу : Flash, ,Silverlight, Java чи частіше усього відеокодеки.
Ми тоді працювавли над : COM, CORBA, Dbus і т.п. і я написав — що єдиний варіант окремий процесс та IPC. Чувачок виявилось був з команди WebKit/Blink. От що круто вони це заімплементили дуже швидко. Наше начальство відмовлялось, довго так зробити. І там були суттєві аргументи так не робити насправді, через перформанс і високу складність дебагу.
чому не державною?Я навів хроміум як приклад з власного досвіду, в якому повно цікавих і практичних речей з різних доменів. Ніщо не заважає відфільтрувати С++ проекти на гітхабі по кількості зірочкам і читати їх.Цей монстр з макросів і шаблонів нереально читати, гугловський стиль якраз створений для полегшеного розуміння коду сторонніми розробниками (хоча самі гуглери пишуть що писати в їх стилі набагато складніше)
Якщо ви про Modern C++ Design, то треба читати і в 2026. Якщо хочеш дізнатися більше про історію C++ і як комітет дійшов до сучасних фіч типу variadic templates. Ну або якщо гребеш на галері на яку скинули підтримку софта базових станцій родом з 2006, ще й без можливості використовувати С++11.
Реально, практики метапрограмування в С++ сильно змінились. Хоча цей дід (в хорошому сенсі слова) і зараз на конфах робить доклади про сучасний С++, але нових книжок про modern C++ ще не писав
Одразу кажу про розпрділювачи пам’яті читати не треба в сенсі самостійно імплементувати. Сам Александреску написав — що тема давно має писатись не так і до того же стандартні бібліотеки сильно змінились вже. Також те що там описано із мьютексами буде дуже повільним, сучасні розподілювачі типу jemalloc, pdmalloc, tcmalloc тощо в першу чергу боряться із багатопоточністю.
Усе інше — на сьогодні є книжки які описують те саме в Boost та стандартній бібліотеці, а не Locki. У Александреску купа статей і сьогодні, він типу йшов із С++ в D — але повернувся. Сьогодні консенсус зробити even more modern С++. Хоча так це усе починає нагадувати ситуацію із Algol 68 подекуди. На момент же десь 2005 року коли ця книга потрапила мені в руки (верніше я тоді лесь надибав PDF, потвм придбав паперову), у мене омобисто не було кваліфікації її нормаоьно прочитати. Тільки після Саттера зайшло. Для реальної практики для вінди — Джефрі Ріхтер ще треба, або якась вдала книга із Unix/Linux.
Так Александреску сказав, що під час роботи над D у нього сталось психологічне вигоряння.
Вже нi як.
С++ ефективно опановували люди, хто мiг годинами втикати у код, дебажити та шукати проблеми.
У епоху ШI це робити вже нiхто не буде.
Ця думка, звісно, провокаційна, але варта серйозного розгляду.
Замість годинами дебажити і шукати проблеми можна використовувати динамічні санітайзери та статичні аналізатори.
«Замість» тут суто некоректно.
Навiщо полумiри?
Можна ШI використовувати.
Мабуть найкраще використовувати все, що може допомогти.
Котрі видають купу false positives.
Вони діють в комбінації із тестами. Тобто науково доказовий метод підвердження алгортимів усе ще дієвий і ясно як його опанувати. А ШІ реально сильно допомагає в зменшенні трудоміскості розробки тестів, та навіть у рефакторінгу який спрошує цю розробку, бо добре спроектований код — це той який добре покривається тестами через правильні рівні ізоляції і відкоремлення елементів коду різного рівня абстракцій.
Раніше задля цього вимагалось мати армію добре підготовлених программістів і джуніорів яких підготовлювали на нижчих етапах. А також дуже чітко виверіни процесси розробки рівень 3+ за CMM тобто так само кваліфікваний PM для кординації процессів і т.д. Зараз усі стають потрохи операторами ШІ, агенти та вайбкодінг.
Проблема в тому — що це пісець як дорого, і не так швидко як цього вимагає бінес чи військова справа через конкуренцію. Коли Індія та Китай, Тайвань, Корея і т.д. виставляють сотні тисяч народу, то з цим важко конкурувати маючи в себе тисячі народу із зарплатами по пів мільйона і більше на рік і джуніорм за 120 тисяч на рік. Вони закидують ринок індійським кодом, китайськими пристроями та жовтими збірками і конкурувати стає не можливо. Тому постійно стає питання про технологію де програмувати дешево як на Python, але потенціал обладнання розкривається як на С або на ассемблері.
А ось — добре покритий тестами код на практиці news.ycombinator.com/item?id=18442941
Ентропія досягла меж.
Щопоавда це усе ще IMHO краща з класичних RDBMS, та вона не усюди потрібна.
В Java коли з цим стикнулись, зроблили маштабний рефакторинг на архітекткру Java 9+ (сама Java HotSpot JVM написана переважно на С++ і трохи ассемюлеру, як і CPython переважно написаний на С), розбили на різні модулі тощо. І хочь це і безумовно крок в перед, та комерційно злам зворотної сумісності і купа різного, потреба монетизації і перехід на подвійне ліцензування суд з Google і т.д. обвалило суттєво популярність технічного стеку. Це був епічний комерційний провал
Власне за, що довго топили Microsoft. Корпораціям зовсім не цікаво коли сталий кеш флоу обвалиться і користувач побіжить на Mac з PC чи на Linux, або на ARM з x86 — бо у нього на якомусь новому Windows усе зламалось і більше нічого не працює.
Таке було і у Python з переходом на Python3 і відбувається просто зараз.
Її називають Раст)))
На ділі усе те саме, та ще з боку хвостик — треба писати купу біндінгів аля JNI. Go lang те саме. Потім пів коду проекту а то і більше, який пів години індексує IDE та крешиться з рештою із out of memory, це по суті той самий MS SDK або GTK+. Це усе нагенеровано чимось, unsafe-и вокреараунды через баги і т.д.
Пентагон вже визнав поразку з цим, терміново побігли до комітету із С++ внести в стандарт профілі безпеки та пишуть протоколи із жорсткою вимогою до підрядників і перевіряючих до торимання процессів із розробки на сам перед. Покриття тестами, санітайзери, dev ops, CI/CD, документування вимог, документування дизайну і архітектури і т.д.
Зясувалось — що якщо просто переписати код на Rust, а не проводити наприклад Penetration test, це зовсвм не захист від того що китайсткі чи російкі кібр служби не зламають софт через знайдені вразливосиі і отрмають доступ до секретних документів. А тим більше коли витоки йдуть взагалі чкрещ те що політики додають в чат усіх підряд, наприклад журналістів.
з Rust не все так однозначно, багато хто його не сприймає, недавно тема проскакувала про мантейнера ядра Лінкса
І я не сприймаю. Не розумію, нащо камасутра, коли RAII або актори більшість проблем вирішують.
Взагалі не зрозуміло як Лінус Торвальдс допустив Rust до розроблення Linux, коли у них в документації прямим текстом написано, що Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust.
почитай його «чому не С++»,
може проясниться мотивація
harmful.cat-v.org/software/c /linus
і зараз би йшов холівар:
«чому не можна буст::асіо в ядрі і коли вже С++26 буде пітримуватися, гей (в смислі „альо“) старий, WTH, тобі пора на пенсію»
Якщо абстрагуватись від нікому не потрібного тикального хамства пана, то якби на час відмови від використання у Linux Kernel, у С++ вже була move semantics та розумні вказівники, то швидше за все ніхто не відмовлявся б.
Що стосується управління пам’яттю в STL, то можна використовувати будь-який потрібний кастомний алокатор.
ясно, пан на держслужбі, а не в інтернеті
Не знаю як хто, але я тут для того щоб у шановного панства переймати знання та досвід і з радістю ділитись власними надбаннями, якщо то кому буде треба.
Що є неможливим без взаємоповаги, яка єдина може бути джерелом здатності до взаємодопомоги.
Dave Abrahams, a founding contributor of the Boost C++ Libraries project:
«Collegial respect and kindness are fundamental to getting great results».
Що повністю збігається з нашою традиційною українською культурою звертання на ви на знак поваги. Оскільки взаємоповага — це те з чого починається взаємодопомога та взаємовідповідальність кровно-духовної спільноти мертвих, живих і ненароджених нас русичів-українців.
І навпаки, наміри демонстрування пихи та зверхности можуть бути лише джерелом нікому не потрібних образ та психологічних травм. І в підсумку остаточно можуть вичавити нашу здатність бути кровно-духовною спільнотою та замінити її, як у московитів, на свино-собаче «кожен сам за себе». Коли самотність є найпоширенішою звичайністю. А тиранія, як відомо, — є суспільством самотніх.
перепрошую пане академіку почесному члене комітету С++ наук, в інтернеті не розпізнав
Цій «традиційній» «українській» культури щонайбільше років триста. До того цього римського маразму не знали, в часи Древньої Русі для одного співбесідника завжди було «ти», а при необхідности показати підвищену повагу використовувались спеціальні означення.
Сподіваюсь, в єдиній світовій мові такої маячні з «ви» не буде.
в сучасній світовій мові (англ.) якраз то залишилось «ви»
Це зауваження наскільки очевидне (хтось «мав» написати його), настільки ж некоректне і недоречне:
1. Англійська не є єдиною світовою мовою на зараз і, сподіваюсь, і не буде (я чекаю на цю роль щось середнє між євро-міксом в стилі виправленого есперанто, і тюркськими мовами).
2. Конфлікт між двома ролями для you привів до створення в багатьох говірках англійської форм «you all» (стягненими аж до youll), «you guys»... — бо принципова необхідність є і, значить, цей попит дасть відповідну пропозицію.
what mean: you or You?
thou
... наразі використовується як виключна форма у звертанні до Господа як Thou
... також ще існують Thee і Thy але їх без підручника я вже не пам’ятаю плюс мені здається то вже як чисто британське імперське не американське не залежне
Там ще колись квакерів за це сильно не любили, бо вони на усіх «тикали» і не знімали шляпу. А коли їх питали, чого такі не ввічливі — відповідали, що Ісус до усіх звертався на «ти», і ми будемо так само!
Квакери, те ті що в1996-2001 роках в комп,ютерних клубах в Quake 1,2,3 грали ?
Так можна сказати про все програмування.
ось цей пасаж
викликає багато питань. коли руки із нижчеспини, то організувати витік пам’яті в мові із GC досить просто, і таки витоків бачив сто мільонів штук. наприклад в шарпі можна в геттері підписати швидко-брудно якусь анонімну лямбду на подію довгоживучого глобального б’єкту — і привіт
статья — нейро слоп
Аргументуйте своє твердження, будь ласка.
ты сам все до последней буквы написал руками?
Перепрошую, ногами ще не навчився.
Написано паскудно, важко читається. Розбито на блоки запитання—відповідь. Повно недоречних англіцизмів. Підозріло що не наведено жодної книги. Все якось дуже загально та зводиться до шукайте в інтернеті і буде вам щастя.
На жаль, не існує книги після прочитання якої початківець запрограмує на C++ легко та високооплачувано.
Але існують напрями докладання зусиль, які гарантовано дозволять вийти на бажаний рівень професіоналізму, за наявності відповідного природного підґрунтя, безумовно.
Цими напрямами є практика програмування, розуміння значення професійної спільноти та розуміння місця C++ серед інших мов програмування.
Про що, власне, і написано у топіку.
Здається, Linux kernel + L2/L3 networking. Принаймні, вони не жаліються на довгий пошук роботи. Але це не С++.
який кернел, ESP32/STM32!
Дякую за заувагу, що наштовхнула на думку як можна поліпшити текст топіку.
Це наклеп. Жодне речення топіка не є копіпастою ШІ.
Мой первый слог на дне морском, на дне морском — второй мой слог
То що не так?
— дикий переизбыток англицизмов
— «Borrow checker та Garbage collector» два раза подряд сразу на границе предложения, в нормальном тексте так если и пишут, то только специально, для достижения особого эффекта. это не тот случай
— в плюсах не нужен GC в принципе, 99.99% память управляется надежно и автоматически через RAII
В C++ неправильне розмикання через weak_ptr циклічних взаємопосилань shared_ptr гарантовано спричиняє memory leaks.
В C++ GC не потрібен, але у GC-мовах memory leaks є неможливими by design.
эту самую проблему ты имеешь во всех языках с GC
технически память не течет, но и не освобождается, хотя ты этого ожидаешь
течет из-за того, что где-то появились неочевидные нежелательные ссылки, о которых ты не подумал
Виходить, що memory safe мови — це чисто маркетингова маніпуляція, оскільки на практиці memory safety досяжна лише з певною імовірністю і лише із застосуванням динамічних санітайзерів та статичних аналізаторів. Що стосується не лише C++, а й «memory safe» мов.
они безопасны и безопасность там может сломаться обычно только когда появляется многопоточность
просто утечки памяти там тоже есть, но они там выглядят не так, как утечки памяти в Си
Memory leak — це не таке критичне порушення memory safety, по суті це баг, але який не несе загрозу безпеці. Це не вихід за межі буфера та подібне.
Це не критично коли немає ефекту накопичення загубленої чи забутої пам’яті, наприклад для серверних застосунків.
Так, я маю на увазі, що такі баги не є загрозою для безпеки.
Memory leaks через накопичення цілком можуть заповнити всю вільну пам’ять і спричинити крах, наприклад системи управління транспортом.
Так, а неправильно написаний SQL запит може дати доступ до системи. Але коли кажуть про Memory Safety — то зазвичай мається на увазі, що у додатку немає вразливостей, через які можна отримати доступ до системи (через переповнення буфера чи подібне).
Різниця в тому, що memory safety це дуже обʼємне і різноманітне поняття, і зводячи все до одного терміну ви вводите у оману.
В AutoMM (Java, C#, Python...) мовах можна передати не те посилання, можна зіпсувати дані в обʼєкті, можна не видалити посилання зі списку чи мапи. Це все є. Але різниця з ManualMM, як асемблери, C, C++, багато інших, що при цьому структури не порушені, неможливий запис в інші дані чи метадані так, щоб не можна було зрозуміти, що це взагалі було. Далі, всі дані в памʼяті можна проітерувати, разом з їх типами, а часто і подивитись, звідки те посилання, яке тримає дані. (Я це реально робив з Python.)
І тому memory sanitizer, address sanitizer в звичайному сенсі в такій мові не потрібен в принципі, бо тих порушень, що він виявляє, там не може бути.
А з деякими допоміжними укріпленнями також і не треба thread sanitizer, некоректний доступ неможливий.
Ну для вас, я бачу, все це стає тотальним відкриттям.
Да ну в тій же Java ви можете отримати проблему висячого посилання, так самро. Коассичний приклад — модифікуєма кооллекція в статичній пам’яті. static Map foo = new Map<>(); що його відлоаить будь який санітайзер.
GC має по факиу єдину перевагу — це можливість дефрагментації пам’яті, та має цілу низку суттєвих недоліків.
Новий підход Borrow Checker, що був занадто дорогим по обчислювальним рескрсам крли його задумав ще Едсгер Дейкстера.
Він створює середовище, в якому, щонайменше, всі дані цілі і на них можна подивитись.
Недоліки, звісно, є — тому завжди є ціна. Але в системах розміром в міліони рядків врятуватись від проблем ManualMM практично неможливо.
Да ну, санітайзери багато років використовуються. Головні проблеми це buffer overflow та use-after-free. Modern C++ вирішує 95% таких проблем, та санітайзери усе ще потрібні. Також сучасні компілятори сильно посилились і мають потужні діагностичні методи та надають важиливі ворнінги. В Rust по суті усе об’єднанно, та зе це заплачено ML подібним синтаксисом і відсутністю зворотнью сумісністю із С кодом — потрібні біндінги та unsafe. Modern C++ (11 та вище) + санітайзери концептуально намагається досягти того ж рівня безпеки, що й Rust, але зберігає головний козир — нативну, безшовну зворотну сумісність із мільярдами рядків коду на C та C++. Щоби отримати приблизний еквівалент із Rust зараз в С++ 26 додають профілі безпеки під керівництвом Бйорна Страуструпа та Герба Саттера, лідерів С++ комьюніті і комітету зі стандартизації. Уряд США також вимагатиме для коду на С++ крім обов’язкого включення профілів безпеки, ще і використання санітайзерів і покриття тестами на СI/СD етапі. Проект DARPA — TRACTOR, вже визнаний економічною утопією. Переписати увесь код С/C++ на Rust за допомогою ШІ без втрати перформансу визнано не реальним станом на зараз. Підрядники Пентагону та сам Пентагон не зуміли усе переписати аж так бігом на Rust як планували.
Що дорожче з точки зору розробки то інша справа. Для Python або TypeScript можна обійтись взагалі без жодних санітайзерів. В Java та С# існують проблеми висячих посилань і т.п. тобто вже потрібні санітайзери але значно простіші, типу : SonarAlazyer (Java), PMD, Checkstyle, .NET Code Analyzers (Roslyn), SonarAnalyzer (C#), JetBrains ReSharper / Rider Inspections.
З точки зору перфомансу він усе гірше чим вищий рівень абстрації, тобто за них дводиться платити CPU та RAM при чому одночасно.
І вони не здатні добороти 100%, в принципі.
99% — може буть.
Невірно. Вони є і іх використовують. Але наслідки від багів там, дійсно, різко обмежені, система майже завжди залишається керованою і відновлюваною. І в тому різниця з ManualMM, де ти не можеш знати, коли і як вистрілить наслідок того, що ти годину назад зламав щось у метаданних купи.
Проблеми можна доловити до такого стану, коли кількість сегфолтів чи корапшнів даних співрозмірна з відповідними проблемами через нестабільність бітів в оперативній пам’яті. Що, зрештою, і зробили в базах даних та браузерах.
З іншого боку, в Джаві ті ж креші відбуваються через null де його не очікують.
Але в Java це виняток, який контрольовано іде по стеку і максимум вбʼє одну нитку. Його можна перехопити, записати, проаналізувати.
Це не те, коли "я зламав всі свої інструменти за допомогою своїх інструментів ([звідси; рекомендую, хто не читав).
Про циклические ссылки вам написали. Я добавлю другой пример — как раз важен для полу-embedded, типа, навигатора в автомобиле.
Кусок сложных данных (представим себе, что это карта в навигаторе) висит на одном единственном unique_ptr или shared_ptr. Её освобождение вызывает высвобождение пары гигабайт данных, что блокирует работу всей программы на несколько секунд, навигатор зависает, пользователь проезжает поворот.
Альтернатива в виде современного инкрементального GC размазала бы эту активность пусть даже на несколько минут, но ничего бы не блокировалось.
Да, пример маргинальный. Но показывает, что «не нужен в принципе» — преувеличение.
я так делал ))
оказалось что примитивнейшая схема с выделением сразу всего куска памяти под весь
с дальнейшей раздачей ёё на мелкие кусочки тупым инкрементом и потом финализацией всего как цельного куска просто цельным куском памяти без разбора что там внутри по кусочкам... а зачем нам вообще знать что там внутри было по кусочкам и как то его «правильно развыделять»? ))
... оказалось тупая схема экономит миллионы миллионы «деструкторов» на какие то совершенно реально не сколько порядков по ресурсам процессора времени
меня помню сильно смутила тогда не сама идея как техническая реализация и что она технически очевидно эффективнее но чисто то как оно оказалось на порядки эффективнее
... что конечно тоже было очевидно опять же ж ведь
... это всё даже не параллелится на много процессоров при чём в общем конечно можно и запараллелить... но _зачем_? ))
Арены — хороший метод. Но впихнуть его в C++ аллокации не всегда просто, мягко говоря.
Я всё-таки стараюсь исходить из задачи.
Поэтому куча системщины пишется на няшной сишечке
я не люблю манежи и арены на них мильйон меняют по рублю (к)
это настолько плохой пример, что мне даже лень его разбирать.
:))
Нормальна каша написана людиною.
Вставка англійських слів з випадковим стилем — ознака гуманоїдного писаки, як мені здається.
Об’єм текту статті невеликий, води майже нема.
А чого каша?
бо без води ))
Без образ, але більшість людей пише тексти достатньо хаотично. А програмісти це також люди, як ми знаємо.
В будь-якому випадку, це набагато краще ніж генерувати псевдопрофесійний текст ШІ-ом.
Один мій знаймий колись сказав що програмування на С++ це як працювати моделлю на онліфанс — це звісно не порно, але їбтись доведеться дуже багато.
Після С++ перейшов на C# та кайфував — наскільки простіше було робити деякі базові речі.
Мені в C# все дуже подобаєтся, крім одного —
99% шарпівських вакансій це ASP, angular, web backend,,,,
«... котрі я ненавиджу з дитинства».
і спорадичні появи сєлєбрітіз буквально вбивають бізнес на довго ))
Як пропатчити kde під freebsd, дивитися без смс
Як писати на C++ під Вінду (Windows XP+) щоб були менеджери розкладок, без .NET і без монстроузних бібліотек?
Що таке менеджери розкладок?
Наприклад хочу я зробити ряд кнопок внизу вікна програми як в Far чи в Total Commander. При зміні розмірку вікна програми вони мають змінювати свій розмір так щоб завжди заповнювати простір по всій шиирні вікна. Або потрібно виділити декілька областей різного розміру, але так щоб всі вони заповнювали собою весь доступний простіір змінюючи свою ширину та висоту на основі заданих пропорцій.
Ось UniformGrid з WPF: postimg.cc/vc0d9bPV
Так тобі з ВПФ чи ні, бо це частина .Net.
Дивися хронолонію де то тожна реалізувати.
WinAPI (C )
MFC (C++, давно на нього забили, але для ХП норм).
Win Forms — .net
WPF — .net
Qt — (C++, це фрєймворк, але в плані десктопа то обгортка для Win API).
Можливо зараз ще щось є.
так сорі і win forms і WPF також і також як я пригадую скрізь є правда і само мальовані віджети
Я з Wpf колись так непогано колупався, і там цікаво реалізовано.
Один хєндл, а всередені вже всі єлементи в канвасі малюются. Хоча це вже не про С++ (ну якщо С++cli не вважати С++...)
WPF можна використувати з C++.
Так, можна буль ласка посилання на статтю чи приклад.
Тільки не використовуйте фрази :
Managed C++
C++/cli
У вашому прикладі, бо то я і так знаю.
Так да не так, ця штука працює як і скажімо Java Swing. Усе малює сама, від окрнної системи Windows або X11 Whyland, Cocoa і т.д. бере тільки вікно. Це дає можлмвість кастомізації і «шкурок» через CSS. Так як не крути для QT рідною середою є виключно KDE. Хоча софт можна розробити під дуже багато що. Та софт на QT видно не озброєним оком.
wxWidgets, JUCE... але це я ностальгую за2007-2013 роками)
ЗІ: ще писав на ATL/WTL... але що зараз воно таке не знаю
Це взагалі не до С++.
CSS
Для цього не потрібно взагалі ствоювати ОС, це можна зробити программою сервісом, аля RocketDoc якщо для вінди. Є щось подібне для KDE чи Gnome ?
Абослютно мимо. Все це тут ні до чого.
Спробуйте подивитись на ImGui
Схоще що найкращий варіант це C++ Builder і на вибір VCL або FireMonkey. Остання версія яка запускається під Windows XP та може видавати код під 64—розрядні ОС — це XE 5. MFC виглядає страшнувато і я так і не зрозумів що там з менеджерами розкладки.
ну пиши на win32 це досі актуальний варіант писати під вінду, при чому навіть під сучасну. Або скористайся С++ Builder, якщо тобі під xp то це мабуть Borland C++ Builder 2006, якщо ти хочеш, щоб твоя поробка працювала і в наступних версіях віндовс, плюс VCL попроще буде ніж голий win32, і працювати буде краще ніж рідні вінформи з дотнета. А так як, в Ембаркадеро С++ білдері 12 який доступний як комьюніті версія, є старий 32 бітний компілятор bcc102 то ти спокійно збереш все це діло і під 11 вінду, і воно буде працювати. І для більшості софта обмеження в 32 біта не буде відчуватись, якщо ти там математику не рахуєш. А нє, правиш під modern C++ 64 бітний компілятор, який на llvm зроблений і кайфуєш.
С++ Builder не варто. MSYS2 та QT, або wcWidgets, GTKMM, FLTK і т.д. покриє будь які вимоги для десктопних аьо гибридних (аля iTunes) застосунків. Хоча сучасний тренд — Electron, їх пишуть не на С++ — а на TypeScript.
Нашо тащить лінуксяче посікс гівно з гцц і криво адаптованими під вінду бібліотеками, коли задача стоїть писати під хп. Для вінди є два правильні інструменти, це власне С++ білдер від ембаркадеро, і рідний мсвц, от будь-який з них можна використовувати для віндовс розробки. А гцц і тим паче qt нафіг не треба, бо qt жирний, він тащить за собою купу непотребу, який вінда і так з коробки надає.
Це 17 років тому воно було криво, справді. Зараз і вже років із 5 там повноцінні новітні версії GCC та С lang, та перейшли на Universal CRT такий самий як у MS VC++. Дебілдер давно там же де і Digital Mars — на межі статистичної помилки. Якщо брати реально номер 4 то це компілятори від Intel та Portland Group/AMD. Також активно займається NVidia, та для ARM та своїх GPU.
Так вже сучасні збірки Python або Git наприклад, зроблені на MinGW64.
Щодо QT то, на смак та колір як то кажуть .. Можуть бути як легкі FLTK або Slint так і середній wxWidgets, адаптований GTK+/GTKMM так і не переносимий WinUI 3, так і класичні MFC та ATL і т.д.
Позаяк статистика використання Mac в США показує суттєву долю ринку, то вже доволі давно більше використовують кросс-платформені фреймверки. Втрачати такий ринок платоспроможного споживача як Mac не хоче ніхто.
Ще є такі фреймверки як : UMG, Control Nodes, Coherent, Stale UI, Gameface, Uitralight, DearAM Gui тощо, які швидше актуальні в сьогоденні бо десктоп типу Skack або Lens станом на зараз пишуть на Electron.
Нафіг ти все це пишеш. Є задача, писати під вінду, вінда існує 40+ років, і підходи розробки в ній не змінюються, є вічностабільний він32, і xml гівно, яке регулярно перейменовують UWP, WinUI неважливо, бо проблема одна і та сама, xml дорого парсити, тому інтерфейси лагають, і вінда від цього тільки програє. Є також прекрасні інструменти створені для вінди для розробки класичних застосунків з GUI це winforms(поверх win32) і VCL(також поверх win32). Qt ще може в якійсь хворій голові можна використовувати. Але таскати в вінду гтк, вхвіджети,
це взагалі ui бібліотеки для ігор. Воно тупо не треба все. Є ОС, є інструменти під неї, кросплатформа не треба. Потрібен універсальний застосунок, у вас є браузер. Ваша кросплатформа працює херово, а вихлоп з цієї кросплатформи по бабкам, майже нульовий, зато проблем тьма, он загляньте в файлик specific_linux.cpp в телеграм клієнті, і порахуйте скільки костилів треба для рандомних лінукс дистрибутивів, що кросплатформенний qt там запрацював, і не давав тобі білі букви, на білому фоні. А це телеграм просто чат, примітивний застосунок максимально, що творить в кишках умовного davinci resolve взагалі невідомо.
До речі про кросплатформу, якщо ти будеш писати віндову прогу використовуючи VCL або вінформи то в 98% випадків, у тебе готова версія софта під лінукс і він запуститься в вайні прекрасно, при чому не важливо ти писав на плюсах, паскалі, пітоні, у тебе просто Wine прекрасно вміє крутити vcl, або класичні вінформи. В інших 2% випадків у тебе танці з бубном навколо кастомних стилів чи контролів, або якісь windows 10/11 специфічні штуки, яких немає в вайні, бо вайн це орієнтовно windows vista/7. У valve proton працює з десяточним оточенням, але протон сильно в сторону ігор перекручений.
З якої планети звалився вельмишановний пан, і як тяжко він забився при цьому?
Додали MFC, викреслили MFC. Додали ATL, проголосили застарілим. Додали EF, викреслили EF на користь WPF. Додали Silverlight, забили на Silverlight. Додали UWP, забили на UWP. Додали Xamarin, забили на Xamarin. I like to move it, move it.
Порівняно з цим розробка під Unix це просто і прямолінійно.
А ще згадаймо перехід на64-бітну архітектуру, простий и зрозумілий (для прибульців з Бетельгейзе).
Ага, і розробляти в стилі 40 років тому.
Кроссплатформенна розробка хоча б вдячна зусиллям.
Теж Whyland насправді і GTK+ 3 і далі зламав к херам підход GTK 2. QT 5 та QT 3 — вважвйтк різні іреймверки і т.д.
wxWidgets досі не модн нормально опанувати GTK 4 і пишуть можна переписувати усе, через архітекткрну несумісність.
Єдині у кого GPU аксклерація в десктрпному меееджері з 2002 — це Apple, тобто у кого не змінився підхід за вже 20 поків. Так вони Objective C на Swift змінили.
Це з епохи війни з борландом
Це тож війна з борландом.
Це взагалі, як макромедіа флеш, фігня для інтерактивних веб застосунків.
Не забили, WinUI це UWP. Вони третій раз цю срань перейменовують, замість того щоб викинути.
Тож живе, MAUI нині зветься. Ну це майкрософт стайл, перейменувати херню, тіпа це шось нове.
Ну да просто і прямолінійно немає графіки в ніксах. А якщо нема графіки, то нема проблем з гуйом.
Так засоби розробки і деграднули до рівня 80х років, камон, коли ти останній раз бачив нову тулзу з графічним інтерфейсом, вони всі залишились десь в 2012. Зараз усьо насрано в cli, бо все виконується в хмарах, ось середньстатистична веб макака зараз програмує, як діди з 80х років, пишучи пасти в консольку. Але чогось обсирають тих хто хоче нормальну середовище розробки з гуєм, а не вім дрочити.
А в CLI і хмарах цінність Windows падає взагалі до нуля, порівняно з Unix (в 99% зараз — Linux). Windows мала якесь значення тільки в межах свого GUI і свого AD, і то тільки якщо нема проблем з ліцензуванням.
Там вже QT/Swing підход, віджети малюються через Direct X в обхід GDI та HAL. До того же нема прив’язки до event dispatch loop та старого до Windiws Vista діспатчера вікон і відповідно старих архітектурних лімітацій із багатопоточністю.
Самі Microsoft рекомендують новий підхід до нових застосунків замість класичних MFC та ATL, бо різниця суттєва.
На ділі самі пишуть той же Teams на WebView2 / React переписуючи його з Electron.
Вони рекомендують цей підхід, бо вони потім під цю джаваскріпт поробку будуть тобі продавати ажур і їм вигідно, якщо софт буде вебом, бо йопт, майкрософт виявляється найбільший провайдер послуг подібного роду.
Electron повинен зникнути. Бажано разом з JavaScript, TypeScript та рештою.
Так сильно дешевше станом на сьогодні, так що цього не відбудеться.
Жарт так собі станом на сьогодні ReactOS написаний uk.wikipedia.org/wiki/ReactOS
Орієнтовно досягнутий рівень відповідності приблизно Wondows 7.
У тебе комілятори тільки вчора повністю освоїли стандарт С++20, все ще ніяк не освоїли С++23, а в С++26 вже оголосили деякі фічі з С++23 застарілими, яка така еволюція, у тебе комітет дельфінів на картах таро фічі в новий стандарт вносить.
Реальність трохи інша: C++ розвивається за чітким планом, а відставання компіляторів є цілком природним через складність імплементації нових фіч.
Якщо хтось думає інакше, то завжди має змогу довести свою правість PR-ми до кодових баз опенсорсних компіляторів.
C++ ISO Committee (WG21) має понад 300 членів, кожен з яких є експертом світового рівня.
Через те, що в комітеті немає «одного головного архітектора» (як колись був Гвідо ван Россум у Python), а рішення приймаються консенсусом сотень людей із різних компаній (Google, Microsoft, Meta, Intel, фінансові гіганти), мова розвивається не лінійно, а як величезний компроміс. Кожна група тягне ковдру на себе (комусь треба перформанс, комусь — безпека, комусь — сумісність із залізом30-річної давнини).
Крім того, застарілі (deprecated) фічі не означає видалені. Якщо щось позначили як застаріле, це не означає, що його визнали помилкою чи негайно прибрали. У C++ часто проходять багато років між появою можливості, оголошенням її застарілою, фактичним вилученням.
І комітет стандартизації не діє випадково. Його рішення проходять через роки обговорень, пропозицій (papers), голосувань і досвіду імплементації ним запропонованих фіч різними командами розробників різних компіляторів.
Особливо лямбда корутини — котрі й були задумані комітетом для access after free
isocpp.github.io/...eGuidelines#rcoro-capture
Цей патерн давно відомий і має власну статтю на вікі
en.wikipedia.org/wiki/Design_by_committee
Саме тому використання корутин в лямбдах викликає доступ до вивільненого стеку.
В11-17 стандартах ще були схожі граблі з захопленням this в лямбдах.
Так шо старі с++ граблі, нові с++ граблі, а вже 2026 рік і світ несется вперед.
Наявність чи тимчасове збільшення технічного боргу не є проблемою. Проблемою є відсутність ефективного механізму усунення технічного боргу.
Проблемою є те, що вже ніхто в комітеті не може передбачити, як взаємодіятимуть фічі (нові та старі) одна з одною. Власне, Ваза.
Щоб переконатись у безпідставності вашого песимізму подивіться, наприклад, цю ISO C++ Standards Committee Panel Discussion.
Це вони в 25 році зрозуміли, що корутини несумісні з лямбдами? Чи про що дискусія?
Дискусія показує рівень фахівців з ISO C++ Standards Committee і які підходи ними застосовуються для розв’язання задач розвитку C++.
Цей рівень їм не допоміг зрозуміти, що корутини конфліктують з лямбдами. Одного цього приклада достатньо, щоб зрозуміти, в якому стані мова, та її комітет заразом. Зрештою, про що й писав Страуструп.
Немає ніякої трагедії. За потреби все виправляється та вдосконалюється до належного рівня.
Почитайте, що пишуть досвідчені пайтоністи про пайтон, або джавісти про джаву, якщо вам потрібен зовнішній заряд позитиву.
Так, трагедії нема і в тому, що С++ втратила більшу частину ринку. Незважаючи (чи завдяки?) зусиллям комітету.
Так Сатттер і Страуструп ніби займаються на пару. Саттер щоправда пішов з Microsoft і тепер швидше на боці Google, що доведеться ламати ABI під сучасні реалії. Варіантів нема — там жорсткий тиск як від індустрії так і Пентагону в першу чергу.
Ви дійсно не бачите протиріччя між цими тезами? Якщо ні, то C++ явно не для вас.
Звісно — експертом по тому, як проходити... навіть не грабельне поле, а ви бачили, як в Entrapment головна героїня проходить, вигинаючись як гутаперчева гімнастка, через поле детектуючих променів, не перетинаючи жодного? Треба тридцять разів провернутись і перегорнутись, щоб пройти крізь маленьку кімнату.
Ось це ми і маємо з C++. Взяли синтаксис C — отримали Most Vexing Parse. Стали розвивали SFINAE — довели до таких жахів, як в Boost.Fusion, щоб потім видумати концепти і переводити на них всю багатоповерхову купу гною зі всякими там enable_if. Зробили автоматичне застосування конструкторів для конверсії в тип — тепер маємо слідкувати, коли писати explicit. З того ж SFINAE отримали, що щоб знайти правильний шаблон, компілятор має бути інтерпретатором значної підмножини мови. Цей ряд можна дооовго продовжувати.
І більшість цього це наслідки саме рішень комітету системи «лебідь, рак і щука».
Я люблю C++, але, на відліч від вас, не ховаю його проблеми. А ось ваша апологетика його наводить на ідею слухати вас якомога менше.
Згоден, неправильне формулювання. Під чітким планом розвитку, насправді, мались на бачності чіткі базові принципи розвитку C++: Uncompromised performance, backward compatibility and standardizing proven practice.
Також процедура стандартизації має обов’язкові формальні етапи: proposal, committee, enquiry, approval.
Ілюзія хаосу може виникати оскільки немає гарантії, що конкретна фіча точно потрапить у певну версію стандарту в запланований термін. Ідеї можуть змінюватися, відкладатися або залишатися на стадії TS/experimental, доки не набереться достатньо консенсусу й практичного досвіду.
І так, ISO C++ Standards Committee періодично хибить і зависає, бо направду непростою є боротьба зі складністю.
Крім цього, виглядає незрозумілою і недоречною недоброзичливість пана.
Ахахахахахаха, ну це прям короночка. У тебе плюси можуть не зібратись на двох однакових машинах, з одним і тим же компілятором, бо температура на марсі на градус нижче.
Some deprecated types and functions were removed from the standard library, including std::auto_ptr, std::random_shuffle, and old function adaptors. (C++17)
TheC-derived headers <ccomplex>, <ciso646>, <cstdalign>, <cstdbool> and <ctgmath> were removed, as they serve no purpose in C++. (The corresponding <*.h> headers remain, for compatibility with C.)
The use of throw clauses was removed.
Some previously deprecated library features were removed, including std::uncaught_exception, std::raw_storage_iterator, std::is_literal_type, std::is_literal_type_v, std::result_of and std::result_of_t.
(C++20)
І після цього ви дивуєтесь
коли ви відверто кажете неправду, яка перевіряється в три хвилини?
Ну вибачте, я наступного разу казатиму в стилі «прошу пана щиро вибачити за незручності, але пан, здається, має перевірити власні слова ще раз, бо я маю скромну точку зору, що пан не намагався взагалі казати щось дійсне реальности», або навіть ще куртуазніше. Так буде краще?
А знаєте, що не дають ваші
?
Це зрозумілість і узгодженість дизайну.
Ось, наприклад, нема проблеми в жодному з цих пунктів з замиканням stdio через fopencookie() чи funopen(), просто взяти готову реалізацію і сформувати вимоги згідно з нею. Але це не зроблено. Проте додають std::print, std::println, які виводять в такі неконтрольовані потоки stdio. Це при тому, що iostreams мають абстрактну базу, на якій можна реалізувати що завгодно, ще з98-го стандарту. І ось це — розчудовий приклад, як комітет робить недофічу, що висить у повітрі.
І де парний йому scan(), який був би ще корисніше?
А скільки десятків років нема того, что тільки в C23 (не C++!) ввели як <stdckdint.h> і для чого в кожному значному проєкті є свій персональний варіант заката сонця вручну? (Тільки я писав це тричі.)
А чому vector<bool> реалізований принципово інакше, ніж vector<int>?
А чому у vector<int> постійно треба тримати на увазі, буде конструктор з заданої кількости нульових елементів, або ж конструктор масиву з одного елемента? І особливо треба слідкувати за цим, якщо такий вектор ініціалізується десь у шаблонній функції?
Я перекладу ці слова в більш простий, незакручений стиль: процедура стандартизації не працює на корисний зрозумілий результат. Замість цього, коли щось стандартизоване, починає широко використовуватись і тільки тоді помічають реальні проблеми — а вся ця підготовка «експертами світового рівня» недостатня.
В Rust, наприклад, з цим борються тим, що вводять експериментальні фічі, які проходять пробу в реальній спільноті, а не у «експертів», які не можуть все обʼяти. Це не ідеал, але вже значно краще. А в C++ комітеті вважають, що вони найрозумніші — і ми всі бачимо, що це не так.
Ну, можете залишатись в своєму пухирі.
Те що ви описали виглядає як намагання ISO C++ Standards Committee зменшувати технічний борг.
Навіть якщо процес по факту є недолугим і безладним, — лише через практику застосування його можна вдосконалити.
З іншого боку, якщо не зменшувати технічний борг, то накопичення помилок у дизайні мови, з часом, унеможливить її подальший розвиток.
У випадку std::print без виправлення stdio, або vector<bool>, немає нічого крім збільшення технічного боргу.
Це і сталося з C++. На зараз розвиток загальмований цим боргом до майже повної неможливости.
Усі члени комітету рівні, але інші як то Герб Саттр та Бйорн Страуструп — рівніші за інших. Так між : Google, Microsoft, та NVidia свого рооду войнушка в комітеті, була. За 5 років не змогли прийняти стандарт API по пулу потоків. Та схоже хараз Пентагон, маючи в свойму розпорядженні трільйон долларів бюджету на рік, а також вплив на інші державні замовлення лихо здвинув справу із мертвої точки. Недоліки та аттавізми С++ визначенні як загроза національтній безпеці США. Прийнято було що баги в софті до F35 і недостатня швидкість оновлення софту складність якого росла геометрично , призвели до багатокоатного перивищення бюджетів та зриву строків. Я так по цілій низці позицій та проектів. Але на С та С++ написано близько до трільона існуючих строк коду твльки для уряду США. Переписувати усе в нуль економічно не має сенсу — краще модернізувати мову.
а якщо не переписувати а писати ?
пробували вже не зліта en.wikipedia.org/.../D_(programming_language
Rust, Карл !!!!
руст навіть близько не про «плюси» як я пригадую в руст навіть ооп не має
мікросервіси рішають
«коли компютери були великі» (к) (тм)
«... А от в єтіх ваших Амеріках негрів лінчують.».
це як ebony ebola what happens in africa stays in africa
nv.ua/...ahoroneniya-50610030.html
Руст дійсно не був про плюси, на самому початку, коли концептуально розроблявся, руст був максимально близьким до паскаля і ади, тільки з сішним синтаксисом. А потім, шось таке сталося, що руст почали розробляти плюсовики, і сучасний руст повністю відповідає уяві плюсовиків відступників про ідеальну мову. Всі приколи раста, це абсолютна заслуга плюсовиків, бо вони це придумали і створили, вони не змогли це запхати в плюси просто.
Багато що в C++ вже в принципі не можна модернізувати, бо це самі основи.
неподільні атоми
... вже модернізували бо тепер же ж є memory ordering ))
Можна але це зламає ABI і зламає величезну купу старого софту який не адаптували. Власне це причина війнушки в комітеті між Google та NVidia і Microsoft була (останні історично в комітеті держали мазу, секретар Герб Саттер працював в компанії з 2002 року і був головою комітета більше 10 років)
Для одних ці зміни це принаймні 5% покращення під сучасне обладнання і мільярди зекономлених коштів на датацентрах, що споживатимуть менше енегргії і краще утілізуватимуться. Для інших — чергова біда із redistribution package і несумісностями, де користувачі старих пристроїів обірвуть звернення в сапорт і т.д..
Але тепер із Azure та Bing, та OpenAI як суттєвою новою бізнес моделлю останніх, та вимогами Пентагону — діло пішло. Усі погоджуються що ABI доведеться з рештою зламати під вимоги нового харду. При чому ключову статтю з цього «The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software» опубліковав сам Саттер у вже дуже далекому 2005.
та ладно, он в дефтек пишуть що вимагається впевнене володіння С++20
В скелі ?
напр.:
jobs.dou.ua/...lutions/vacancies/360178
jobs.dou.ua/...-agency/vacancies/356230
бо С++20 мабуть єдиний з стандартнів останніх10-15 років, який повністю реалізували в основних трьох компіляторах і у ембаркадеро частково.
Ардуіно підтримує
так компілятор під ардуйню це гцц, дивно якби воно не підтримувало, адже саме разраби гцц сидять в комітеті С++ і придумують всю ту херню, яку потім продають за гроші у вигляді пдф макулатури.
там 2 кб оперативи навряд чи там можна помістити щось достатньої складності щоб мало сенс писати на «плюсах» як ціль вирішувати питання складності
так ардуїно поняття розтяжиме, в платформі є не тільки атмега 8 бітна, там і 32 бітний пік, і 32 бітний арм, і 64 бітний арм. Там багато чого, де не то шо на плюсах писати можна, туди дотнет запхать можна, причому увесь.
я сумніваюся щоб дотнет запустився без наявності лінукса під ним або ж то є буде дуже спецільний порт дотнету з фактичним вбудованим майже лінуксом під ним
а це в ньому модулі додали?
бо сучасні військові технології на старих «плюсах» не напишеш вийде хіба той самий американський брухт70-х минулого століття
толсто аж тонко
youtu.be/a2o_cSnKf1Y
С++ не потрібно опановувати. Бо як мінімум — це неможливо, як максимум, нафіг нікому не треба.
І якщо довго дивитися в С++, С++ теж дивитиметься у тебе ©
А ще плюсовикам дають відстрочку в армії по психіатрії.
байка
чого? мені ж дають ))
спорадична кореляція
от за психіатрію щас абідна біла ((
до клюбу анонімних с-приприлюснутих не пробували записати?
youtu.be/orbFDdlq1ig
якщо є нездорова залежність, то потрібно з нею якось боротись
Зараз я не про саму мову пограммування.
Але про маркет.
Так от останні роки С++ летіть «в сраку».
Ембеддед — люди починають забивати на С++ (порізаний С++) і застосовують С все більше.
Трєйдінд, блокчейни — там вже давно раст, С++ ще тримаєтся в HFT, але раст перделить вже і там.
Гєймдєв — топ проекти, чи Анреал енжайн. Увесь міддл левел вже давно на Юніті/шарпі.
Залишаєтся лише підтримка якогось лєгасі, де будуть платити +/- на їжу...
І як би я не любив С++, факт є фактом, останні роки він все стрімкіше летить в прірву.
Це не останні роки, а вже декаду. І автор мови перший це передбачив www.stroustrup.com/...977-remember-the-vasa.pdf
Так, це моя особиста бульбашка.
Влітку 2024 мене звільнили, і тут ще іт криза наклалась і мої «рожеві С++ поні з,їбались в одну мить», точніше через 3 місяці пошуку С++ роботи.
До цього восени 2021, через 2 тиждні пошуку, в мене були 3 С++ офери на руках.
пора йти в фронтенд
І чим скінчилася історія? Бо в мене десь так само зараз буде.
Через 3 місяці прилетіло 3 оферри.
C#.
C++.
Golang (який я взагалі в очі не бачив).
Вибрав Golang, бо зрозумів, що на 2х стеках в моїй кар,єрі (C++, C# desktop only, not web), можна одного дня з голодухи здохнути.
ДАТИШО!
Тільки АСМ тільки ХАРКОР!!!!
Ja pierdolę
... Дякую, ми вас почули.
дякую, а ми вас зрозуміли
Я би почав з Сі. Щоб набити руку в архитектурі цього досить, що буде однозначно корисно. А питання дизайну вони дуже дискусійні.
З Пітону починати в рази швидше. Бо вміє те ж, що й С та С++, але більше можливостей та менше коду.
Я про рузуміння архітектури. Python я розумію через Сі: уявляю як воно написано зсередини.
Так, вони компліментарні. А С++ десь збоку.
Але ж ми про розуміння архітектури софту (сервіси, меседжінг, компоненти, класи) а не заліза (пам’ять, кеші, ядра)? С надає розуміння заліза, але щоб на ньому дістатися до отих усіх сервісів та шарів — треба рік кодити без перестанку.
Я під архітектурою розумію залізо, все що у Танненбаума «Архітектура комп’ютера». Архітектура софта взагалі зав’язана дуже на мови програмування, фреймвьоки, того.
Низькорівнева — на рівні класів — буде зав’язаною. А от у високорівневій — де сервіси чи модулі спілкуються — знову мова вже не грає ролі, бо кожен компонент можна писати на чому хочеш — бо назовні лише стандартне АПІ стирчить.
Року не вистачить, від 3 до 5 щоб до серпднього ріані дістатись. Рік це про Java наприклад або Python чи TypeScript.
Там щоб алгоритми та структури данних просто скриті від скріпт программіста. Щоюб написати бінарну кучу наприклад, без вайбкодінга на С — чи навіть С++, вже треба мати не слабв теоретичну і практичну підготовку.
В Python робиться dictionary поосто і от ХЗ, що там буде під капотом після оптимізації. Щоправда для прикланих задач — підійде в 75% випадків. Власне тому і комбінуть із С та С++. Наприалад ті же іетграуійні тести до С шного чи будь якого іншного сервіса написати.
Там абстракції такого рівня як : списки, ассоціативні массиви, тупли (динамічні структури) або аспектне програмуваня як то аннотації та декоратори прямо з коробки. З одного боку не ясно як можна взяти таку наворочену мову як першу, хоча багато сучасних університеських поограмм роблять саме так — інші беруть С. Де істина — ХЗ.
Для реальної бізнес розробки рівень синтаксису : Python, або Kotlin чи Scala, теж занадто примітивний. Мисля йде одразу : бізнес процессами, мікромервісами — API, UI та моделлю даних. Така хеоня як зл ти обрав список, дерево чи хеш таблицю взагалі нікому не цікава.
Я починав з Пітону. Не шкодую, бо за місяць мав написану половину іграшки, з досвідом відловлювання багів, ООП, та навіть autosuper. На С++ пішло б пів-року.
А, зрештою, головне — зрозуміти, як писати складні речі. А синтаксис — то фігня, котру можна довчити й перевчити.
перевчити набагато складніше, чим довчити
Не знаю. Імовірно, що якесь Го простіше вивчити, ніж нові стандарти С++.
якщо не писати на Го як на С++, то прийдеться перевчатись
нижче ж писав, позавчора
dou.ua/...rums/topic/59811/#3084918
Ну я на С++ пишу як на С на котрому писав як на Пітоні. Тому додати ще й Го в ланцюжок — не завадить)
з defer (вазеліном) чи без?
Я його ще не вивчив. Але тут вже писали, що на С++ роботи нема, і треба переучуватися.
Як це нема? Якщо проходиш поліграфа, то є
Поліграфістки не усіх хочуть
Вас багато, а я одна!
Та не, то застарілі данні.
Тепер треба ще пів року на 0 відбиватись лопатою від кацапських дронів/штурмів/кабів.
Якщо виживеш, то можуть вже старий ноут з gcc 4.9 видати.
ніт, це різні мови із різними парадигмами, потім ще попробуй перевчись бо на «справжній програміт здатен написати на любій мові мові програму на С»
Це ж про Фортран було.
The God is real, unless declared integer.
А на мові без вказівників повторити C якось складно.
можна все на посиланнях
... і от буде цікаво на сі посилання не є nullable а в нас є ))
Які посилання в С, їх там не було ніколи.
youtu.be/Nu3f6T0_pCE
Огляд від ШІ
The C programming language does not support references; it only supports pointers. Reference variables (using the & syntax) are a feature of C++ and do not exist in standard C
Хіба “ефект Мандели”
іти в дефтех
Хм, ще 20 років тому тім лід мені рекомендував Скотта Маєрса Effective C++ 55 порад із С++, книга актуальна по сьогодні.
А так С++ це дуже широке з точки зору бізнесу поняття. Є скажімо JNI або Node розширення, а є GameDev і наприклад Unreal та Godoot, так само є High Performance різниця на рвані різних профессій.
🥱️
Якби я був початківцем в C++ чи думав, куди піти, я б після такої статті розвернувся і змінив мову і домен.
А з досвідом 10+ років суммарно і з кінця90-х календарно — можу тільки сумно реготати з ключових тверджень типу «найкращої мови загального призначення» чи «дає можливість» (ну, звісно дає. дорогою ціною і при наявности значного досвіду.)
Хоча ось це:
дійсно правда, і це майже єдине, що вірне і корисне в статті.
Зараз ера вайбкодингу, тобто багато чого дійсно можна генернути не знаючи тонкостей. Скажімо писати па Python без «акценту» і т.п. Досі певним мистецивом залишається дебаг.
Чи можна узнати про «найкращу мову загального призначення» за версією пана?
www.tiobe.com/tiobe-index
Це індекс щільности WTFов, а не адекватности мов :))
Можна. Такої не існує і не може існувати, тому, що вимоги різних цілей і доменів завідомо протирічать одна одній.
І спроба усидіти на двох стільцях одночасно, коли один з них — стоматологічне крісло, а інше — сідло гоночного велосипеду, ніколи не може завершитись успіхом для обох.
Але в усіх доменах існують класи задач для яких критичною характеристикою є performance, яку by design не можуть дати доменно-спеціалізовані мови.
Це маються на увазі DSL, такі як SQL?
Чи це маються на увазі звичайні мови, такі як Фортран?
Маються на бачності GC-based мови програмування.
То вони зазвичай не є доменно-спеціалізованими. Пітон, Джава, C# - general programming languages.
Кожна GC-based мова програмування має свою спеціалізацію.
Наприклад, Python широко застосовується для програмування AI, але чомусь AI ліби для яких є критичним performance пишуть на C++.
А також — для:
- Наукових розрахунків
- Бекенду, від інтернет-магазинів до мікросервісів
- ДОУ
- Тестування будь-чого
- Скриптінгу в іграх та 3Д редакторах
То на якому домені він спеціалізується? На ШІ, котрого ще не було, коли Пітон вже став популярним?Ну то нащо в ШІ C++, якщо Python все може?
А нащо в браузерах джаваскрипт, а в базах даних — SQL, Якщо С++ все може?
C++ не гірше за C може в Performance.
Але на відміну від C, C++ первинно проєктувався для спрощення і прискорення розроблення великих і складних систем через спрощення повторного використання коду, через повну підтримку OOP та автоматизацію генерування бойлерплейтного кода через RAII та Generic programming.
Оскільки час — це самий цінний не відновлюваний ресурс, то виходить, що C++ найкраще може в саме головне.
Але є нюанс в еволюції C++. Цитата з інтернета:
“Lack of an industry grade3-tier stack (framework) — this is probably the top reason why C/C++ is not used much in web development. J2EE and Spring are just two of the many stacks built to code with Java. With jsp for front end, Java for business layer and jdbc for database operations in J2EE, similarly ASP for web pages, C# for business layer and ADO for database ops in dotnet framework, Django for Python, Rails for Ruby, MEAN and MERN for javascript, there isn’t one for C/C++. So you would end up building the components first before you build the tool.”
Котре так і лишилося обіцянкою
Котре вже завезли до С
Не може, саме тому ентерпрайзи пишуть на Джаві, інтернет-магазини та науковий софт — на Пітоні, а високонавантажений бекенд — на Го. А ядра операційних систем — на С.
Але ж питання було не за це, а за те, чи може С++ замінити джаваскрипт та SQL? І якщо може — то чому вони досі живі?
Здається, навіть Пітон не змогли замінити на С++.
На грунті ще LISP було вперше доведено, а потім з сучасним GC в C# було підтверджено на початку2000-х, що GC може дати навіть швидчішу роботу — за рахунок того, що замість дрочення памʼяті врозкид по кожному malloc/free/new/delete, при якому забруднюються кеші — збирання памʼяти тільки тої, що треба, ще й компактними смугами, що дає cache-efficient роботу з RAM, може бути значно скорішим.3-4 рази більше це неможливо для багатьох доменів, а при вимозі хоча б мʼякого realtime часті часткові збірки зменшують цей виграш. Але для неінтерактивних задач таке рідке збирання можна собі дозволити.
Недолік цього, звісно, є — чим рідше викликається GC, тим більше економія, а вимагати памʼяті навіть в
Ось бачите, ви і тут розходитесь з фактами (і я вже не згадую те, що DSL ≢мова з GC).
Порівняймо підходи до ведення дискусії:
1) Твердження A є настільки недолугим, що щонайменше можна робити висновки стосовно автора того твердження, якщо не встановлювати діагноз чи не оголошувати вирок.
2) Твердження A є хибним по причині B, C і D.
Питання: який підхід вміщує в собі більше поваги до часу та уваги читача?
Розгорнутий аналіз вам був даний сумою коментарів місцевого «колективного розуму», включаючи і всі мої коментарі. Він вже довів, наскільки і як ваші твердження невірні.
Щодо поваги до часу читача, якщо у вас була ціль підняти флейм, то це вам вдалось.