Архітектори (справжні) теж, чай, не замальовками від руки свої проекти описують.
На щастя, я їх не бачив.
діаграми для тих, хто працює на рівні діаграм, а не коду
Якщо я дізнаюся, що є люди, які працюють виключно на рівні діаграм, напевне я буду думати де шукати нову роботу.
А от коли в переговорку зайде людина, що не була присутня на обговорення, то багато інформації з малюнку вона не отримає. А от з більш-менш стандартної умл — отримає.
Сумнівно, не кажучи про користь.
Коли я малюю власне бачення, то зазвичай я орієнтуюся на те, що читач буде його сприймати як малюнок, а не UML діаграму. Тобто стрілочка це просто стрілочка, а ось у UML пунктирна стрілочка означає одну, подвійна інше, ...
з умл теж не вимагають пояснення
Мені як раз важко... Коли бачиш UML, а на щастя, це не часто, ти думаєш: «А чи він не вмер? Чому б не намалювати для людей»... Суб’єктивно, треба більше пояснень, бо я відчуваю, що від мене очікують, що я маю розуміти певний код.
З іншого боку якщо не малюєш ті умл щодня, то вивчати його достатньо глибоко може виявитися зайвим.
Тут виникає питання, для кого тоді усі ці діаграми?
Ну... особисто мені незручно. Я майже не зтикаюся UML у своєму повсякденному житті, тому треба... щось гуглити, щось дивитися, не факт, що воно налізе, а ще й треба пояснити що це означає, та переконатися, то той, кому ти пояснюєш, також це розуміє...
Тут просто цікава цифра «40». Беремо 10 томів теоретичної фізики Ландау та Лівшіц, чотири плюс додаткові випуски Д. Кнута...
У мене все навпаки
1. Я дуже сильно відстаю від своїх планів, тому немає сильної потреби відстежувати. Був би час :-)
2. Ну... як раз коли я читаю з гаджетів, то відсоток розуміння досить невеличкий, як на мене. Дуже велика спокуса щось пропустити та піти далі, на щось не звернути увагу. Також дуже не вистачає зручного функціоналу робити помітки та повертатися до них через рік на іншому пристрої.
3. Ну... є книжки, які я дуже люблю читати, але більше ніж на 100% впевнений, що ніколи не дочитаю їх до кінця. Наприклад, Д. Кнут. Тому це виглядає досить дивно. Знову ж таки, якщо якийсь розділ тобі не цікавий, навіщо його опрацьовувати?
4. Я не розумію, навіщо мені художня література. Якийсь міфічний баланс... Так можна дійти, що дивитися не тільки фільми, а й порно для «балансу».
5. Ну... якщо ти читаєш книжку, від якої тебе легко відірвати, то це ознака того, що тобі вона не потрібна. Це більше прокачка ПВВ: я читаю 40 книг на рік.
6. Навіщо треба ознака від інших? Знову виглядає як прокачка ПВВ. Мені подобається — я читаю. Не подобається — не читаю. При чому тут інші?
7. Швидкість читання ніколи не була проблемої, я мене скоріше навпаки, бороться з тим, щоб не читати швидко. Тому якщо матеріал складний, або в електронному вигляді, то часто я навіть повільно переписую його у зошити, щоб не втрачати концентрацію. Чесно, проблема завжди у розумінні, не читанні. Можна прочитати 100 сторінок Ландау та Лівщіц за день? Думаю, не питання, але сенс?
8. Аудиокниги треш, що книгу слухав, що радіо.
9. Навіщо?
От лише з цитатою М. Твена я згоден. Але, в моєму розумінні, автор статті читати не вміє, бо робить усе неправильно. Можливо, якщо стоїть ціль нахапатися по верхам, щоб прокачати ПВВ та давити на інших це й спрацює. Але не мої цінності.
Цікаво, що я теж колись писав статтю у DOU на тему, як я читаю книжки, link, але отримав коменти, які робити не хотілося, також неприємно працювати у Google Doc, тому так й лишилося чернеткою.
Ну... то як дозволити `consteval` але заборонити наслідування та віртуальні функції?
Воно ніби-то зрозуміло, що оскільки Сі на дуже багато відсотків є частиною С++, то можна знайти у С++ такі фічі, які не завадили б... Але... як на мене проблема С++ більше у тому, що ця мова програмування нагадує мені чимось героїн: фіч багато, деякі виглядають прикольно, але коли починаєш захоплюватися, то з часом не знаєш, як з цього злізти :-)
Будь яка мова розвивається, з часом з’являються нові слова, які на початку здаються дивними, але потім до них звикаєш. Тому мені в принципі байдуже, сьогодні я цього слова не знаю, завтра буду використовувати сам.
перетворити гемблінг на спорт і створити бестселлер, який за кількістю геймерів стане абсолютним рекордсменом Світу.
Я вражений, як до цього ніхто не додумався раніше?
Гемблінг — жанр ігор, у якому результат повністю залежить від випадку, а не від навичок гравця.
Тоді виникає питання навіть до такої гри як Black Jack, а покер вже точно не належить до gambling. Але взагалі до геймблінгу відносять ігри, що містять три складові: ставки, ризики та виграш. Тоді покер можна віднести до геймблінгу, що не відміняє скіл.
Нормально, але у мене відчуття більше навпаки, власної переваги... Загальні запитання відповіді ОК, але якщо брати щось специфічне, то зазвичай може обманювати. По-друге, для роботи ChatGPT зазвичай треба контекст, який можна формувати власним плагіном, бо інакше йому важко здогадатися що від нього хочуть.
Взагалі по взагалям, плюс, як на мене не з того боку. Усі питання другорядні, деякі у моєму розумінні не мають сенс.
По-перше, треба викреслити ігри, де є вибір. Бо зазвичай треба, щоб кожен міг вибрати собі на смак. Тому Mass Effect... Хочеш є Талі. Хочеш — Міранда. Як на мене гомогенні стосунки це більше навіть задоволення таких гравців як я, коли я не проти побігати за дівчину, але романтити чоловіком... огидно. А тут Ліара!
Знову ж таки, є жанр гарему, де як раз за ціль звабили все що можливо. Це цікаво, тому це буде. А коли ти зваблюєш, то хочеш отримати у нагороду сексуальну сцену. Чому й ні? Знову ж таки це опція, не треба — будуй персонажа як хочеш.
Також художники малюють жіноче тіло, дизайнери роблять те ж саме. Одна з причин що їм це подобається. А значить такий контент буде.
А так нехай люди есперементують без жорстких рамок, а я буду обирати те, що мені подобається. Я взагалі чекаю на більш відвертіші сцени, ачівки не тільки переспати з усіма, а ще й зробити це в усіх місцях/позах. Поліаморія велкам! Чекаю на гарні переклади хентай-ігор та за мотивами. Усі ці «треба обмежити» це безглуздя.
До речі, чи є хоча б одна гра, це можна замутити утрьох?
Ok, Simula-67 like :-)
Взагалі, якщо брати більш зрозумілі описи, на кшталт
Intriduction to Simula, то там є Virtual, но немає нічого про route, wait, ... Тобто Wait використовується як звичайний метод.
Ну... мені приємніше юзати справжні сішні двозв’язні кільцеві списки, бо при видаленні елемент списку не має знати, з якого контейнеру він видається.
Ну... зазвичай brk рухає пам’ять лише уперед. Але і під Windows за рахунок фрагментації досить мало шансів, що певна сторінка буде звільнена. Тому шанси на segfault незначні.
Ну... ось простий приклад UB:
int * ptr = malloc(100); free(ptr); some_call(); *ptr = 0xFACE0000;
при якому у пам’ять запишеться випадкове значення. Тут як пощастить, може ця пам’ять не буде аллокована, тому нічого не зміниться. А можливо ми змінимо якесь бойове значення. Можливо пошкодимо сам алокатор. Цей код може працювати по різному навіть у двох послідовних запусках програми.
Ну... для мене дуже неприємне UB це інвалідація ітераторів при модифікації контейнера в STL. Інколи capacty контейнера достатньо, там програма поводить себе добре. А інколи трапляється realloc та ... Звісно, що намагаєшся такого уникати, але... життя бентежне...
99.99999% чисел що використовує программа ніколи не будуть вище за мільярд.
Ну... оцінка трохи завищена, у мене був випадок, коли я використовував uint256_t
саме через переповнення. Але так, ця проблема зазвичай перебільшена.
Як на мене, Rust обирають більше через concurency та ADT. Якщо у нас сума типів, то компілятор сам вкаже, які ситуації в нас необроблені. Якщо у нас ООП та сума реалізується через наслідування, то є проблема ієрархії, також дуже часто ти просто забуваєш подумати про якийсь можливий варіант.