На захист C++
Якщо почитати що в WWW пишуть свідки революційно асинхронного JavaScript, поціновувачі геніального Go і такого неймовірно безпечного Rust, то можна виділити дві тези:
- C++ (або інша непопулярна мова як наприклад, олдфажний Pascal) підвласна лише геніям які змогли опанувати цю мову лише через 30 і 3 роки безперестанного навчання.
- Програми на C++
пищать та псують текстпищать та псують оперативну памʼять.
В звʼязку з цим хочу звернути увагу на те що довкола нас мʼяко кажучи немало програм на C++, написані вони аж ніяк не пробірочними геніями з закритих академмістечок і за всі роки користування компʼютером нічого страшного я не пригадую.
І друге: псують памʼять і справляють враження недоробленої кустарщини чомусь саме скрипти на JavaScript та інші подібні середовища де програмісту нібито не треба слідкувати за памʼяттю і все робиться якось саме по собі. Випадки коли, яка—небудь вкладка в браузері доїдає другий гігабайт оперативки не те щоб рідкісні. Або внутрішнє життя програм на Java за яким інколи можна спостерігати, коли програма нічого не робить, але все таки щось там відбувається що видно по графіку використання ЦП.
293 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівкраще б новий режим до c++ додали замість rust
До речі, ж питаннячко щодо конкурентів.
Ктось знає, нафіга гугль якийсь карбон пиляє, якщо вже раст є ?
А нафіга гугл пиляв го, коли існував php, а нафіга гугл розробляв дарт, коли є джаваскріпт?
нє нє, дарт так би й залишився метрвонародженим «викиднем», якби його не придумали запхати в флаттер...
а на місце жабаскріпта — тайпскріпт!!!
Ну конкретно дарт розроблявся для заміни джаваскріпта, і намагання гуглом завендорлочити розробку під їх браузер. Бо вони і дарт зробили, і ангуляр на цьому ж дарті писали, але потім шось пішло не так. Власне флаттер писали чуваки, яких гугл кікнув з команди розробки дарт-ангуляр.
Краще не треба.
а шо не так?
Чи ви з тієї категорії розробників, які супресять ворнінги тайпскріпта, а коли качаєш собі проект і починаєш перевіряти код, то там мінімум 6 помилок у коді у логікі використання хуків?
github.com/...4#issuecomment-3643542330
Я з тієї категорії розробників, які розбираються в перевагах та недоліках мов програмувань та не ходять зі своїми дурнуватими вимогами до чужого монастиря. Навіщо калічити скриптову мову? Навіщо її використовувати не за призначенням?
Коли дивився авторський огляд відносно хісторі мов програмування B (typeless) -> NB -> C (statically typed) — там доволі ясно з чим такий перехід було пов’язано. А відносно statically typed TS — в чому саме недоліки у порівнянні з JS вбачають?
Якщо ви вішаєте на ногу гірю, то бігати з нею стає не зручно. TS дорожчий за JS, як би парадоксально це не звучало.
По-перше, вам треба інфраструктура для транспайлінгу. А її потім ще треба оновлювати та робити зміни в коді, бо щось може статися зі зворотньою сумісністю.
По-друге, ви мусите більш ретельно обдумувати архітектуру, яка стає більш імперативною, ніж функціональною. При цьому ви не зменшуєте рівень помилок в проекті та швидкість розробки, бо збільшується багатослівність та рівні абстракцій.
Втретє, ви не можете ніяк впливати на швидкодію коду, робити оптимізації, бо у вас «компіляція». Значить будете пожежу тушити ресурсами користувача.
Це якась нова форма троллінгу писати такі комменти, які не мають більше 10% спільного з реальністю?
Це якась нова форма тролінгу замість аргументованої відповідь писати токсичні пафосні коментарі? Ваша реальність не співпадає з реальністю інших людей, зміріться з цим в решті решт.
Може кави?
Це якесь грунтовне нерозуміння шо таке TS і з чим його їдять.
programming-language-benchmarks.vercel.app/typescript-vs-javascript
TS фактично виконує перевірку типів на відповідність деклараціям, далі все це компілюється у чистий JS.
Можете навести якісь приклади де ви побачили те, про що написали?
Легко. Проблема не в тілі функції, проблема в кількості методів, класів, модулів, які треба створити, щоб код був красивий з точки зору статичної типізації. Кожний зайвий інстанс їсть памʼять, вимагає роботи GC, на виклик функції будуть витрачатися дорогоцінні ресурси (які ви звісно ж не цінуєте, а батарейку мобіли чи планшету берегти все ж таки треба). І оптимізувати кол стек, наприклад, ви не зможете.
TS знижує поріг входу у проект для нових розробників,
запобігає виникненню помилок, пов’язаних з неправильними типами
спрощує навігацію по коду
дозволяє робити рефакторінг не через одне місце.
TS компілюється у чистий JS, власне так більшість всього, що працює на TS, робить.
Ваші аргументи зрозуміли, те, що ви любите писати Г-код, це зрозуміло, і те, що є ще армія таких як ви — це теж зрозуміло.
Одне не зрозуміло, чому ви вирішили що це правильно? Ви вже визнали, що такі речі як архітектура вам не зрозуміло навіщо існують, на цьому можна завершувати діалог, нє?
Ніхто не доводив це. Просто популярна казка, яку всім напарюють як загальновідомий факт.
Чергова байка для пересічних. В світі мільйони проектів написаних з використанням мов зі статичною типізацією. Назвіть хоч один складний проєкт, який активно розвивається та не містить жодної помилки.
В JS не так багато типів та правил приведення, щоб не змогти їх вивчити. Якщо ви кажете про власні класи чи обʼєкти, то можу вас розчарувати, світ має приклади успішних проектів, які керують різноманітними за структурою обʼєктами без жодних проблем з обробкою. Наприклад той самий NiFi. Там розумні люди просто побудували правильну архітектуру системи, яка дозволяє обробляти будь-які потоки даних будь-якої структури. Нічого не падає та працює роками.
Проекти зі слабкою повʼязаністю та в яких використовуються DSL рефакторити ще простіше. Легкий рефакторінг — результат архітектурних рішень, а не типізації в мові програмування. Я вам можу привести дуже багато принципів, як можна досягати ще кращого рефакторінгу з будь-якою мовою програмування та будь-яким рівнем розробників.
Я люблю писати дешевий код, який легко рефакторити, підтримувати, модифікувати. А ваше намагання принизити мої досягнення кажуть про слабкість ваших аргументів.
Досвід. Практика.
Звідки така впевненість? Може все діаметрально протилежне? Не спадало таке на думку?
то не лише про TS а й JS в JS також досі транспайлять...
... ну а взагалі, моя така надія, що «вебасемблі прийде, порядок наведе»))
Це трохи інша проблема. Я тільки мініфікую. Та вирішив повністю відмовитися від будь-якої збірки за допомогою нодівських бібліотек, на кшталт вебпака, гульпа та іншого. Не ефективно в моєму випадку.
:D Не можна одну проблему вирішувати за рахунок створення іншої...
Строга типизація — краєугольний камінь сучасного програмування. І якщо у деяких прикладних напрямках відсутність типізації може мати якусь перевагу, то це максимально не стосується комерційних проектів з якими працюють, переважно, низькокваліфіковані розробники.
Власне, низька кваліфікація зачастую і є результатом недолюблювання тих, хто лізе у чужий монастирь.
Бо як продати своє костильне чудо чуваку, який за 5 хвилин і одну команду може тебе звільнити за результатами ревью коду, якість якого не налізає ні на жоден стандарт?
Ви зараз намагаєтеся знайти кореляцію там, де її не існує за замовчуванням. Якщо у вас є низькокваліфіковані кадри, то вам треба давати їм задачі відповідної складності, щоб вони не могли нічого «зламати». Тобто давати інструменти по рівню кваліфікації. І мова йде не про статичну типізацію, чи динамічну, а про фреймворки в першу чергу. Кращим варіантом взагалі буде обрати Domain Specific Language (DSL), який дозволяє досягати результату на високому рівню, приховуючи всі деталі реалізації від розробника.
Статична типізація не забороняє людям стріляти собі в ногу. А «поролонова сабля» не нашкодить нікому, скільки нею не махай.
Наче й слова знайомі, сенс сказаного не зрозумілий. Навіщо ви сюди ще код ревʼю додали?
Це нормально, шо не зрозумілий.
Людина, яка скаржится на те, що її змушують продумувати архітектуру і малює відсотки овкрхеду по рантайму через використання ТС — наврядше зрозуміє Про що мова.
Але я пізніше більш груниовно дам відповідь на попередній ваш коментар.
Ви невірно прочитали написане. В цьому проблема. Ви однобоко дивитеся на речі, тому вам моя аргументація не зрозуміла. Але з часом та досвідом ви зможете усвідомити, що світ трохи складніший, ніж вам здається.
Це мені пише людина, яка у якості аргументу за чистий JS приводить наступне:
Ваш рівень я ще зранку побачив.
Адекватна людина обговорює обʼєкт. Неадекватна — субʼєкт.
Засоби розробки це один з головних бізнесів головного стоптегічного конкуркнта Google — корпорації Microsoft.
Це маркетингово необхідно. Поміттє Intel, AMD та ARM — концетруються лише на С, С++ та Fortran, разом із ассемблерами.
Хотілось би ще паскаль, але представники коміета по С, ніколи не дозволять, щоб поряд з С з’явилась нормальна мова, на якій можливо писати, а то почнуть виникати питання, до комітету з розробки стандартів, а чим ви клоуни займаєтесь, де стіна, де мільйони.
Так у Pascal свій комітет, стандарт древній ISO/IEC 7185:1990 Pascal
А так є FreePascal, Delphi — насправді він жвивий навідміну від Borland і т.д.
Питання не стільки в мовах скільки у виробниках засобів розробки. Скажімо GCC — це Red Hat/IBM та Google які вписались, ICC — це Intel/The Portland Group. Clang — Apple та Berklay. У Microsoft — усе своє. А Borland, Digital Mars і т.д. — і інші фірми без таких потужних маркетингових можливостей спочили.
Якось менеджер з яким я працював нині маркетинг директор в JetBrains в Мюнхені писав статтю про те як це працює. Як вивели на ринок той же Kotlin і що це чистої води маркетниг.
Воно то живе, але жоден разраб хардвара не використовує його і не робить компілятор під себе, хоча паскаль активно використовується в ембеді.
Були би ядра Unix написані на Pascal — усі робили би. Власне в Пентагоні і Карнегі-Меллон зовсім не дураки, коли топлять за «не С».
З іншого боку коли Кен Томпсон та Деніс Річі робили ядро саме на С, то це зовсім не тому, що вони так собі були в розробці мов програмування і ніхто їм не заважав викорастити щось по типу PL/1 чи Algol 68. Вони саме робили — те що і зробили.
Паскаль согласно позиции того же Вирта был дальше улучшен в направлении Modula (аж до3-й). Я не включаю сюда Оберон, потому что он намеренно был сделан больше как единый флакон, чем универсальный язык — во времена, когда всё уже задавлено было C с потомками. Но масса детских болезней Паскаля была исправлена в Modula.
Паскаль же сам вырвался на свободу по известному принципу — в IT побеждает не лучшее, а первое минимально приемлемое (впрочем, такое много где).
Если сейчас смотреть в ту сторону, то нужно сделать нечто среднее между Modula-3 и Ada, без особых тяжеловесностей последней, но с максимальной защитой от типовых граблей, для чего упор на мощную типизацию.
Я вже не памʼятаю, на Паскалі свої ліби писати можна було, чи ні? В нього була ще проблема з неструктурованими даними, там не було буферних операцій, наскільки я памʼятаю... Може й не правий, давно було..
В лінії TP — BP — Delphi все було.1970-х не було нічого такого.
В стандарті ANSI (досить пізньому) теж було, але інакше.
В базовому зразку
Турбопаскаль я якось проскочив повзь, трохи на Делфі писав. Непогані там концепти були, особливо в UI компонентах. Дуже шкода, що мова нішевою стала...
Турбо/борланд паскаль був у нас певно як пік паскаль-популярності саме як мови програмування. Якщо delphi запам’ятався в основному чимось з UI, то в принципі то можна вважати як звуження до чогось на зразок фреймворк використання, що напевно і було однією з причин його закату.
Ну, в першому Делфі не було особливо куди розганятися...
Паскаль слохпнувся, бо майкрософт переманив чуваків з борланда робити дотнет, а сам борланд ходив по рукам. Відбувся бізнес так сказати. Жирна мегакорпа з’їла корпу поменше. 1 в 1 як ситуація з гуглом і престо, а потім сиквел з гуглом і оригінальним еджом.
Мовний ландшафт буде сильно мінятися в наступні роки. Років через 10 популярними залишаться ті мови, на яких дуже добре пишуть AI-агенти.
«на яких пишуть аі-агенти» мається на увазі мови згенерованого коду, чи мови які використовуються для написання софта яким генерується код та інший контент на виході?
це якісь SDL?
Я думаю будуть мови над високого рівня, які вже формальний до якогось рівня промпт, аля то юзер сторі наприклад, будуть компілювати безпосередньо в миншинний код.
Оперувати на такому відносно низькому рівні абстракцій, як то цикли та оператори вибору, потреб більше не буде — відповідно вирішиться проблема ІТ бізнесу, кратно збільшити виробничисть праці без критичної втрати якості і підвищення ціни.
З точки зору бізнесу, уявіть — що ви можете створити прототип по факту із пітчу власної ідеї, за лічені дні. А до того, вам би довелось кликати цілу ватагу профільних спеціалістів, брати на роботу менеджерів для організації їх роботи тощо. Хочеш якись Uber або Netflix або Facebook і за день на тобі — усе що треба з точки зору софту, йди тестуй бізнес ідею.
Єдине але — переважна кількість людей логікою Аристотеля не володіє і формулювати структуровано свої складні мислі не здатна, тобто програмісти все ще будуть порібні, вони будуть більше схожими на бізнес аналістів.
:) getting momentum behind excerpting
йопта!
підкину трохи
www.quora.com/...ll-bad-for-Linus-Torvalds
Хрести страждають від багажу шо тягнеться пів століття, починаючи із сі.
100500 віріантів як об’явити змінну, і половина із них це відстріл ноги відразу.
Сучасний раст всього цього не має, тому є значно легший для психіки.
Чому «страждають»? І як ви порахували 100500 варіантів, дуже цікаво.
en.wikipedia.org/wiki/Most_vexing_parse
це тільки перше що легко знайти.
Це 100500 позначає 19.
Ну це якщо після C++20 ще чогось не додали.
-
і чьо? це якийсь діалект плюсів?
Якщо ви не знаєте, хто такий Джосаттіс, і навіть не подумали спитати гугла про це імʼя, то вам в цій темі робити нічого.
Якийсь новий кумир мілленіалів? )) Чи просто автор книжок, один з сотень чи тисяч?
youtube.com/watch?v=...qslUA?si=r0Osk5PXCpKOHUMl
Counterintuitivе, в цьому проблема? ))) Ну а я вважаю польську нотацію контр-інтуїтивною, а також всякі Ерланги зі Скалами. Не подобається — обирай іншу мову. Це лише твоя проблема. А для вирішення проблем двозначних конструкцій синтаксису, давно існує typedef та using. Писати в поганому стилі можна будь-якою мовою, і це також не проблема мови, а проблема поганого володіння нею.
І це також, якщо не подобається щось нове — не користуйтесь. Не обов’язково в кожен проєкт пхати все що навигадували в стандарті. Беріть лише те, що знаєте добре.
В неоднозначности, що викликана незадовільною проробкою синтаксису. І ні, не всі випадки лікуються через typedef і using, інакше б в C++11 не додали {} для ініціалізації.
Тобто стандартизатори додали засоби виправити ситуацію, а Thomas Anderson, вочевидь, вважає, що вони погано володіють мовою.
Коли треба фактично вибирати з поганого і ще гіршого — а де-де проблема виглядає саме так — вона не тільки моя.
{} для ініціалізації було додано як загальний засіб, який працює в будь-якому випадку (особливо коли тип є неявним, оголошеним через auto, або як параметр шаблону). Нові засоби потребують нового синтаксису. І так є в будь-якій мові.
Я вважаю, що хтось просто скаржиться на життя, бо воно не таке як має бути))
Отож)
Я про те, що саме через Most Vexing Parse вони були вимушені зробити це через новий синтаксис — вибрали «{}» - а не через те, що було («()»).
А якщо б був нормальний порядок в визначеннях — проблеми б не виникло.
І це разом з новою милицею «using» показує, що синтаксична спадщина C дає проблеми.
Можна вважати і скаргою. Тому що коли розумієш, що спочатку вибирають погане рішення, а потім виникає таке легасі, що вже і переробити не можна (а ще більше випадків, коли просто не хочуть), а у тебе потім вибор — на якому з кривих монстрів писати своє — то це дійсно скарга.
Але тут вся тема така.
Є купа ніш, де адекватної альтернативи досі не існує.
Браузери можуть бути як приклад? Якщо прийняти за показовий випадок, то який фактор найбільш критичний — об’єм коду, сама мова програмування, чи ще щось?
наприклад?
Ну відстрелити србі ногу в С++ набагато менше способів ніж у С, але коли ви це робите — то відстрелюєте її цілком.
Не згоден. В принципі розробка на Сі досить безпечна, якщо підходити правильно. На C++ багато робиться неявно, наприклад, десь забув std::enable_shared_from_this і лови core dump в деструкторі буфера в лямбді при асинхронних операціях...
Якщо дотримуватись правил, будь-яка розробка безпечна. Ваш кеп.
якщо забув std::enable_shared_from_this то в тебе просто не буде потрібного методу і воно не скомпілиться
не відходь від канонів:
“THE PROGRAMMER’S QUICK GUIDE TO THE LANGUAGES”
www.stsci.edu/...~jboia/Public/shootf.html
Як казав один колега, перефразувавши Маркса, «нема такої підлости і ницости, на яку б не пішли автори GCC і Clang заради чергових 2% покращення в нікому не потрібному синтетичному тесті». Бо вони за такі показники отримують гранти.
Щонайменше в моєму звичному світу (Unix всіх типів) саме в цьому головне зло C++. Решта — небажання інших учасників вкладати гроші в те, що їм здається непотрібним саме для своїх користувачів, тому стандарти рухаються і компілятори разом з ними тільки тоді, коли найостанніший зрозумів, що без цього не можна.
Тому — шуміть. Пишіть всюди де можете про проблеми, хай лунає.
Дивно, чому це учасники не хочуть вкладати гроші в те, що їм непотрібно. Дичина якась. І стандартів як на мене, й так занадто багато. Все що треба, вже давно є в C++17.
Дичина і є, без сарказму. Якщо не розвивати спільне, буде фрагментація і тотальна несумісність.
Ну от наприклад позбавлення від UdB в арифметиці там немає. Може, в C++26 нарешті зроблять хоч половину.
То зроби свої класи, в чому питання? Чому в стандарт, чому не ліба?
Подивіться на те, що війшло в стандарт C23, подумайте трохи (!) і тому зрозумієте, чому без підтримки компіляторними інтринсиками це просто неможливо зробити (а в дуже обмеженому вигляді — буде дуже дорого і не оптимізуватись).
А не розумію, чому компіляторні інтринкси мають бути частиною стандарту. Ну додай __builtin_add_overflow_with_exception
і компілятор буде знати те саме, що й про звичайний +: асоциативно, комутативно.
А я не розумію, звідки ви взяли цю маячню.
Стандарт дає стандартні засоби. Як вони реалізовані — це справа компілятора, доки воно підримується.
В стандарт?
Драбина-та висока була?
UdB з’являється через те, що C++ існує для безлічі архітектур, кожна з яких має власні особливості. Якщо треба щоб все було визначено, для цього існує C# з дотнетом.
Ну... C створювався як системна мова програмування, яка дозволяє використовувати всі особливості платформи. Коли ти пишеш операційну систему, то ти не хочеш щоб кожного разу, коли ти додаєш два цілих знакових числа, генерувався допоміжний код навколо, який корегує результат асемблерної операції до стандарту. Так, в сучасному світі складно найти екзотичні архітектури, чи живий там UNIVAC? Ну а C# це взагалі тільки x86 та aarch.
Але «чомусь» для беззнакових результат виходу за межі означений, а для знакових — ні. Хоча з точки зору асемблера вони однакові.
І в операційній системі можна явно помітити ті частини коду, в яких хочеться саме relaxed підходу за замовчуванням — і щоб це було не тільки для знакових. Якщо програміст впевнений, то хай розмічає.
А ось у 95% юзерленду оптимальна політика як раз виняток на будь-яку таку ситуацію.
Тому що для безнакових результат однаковий на всіх архітектурах. А от для знакових це не так, наприклад, для UNIVAC 1100 мінус один це 0×11111110 (Ones’_complement) Там також є плюс нуль та мінус нуль (всі одинички). В асемблері там чотири різні операції додавання AA, ANA, AMA, ANMA.
Дякую, я в курсі про 1sʼ complement («зворотне» кодування в прийнятих тут термінах). Знаю навіть, як згідно йому рахуються контрольні сумми в IP.
Починаючи з C++20 і C23 підтримка всього цього виключена, тільки «додаткове» (0ʼs complement, чи на прийнятому жаргоні 2ʼs complement) кодування відʼємних. І то — останні архітектури, на яких ще було актуально якось інакше, залишились в1980-х, якщо не раніше. Більш того, LLVM з самого початку декларований був тільки для 2ʼs complement архітектур, тому і Clang може компілювати тільки для них.
Але «чомусь» всі ті хаки, що нагнані в GCC, Clang і примкнувших до них, щодо операцій зі знаковими, не вилучені, і не тільки вони (ще є жахливих прикладів), минне поле «шукаємо UdB всюди, де зможемо» збереглось і тільки укріплюється. Не знаєте, чому? Це було риторичне питання, але я спочатку хочу послухати вашу думку.
Як на мене всі операції зі знаковими так мало впливають на практичне програмування, що я не памʼятаю коли я останній час наступав на ці граблі. Працює — не чіпай. Тому більшість не хвилює.
Якщо брати Сі, то інколи він виконується на чіпах, де навіть цілочисленого ділення немає. Тому я можу зрозуміти чому не чіпати.
Далі, я просто хочу висловити свої думки з приводу переповнення. Які ніколи не будуть в С/C++ через зворотню сумісність. Але тут Ada попереду планети, Delphi на рівні.
Коли ми працюємо з кількістю, то будь яке переповнення в принципі зазвичай це помилка, при чому не важливо, знаковий чи безнаковий. Тому рішення Rust, коли singed/unsigned ведуть себе по різному, меня не подобається. Єдине виключення це модульні типи. Тому мене дуже дратують попередження signed/unsigned порівняння. Ну камон, якщо UB, то щось раніше пішло не так. А так порівнюй як signed, бо якщо у нас кількість, то я не памʼятаю, щоб вона була більше 2**31. Так, хеші, криптографія, але тут як в Ada модульний тип:
Все, кожен раз, коли ціле буде зберігатися в змінній типу RingBufIndex, буде взятий модуль і 1005 перетвориться в 5. Типи розрулюють, коли переповнення це помилка, а коли поведінка. До речі, бітові операції дозволені лише з модульними типами.Далі,
charзнаковий... Ну знову тут Ada/Pascal, де є Byte для цілих, а є Char, який треба обовʼязово кастувати (або Ord). Зайвий гемор, що треба писати(unsigned)ch >= 0xA0.Далі, якщо брати Debug-збірки, то всі UB імхо, мають бути або виключенням, або panic, щоб про це ставало відомо. Для вказівників також, не бачу проблему передавати зі вказівником розмір, та перевіряти кожне читання/запис. А якщо брати Release, то тут поведінку мають керувати опції, як в Delphi
{$I-}.+100.
А інакше не можна, поки конверсія до єдиного диапазону може спаплюжити якусь одну із сторін.
Ada — да, зроблено значно якісніше.
Таки не зайвий. Знову реальна ситуація: в лог виводиться щось, по типу
std::cout<<"value:"<<value<<"\n";Тип цього value змінюють на uint8_t, і лог паплюжиться, бо він сприймається як char і виводиться як один символ.
Тому — типи цілих і символів мають бути розділені без неявної конверсії.
Само розділення на debug і release тут дещо некоректне.1-2% критичного по часу і в дебагу треба мати можливість їх вимикати. Тільки для решти це має твердо залежати від режиму.
Для 95% коду і в релізі всі перевірки мають бути активні. Для
Тому режим має бути контекстний, у стилі, як в C# зараз є
але з більшими можливостями:
func moo(a: int, b: int): int = { #next(int_mode(wrapped)) // діє до кінця блоку ... c = #(int_mode(relaxed)) (a*b+e*f); }(ну і так далі)І ось тут можна додавати залежність від debug/release/etc. де хочуть:
Точний синтаксис треба буде проробити, але без завдання для всього блоку (функції, одного виразу) чи його решти (до кінця або до наступного режиму) не обійтись.
Можливі режими для арифметики з цілими:
checked (генерує виняток)
checked_with_flag (задана змінна, в яку пишуть 1 при проблемі)
wrapped (усікається)
saturated (береться крайнє) — з допоміжних
relaxed (програміст гарантує непереповнення) — як зараз в C для знакових
Може бути ще якісь.
І це не тільки для цеї одної проблеми. Ще є, наприклад, розіменування пустого покажчика (в специфічних випадках 0 допустимо), політика аліасінгу (! — іще одна болюча проблема)...
Ось з такою мовою можна вже досить сміло щось серйозне робити...
Можно подробнее?
З того, що цю можливість стали абьюзити замість тих самих 2% всупереч тому, що хотіли програмісти.
Можно пример архитуктуры, которая требовала, чтоб пустой бесконечный цикл приводил к «проваливанию» в какую-то рандомную функцию?
social.hails.org/...hailey/112147785725190189
як правило delay(1) рішає
Он может быть и решает, но я б хотел услышать ответ на свой вопрос.
Ось Вам відповідь на ваше питання: isocpp.org/...files/papers/P2809R3.html
Це було визнано дефектом стандарту і буде пофікшено в С++26.
Т.е. поинт UB в данном случае не в том, что есть «какая-то архитектура, которая имет свои особенности» (о чем говорил предыдущий оратор).
Поинт UB в том, что оно Undefined только в общем случае. В конкретном случае, какой-либо определенной архитектуры и компилятора, любое UB вполне себе defined, и либо документировано, либо может быть определено в процессе тестирования. А без тестирования, все равно никакой продукт права на жизнь не имеет.
Виявляється, лівацтво несе шкоду не лише в політиці, а й в програмуванні ))
+100500, але що «C++» що «няшна С-шечка», обоє страждають «стрікт аліазінгом» майже однаково... (ну в Сшечці ще restrict є... а тим, хто в С++ зробив доступ до «нетого» мембера юніона «андефайнед біхевіор» — взагалі треба руки повиривати... й std::bit_cast — лише костиль довкола того)
Ничего не имел против С++ долгое время пока не начал на нем писать. Язык простой (типа си-подобный), и в нем за последние 50 лет почти ничего не поменялось (ну епта, 50 лет работало и нахрена его менять ?). А, ну смарт поинтеры завезли и можна в forEach() поиграть, а так все по старому. Ждем модульной компиляции, а то строчку кода поменяешь и ждешь час билда. Из претенций — в мире с++ полно задротов. Ну хотябы требование к форматированию что бы код влазил в 80 знаков, типа имена мы уже как в джава пишем ЭтоДогоеИмяОбъясняетВсеПроЭтотКласс, а лимит 80 знаков никуда не делся, все как 50 лет назад короче !!! И еще по дибильному юнит тесты пишутся, везде есть мок фреймворки и т.д. В мире с++ люди предпочитают фейки, и что бы еще в фактори завернуть — настоящий клас в код, а в тестах что бы фейки, и обязатьльно в тестах показать насколько ты разбираешься в смарт поинтерах, не дай бог в ручную прибить какой то объект. И побольше енумов, они типа не дадут тебя забыть какой то из них. А потом ты пишешь на джава и вспоминаешь с++ и людей которые на нем пишут как сон — как можна загнать себя в таки рамки и там жить ? Ну понятно ты 10 лет на плюсах седел, но если ты каждые пол года меняешь стек — как можна не видеть эти задротства ?
Тоді з тобою щось не так.
Ну або такий бізнес і такий ринок. От мене останнім часом носить проміж :Kotlin, Node.JS і от тепер ще і Python. А ще давай типу Kubrnetis, Teraform в черзі , та треба вивчити Angular та Apache Spark, в той самий час доводилось і писати авто тести засвоїти ра базовому ріні Cucumber тощо. Це объективна реальність на ринку — червоний океан конкуренції і щоби залишатись на плаву необхадно мати доволі штрокий асортимент навичок. Клієнт заоаз хоче таких собі мега стек інженерів. В цілому за допомогою ШІ це поступово стає можливим.
OK, я спочатку подумав про інше. У мене насправді дещо схожа ситуація та «мега стек». Я б назвав це не «міняти стек», а розширяти свою кваліфікацію та спеціалізацію.
А такі речі як Kubernetes та Terraform від стека не залежать. Вони скрізь.
обожеж ти мій.
Стандарт C++11 — 1250 сторінок. C++17 — 1605 pages. С++20 — 1930. С++23 — 2049.
Точно нічого не помінялося?
Модулі з’явилися в С++20.
Вимоги до форматування в кожному проєкті свої. Ставте собі скільки хочете, мова того не забороняє.
І в С++ є. GoogleMock — фактично стандарт.
Що там розбиратся, базових смарт поінтерів з різною семантикою володіння — всього три штуки. Пояснити їх використання можна третьокласнику за 15 хвилин, з двома перекурами.
І правильно, чим менше ручного меморі менеджменту — тим краще.
Я чесно не пишу на c++, але доволі часто чую що з модулями не все так гладко. Через те що кожний виробник копіляторів робить це по своєму.
Робить, ну то й що. Беріть Clang і юзайте його реалізацію кругом. Якщо Гугл на ньому Хром написав під всі ОС, то і вам підійде.
І всю інфраструктуру збирання теж копіювати з Хрома?
Інфраструктура збирання Хрома вирішує купу різних задач. Дивіться самі, чи воно Вам треба. Швидше ні, ніж так.
"
— как ты мог все это знать? может ты и есть один из тех людей кто делает с++ языком задротов?)) Прошли те временя когда ты мог взять и на проекте просто поменять ширину кода, счас все работает типа — мы пользуем рекомендации такой то компании к форматированию и просто акцептите это. Про поинтеры — хорошее изобретение, но мозки выносит сильно. Одно дело — ты пишишь код с нуля и лепишь смарт поитнеры там, другое дело ты добавляешь код в проект которому 10 лет, давай добавь свои смарт поинтеры к старым не смарт поинтерам и 3р библиотекам которые частично смарт а частично не смарт, потом твой код просмотрят задроты и начнут расказывать что смарт поинтеров можна было бы и больше написать...Тоесть всесто того что бы думать над бизнес логикой ты тратишь время на выбор дата стракчерсов, их создавание и их удаление из памяти, даже в юнит тестах ? И ты будешь думать что все ок пока не начнешь писать на джава и жс, и только потом оглядываясь назад ты поймешь что с++ маст дай !)
Відносно тільки одного пункту — робити якісь висновки по мовам програмування виходячи з рекомендацій по форматуванню — а в інших мовах не існують відповідних практик рекомендацій від слова зовсім?
Як це мови стосується? Вас компанія може заставити стрибати через скакалку на будь-якій технології.
Ця проблема була актуальною десь в 2011 році. Після цього std::unique_ptr/std::shared_ptr/std::weak_ptr стали стандартом і за2-3 роки всі живі проєкти на них перейшли. Якщо щось було мертвим вже в 2011 році і не мінялося з того часу — ну, співчуваю в такому проєкті копатися.
Швидше видаліть це, так і до GC недалеко
Я би навіть сказав, що С++ 98 і С++ 11 вже різні мови програмування. Далі переломна віха С++ 20. Реальна архаїка тим не менше в Modern C++ є і позиція в комітеті зі стандартизації дуже потужної присутності Microsoft, блокує в сутності пропозиції Google прибрати цю архаїку та отримати 15% буст із продуктивнісю, разом із тим зламавши зворотну сумісність по ABI. А по суті у корпорацій діаметрально протилежні бізнес інтереси в цьому випадку, одним треба скоротити кости на сервери і 15% краща продуктивність коду це мільярди з економічних коштів на електрику і т.д. Для інших зберігти зворотню сумісність для софту який працює на мільярдах пристроїв по усьому світу.
Саме тому, наприклад, із пулом потоків не можуть розібратись 5 років.
Моя особиста позиція на стороні Google, ABI так чи інакше з часом доведеться зробити не сумісним.
Переписувати десятки мільйонів строк коду на С++ на Rust чи ще щось, без змістовно, навіть з допомогою ШІ.
Где вы насчитали 50 лет? Первые коммерческие реализации появились в80-х. Модульная компиляция давно есть, библиотеки называется — пользуйтесь. Лимит 80 знаков это дичь, конечно. Я стараюсь влазить в 120. Юнит тесты пишутся так, как позволяет язык — это ж не C#, где есть интроспекция и можно генерить IL-код на лету. Остальное видимо, следствие вашей профдеформациb после долгих лет на Java ))
Якщо візмеш код С++98, та щось написане вже на С++20. То це майже різні МП.
Те, що якість чуваки в 2025 пишуть спп код, де напряму юзають рау поінтери, інклуди замість модулів і іншу хрінь типу typedef не каже про те що мова не змінилась.
Настільки товсто, що серйозно коментувати немає сенсу. Тому я просто залишу тут mohitmv.github.io/...ined-Behaviour-In-Action
Растаманов набирают. Набегайте, кто в теме.
www.linkedin.com/...wLr-Lh2Rt5GGvg934JGoZRRl4
Ну що взлетить п"ятнична тема?
Згадався анегдот про голодних звірів у ямі.
— Давайте з’їмо самого слабкого.
— Заєць: «Не чіпайте медведя»!
заходить Раст у кімнату... слухав-слухав... — А зато я збираюсь найдовше!
Зайченок (JS/npm): А мне папа вчера машинку купил!
Лисенок (Rust/Cargo): А мне папа велосипедик купил на той неделе!
Мишка (C++/WTF): А я!! А мне!!! А я вам всем щас 3.14зды дам
з трохи поржавівшими колесами, а зато не так падає, бо квадратні колеса ще необкатані)
на лого таки коліща, так що не потрібно ляля про квадратні колеса
то вело-колеса такі для зручності придумали? хмм..
може і взлетить якщо колеса підрівняти і наждачкою пройтися)
в С++ на лого якась гайка на 6 граней
після велосипеда все може виглядати гайкою, навіть 3D hexagon)
це тільки вид зверху граньоного гексагона, зі зворотньої сторони там глухий отвір зі збитою різьбою (С++ник: «повидло, засахарилось», Rustаман: «а я ж зразу казав що г.»)
під таким вузьким кутом не взлетить, якщо тільки плюсовики не зацікавлені лого шестернями поштовхатися
С++ — язык графики. Появился во времена позднего DOS, расцвел на Wintel десктопе, сейчас нишевой язык игр/3D/обработки видео.
Отрицать его, как и пропагандировать за пределами этой ниши — глупо.
Я майже згоден. Хочеться вірити що це не зовсім так та в мене немає відповідних знань.і досвіду. Просто коробить від Rust і його фанатиків. C++ майже те саме, але не таке бридке.
А як же Хромог, Alcohol 120%, Adobe reader, PDF-Xchange editor, всякі там дефрагментатории і оптимізатори для Windows, EyeDefender і подібні програми, архіватори, фаєрволи, антивіруси, FlylinkDC++, Notepad2, Notepad++, Sublime text, KDE і вагон програм на Qt, Clipdiary, oMegaCommander, XnView, Cinta notes і т.п.?
настільки зараз вузька ніша — really?
:) нп браузери.. та навіть llvm
p.s. ніша ігри/3D виглядає в майбутньому досить зручною для Odin, хоча мова програмування доволі нещодавно тільки і створена (тому невідомо у що виллється якщо популярною стане)
писав на C++ і різних його варіаціях як C++/CX десь майже 5 років, що працював в Майкрософті, в тому числі компоненти ОС. Пишу на ньому ж останні 3 роки в Гуглі і твердження про нішевість С++ дуже далеке від реальності.
Ви не повірите скільки всього і в яких доменах написано на С++, спробуйте порахувати навіть тут chromium.googlesource.com/...ads/main/chrome/renderer або тут github.com/...tree/main/src/CalcManager або тут sources.debian.org/src/apt/3.1.5/methods
А кто сказал, что это -хороший- софт?
Їм користуються мільярди (не мільйони, а саме мільярди) користувачі в усьому світі. Але це зміщення фокусу — класичний прийом демагогії, перше твердження було про нішевість С++, а не про «хорошість»
Миллионы мух никогда не ошибаются.
Чем шире аудитория продукта — тем больше он похож на дерьмо.
Зазвичай в точності до навпаки — чим більше аудиторія, тим вище конкуренція, тим вищі стандарти якості і вимоги до якості коду, безпеки і надійності. Бо інакше конкуренти тебе замінять чимось кращим, 0.01% проблеми надійності означає що вони впливають на сотні тисяч користувачів, а найменша проблема безпеки фактично гарантовано буде знайдена і використана.
И шо? Большая конкуренция у Windows?
Звичайно і дуже значна.
Не треба плутати домінантну позицію на ринку десктопних ОС і конкуренцію. Як тільки Windows стане гірше, то почне втрачати долі ринку і заміщуватися конкурентами (MacOS, ChromeOS, Linux ітд), не одномоментно, поступово, але це втрата мільйонів користувачів. Як тільки в коді буде суттєва помилка безпеки — хакери її знайдуть і використають, найменша вразливість може обернутися глобальною катастрофою. Як тільки тільки буде допущена помилка в коді яка впливає на 0.01% користувачів — це вплине на сотні тисяч і про це обовʼязково напишуть в інтернеті.
Тому вимоги до якості коду, і відповідно результат, значно перевищують вимоги до невеличкої програмки на10-20 користувачів зробленою на замовлення компанією Ратиці і Копитця, чиїм основним підходом до безпеки є те, що її ніхто не намагатиметься зламати.
хакеры-шмакеры ...
1. Винда необычайно тяжеловесна — в несколько раз больше юниксов.
2. Тормозная
3. Кошмарный UX, как и у всего Майкрософта.
4. Необыкновенно трудно настроить что-то кастомное
Но мухи продолжают садится.
Тобто: початкове питання вузьконішевості звелося до невдоволення віндовсами
А якщо лінукс софт на плюсах — те саме?)
Тут все наплутано — нішевість мови програмування, якість програм, якість продукту, якість UX і ваші субʼєктивні враження від користування. Давайте розберемо по черзі.
С++ має мало звʼязку з цим, Юнікси теж використовують С++. Великий розмір це ціна за підтримку заліза і сумісність з старими програмами (тими самими, чиє використання часто спонукає користувачів залишатися з Windows) і рішення, що саме буде поставлятися з ОС, а що ні вирішують не тільки інженери, а і ті, хто ці ОС будуть продавати. Але цю проблему потрохи вирішують. Наприклад моя команда займалась цим www.windowslatest.com/...t-for-better-performance для зменшення розмірів, що займає ОС в середньому випадку.
Часто те що називають «тормознутість», це наслідок роботи сторонніх (не msft) програм, які користувачі встановлюють на свої системи.
UX != інженери і не має відношення до С++. Але в будь-якому випадку UX це часто питання смаку і звички. Комусь он подобається Vim а хтось програмує пересуваючи мишкою блоки в якихось low code системи типу Power Platform. За кожною зміною UX стоїть експеримент і UX дослідження. І якщо його впровадили — то більшості підходить.
PowerShell може приблизно все, коли мова йде про налаштування. Може ви просто не розібрались. Але знову ж таки — більшості це може бути банально не потрібно. А магрінальні групи людей, кому потрібно, можуть бути недостатньо великими щоб виправдати інвестицію часу і ресурсів.
Якщо привести аналогію з машинами — то деякі машини це Феррарі, а деякі автоваз адаптований для єгипетського ринку. І якщо для більшості людей Феррарі по якості буде краще за єгипетський автоваз, це не означає що вона краще по всім характеристикам бо для неї треба спеціальне паливо і багато, а автоваз можна заправляти і паливом розбавленим віслючою сечею і він, може, ще й поїде, бо датчиків-запобіжників якості палива у нього нема. Я не стверджую, що Windows це Феррарі світу ОС, ні, скоріше, що критерії порівняння як «субʼєктивне враження 1 людини» недостатні для обʼєктивних доказів всіх перерахованих недоліків.
Ага. А ще є реєстр, Windows script host, Windows API і ніхто не заважає поколупатися в DLL і написати програмку яка буде робити щось таке незвичне. А от перезібрати ядро вже не можна, ніяких тобі KDE, GNOME, MATE, XFCE, TDE і віконних менеджерів.Завантажувач тільки один і з ним особливо нічого не придумаєш. Немає мішка файлових систем. Життя з домашнім каталогом на окремому розділі — суцільний головний біль.
Винда тяжеловесна, по той простой причине, что в ней обеспечение бинарной совместимости с написанным за 20 лет кодом это абсолютный приоритет. И это есть основной фактор ее успеха на рынке. Потому что бизнес такое ценит. Write once — run forever.
Ну да, конечно. Игры почему-то только и делают на винде.
Ну это он по-вашему кошмарный. По-моему, идеальный (если брать Windows 10). А кошмарный он как раз в OS X.
Что например, вам нужно настроить «кастомное»? Вы вообще имеете представление о WinAPI, чтобы делать такие заявления? Винда это система в первую очередь для десктопа. Во-вторую, для встраиваемых приложений, где нужен развитый программный стек и технологии UI, с долговременной поддержкой (25 лет для версий Embedded). Например для банкоматов и киосков самообслуживания. Ну а для серверов и легкой одноразовой электроники, ничего лучше Линукса конечно не придумали.
На гнилое Apple, ага.
О да, ради бинарной совместимости с тем, чего ещё не было, придумали WMI.
Ради бинарной совместимости с тем, чего ещё не было, придумали NTFS с раздутыми структурами на диске и чудовищно запутанным драйвером, в котором лет 20 лечили «мелкие» проблемы и который в полном объёме понимает человек пять на всю планету.
Ради бинарной совместимости (с чем?) придумали 13 аргументов у CreateFile().
Ради бинарной совместимости (с VMS для VAX, что ли?) до версии где-то 3.51 любой сисколл гонял в ядро и обратно 4KB данных.
Можно как-то убрать эту «совместимость» из базовой поставки и чтобы она возникала только для тех, кому реально нужна?
Как запустить приложение для MS-DOS на Windows 11? Без виртуалок, пожалуйста.
Настоящее Write once — run forever — это у IBM. Написанное под S/360 в 1964 году будет без изменения работать и сейчас, причём, если не системное, то и виртуализация не требуется, а если системное, то достаточно лёгкой (Base Control). А у Microsoft это кривой хилый закос под.
Снизим пафос на два порядка, но процесс идёт. Винда становится слишком дорогой.
Каждый раз, когда надо что-то подстроить, я знаю, что уйдёт на это вместо одной минуты — до десяти в простом случае, потому что 1) функции разделены между Control Panel и Settings самым неочевидным образом, 2) придётся продираться через «облегчённые» настройки, в которых фиг выйдешь за пределы типовых случаев, а всё чуть сложнее сидит на третьем уровне всяких advanced settings.
И при этом всё равно не починили, что если всплывает новое окно, то открытое меню может схлопнуться, и нажатие пойдёт не туда, куда ожидаешь.
И они тоже активно мигрируют с Windows, в первую очередь по причинам, что разоришься на юристах, разбираясь, за что ты должен платить в контейнере.
WMI придумали, чтобы легко можно было пользоваться из скриптовых языков (VBScript), а также из командной строки. Это тулза для администрирования. В чем с ней проблема?
Скажите сразу, что вам название не нравится — аргументация того же уровня.
Вы что-то путаете, у CreateFile всего 7 аргументов.
Что еще вспомним, может быть CP/M?
Можно, называется Windows Embedded. Я правда давно с ней не работал, но раньше был Platform Builder, можно было составить свой образ без лишних компонентов.
Ну так реальный режим уже и процессором не поддерживается, в x64 он не реализован. Так что MS-DOS только на виртуалках. Приложения DOS кстати всю жизнь работали в виртуализации, если вы не знали.
Кривой или нет — это ваша субъективная оценка. Объективно — старые приложения поддерживаются даже на уровне багов, для которых были сделаны пути обхода. Причем как на уровне приложений (в Windows есть специальная база данных, которая для протестированных приложений включает режим совместимости). А для не протестированных, можно выбрать просто Run as Windows 7 (Vista, 8, etc).
Вам что, заняться больше нечем, каждый день что-то подстраивать? Подавляющее большинство настроек делается ровно один раз, максимум два если результат сразу не понравился. У вас наверно просто психоз, это тогда к другому специалисту))
Видно, что вы никогда не сталкивались с её багами. Ну, бывает.
Описка. Всё равно нелепо много. А ещё вспомним, что регулярно требуется извратиться с UNC.
Можно и CP/M. Это будет относиться уже не к вопросу раздутости, но к тому, почему вместо нормальных названий дисков всех обрекли на вековые страдания с буквами, да ещё и сломали логику имён устройств.
Когда Intel хотел в пику AMD сделать свою кодировку для64-битного режима (это не про Титаник, это именно про расширение x86), MS сказала, что не будет для такого делать Windows — и Intel взял под козырёк и остался с той кодировкой, что AMD сделала наспех, когда была нищей на грани банкротства.
Когда стоял вопрос о логике расширения для AVX, и выбор между стилями «надо разрешить явно» и «само приползёт» — MS выдавила второе, и имеем теперь абсурд с командой vzeroupper.
А с реальным режимом почему-то MS этого не захотела, хотя если бы сказала «надо» — Intel бы взял под козырёк. Или даже без него: переключаться между legacy и long больно, но вполне подъёмно, любой x86 процессор позволяет, и не такие извращения делали. Вот про это я и говорю: разговоры про бинарную совместимость как «абсолютный приоритет» это миф. Нету у MS такого правила. Максимум есть «если очень хорошо заплатят, мы подумаем».
Virtual 8086 != полной виртуализации.
Сколько из таких ещё осталось? Большинство этих хаков было вообще для16-битных приложений.
Про «каждый день» верните на тот потолок, откуда взяли. А если вы не представляете себе ситуацию типа «теперь надо добавить ещё польскую раскладку», «дорогой муж, а подправь мне чувствительность мыши» и пр. (может быть несколько раз, пока не найдётся оптимальный результат, и то может «плыть») — это ваши п/с проблемы, а не мои.
Бывает, что и палка стреляет. За мои почти 25 лет пользования виндой с NTFS, начиная с Win2K, как-то не сталкивался, да. Не считая случаев нештатного завершения, когда портился реестр. Ну абсолютный fault tolerance никто и не обещал.
Извините, но ваши аргументы все больше напоминают нытье. В винде хотя бы есть универсальный доступ к сетевым и локальным ресурсам, на уровне API. В линуксе с макосом таким и не пахнет.
Кто ее определяет, эту «правильную» логику? Система с буквами дисков была простой и понятной — есть устройство, есть его название. И понятная до сих пор. А не путь где-то там от рута, который еще и монтировать надо. При любом подходе, найдутся люди, которые будут «страдать». В данном случае это вы, а все остальные привыкли и пользуются. Как МКПП в машине или шнуровкой в ботинках.
Вот именно. Сохраняется то, что реально востребовано. То что не востребовано, удаляется из системы. Но в целом, подход именно такой. Были бы кому-то реально нужны были DOS приложения, до сих пор, они бы поддерживались из коробки.
Приложения MS-DOS это не приложения Windows. Можно еще OS/2 вспомнить, тоже поддерживалось до WinXP вроде бы (и то, в рамках16-бит кода, т.е. до конца совместного участия с IBM). Если хотите взять на понт, ничего не выйдет) Здравый смысл никто не отменял.
Прекрасно представляю. И прекрасно помню, что где крутить. Плюс тоже самое на Андроидах разных мастей (гепловских поделий в обозримом периметре нет, бог миловал). Плюс собственный сервер на Debian. Вот последний реально жестяк, не дай бог какое обновление что сломает, считай пару часов увлекательного траха обеспечено.
5"25 флопік
A двікрапки
для тих хто флопіки досі юзає
Флешки зараз, яка різниця? І не лише флешки — Google Drive так само має букви. І до речі, це дійсно зручно — бо є 4 акаунти, є 4 диски. Ти звик що G: це один акаунт, H: інший. Заперечувати що це зручно — ну не знаю, якась тупа впертість вже.
в сакральності «A:» для 5,25 флешки)
монтувати з назвою яка зручна і там де виникає потреба, а не там де є знайома буква G
назвемо так — C: впертість типу дос)
Нема ніякої сакральності. Ось я зараз призначив A: для флешки, можу показати:
Слово «монтувати» користувачам без технічної підготовки взагалі не знайомо. Це те, що має відбуватись автоматично та інтуїтивно. І букви пристроїв якраз так себе і поводять.
суб’єктивне використання практично взаємовиключних частин можна називати впертістю?
Що саме є взаємовиключним та неінтуїтивним? Букви пристроїв існують з початку ери PC та є звичною практикою, а PC та Windows є досі домінуючою архітектурою на ринку. Нагадати скільки років? Вже 3 покоління на цьому вчиться. Це значно простіша абстракція, ніж оте «монтування» що для користувача виглядає як якась папка, яка з’являється десь сама по собі, і треба ще знати де і як вона з’явиться. На OS X цю папку дійсно відображено як окремий пристрій, але це омана. В Windows омани немає.
неінтуїтивні букволегасі типу G:
для користувача — у віконці чи якомусь докбар побачив у списку назву чогось (з більш-менш зрозумілою назвою)
для адміністрування etc. — ієрархічна система необмежена однією буквою (навіть G:інтуїтивною чи C:cакральною) — зручно
Ви мабуть окрім смартфона нічого не бачили. Для всіх хто користувався комп’ютером, а я впевнений що всі починали з Windows, концепція «пристрій позначається буквою» є абсолютно інтуїтивною та зрозумілою. Цьому ще в школі вчать. Ви прогулювали інформатику?
яка показова я-самовпевненість у «всі»
тобто цікавить не тематика підтеми, а хто що прогулював?)
В часи коли дос ще не було — чи була інформатика у школах...
а якщо була — як же тоді вивчали букви А-Б-Ц — містична загадка яка ще досі інтригує деяких осіб)))
Була, класи були на Yamaha MSX наприклад. Я сам в такому вчився, десь пару років застали ще. Що потім з’явилось не пам’ятаю, але вже вивчали Паскаль, то мабуть були PC AT. Але навіть на Ямахах, на вчительскому компі була CP/M (якщо вірити Wiki), а в CP/M диски теж позначались літерами. На учнівських компах ніяких пристроїв не було взагалі. На Спектрумах OS як такої не було, був системний монітор що мав 1 команду на завантаження даних що йшли з магнітофону через лінійний вхід. То ж це не пристрій в системі. А на дискових OS на кшталт TR-DOS вже були саме диски з літерами.
В підсумку, можна стверджувати, що будь-хто, хто хоч чомусь навчався, має уявлення про те, що накопичувачі позначаються літерами. Тобто це інтуїтивна та зрозуміла концепція, яка є стандартом де-факто.
Трохи раніше починали з фортрану і макроасемблера, паскаль і сі були — але на тому «фортран»-залізі були настільки повільні що їх практично ніхто не використовував у розрахунках (хоча на ознайомитись було нормально). Ще трохи з того що було наводив у коментарях VN.
треба в меморіз внести, щоб будь-хто з майбутніх нащадків часів диску Це букви не забували)
після «Додати коментар ...» можна не додавати)
Макроасемблеру, серйозно? )) Це де ви таке бачили, на кафедрі якоїсь кібернетики в КПІ? Дуже масове явище, ага. Якби вся країна так.
хоч взнали трохи що існувало поза диском Це, а то школа школа ...)
з двокрапкою
Есть куча людей, которые начинают свое ознакомление с компьютерами именно со смартфонов/планшетов и потом с макбуков, и таки да, не знают ничего про какие-то там буковки.
Что-то мне подсказывает, что такие люди не только про буковки не знают, а вообще практически ничего. Кругозор размером с яблоко.
назвіть то яблукозір versus дискцезор :)
Якщо дуже треба щоб все було в одній ієрархії, то змонтуйте пристрій як папку, NTFS таке підтримує. Або як symbolic link. Ну щоб зовсім як в лінуксі.
забувши нещодавнє зневажливе «оте монтування» пропонуєте «змонтуйте»)
Це ж ви того хочете, не я.
Если называть «ресурсами» шаринг файлов, принтеров и т.п., то завести нет проблема и на юниксах, только вот смысла в последние годы как-то совсем около нуля.
У вас проблемы с чтением сообщений собеседника. Не пути от рута, а имена дисков. Если вы не в курсе: в RSX-11 с аналогами было, например, что где бы системный диск ни находился, для него есть алиас «SYS», в путях — используется типа «SYS:COMMON.LIB». Алиасы можно назначать от админа достаточно произвольно. А ещё когда отправляешь, например, FOO.TXT на принтер, создаётся «PRN:FOO.TXT». Вот это у MS сломали и не восстанавливали, а в результате имеем проблемы типа такого, где я без UNC не могу гарантировать, что мне не подсунут AUX.CPP (реально был когда-то в MySQL) или COM³.TXT, который завесит программу от попытки доступа.
И нормализовать тут оба аспекта было бы банально, но MS продолжает хотеть, чтобы было через зад.
Эта формальность за отмазку не канает. Под DOS написано огромный объём софта, а автор оси та же MS.
Специально запоминали 100500 частных случаев «вот это в Control Panel, а это в Settings, а это вообще в отдельной тулзе». Мне моя голова пока что дорога в разумном состоянии.
Просто удивительно, как вам нравится запоминать херню, но не пользоваться логикой.
Вопрос субъективный. Для меня это абсолютно естественно, что любая прога из коробки поддерживает сетевые пути.
Ну так в винде системный диск всегда будет C: — так было еще со времен DOS. Трудно запомнить? Можете назначить Volume Label если трудно. Обозвать флешки как PHOTO или BACKUP, в Проводнике будет сразу понятно что есть что. Google Drive их сразу создает, с именем аккаунта — тут вообще без вопросов.
Ну вот я создал в Far три файла — AUX.CPP, CON.CPP и PRN.CPP. Да из стандартного UI они недоступны, но ничего нигде не зависает. Согласен что сообщение могло бы быть и более понятным, чем «Elevation required» или «File not found», и удалить их стандартными средствами нельзя. Но и создать не получится. Far может создать файл с именем хоть из одного пробела.
Написано, но софт под DOS уже история. Оно сейчас если где и работает еще, то на всяких контроллерах, с дисплейчиком 16×2. Сам писал под такое 20 лет назад.
Такое ощущение, что вы застряли на системе 10 летней давности. В Win10 22H2 путь ко всем настройкам идет через Start — Settings. В Contrl Panel уже практически ничего важного нет. А то что есть, имеет ссылки из нового UI. И все устроено более-менее логично. Поиск по настройкам помогает, если что. В крайнем случае открываете gpedit.msc и видите все что поддается настройке в виде дерева — логичней не бывает. Cтавьте лайк если не знали ;)
Ну если продолжаете пользоваться файловым шарингом в 2020х как основным методом... извинити (tm)
А кроме системного диска вы про какой-нибудь ещё слышали?
Недоступности достаточно, чтобы с этим были массовые проблемы у приложений.
Самое главное, непонятно, накойхер оно осталось в не-DOS, а тем более в Win64 приложениях.
Именно что на 10ке стало резко хуже, чем на 7ке. Нет, не все. Многие оттуда недоступны, приходится идти через Control Panel. Это раздвоение известно всем, кто работает с виндой, но почему-то не вам.
11ка 24H2. gpedit.msc отсутствует. Вам дизлайк 👎
Да, продолжаю пользоваться. У меня есть NAS, который доступен через шаринг. Простые вещи должны оставаться простыми.
По-моему этот тред начинает превращаться в демагогию. Доказывать очевидное, знаете ли, утомляет.
Например?
Вы аж заставили меня поднять виртуалку и проверить:
Как бы, сказанное вами не соответствует действительности.
На моей винде со свежекупленного лаптопа Asus его нет. Я ничего не делал, чтобы его не было.
По причине перехода Thomas Anderson на личные оскорбления в соседнем комментарии закрываю дискуссию с ним.
Ну как не делали. Вы купили устройство с урезанной версией винды (Home Edition). И теперь оказывается, что там чего-то нет, внезапно. Причем и не было никогда — начиная с WinXP как минимум. Просто детский сад (салфетка была намеком именно на это).
Тут интересный вопрос, MS ничего не стоило реально встроить в ОС программный эмулятор старой архитектуры для поддержки старого ПО про которое они так беспокоятся, причем оно б работало следующие 50 лет с нулевой поддержкой, но почему-то решили, что лучши поддержку дропнуть, что ставит под большой вопрос аргумент про любовь MS к совместимости со старым софтом.
Это ж не Windows-софт, почему он должен нативно поддерживаться? При том что и железо тех лет уже давно умерло и не имеет прямых наследников (звук, графика, периферия — все это не будет сегодня работать). А какая-нибудь БД на FoxPro или Clarion в текстовом режиме 80×25 с успехом взлетит в виртуалке, обеспечивая дополнительные плюшки вроде простых бекапов (VM snapshots), что для таких файловых систем как FAT было актуально. С другой стороны, Windows-софт уже не работает напрямую с железом, поэтому и поддерживается гораздо проще. Нет смысла в нативном DOS короче.
Что обозначают первые две буквы в слове MS-DOS?
Да, но эмуляторы существуют и на них все прекрасно работает.
Поставщика системы. У Майкрософт еще Unix был собственный, Xenix назывался. OS/2, которая должна была стать будущей NT, но не стала. Тоже нужны эмуляторы? А для OS/2 он был, между тем (поддержка16-бит NE бинарников и вызовы API).
Возможно. Но это по больше части для старых игр. Серьезный софт для работы давно уже переписан под Win32, а если надо чтобы работал старый софт — я думаю, у Microsoft есть что предложить.
Вообще, смысл моего посыла «Write once — run forever» был в том, что так это делает Майкрософт, больше не делает никто. На линуксе — пересобирай пакеты под каждый новый релиз, а пока сидишь на старом, никакой новый софт тебе не светит. Даром что никакое новое ядро ему не нужно, а нужны просто библиотеки, которых в системе нет. А нет потому, что все сцементировано на системном уровне — невозможно обновить что-то одно и локально, надо обновлять все и глобально. Т.е. ты либо сидишь на старой системе со старым софтом, либо обновляешь систему и весь софт вместе с ней. Варианта обновить только систему нет.
В OS X Apple вообще срать хотела на старый софт — конечно, зачем его поддерживать, если можно нагнуть разработчиков чтобы они все переписали. А если разработчиков уже нет, то и хрен с ними — выкинем из аппстора, а взамен кто-нибудь что-то новое напишет. Ну или не напишет — скажем юзерам, что это для их же блага, не понимают своего счастья. А Apple потом поимеет процент с продаж. Профит!
Це робить також ядро Linux в парі з контейнеризацією, випадки ламаючих змін в сисколах там надзвичайно рідно стаються.
шукаєте схоже immutable os з розділенням на core/user та з їх атомік апдейтом системної частини, при бажанні знайдете (опцій з дистрибутивами достатньо, але то не системи диска Це)
Ради справедливости, встроенный поиск в кнпоке Пуск стал довольно годным и позволяет найти что нужно, если помнишь как оно называлось.
Нет, он постоянно в первую очередь вываливает в веб со страницами самых общих рассуждений на тему названных слов.
Настроить клавиатуру или то, что называется accessibility, как «пузырьки» локации мыши — через него идти тупо бесполезно, предложит всё что угодно, но не нужные пункты программ настройки.
Так что и это они сделали отвратительно.
1. Каким образом «Ease of access» означает раскладку? У MS своя версия английского?
2. 11ка 24H2. Этих пунктов в списке нет.
3. Ну вот открыл accessibility mouse settings. Чтобы дойти до нужного, я должен докрутить вниз, дойти до additional mouse settings, которые откроются отдельно (а как же accessibility и какая связь с additional?), там среди интерфейса древнего стиля (95) найти это в pointer options (логика уровня «безумный бог») и только там включить.
Прежде чем давать советы, вы хоть пробовали сами проверить, о чём говорит другой?
Accessibility вы упомянули, не я. Хорошо, замените на «keyboard». Вам случайно салфетка для носа не нужна? А то сопли текут, некрасиво.
«А если найду»? Нет, реально вы думаете, что у меня нет на чем проверить?
Конечно. Поздравляю, вы справились. Может еще чем-то помочь?
О, вы начали оскорблять оппонента! На этом считаю дискуссию законченной.
> Вообще, смысл моего посыла «Write once — run forever» был в том, что так это делает Майкрософт, больше не делает никто.
Повторюсь: единственный, кто так реально делает, это IBM. Как минимум в линиях Z (потомки IBM/360), I (AS/400), частично и P (POWER, RS/6000). А Microsoft делает в лучшем случае наполовину, очень ограниченно, после того, как ей пригрозят уходом с её решений (были примеры) и при всём при этом качество в последние годы упало в разы за счёт избавления от собственного штата тестеров.
> Т.е. ты либо сидишь на старой системе со старым софтом, либо обновляешь систему и весь софт вместе с ней. Варианта обновить только систему нет.
То есть про докер с кучей аналогов вы не слышали, как и то, что подобные решения на базе даже простейшего chroot() существуют ещё с середины1990-х. Это если решать максимально прямолинейно, а есть и более хитрые методы.
Вам ещё многое предстоит узнать...
Я рассуждаю с т.з. пользователя десктопа, которому нужна система с поддержкой, но у которого есть какой-то свой коммерческий софт, за который он один раз заплатил, и хочет пользоваться пока в нем есть потребность.
По поводу chroot, это средство для повышения безопасности, а не совместимости. Чтобы софт работал с ограниченной видимостью файловой системы, в частности чтобы не было доступа ко всему /etc а только к собственным конфигам. Штука хорошая, сам недавно делал песочницу для одного сервиса на Golang, но вопросы совместимости не решает.
По поводу докера, это решение не для конечного пользователя. Это форма, в которой продукт должен поставляться изначально. Если у тебя обычный .deb пакет, то докер никак не поможет. Точнее, конечный пользователь тогда должен решать свои проблемы самостоятельно, создавая окружение которое требуется. Что он вряд ли осилит.
один з можливих варіантів гарантування runtime — snap/flatpak як засіб пакування, а з орієнтацію систем на «конечный пользователь» познайомтесь з immutable дистрибутивами як опцією
С другой FS. В которой уже может быть что угодно, но другое.
chroot был для примера, что средства есть давно. Естественно, сейчас лучше использовать что-то вроде snap. Автоматизация этого для старого софта есть, я видел коммерческие решения, но названий сейчас не найду.
Или осилит, или заплатит. Главное, что система этому не мешает.
Чего-то я не понял, почему я другому человеку тут отвечаю. Артём, извините, промахнулся где-то.
я тут на днях на T480 намагався убунту поставити, мінт та кубунту.
Від чорного екрану до зависання інсталлятора на етапі вибора часової зони.
Стає тільки калі. Але калі у мене стає і на 12700h і на 12900К, і на старенький A200 тошибу.
Може це, варто перестати гратись у дитячий садочок з кастомізаціями і трохи зайнятись тим, аби догнати вінду у плані сумісності з залізом6-8 річної давнини? Ну шо б ставало без «ой, може вам треба спробувати поставити без графічного інтерфейсу, напевно це сумісність з графікою
»
Образы Убунту9-20 продолжают лежать в репозитории.
так, дивиться, кілька вводних.
1) у нас є мільони громадян які голосували за шарія і інше дно на виборах. Сьогодні їх практично не знайти.
2) ви тільки що визнали що ваші дістрибутіви на базі лінукса для массмаркета — донноє дніще. Можете не писати більше нічого, я розумію що ви можете попадати у типаж людей з п1, і вам дуже важко визнати свою неправоту на публіці через психологічні деформації.
Бо для того аби вліпити мас-маркет лінух дистр на ще свіжий ноут з проциком 8го покоління — потрібно качати out of support версію дистра.
Я просто не можу зрозуміти, знаючи про таку дегенеративну особливість мас-маркет дистрів лінуха, навіщо пропагандувати це?
А ще, пропоную вам уявити що б ви писали про вінду (це теж відноситься до п1 — бо у нас ура-патріоти кудись зникли на переломі 19-20го року, а деякі з них, навіть по 300к почали отримувати) як би для того аби встати на процик 8го покоління потрібно було б качати тільки він7.
Час іде, зомбі-пропагандісти не міняються.
PS чесно кажу, я намагався поставити убунту як основну систему для розробки, чат гпт не рекомендує калі для цього. А все інше на тестове залізо не встає. Чи встане на 12700h — якщо воно не працює на старому, стабільному залізі? — хз, у мене просто нема бажання (я не настільки у дитячому віці, що б оце гратись у кастомізації вже, бажаю вам подорослішати, дореч) витрачати на сміття час.
PS PS у мене чудово працює бубунта у якості білдагентів на пулі у ажурі, сам налаштовував все :) трохи довше, ніж вінда і геморніше, але запрацювало :) Так шо пропоную притримати у собі «да ти ружокоп»
Біда, ну раз chatgpt не рекомендує, то все.
Цікаво, чому chatgpt забув про Debian, на якому що те калі, що убунту й базується.
btw, зараз десь з приблизно такого нетбука (з intel 8145U та uhd620 графіка) і пишу цей комент, був там спершу win11 — який зніс та поставив debian13+gnomeDE, нормально робить включно з тачскрін. Хоча була думка поставити cachyos чи свіжу ubuntu (не пробував на такому залізі) тільки заради того щоб потім отримати софт зібраний під x84-64-v[23] — але то не особливо і потрібно за овероптимізацією під проц гнатися, та мені дебіан зручний, реліз якого покищо достатньо свіжий, — тому на ньому і зупинився.
Тобто почати відмовлятися встановлювати без TPM 2.0? :)
1) штучне обмеження, яке обходиться вентоєм або консольною командою.
2) корпоративні ноути вже давно з тпм2, ще коли мамкіни іксперди про нього і не чули.
УПС
Звісно. Але до чого тут корпоративні ноути? Специфікація TPM 2.0 війшла лище у квітні 2014, тому я більш ніж певний, що є моделі восьмирічної давнини без його підтримки.
Ну так обійдіть штучне обмеження на встановлення linux на старе залізо встановленням іншого дистрибутиву.
В кого що болить... :)
Якось занадто наївно. Коли вийшла Vista кидалися переходити на дистрибутиви Linux, коли вийшла Windows 8 було те ж саме, коли вийшла 11... Коли Яблуко перейшло на інтеловські ЦП окремі ентузіасти ставили Хакінтош. Гірше повинно стати просто капітально.
Коли мова йде про мільйоні і мільярди користувачів, будь-яка зміна впливає, бо завжди є користувачі, які перебувають у хиткому стані вибору. Кожний провал вартував долі ринку Windows. Інертність змін розтягує цей процес на роки чи десятиліття, але подивіться на долю FireFox або Internet Explorer. Навіть домінантна позиція на ринку не допоможе, якщо помилки призвели до втрати репутації.
Так, наприклад, Vista частково відповідальна за збільшення ролей ChromeOS в нижньому сегменті, macOS в верхньому сегменті і часткову втрату довіри в корпоративному секторі.
Vista не була гіршою. Це була просто бета-версія Windows 7, яка стала абсолютним хітом, і яку можна використовувати навіть зараз (бо є підтримка в деяких каналах, що закінчується лише у 2026 році). Windows 8 була невдала версія, скоріше експериментом. Але Win 10 повернула позиції, і досі їх тримає. А щодо Хакінтош, то було і зворотнє — встановлювали вінду на геплівське залізо. Бо воно само по собі непогане.
Vista була гіршою в порівнянні з Windows XP. Все виглядало так ніби вони налажали і випустили щось з новою назвою аби не було асоціацій з недоробленою Vista. Краще б вони не випускали Windows 7 а таки доробили Vista хай би навіть для цього довелося випустити 10 сервіспаків бо в Windows 7 GUI став повільнішим (мабуть через переписування на .NET), нормальну панель задач замінили на вкрадений в Apple dock, хоч і не сильно та все ж перероибили оформлення в дещо гірший бік і в цілому Windows 7 якась ніби трохи повільніша.
Vista сприймалась гіршою, а не була гіршою. Бо якби вона справді була гіршою, Windows 7 не мала б ніяких шансів. Бо майже 90% (моя суб’єктивна оцінка, слід сприймати в сенсі «майже все») нового в ядрі та API було зроблено саме в Vista. Ну а оцінювати візуальну частину категоріями гірше/ліпше то взагалі не має сенсу. Особливо якщо врахувати засоби персоналізації, які можуть як повернути інтерфейс в стилі XP, так і увімкнути новий з ефектами Aero, якщо це подобається.
Так віста не була поганою системою, вона просто вийшла досить рано, віста мала запит на кор 2 дуо, а вийшла в світ віндовс хп сп2 на пентіумах. А коли світ вже массово перейшов на багатоядерні проци, вийшла уже віндовс 7 і віста просто стала непотрібна. І ніхто не кидався переходити на лінукс, залишались на XP до кінця, ну і багато не втратили, адже підтримку дропнули аж в 2014 перед виходом десятки.
Шо було з 11? Віндовс 11 найкраща вінда евер, вони перелопатили систему, дещо попереписували, вона стала надзвичайно швидкою у порівнянні з десяткою після третього редстоуна, і тим паче більш старих версій. Всі нахрюки на 11 вінду були від гордих власників помийних відер з 1155 сокетом. 1 в 1 як ситуація з десяткою, і тими самими власниками 775 сокета.
1155 сокет був ще до 1150 сокет я щойно перевірив на 1150 в мене ще досі ганяють 2 блоки 4160 та 4170 ще на вінді 8 треба до речі вінді 10 туди переставить просто щоб було
вінда 11 туди на сокет 1150 просто не ставиться
... щоправда я не перевіряв то вона пише що звиняйне ніт то я і повірив а чого ж не повірить то ж було трохи давно
і та сама історія з 775 сокет
в мене так само ще досі є система на 775 просто вже ні куди там стоїть хп яка пережила декілька переходів через залізо і ще варкрафт 3 чи якось так я іноді дістаю хоча може вже складно бо я не точно пам’ятаю чи є там ще hdmi бо там мабуть лише dvi
а це було так давно що вже геть давно мабуть ще до революції при царі ))
... тож кажучи це маю що то є якісь дуже дивні користувачі які досі мають 775 сокет і які якімось чудом намагаються його всунути на вінду 10
... а чого тоді власне 10 а не той самий 8?
особисто не знаю таких і не зустрічав ніде зі свого інфо простору також що вказує слід що я все правильно роблю живу простим щире життя ))
Мухи не способны делать рациональный выбор. Человек — способен. И то что C++ сейчас это фундаментальная основа всего ПО, как раз и есть проявление этой рациональности.
І JS теж? Ви переоцінюєте людей. Тут як еволюція, хто перший захопив нішу. C++ був перший.
А что JS? Для своего основного назначения (веб-фронтенд) это вполне адекватный выбор. При всех своих недостатках, достоинства перевешивают — абсолютно аналогично C++. Но поскольку каждый уже промышленный стандарт в своей нише, это уже само по себе достоинство — т.к. технологии проверены временем, есть масса наработок, литературы и прочего. И кстати, быть первым не значит быть успешным. Xerox придумал UI, Apple его вывела в массы, но первой она не стала. Потому что продукт не соответствовал ожиданиям. А вот IBM PC соответствовал, потому и стал доминирующей архитектурой на десятилетия.
А що тут обговорювати, якщо вибору немає? Це як хвалити єдиний ресторан у селі за смачну їжу. Звісно, для веб-фронтенду JS адекватний, бо альтернатив просто не існує. Elm спробував щось змінити, але екосистема JS уже була настільки величезною, що новачки просто не мали шансів.
Далі, якщо є недоліки, то вже можна їх виправити і буде краще.
А от це «перевірені часом» мене завжди забавляє. Часто це просто означає «застрягли в минулому і тепер нічого не можемо змінити». PHP теж 25+ років «перевірений». Це просто не дає можливості іншим захопити нішу, то вимагає значних вкладень.
Альтернативи і раніше існували, і зараз є. Наприклад був Silverlight, чудова технологія, в якої все було прекрасно. Окрім хіба що SEO, але мабуть з часом вирішилось би. Зараз є Flutter, у якого щоправда, так само складнощі з SEO. Але там де воно не потрібно, наприклад в якоїсь корпоративної CRM, то можна чудово все робити на Flutter, і забути про жахливий JS (хоча воно і транслюється в той JS і відповідно працює на JS движку). А все тому, що хтось вирішив що плагіни до браузера це погано...
Саме так — перевірений, зі зрозумілою поведінкою та великим досвідом застосування. Промисловий стандарт. Я ніколи не розумів, навіщо щось змінювати, заради того щоб змінювати. Хіба що знов взяти гроші за те саме. Але це огидно, і егоїстично. Ось як є одна компанія, яка весь час щось змінює, під соусом «прогресу» та «інновацій», але щороку дорожче і дорожче. Підказати назву?
А памʼятаю... Казала мені іди нахрен зі своєю FreeBSD. Технологія померла, бо вже був JS який працює крізь, а портувати .NET на кожну мобілку не вистачило ресурсу. Що ще раз доводить тезу про зайнятість ніші, та як важко витісняти.
Я це саме кажу, ніша зайнята. Коли зʼявляється нова ніша, відкривається вікно можливостей. Краще ворог гарного. Але це не означає що не можна було краще. І часто, коли зʼявляється нова ніша, то інші інструменти починають свій шлях, і вже створюють конкуренцію
Був ще Adobe Flash, також технологія web-frontend. Набагато більш успішна, і якщо вірити чуткам, досі популярна в Китаї. Але її не вивчав, то ж як там з погляду розробника, х.з. Але Silverlight мені подобався (а Windows Phone 7 на ньому взагалі був цукеркою).
Ну як зайнята, давно є і Python/Django, є Ruby on Rails — теж привабливі альтернативи, мають свої переваги. Але мають і недоліки, бо складно знайти хостінг — шареного майже не існує, треба брати VPS. А це значно дорожче. І ще Golang, так само.
Така доля у маргіналів. А ще Opera зазвичай помітно краще працювала в Windows а ще Flash, не знаю що там в FreeBSD та в Linux воно робили через пень—колоду. Особисто я відмовився від Linux бо зроблено воно не зовсім для домашніх комплюктерів та й монополія Windows не сприяє.
Вже був Flash. Silverlight — це як Flash від Microsoft. Якщо постаратися, то й зараз можна знайти сайти з Flash а от щодо Silverlight, то якщо такі ще є, їх прям дуже мало.
І що, в гулі реально ще цпп десь використовуть ?
Зверніться до публічно доступної інформації — medium.com/...oogle-and-why-b798c509652. Так, це одна з основних мов програмування.
Старенька стаття, але ок.
The most important and used languages are the so-called Big Four: Python, C++, Java and Golang.
Ооо, 3 з 4 МП які я найбільш знаю та використовую.
Перефразовуючи
а шо реально сьогодні ще джава десь (крім legacy) використовують?))
Цікаво, я з цих 4 МП саме джаву не знаю і ніколи не писав на ній.
Але нічого особистого, просто так «карти склались».
я бы не был так категоричен, есть компании где с++ это язык первого выбора для всего — что вебстраницы что компиляторы сначала пишут не нем.
Есть компании, где все пишут на JS, даже embedded.
Но мы ж понимаем, что вкусовщина, а не объективная реальность.
Вакансії С++, які мені пропонували рекрутери за останній місяць (при тому, що я роботу зараз не шукаю):
— Писати Автокад
— Писати Блумберг термінал
— Автомотів
— Писати Вайбер
— Писати якусь кастомну RTOS для якогось дивного заліза
— Писати плагіни до відеоредактора
— Писати торгівлю опціонами
— Писати гру
Лише дві вакансії з восьми стосувалися графіки та відео.
Ну і вцілому про популярність мови та затребуваність людей — вісім запрошень на співбесіду за місяць для людини, яка не шукає роботу.
— Автокад
— Автомотив — скорее всего очередные мультимедиа в тачку
— Вайбер = видео и звуковой поток.
— Видеоредактор.
— Игра.
С финансовым софтом я работал, они любят С++, но пишут в С-стиле. Был бы какой-нибудь GLib более хайповым- писали бы на нем.
Остаётся RTOS, кто же лекарь извращенцам.
Или желанием писать RTOS на С++.
Я например дропаю все С++ предложения, несмотря на ситуацию на рынке. Графики не знаю, а писать на С++, то что можно сделать на Go — не хочу.
Все, що можна зробити на Go, треба, звичайно, робити на Go. Але часто у людей вже є мільйон рядків коду на С++ і наступний мільйон рядків буде написаний теж на ньому.
Зная С++ переключиться на Go — как стакан воды выпить. Но люди продолжают писать CRUDы на С++, компилировать по часу, а потом искать текущую память.
Комбайном не косят газоны.
даже не рядом сори
стояв
Конечно, лучше вообще забить на память и потом винить GC в том, что он ее плохо освобождает))
Ну вообще-то совсем не так просто переключиться — знаю по опыту. Местами не просто функции другие, а идоматика совсем другого типа.
И без реального наследования местами ой тоска.
Утечка памяти — полбеды. Битая, когда побитие взрывается через час — вот это реально горе.
Тут действительно писать на языках с MMM это надо отдельно учиться.
Go C++!
І все одно краще переписати, якщо в задачі нема такого, що суворо б вимагало саме C++.
Два останніх моїх проекти з категорії «embedded на потужній залізяці з Linux» були як раз такими, що якщо замінити там C і C++ на Go, то з ходу кількість багів скоротилася б на порядок.
Ось приклад багу: він просто чудовий:
Компонент A отримує запит по внутрішній мережі (загорнутий в Thrift) видати, не видаю з-під NDA, кількість... ну, наприклад, встановлених посудомийок і їх номери в локальному індексі.
Функція, що виконує це в A, отримує масив розміром 8 (їх більше не може бути) і повертає int8_t, який ⩾0 якщо успіх, і −1 якщо помилка.
Функція, що її викликає з колбеку мережі, читає результат в uint8_t, отримує 255 замість −1. Компілятор навіть ворнінга про проблемність конверсії не дає. Вона заповнює свій масив із 8 значень прийнятими 255 значеннями, дивом при цьому не крешачись, і передає відповід в мережу.
Компонент B приймає відповідь, заганяє 255 байт даних з мережі в масив на 8 елементів і крешиться.
Я не згадував ще, що використовувати звужені типи на зразок int8_t за межами пакованих структур це безглуздий злочин сам по собі — цьому тих індусів (справжніх!), що писали цей код, не навчити. Але на Go хоча б відловити помилку можна було швидко і без того, щоб крешнулось не там, де помилка, а в сусідньому процесі.
Або там же на пару місяців раніше виходив циркуляр «не можна робити просто цикл по ітератору, якщо всередині є erase, треба оновлювати ітератор на самому erase». Найсмішніше, що те, на чому був другий приклад, взагалі робилось як the_map.clear(), без явних циклів, але щоб пропхнути це в реліз потребувався окремий тікет з циклом тестування.
«І так у них все» ©.
Зараз щоб писати на C і тим більше на C++ треба вимагати окремої ліцензії типу «робітники мають вміти, і доводити це, писати код не прутнем, а головою».
а сам мікро процесор видає? бо прийде Христос і судити буде і мікро процесор теж буде на Суд Божий!
загалом то є на всіх працює без винятку зазирни у розподіл популяції за дефініцією там лише до 15% усієї популяції людей реально можуть вміти і доводити це писати не прутнем а базова популяція 70% то є самий максимум не пошкодити прутень собі та не пошкодити прутень машині
... для прикладу виявляється що у той макдональз влаштуватися маючи айкю 83 уже складно а маючи 70 уже рахуй не можливо тож селяві просто бізнес і робітників з окремої ліцензії прінцев мало і на всєх іх нє хватаєт
І тому добрі люди створили www.boost.org/...ion/doc/numeric_cast.html
«Добрі люди» зробили десятки таких ліб. У мене є власна така з одного з проєктів.
Проблема в тому, що під них треба явно писати. Причому в крайному випадку весь код має бути написаний під них, а це читати буде вкрай важко.
Тому правильний варіант — коли компілятор робить все це сам за замовчуванням. І тільки там, де програміст бере на себе відповідальність, він позначає це в коді дозволом не генерувати виняток на кожному некоректному результаті.
І ще:
1. Показаний numeric_cast уміє тільки перевіряти границі, але йому не можна явно і надійно сказати «а тут, навпаки, перетвори з усіченням (насиченням)».
2. На останок: в прикладі, що я навів, був C, а не C++. Тому ваша пропозиція про Boost.NumericCast в принципі недоречна.
В цьому, я думаю, і проблема. Поки пишеш власні велосипеди і не використовуєш С++, то воно так і буде — в кожному рядку треба бороти всі відомі і невідомі людству проблеми власними руками. То весело, поки молодий, але потрім набридає. Рано чи пізно розробка приходить до вибору якогось гарного фреймворку і довірі йому. Буст, Qt, можливо щось корпоративне, в геймдеві он купа гарних фреймворків, в мультимедіа, в фінансах, тощо. Береш і пишеш. Всі кути вже обклеєні м’яким поролоном, зручно.
Ще раз мій головний тезіс: стандартна мова _не дає_ потрібного, і саме тому робляться власні доповнення.
Прошу не йти далі в дискусії, поки ви не зрозумієте цей тезіс. Або якщо його спростуєте (не вірю! бо інакше б стандарт не розширювали, саме в цьому місці).
Сподіваюсь на відповідь за суттю, а не міркування навкруги.
Так, не дає.
найчастіше — не доводиться, бо воно вже існує у вигляді гарної протестованої бібліотеки чи фреймворку. Он в мові С++ досі немає network чи графіки, але це ж не значить, що робота над проєктом, що їх потребує, почнеться з того, що Ви почнете це писати з нуля від рівня взаємодї з залізом. Ні, Ви візьмете потрібну лібу — та й буде.
Пропонувати і отримати офер дві різні різниці.
Спробуйте дійти до кінця процес найму.
Доходження (чи не доходження) до кінця дасть оцінку мені. А я ж кажу про оцінку ринку, потребу в людях і типах проєктів.
приблизно вимоги такі:9-5 але понаднормово (відпочинок після перемоги, мабуть звільнять)
— програмувати RTOS, bare metal, Linux (ядро і юзерспейс)
— знати С і С++ останніх стандартів
— вміти CI/CD та AWS/Azure/GCP
— вміти low latency video
— паяти BGA і тп.
— їздити в поле та на полігон
— знати Compass/AutoCAD/Altium, вмітималювати схеми та розводити PCB 8 слоїв з глихими отворами та з шинами 1GHz+
— підбирати BOM
— користвуватися осцилографами та різними іншими спектографами з логаналізаторами
— знати аналовову техніку, ЦОС, RF, MatCad/Matlab/Simulink, знати АІ та Python/Torch
— ходити в офіс з
— проходити поліграфа (секюрність понад усе ж)
— мати оновлені документи для оформлення згідно КЗпП
— бути згодним на оплата вище ринку (40К ..50К грн. до податків, залежно від досвіду)
Це шо таке? Я б канєшн прикинув, що це расєянский Аскон Компас-3Д, якщо дивитись по подальшому списку, але не схоже.
Думаю, він. До інших вимог, я так розумію, питань нема.
P.S.
Забув ще FPGA/Verilog
-
бувають, але мова про середньо-геометрично-квадратично-медіанно з.п. з локальними мінімумами в якому ДП 15..20 Кгрн при «кадровому голоді» тому «змушені брати початківців», але стьоб щодо вимог у темі «на захист С++»
А также десктопа, большинства тяжелых приложений и практически полностью embedded (если считать C туда же).
Як на мене, Сі та C++ дуже різні мови. Навіть Zig, Rust ближче до C++ ніж Сі. Причина контейнери.
З першою частиною згоден.
Но до чого тут контейнери і які контейнери ?
мабуть ті що в STL (строка, масив, вектор, сет, черга, мапа ...) не докер контейнери ж?
Точно.
В мене 15 років були stl, а тепер рік кубернетеси.
Назва таж а сенс різний.
Во всіх цих мовах є контейнери з коробки, з якими люди звикають працювати. Виникає контейнерно орієнтоване мислення: має бути власник елементів. І коли запитуєш як це зробити, то відповідь буде з серії треба тут масив/вектор, тут мапу, тут ще, .. Це складові блоки мислення.
Якщо брати Сі, то там контейнерів немає, там списки (двозвʼязні, циклічні). І це трохи інші складові блоки. На Rust реалізувати двозвʼязні циклічні списки це горе. На Zig це можливо, але багато писанини з @alignCast. Тому вони відсутні навіть в стандарній лібі, я ось пробував вийшло так: dlist.zig Тому C++, Zig це можливо, але видно що так не роблять.
Тому коли розробник змушений переходити на Сі, то часто можна бачити великий дискомфорт без контейнерів, щось на кшталт боксера, якому заборонили використовувати кулаки. Тому першим ділом вони починають писати власні контейнери на зразок цих мов.
емм... це пан сам придумав, про «контейнери», чи звідки це???
Це моє пояснення того факту, що двозвʼязні циклічні списки дуже широко використовуються у коді на Сі, і не використовуються ніяк в C++, Zig. Ну а в Rust, C#, Java їх без unsafe не реалізувати.
Ну а більшість розробників навіть взагалі не знають що таке двозвʼязні циклічні списки, починають таку пургу писати... Бо треба контейнер, який володіє елементами. Той факт, що любий елемент по суті сам є контейнер поза розумінням.
ну ви вводите якийсь термін «контейнери», в який засовуєте одні структури даних, а інші — ні. крім вас його ніхто не використовує.
p.s.
в Java LinkedList якраз двохзв’язний. Що саме там не реалізували що вам було б потрібно?
Це термінологія STL: Containers library
Нариклад, як елемент може видалити себе зі списку? А потім відмінити видалення?
void dlist_delete(struct dlist *item) { item->prev->next = item->next; item->next->prev = item->prev; } void dlist_undo_delete(struct dlist *item) { item->prev->next = item; item->next->prev = item; }якшо ми говоримо саме про елементи списку то вони себе ніяк видалити не можуть, вони нічого про список не знають.
якщо мова йде про «елемент aka ноду», то знову ж таки, якщо в ноді тільки пойнтери і дані, то видалити сама себе вона не може. що логічно, в ній ніякох додаткової логіки немає.
йдемо зверху, з боку списку: як видалити елемент — передати елемент в метод списку, там якимось чином ідентифікувати чи є такий елемент і де він лежить (в якій ноді), видалити його, видалити ноду, поправити пойнтери в списку.
ок, тепер те ж питання, але стосовно ноди — як видалити ноду зі списку? а звідки у вас взялась інфа про ноду, як вона витекла назовні? це внутрішня структура, нею не потрібно оперувати іззовні. відповідно і «відмінити видалення» в контексті ноди немає змісту, якщо список коректно реалізований і інфу про ноди назовні не віддає.
а в контексті елементу як такого — робите обгортку над стандартним списком, імплементуєте там якесь undo/redo. це ж не задача списку пам’ятати які елементи в ньому колись лежали.
Не розумію логіки, на Сі це звичайнісінька практика, подивіться Linux Kernel. Те, що неможливо в Java, я постійно роблю на Сі.
Ще раз, список це просто необовʼязковий елемент списку, бо кожен елемент і є список. Якщо нам треба список, ми виділяємо елемент та робимо його списком, але це необовʼязково, якщо не треба, то ми можемо обʼєднати будь які два елементи у список без списку, а при ініціалізації кожен елемент буде списком з одного елементу самого себе. Що тут незрозумілого?
Вони можуть бути з самого початку, як частина задачі в багатовимірному списковому просторі, самоорганізовані в мережі списків, де кожна нода манипулює собою. Попасти в ноду ми можемо з одного списка, а видалити її захочемо з іншого. Після цього ми можемо перейти в іншу ноду, а як воне поверне керування, то відновитися точнісінько там де ми видалялися щоб інші ноди нічого не помітили. Типовий бектрейсінг.
Навіщо мені зайвий головний біль, коли я можу просто використати справжні двозвʼязні циклічні списки, в яких з коробки є усе що треба.
це аргументація типу «от бачиш, сусіди теж так роблять». хотів написати, що це порушення принципу інкасуляції, але що таке «інкапсуляція» для сішника — дивний незрозумілий концепт. ))
Оце все і незрозуміло, що ви намагаєтесь сказати.
Ок, крок за кроком, маючи на у вазі саме елемент, а не ноду;
До чого це твердження? У нас є список. Це структура, яка може тримати в собі елементи. Кожен з цих елементів може бути списком, а може і не бути. Умовно, не говорячи про примітивні типи, у нас там як елементи пойнтери лежать, які вказують на структури в памяті.
Що значить «якщо нам треба список» — «якщо нам потрібно додати список в список» ? Для чого ви сюди залізли, йшла мова про елементарну операцію додавання елемента в список, що це за елемент, не важливо.
який елемент, список пустий, ми додаємо в нього елемент, тут нічого «виділяти». список непустий — ми _замінюємо_ один елемент іншим. ми не «робимо елемент списком». якщо мова не йде про екзотику де ви, не змінюючи пойнтер, перезаписали вміст пам’яті що за ним лежить.
це взагалі «за гранню добра і зла» — мені абсолютно незрозуміло що ви намагаєтесь описати.
ок, знову про ноди (НЕ елементи)
О-о, «панєслась», пішли якісь задачі/конструкти, де не наступити на граблі буде за щастя.
«щоб інші ноди нічого не помітили» — і як саме це можливо: от була у нас друга нода в списку, у неї був пойнтер на першу, перша «самовидалилась» — куди вказує пойнтер другої, вона ж тепер перша? ви ж його проапдейтили (сподіваюсь), тобто змінили другу ноду.
В Java так, але це дуже велике обмеження. Список це структура, яка містить в собі посилання, а не елементи.
От ілюстрація для вирішення exact cover (Судоку, ...)
Знаходимо рядок з мінімальною кількістю варіантів, список додаємо до розвʼязку та видаляємо конфлікти (стовбчик). Після цього рекурсивно знаходимо інший рядок, ... після того як повернулися з рекурсії, відтворюємо те що видалили, та переходимо до наступного.
На ту, що була перед першою. Класика же
якщо first->next це друга, ти ми оновлюємо її посилання prev. У мене враження, що ви зовсім не розумієте про що йде мова. Щоб зробуміти двозвʼязні циклічні списки треба повністю відкинути Java досвід, бо він не відповідає дійсності.Є static є handle. В принципі в Python її теж особливо немає, тому принцип не має бути догмою.
Це звичайно классно.
Але кто тут буде перевіряти, що користувач, між викликами
Нічого не зробив з контейнером, наприклад не видалив
item->next ?
Логіка бектрейсінгу дає гарантію. От у нас є перебір: взяли елемент, зробили пошук, повернули його на місце, взяли наступний. Що буде, якщо ми його не повернули на місце? Ну баг буде.
Так він буде видалений неодноразово зазвичай. Просто він має відтворитися. Це питання із серії, що буде, якщо користувач зробив lock на забув про unlock.
на сі так само є масиви як шматки шматків пам’яті які ідуть підряд як то аж геть класіка кільцевий буфер з цього і починається
ЗЫ: я вже бачив людей (на співбесідах правда но є підозра що не тільки просто вони скриваються) які не могли пояснити що там за стек як то воно узагалі що таке «виділити на стеку» типу «сі++» но як чиста абстракція верхнього рівня плюс цікавенно дивна не можливість робити сміливі утотожнення «спостерігаючи краплю води робити припущення за можливість існування океанів» або ж до сішечки люди знають за малок який виділяє пам’ять люди знають за нью який виділяє пам’ять ок а от нью то що там відбувається у середині ... «ну виділяє пам’ять...» ... і ну? «ну не знаю» (сірьозно штолє)
так недо люди вони такі )) втім звісно може вони навчаться але з досвіду вже навчався я так не думаю
Є масиви, є кільцевий буфер. Але от вже realloc вважається поганою практикою, бо вказівники на елементи інвалідуються. Багато ліб живуть без нього. На відміну віж std::vector, де push_back одна з самих частих операцій, інвалідація ітераторів при модифікації контейнера...
Там вже років 10 як emplacemet_back використрвують.
какие такие контейнеры? )
обичні морські у нас такі по 2 в ряд один на оден возять по залізній дорозі
якісь одні якихось обічних дідотуристів возять, треба транслятор з туристичного додавати
Звісно що різні, бо перший процедурний, а другий ООП. Просто засоби C++ можна використовувати в будь-якому обсязі, не змінюючі підходу до проєктування. Наприклад можна мати API в стилі libcurl, але застосовувати об’єкти RAII для зручності. Або віртуальні функції, як це робиться в COM (Component Object Model). Можна відключити Exceptions, але залишити RTTI. Можна не використовувати STL та замінити її власним аналогом. Тобто C++ не примушує вас до якоїсь конкретної моделі. І це також фактор успіху.
Це теоретично, а на практиці C++ нагадує героїн: спочатку прикольно, бо дійсно уникаєш боілерплейту. Потім не знаєш як злізти.
Якщо брати ООП, то і на Сі можна бачити інтерфейси, наслідування, ... (GTK, WinAPI, msquic, ...) Фактично об’єктну модель через структури та функці, як я писав, про бойлерплейт. RAII до ООП відношення не має, зручно, але легко захопитися та розролювати виключення в деструкторі. Винятки так, але теж переускладнено та створює багато простору заплутатися. RTTI в принципі якщо треба, то часто своє пишуть.
Головний фактор успіху? Думаю що сумісніть з Сі (купа готових ліб), ООП хайп та можливість написати wnd.move(10, 20) замість windows_move(wnd, 10, 20). Для мене золотий стандарт ООП це Delphi, там дійсно все продумано. А С++? Ідеальна комбінація: готові C бібліотеки + модний ООП + синтаксичний цукор. Технічно нічого революційного, але маркетингово в яблучко.
Не розумію про що ви. Я перший код на C++ написав ще в1999-му, і це був open source, коли ще навіть SVN не існувало. Патчі відправляли по Fido. І якось за цей час не виникло бажання «злазити». Навпаки, завдяки Qt, я вважаю нічого кращого за С++ зараз не існує.
Так, але це не є безпечним з погляду перевірки типів. Статичний аналіз не допоможе, лише дисципліна застосування. То й же Objective C був набагато краще з цього погляду. Шкода до речі, що він не отримав популярності окрім як на Apple.
Ну як не має, якщо це є базові механізми інкапсуляції. Об’єкт володіє ресурсами, об’єкт їх звільняє. В С таке не зробиш.
Щоб не захоплюватись, треба книжки читати. Кожен інструмент потребує навчання, бо можна й молотком по пальцях влупити.
І чудово виходить, ось як в Qt (там ще й інтроспекція є). Але одне іншого не виключає.
Технічно це і було революційно — мова, що початково була лише низького рівня, отримала засоби створення високорівневих абстракцій, які дозволили тримати складність проєктів під контролем. Не втрачаючи ефективності. Страуструп писав про це ще в перших своїх статтях про C++.
таксамо як стверджувати що
завдяки GTK, я вважаю нічого кращого за С зараз не існує
Можливо. Але для C це здебільшого милиці, застосування мови в спосіб, до якого вона не призначена. Бо це натягування ООП на процедурну парадигму. В той час як саме для цього призначений C++. Навпаки, Qt це саме доповнення С++ засобами, яких в ньому бракує (signal/slots що є втіленням Observer-паттерна майже на рівні мови, а також метадані/інтроспекція про що я вже згадував). Загалом Qt це повноцінний фреймворк на кшталт .NET, а не лише якійсь графічний тулкіт.
Якщо дивитися по результатам: обидва мейнстрім DE — Gnome та KDE приблизно однакові з рівня популярності у користувачів. Так і GTK чи Qt поміж девелоперів.
p.s. дотнет поза межами зацікавленості бо відсутній
Qt це ж не тільки KDE, це дуже популярний фреймворк для будь-якої платформи. На Windows багато чого зроблено на Qt — від Telegram з Viber-ом до як не дивно, офіційного клієнту OneDrive від Microsoft. Переносність коду майже абсолютна, особливо якщо UI робити на QML — десь на 95% все буде працювати просто як є (звісно, якщо немає коду, що явного залежить від платформи).
А ще можна згадати Automotive- та IoT-галузь, де там буде той GTK?
Qt як це буст, тільки інший, але вважати що С++ найкращий через нього, ну звиняйте
завтра придумають який модний рустреакт і зрада, розлучення і дівоче прізвище?
«Короля делает свита». Qt додає C++ саме тієї привабливості, якої йому не вистачає, порівняно з C# / .NET. При цьому зберігаючи всі його сильні сторони, які нікуди не зникають.
яка там ліцензія в Qt?
LGPL, а що?
та нічо, мутна і обрізана
Оцінювати вірогідності у найближчому майбутньому завжди можна:
— завтра полетять на Марс
— завтра напишуть Раст DE
— завтра перепишуть растом браузер
Що саме раніше відбудеться?
RS (Rust Script), а вже є
servo.org —> in progress github.com/versotile-org/verso
www.rust.de
це дві різні зовсім неоднакові вірогідності:
одна що з’явиться rustscript, інша що він стане достатньо популярним і на ньому напишуть крупні проекти
По прикладам браузери і DE:
Можна додати що не кажучи навіть про in-progress, багато release версій часто так і залишаються на рівні вузького кола ентузіастів. Тобто вірогідність широкого розповсюдження у майбутньому — відповідна може бути.
p.s. якщо відносно DE мало що чути покищо, то для мейнстрім браузерів оминути приклад Firefox буде важко
Чому?
Я писав раніше, але Borland C++ 3.1 навряд чи можна вважати повноцінним C++.
Для мене золотий стандарт ООП це Delphi, там зроблено було набагато краще з точки зору дизайну мови.
__attribute__ cleanup робить С ООП? Взагалі не бачу звʼязку.
Ой, вірити маркетологу... Так, харизматичний дядько, але що по факту?
Ada була з усих боків краще, ІМХО
Цікаво, що якщо взяти унікальні фішки С++, то їх щось не дуже запозичували інші мови. Економія на ініціалізації полів класу (zero overhead). Жах. RAII, інші мови переробили більш людяно. Множинне наслідування... Ніт. Неявні перетворення типів... Ніт. Екземпляри класів на стеку. Теж. Автоматичне інстаціювання шаблонів? Привіт повідомлення про помилки. Одночасно вказівники та посилання?
Усі інше, синтаксіс obj.method() та VMT це Simula, виключення це Ada. Так, можливість передавати свої поля ніби-то унікально для С++ та перейшло в інші мови. В Ada там можна тільки назва класу та повідомлення, свої поля ніяк. Шаблони теж Ada.
Тому скоріше C++ став посібником як не треба робити мову програмування: люди подивилися на досвід використання... Та зробили по іншому.
Тому що в C++ це зветься reinterpret_cast і не вважається безпечним. Це по суті, пряма вказівка компілятору «мені пофіг що ти там думаєш щодо цього типу, роби як я сказав». Навіть попереджень не буде.
В мене був gcc 2.8 здається, і це було під OS/2. Трохи допілював редактор GoldED, коли автор припинив розробку/продаж та подарував його в Open Source. Але основні риси C++ на той час вже були (OOP, та здається exceptions). Перший стандарт тільки що вийшов. Те саме перше видання Страуструпа досі займає почесне місце в мене на полиці. Жовте вже від часу)
Можливо, з Delphi не мав справи.
Це нестандартне розширення конкретної реалізації. І ні, не робить, бо це треба вказувати явно при кожному оголошенні об’єкта. Тобто треба про це пам’ятати — те саме, що вручну робити виклик free() по завершенню. Те що C++ робить автоматично, бо має концепцію об’єкта, а C не має. Але згоден, трохи нагадує RAII.
Він вчений, який маркетолог? Він розробив C++ для власних потреб, в той час коли працював в AT&T. Інші досліджувачи це оцінили та підтримали. З таким саме успіхом і Торвальдса можна назвати маркетологом. Вивчайте історію.
Ada занадто складна, і саме це її і вбило. До того ж, мала проблеми з продуктивністю кода, тобто програвала вже по двох важливих параметрах.
Це є принциповою рисою C++. Дорікати на це, все одне що дорікати тигру що він хижак.
Запозичували, але не всі і не одразу. Множинне наслідування інтерфейсів багато де є. Неявне перетворення типів теж, наприклад в C# (implicit cast operator). Так само екземпляри класів на стеку (C#). І вказівники в C# є. Ще скажи, що асемблерні вставки ніде не можна робити, і я скажу, що тому C++ і існує, що лише в ньому і можна))
І де вони всі? ))))
Це називається С-style cast. В Сі це теж не дозволено робити без каста. Каст це небезпека. Яка відміна?
Ну... а памʼятаю зелене видення 1991 року. Так, спочатку це було надихаючи, критика прийшла пізніше.
Це деталі реалізації, ну викликай автоматично деструктор... Суть одна й та сама. Знову це особливість С++, а не ООП.
Ну... останній стандарт Ada це 2022, вона досі жива. Але вона програла не С++, вона програла Сі (Turbo C 1.5 мій перший досвід). А С++ обирався через сумісність з Сі.
Коли є ООП, то ми не рахуємо такти.
Не зустрічав, ОК. Хоча я більше за строгу типізацію.
Ой, там по іншому зроблено. В Сі ти можеш обирати для будь якого класу. В С# виключно boxed типи, читай структури та скалярні типи. Звичайний клас з віртуальними функціями на стек не покладеш.
Це unsafe, і ніби-то обмежене використання.
Ой, в C++ там жахливий синтаксис. От Delphi, ностальгія, скільки таких вставок я робив:
Поступово витісняють С++, доля нових проєктів на ньому падає. Особливо я для своїх пет-проєктів даунгрейдився на Сі.
Бо в C++ є також static_cast, const_cast та dynamic_cast, що роблять більш безпечні перетворення, а reinterpret_cast без зайвої потреби це є поганий стиль. До того ж для похідних типів cast взагалі не потрібен, а в C навпаки, потрібен в будь-якому разі.
Це саме ООП, бо є частиною концепта інкапсуляції. Бо якщо у об’єкта є стан, мають бути засоби його ініціалізації та очищення. Інакше це не об’єкт, а проста структура (композиція). То ж деструктор і є таким засобом. Він навіть в C# є, finalizer зветься.
Чому це? OOП це спосіб керування складністю, подрібнення великого на окремі частини, с визначеною поведінкою. З можливістю повторного використання коду та втілення інших SOLID приципів. Продуктивність завжди йде наступною вимогою.
Це для того, щоб C# був практичний, щоб API-функції (__stdcall) можна було використовувати напряму, без бріджів/враперів.
Від компілятора залежить, ось в MSVC наприклад:
int my_var = 5; __asm { mov eax, my_var add eax, 10 mov my_var, eax }Воно само це робить, якщо escape analysis підказує, що можна.
Якщо мова про синтаксис GCC, то він, може, естетично і «не того», але він чітко описує входи, виходи, побочні ефекти, при бажанні параметризується («%4 — довільний регистр»), і тому ефективний, на відміну від того, що у Borland і MS, які для захисту від непередбачуваних проблем зберігають навколо такої вставки все, що можуть. Тому в GCC як раз все правильно. А MS в 64 бітах взагалі скасували такі вставки, бо не впорались з проблемою визначення точного контексту.
А що позначення там це окрема надто лаконічна мова — ну, на жаль.
... І гемору також, нажаль.
Ніякої аргументації, лише підміна понять. Щодо складності взагалі жодних коментарів, хоча це один з найважливіших моментів. C++ справді дуже переускладнений. Далі, наявність проблем з корупцією пам’яті в C++ «спростовується» тим, що в інших мовах буває неоптимальне споживання пам’яті. Це два абсолютно різні типи проблем, як на мене.
Де підміна понять? Немає ніякої підміни.
Настільки що однокашники в технікумі писали простенькі двохвимірні ігри і клієнти до баз данних. Як погано що тоді не було нікого хто б пояснив їм що їхній куций розум не в змозі осягнути такий складний C++.
Є проста як двері мова програмування Сі. На С++ можна писати як на Сі. А можна з boost, asyncio, з використанням усього що там є.
Коли ти пишеш сам, ти не використовуєш того, чого не розумієш. В продакшені всі інакше.
Є проста (насправді не така й проста) як двері мова програмування JavaScript і CSS... далі мені було лінь передруковувати. Висновок: JavaScript справді дуже переускладнений сам по собі а якщо додати ще й ту ж верстку бо JavaScript існує не в вакуумі, і далі по тексту.
PS
Писати замість C Сі це якась інтелектуальна особливість чи що?
Сі Цзіньпін
Сі проста як лопата. JS скоріше як екскаватор, можливо й просто користуватися, але коли треба заглянути під капот... то щоб розібратися, треба спочатку вивчити Сі, зрозуміти памʼять, вказівники.
Згоден, але для Frontend реальної альтернативи йому немає. Тут як і в житті, хто перший встав, того й тапки.
Ні, це скоріше звичка, на початку 90х часто можна було зустріти «Мова програмування Сі», от тільки коли мова заходила про конкретне середовищу розробки писали «Опис стандартних функцій Turbo C 2.0». Плюс інколи хочеться підкреслити відміну Сі від C++ хоча б написанням.
у продовження аналогій з «лопатами»)
C++ лопата де з протилежної сторони держака встановлені вилки і граблі (періодично перевертаючи держак догори ногами можна використовувати у доволі широкому діапазоні робіт по господарству)
Rust лопата пофарбована нестандартна, але з safe рукавичками (по інструкції використовувати тільки з ними, але навіть виробники то часто і самі ігнорують), користувачі пробують приладнати її для любого типу сільгосп.робіт
дивлячись що розуміти під тим
ніши між ними в багатьох випадках пересікаються, але в багатьох і ні (reliable аргументація була нп.. від Лінуса)
Ну... хоча би просто не використовувати класи, віртуальні функції, ... Знаю проєкти, де заборонена STL, smart pointers, ... Просто С++ він як героїн, спочатку прикольно, давай це спробую, потім це... А потім не знаєш як злізти.
якби все зводилося тільки до того, плюсами вже давно би розробку робили там де зараз сі
проблема меморі ліків в с++ фактично неактуальна років 15. зараз це вкрай рідкісні проблеми спричинені як правило кривою архітектурою або дуже старим слабо протестованим кодом. в той час як надмірне споживання пам’яті всякими java/javascript є дуже розповсюдженою проблемою яка зустрічається практично в 100% випадках.
Блажен є хто вірує, тепло йому на світі ©
Один такий «дуже старий» код в проекті, де я робив, почався з нуля приблизно в 2012, інший в 2018. І ніхто тих супернових захищених полісі, які ви маєте на увазі, не застосовував. Це реальність комерційного галерного світу. Вважаємо, з 4 великих C/C++ проектів, де я робив «на галерах», така херня була в 3. Ітого 75%.
Там хоча б ліки і шкоду даних легко відловити. Для цього і завищення витрат в2-3 рази, як на зараз, можна вважати нормальним.
Головна проблема C++, щоправда не зараз — а колись була, бо зараз ренесанс разом із AI — був низкий маркет фіт.90-ті та нульві ціла купа різноманітних навчальних программ різної якості, від С++ за 21 день до топових курсів провідних університетів типу Берклі, на плодили на ринку червоний океан конкуренції. На сьогоднішній момент те саме — це Frontend, з абсолютно аналогічних причин.
В
Так усе влаштовано, що взагалі усе в індустрії, оскільки ми живемо в капіталістичній системі, регулюється ринком і через зміну попиту на ньому, маркетинговими інструментами та інноваціями будь які навички можуть як повністю перестати мати попит на ринку, так і тимчасово, так і відновитись. Ілан Маск написав Zip2, тобто електронний довідник телефонів жовті сторінки для інтернету в 1996 році саме на С++. Тобто справа зовсім не в мові програмування, вона в бізнесі. Інтернет був новітньою інноваційною технологією в якій ряд бізнесменів, що зараз є найбагатшими людьми планети зробили бізнес, при цьому не маючи жодних гарантій успіху.
Таким чином той же Rust мало чого гарантує і якості тахнологічної конкурентної переваги, якщо немає проекту і роботодавця чи інвестора який обрав цю технологію. Щоправда як ми знаємо, станом на зараз це Пентагон, а там річний бюджет 810 мільярдів долларів цього року і 900 наступного.
Ну а скажвмо в GameDev — С++ як був так і є провідною мовою.