А эта практика не прижилась ни в одной студии (из тех, где я был). Попытки были, и я сам такую простынку проходил, но эффективнее всего оказались просто задачи из беклога давай, которые на текущем спринте закрывать не очень хотят, потому что есть более приоритетные.
Одно время ~2016 было поветрие все делать через конфлюенс. Я застал момент, когда нужно было писать таски-опросники для новеньких и делать мини-проекты для онбординга, так что нет, не ведут. Да и недавний опыт с мобильной компанией, тоже показывает, что не ведут.
но смысл не в картинках же. Хабр, я надеюсь, все еще свободен для написания статей, и у вас всегда есть возможность сделать лучше и так как Вы считаете нужным.
можете поспрашивать @alyokhin или @OlegSivchenkoпро наличие черновиков и сколько раз они переписывались :) А про картинки я честно написал откуда они и каким инструментом были сделаны, вы видимо не добрались до конца статьи.
В пределе строку можно ужать до одного указателя и 8 байт, но это слишком мало и размер и capacity тогда приходится держать в куче, рядом с самими данными. Объект (строка) выходит крошечный, массивы таких строк плотно ложатся в кеш, но за каждое обращение к длине или ёмкости платим индирекцией и лишним походом в память. Чтобы её убрать, размер и capacity вытаскивают обратно в сам объект, рядом с указателем. Дальше работает правило (для строк) N байт SSO-буфер вмещает N−1 символ и отсюда два типовых расклада: либо { char* + uint32 size + uint32 cap } и 16 байт, 15 символов inline. Либо { size_t cap; size_t size; char* data; } и 24 байта, и при удачной упаковке 23 символа + терминатор.
23 символа звучит много, но на практике это покрывает где 40% строк, значит остальные 60% будут болтаться в памяти. А хочешь больше, ну скажем, 60% под ногами и нужен буфер символов эдак на 40, а это объект уже за 40 байт. И вот тут и приходит та самая расплата, чтто 40 байт против 8 или даже 24 уже жирный объект и две такие строки в одну кеш-линию (64 байта) уже не положить, и при проходе будет чтение из другой кешлинии.
Получается дилемма: либо мелкий объект и плотные массивы, но всего ~8 байт под SSO и индирекция на длинных строках, либо большой SSO-буфер и быстрый доступ к содержимому, но жирные строки, которые уже в кеш-линию не лезут. Я на строках объяснил, но для всего остального суть таже. Нужный размер нужно мерять для своего домена применения, про 40 символов строки я могу сказать об играх, потому там есть замеры.
а я не знаю, как она работает, но должно быть не сложно, подключаешься к процессу, бежишь по памяти, кастуешь набор байтиков в нужный тип и вуаля, вот тебе артманя.
Ну почему же не упомянутым, секций ровно 101-а. Разных базовых идей, понятий и механизмов, с которыми сталкивается с++ разработчик (да и не только с++) больше, но я постарался выбрать те, которые широко известны и применяются. Как сказали выше еще 101 это вводный курс, где в том числе дают и историю возникновения отдельных терминов и понятий.
Если я правильно помню порядок цен для 2023, то начиналось это все от 20к за одну игру и дальше зависело от ваших желаний. Они могли хоть отдельную команду вам дать для реализации хотелок
Да есть такая проблема, но это не беда именно ui а вообще любого middleware, которое нужно обновлять чаще одного раза в секунду.
у scaleform был механизм loadVariables который позволял прокидывать данные внутрь анимации, чем многие и пользовались размещая на простых лейаутах такие псевдовиджеты и работая с ними как со статической страницей, пересоздавая её а конце фрейма. Сами анимации уже загружены, и заново сделать разметку выходило дёшево.
Но яаще основной механизм взаимодействия был через ExternalInterface и GFx::Movie::Invoke или SetVariable со стороны C++, как вы описали, потому что возиться со своим парсером shtml было лень.
А эта практика не прижилась ни в одной студии (из тех, где я был). Попытки были, и я сам такую простынку проходил, но эффективнее всего оказались просто задачи из беклога давай, которые на текущем спринте закрывать не очень хотят, потому что есть более приоритетные.
Одно время ~2016 было поветрие все делать через конфлюенс. Я застал момент, когда нужно было писать таски-опросники для новеньких и делать мини-проекты для онбординга, так что нет, не ведут. Да и недавний опыт с мобильной компанией, тоже показывает, что не ведут.
но смысл не в картинках же. Хабр, я надеюсь, все еще свободен для написания статей, и у вас всегда есть возможность сделать лучше и так как Вы считаете нужным.
можете поспрашивать @alyokhin или @OlegSivchenkoпро наличие черновиков и сколько раз они переписывались :) А про картинки я честно написал откуда они и каким инструментом были сделаны, вы видимо не добрались до конца статьи.
Я пока не посмотрел лекции Константина Владимирова, тоже был уверен что знал С++, теперь не уверен :) https://www.youtube.com/watch?v=9N_wJ7oIHDk
Ну если просто списком, которые не вошли тогда так:
Скрытый текст
Hollywood Principle («don't call us, we'll call you») : инверсия управления вместо жёстких регламентов.
Customization Point Object (CPO) : расширяемость через точки настройки, а не единый «стандарт на всё».
Strong typedef / strong types : несовместимые типы не склеиваются.
Separate Compilation Model : TU + линковка как основа сборки.
Command : одна операция = один объект.
Design by Contract (Expects/Ensures) : явные пред-/постусловия.|
Dependency Inversion Principle (DIP) : верхние уровни не зависят от деталей.
Lazy Evaluation : вычисление только когда реально нужно.
Perfect Forwarding (std::forward) : дешёвая передача без копий.
Dependency Injection : зависимости передаются, а не берутся из глобала.
Monostate : «глобал», притворяющийся локальным объектом (редко, но осознанно).
Information Hiding (Parnas) : модуль знает только необходимое.
Forward Declaration : скрыть детали типа без #include.
Scoped Locking : захват/освобождение lock в паре enter/leave.
Monitor Object : данные + mutex как единый монитор.
Law of Demeter : не лезть в чужие internals через цепочки вызовов.
Unique Ownership : один владелец, явная передача.
Phantom Types : «метки» в типах, ловящие ошибки при компиляции.
Const-Correctness as API contract : const как часть контракта.
Immutable Value Objects : объект после создания не меняется.
constexpr functions / inline functions : замена макросам с типами.
Strong typedef : using Meters = strong_type<double, tag_meters>.
IILE (Immediately Invoked Lambda Expression) : локальная область + cleanup в деструкторе лямбды.
Uniform Initialization {} : нет «висячей» инициализации.
Guard Clauses / Early Return : плоская структура вместо вложенности.
Magic Statics (C++11) : thread-safe init function-local static.
Static Initialization Order Fiasco awareness : знание проблемы, даже если решаете иначе.
Include What You Use (IWYU) : включать только нужное.
Observer pointer (non-owning) : T* / std::reference_wrapper без владения.
Principle of Least Surprise для операторов : a + b не делает I/O.
Return-by-value + elision : канон для factory-функций.
Regular Type concept : тип ведёт себя «как int» для операций.
Extract to statements : вычислить аргументы в отдельные переменные до вызова.
Extract Class / Extract Interface : рефакторинг к мелким типам.
Delegation : объект делегирует, не наследует.
Composition over Inheritance : дополняй, не меняй.
Lollipop Interface : « lolli»-интерфейс, отделённый от реализации.
Pure Abstract Base Class (ABC) : классический термин до «Interface Class».
explicit conversion operators : только явные static_cast-подобные пути.
Tell, Don't Ask : поведение у объекта через getters.
Capability-based security / least privilege : минимальный API.
ADL (Argument-Dependent Lookup) : свободные функции в namespace типа.
Aligned allocation overloads : operator new(size_t, std::align_val_t).
Placement new family : in-buffer construction без heap.
Member initializer list discipline : порядок в списке ≠ порядок объявления → ошибка.
Delegating constructors : один ctor вызывает другой.
Basic/Strong exception guarantee : классификация гарантий.
Rule of Four : исторический предшественник Rule of Five.
noexcept swap guarantees : для vector, контейнеров, strong guarantee.
ADL-friendly API design : operator<<, swap, begin рядом с типом.
Namespace per library/component : границы модулей через namespace.
Qualified names in headers : std::vector, не vector.
DLL-safe allocator boundary : своя heap внутри .dll/.so.
Object Pool per module : память не пересекает границу.
ODR (One Definition Rule) : одно определение на программу.
Error codes at module boundary : HRESULT, error_code, C API.
Exception translation layer : catch internal → throw external.
POD / standard layout / trivially copyable : критерии для FFI.
C-compatible API surface (extern "C") : стабильная граница.
Static Polymorphism (templates) vs Dynamic Polymorphism (virtual) : два режима.
External Polymorphism : non-virtual полиморфизм через type erasure
Generic Programming (STL-style) : алгоритмы от итераторов, не от контейнеров.
Concepts-constrained templates : обобщение с ограничениями.
Fail-fast vs fail-safe : осознанный выбор.
Rollback / Transaction pattern : откат частичных изменений при ошибке.
Catch by const& : slicing + лишние копии.
Contiguous storage idiom : cache-friendly последовательный контейнер по умолчанию.
No raw owning pointers in containers : ownership policy.
Amortized growth strategy : понимание reallocation policy vector.
Range-based for / C++20 ranges : алгоритмы над диапазонами.
Half-open range [begin, end) : STL convention.
Iterator category requirements : complexity зависит от категории итератора.
Pure predicate functions : без скрытого state/side effects.
State-carrying lambdas / functors : захват контекста без глобала.
Regular types / Value semantics : копируемость и равенство по смыслу.
Domain-driven type naming : тип отражает домен, не layout.
Trivially copyable / standard layout checks : static_assert перед bitwise ops.
Variadic templates / fold expressions (C++17) : типизированные параметры.
Valid state invariant : объект всегда в допустимом состоянии после ctor.
No strcpy/sprintf : безопасные альтернативы (string, format).
Object Pool : переиспользование объектов вместо частых new/delete в hot path.
Arena / Linear Allocator : пакетное выделение памяти; освобождение всей области за O(1).
Observer / Publish-Subscribe : подписчики получают события без жёсткой связи с источником.
Null Object : объект-заглушка с no-op поведением вместо проверок на nullptr.
State Pattern : поведение через объект состояния, а не switch по enum.
Adapter Pattern : обёртка над чужим API под интерфейс.
Decorator Pattern : добавление поведения слоями без подклассов.
Factory Method : создание объектов через фабричный метод.
Abstract Factory : семейства связанных типов без знания конкретных классов.
Mediator Pattern : координация через посредника вместо N×N связей между объектами.
Chain of Responsibility : цепочка обработчиков, каждый решает брать задачу или передать дальше.
Double Buffering : два буфера для безопасного чтения/записи из разных потоков или кадров.
Struct of Arrays (SoA) : data-oriented layout поля сущностей разнесены по массивам, не AoS.
Amalgamated Header (stb-style) : один .h + #define IMPLEMENTATION в одном .cpp.
Overload Pattern : набор лямбд/функторов для std::visit и подобной диспетчеризации.
Deduction Guides (C++17) : явный вывод типа шаблона из аргументов конструктора.
std::declval : «фиктивная» lvalue-ссылка на тип без его конструирования
Type-safe Bitmask Enum : enum class + перегрузки |, &, ~ без неявного int.
Copy Elision / Guaranteed RVO (C++17) : возврат локального объекта без лишней копии по стандарту.
Reference Wrapper (std::reference_wrapper) : nullable-ссылка в контейнерах и колбэках, где T& нельзя.
Railway-Oriented Programming : цепочка операций, где ошибка ломает дальнейший путь (expected/optional + early return).
Извините за кучу синтаксических ошибок, сколько не вычитывал, а все равно остались.
Огромная благодарность @Mingunза правку текста.
В пределе строку можно ужать до одного указателя и 8 байт, но это слишком мало и размер и capacity тогда приходится держать в куче, рядом с самими данными. Объект (строка) выходит крошечный, массивы таких строк плотно ложатся в кеш, но за каждое обращение к длине или ёмкости платим индирекцией и лишним походом в память.
Чтобы её убрать, размер и capacity вытаскивают обратно в сам объект, рядом с указателем.
Дальше работает правило (для строк) N байт SSO-буфер вмещает N−1 символ и отсюда два типовых расклада: либо
{ char* + uint32 size + uint32 cap }и 16 байт, 15 символов inline.Либо
{ size_t cap; size_t size; char* data; }и 24 байта, и при удачной упаковке 23 символа + терминатор.23 символа звучит много, но на практике это покрывает где 40% строк, значит остальные 60% будут болтаться в памяти. А хочешь больше, ну скажем, 60% под ногами и нужен буфер символов эдак на 40, а это объект уже за 40 байт. И вот тут и приходит та самая расплата, чтто 40 байт против 8 или даже 24 уже жирный объект и две такие строки в одну кеш-линию (64 байта) уже не положить, и при проходе будет чтение из другой кешлинии.
Получается дилемма: либо мелкий объект и плотные массивы, но всего ~8 байт под SSO и индирекция на длинных строках, либо большой SSO-буфер и быстрый доступ к содержимому, но жирные строки, которые уже в кеш-линию не лезут.
Я на строках объяснил, но для всего остального суть таже. Нужный размер нужно мерять для своего домена применения, про 40 символов строки я могу сказать об играх, потому там есть замеры.
конечно, чето там только нет. и cli, и софтовые бряки, и триггеры на переменные.
а я не знаю, как она работает, но должно быть не сложно, подключаешься к процессу, бежишь по памяти, кастуешь набор байтиков в нужный тип и вуаля, вот тебе артманя.
Ага, как оказалось платить в С++ приходится за всё, даже за бесплатное и за Zero-cost, но язык даёт контроль над тем, кто платит, когда и чем.
Ну почему же не упомянутым, секций ровно 101-а. Разных базовых идей, понятий и механизмов, с которыми сталкивается с++ разработчик (да и не только с++) больше, но я постарался выбрать те, которые широко известны и применяются. Как сказали выше еще 101 это вводный курс, где в том числе дают и историю возникновения отдельных терминов и понятий.
Это вы устали читать :) шутка. А Мейерс с Александреску половину этого придумали
Ваш комментарий к предыдущей статье был более осмысленным. Этот я опять не понял
Есть такое, но это небольшая цена за гибкость и ловится тестами в 99% случаев
Программисты всегда будут крайними, потому что в идеях начальства сомневаться нельзя, а кривенькие ручки вот они, у всех на виду.
— Вас мучают эротические сны?
— Ну почему же мучают? (С)
Если я правильно помню порядок цен для 2023, то начиналось это все от 20к за одну игру и дальше зависело от ваших желаний. Они могли хоть отдельную команду вам дать для реализации хотелок
Да есть такая проблема, но это не беда именно ui а вообще любого middleware, которое нужно обновлять чаще одного раза в секунду.
у scaleform был механизм loadVariables который позволял прокидывать данные внутрь анимации, чем многие и пользовались размещая на простых лейаутах такие псевдовиджеты и работая с ними как со статической страницей, пересоздавая её а конце фрейма. Сами анимации уже загружены, и заново сделать разметку выходило дёшево.
Но яаще основной механизм взаимодействия был через ExternalInterface и GFx::Movie::Invoke или SetVariable со стороны C++, как вы описали, потому что возиться со своим парсером shtml было лень.
Под адалт понимается очень многое от того что вы назвали до симулятора свиданий и казино и слотов