Есть ещё такое мнение, что C++ широкого назначения, и есть много разных подходов и стандартов качества кода.
Есть HIC, есть Google C++ style guide, есть https://github.com/isocpp/CppCoreGuidelines , и каких-то универсальных профессиональных техник нет.
Отчасти это связано с идеологией "не плачу за то, что не использую". Я бы и сам не прочь погрузится в обобщенное программирование, но это удел лишь тех, кто пишет библиотеки общего назначения, кандидата в boost, например. В других случаях оно не надобно практически, лично мне, конечно же. Язык действительно обширный.
Отчасти связано со сложностью поддержки и спецификой применения языка. Например, в разработке игр новые стандарты языка и STL часто не используются, а если используются, то с опаской и полным пониманием что и зачем. К тому же, дополнительное ограничение на использование даёт конкретный компилятор.
Демонстрационные проекты обычно пишутся так, чтобы показать реализацию простой задачи, часто упор идёт демонстрацию классов и методов в действии.
В реальном проекте вам могут быть не нужны все абстракции в таком же виде, как это может быть в демо. Обычно все гораздо сложнее, пускай взаимосвязи классов в демо не вводят вас в заблуждение.
arzamas-nick, да, примерно так. Приведенный вами пример скорее всего является лишь одним из шагов реализации изменения части проекта, который вы делаете в рамках воплощения какой-то фичи. Такой коммит никому пользы не несёт, поэтому его лучше объединить с другими. У вас в локальном, атомарность изменений может быть мельче, чем это нужно на практике.
arzamas-nick, у себя, локально, вы можете делать насколько угодно частые коммиты, оставляя "зачем вы сделали изменения в коде", допустим, в названии ветки. Ваш локальный репозиторий не обязан быть точной копией origin. Когда вы закончите работу над частью реализации фичи, вы можете соединить коммиты (которые имеют смысл лишь для вас как точки сохранения вашего процесса изменения кода) в один, в котором явно опишите изменение (которое имеет смысл для другого разработчика) и его запушите, снабдив описанием, про которое вам ответили выше.
Вова, верно, но с другой стороны имя флага лишь вершина айсберга, то как флаг называется контролирует проверка/действие, которое он всего лишь представляет как итог.
Если важнее контроль над отключитением кода по признаку авторства, а модификации и этого кода вообще не в приоритете, то ваша позиция более адекватна, чем позиция ваших коллег.
Stelette, кажется у вас не хватает абстракции, которая бы представляла в целом обобщенно любую игру из вашего сборника. Советую вам все же использовать названия игр, при необходимости хоть и интерфейсы с дженериками по названию игры, до тех пор, пока вам не станет видна конечная архитектура - так переписывать код позже будет намного проще.
jcmvbkbc, подтвержднегие только косвенное, т.к. ооп не расчитано на скорость исполнения, а рассчитано на скорость разработки, это тезис является просто своеобразной мнемоникой.
Вы правы, это UI, здесь мои высказывания не уместны.
hell0_w0rId, чем меньше ООП и больше структурщины, тем быстрее. Флаги всегда хочется быстро читать, тут можно даже попробовать обернуть fl в #pragma_pack(1), но возможно придётся выровнять размер структуры под целевую платформу. В общем случае, копирование кода не есть плохо, если, как здесь , читаемость упрощается в разы.
devalone, получается намного комплекснее и сама разработка, и само приложение, и соответственно медленнее работа приложения, в случае если дергать C++ функции написанные под Андроид через плагин из C# скриптов в Unity, нежели использовать Android просто для загрузки движка и обрабатывать события напрямую. Если там игра типа головоломки и подчистую осонвана на физике и принято решение не идти по пути C++, за это придется расплачиваться скоростью работы и неэкономным расходом батареи. Поэтому на сегодняшний день мой выбор - движок на c++.
Даниил Демидко, емнип StandartInput/Output даёт вам поток вывода / ввода для запущенного процесса, там же System.Diagnistics.Process есть методы для нахождения процесса как по имени, так и по id.
Как конкретно целевое приложение должно получить текст? Через терминал как аргумент вызова? Где целевое приложение запущено? Windows? Оно уже запущено? Порт слушать ему можно/нельзя?
Учитывая достаточно абстрактную постановку вопроса/задачи, единственным верным ответом будет - вынести узкое место на c++ или go и оставить все как есть.
Есть HIC, есть Google C++ style guide, есть https://github.com/isocpp/CppCoreGuidelines , и каких-то универсальных профессиональных техник нет.
Отчасти это связано с идеологией "не плачу за то, что не использую". Я бы и сам не прочь погрузится в обобщенное программирование, но это удел лишь тех, кто пишет библиотеки общего назначения, кандидата в boost, например. В других случаях оно не надобно практически, лично мне, конечно же. Язык действительно обширный.
Отчасти связано со сложностью поддержки и спецификой применения языка. Например, в разработке игр новые стандарты языка и STL часто не используются, а если используются, то с опаской и полным пониманием что и зачем. К тому же, дополнительное ограничение на использование даёт конкретный компилятор.
Наверное, то что вам нужно, это идиомы языка C++ https://en.m.wikibooks.org/wiki/More_C%2B%2B_Idioms