Ну так за 12 лет с момента выпуска он обрёл собственный интеллект и уже скоро начнёт охоту на разработчиков. А вы что думаете, ведь именно поэтому нельзя так долго использовать старые версии ПО.
Мне тоже так кажется. Если в Valve ещё об этом не догадались — это серьёзное упущение с их стороны.
Поколение HL-геймеров будет ощущать внутреннюю неудовлетворённость без монтировки.
Казалось бы достаточно было бы сделать STL'ный buffer.reserve. Но при каждом увеличении массива происходит создание НОВОГО нативного массива, а потом ещё и создание поштучно конструктором копии/переноса в нем всех уже существующих элементов. То есть — если мы не хотим добавлять конструктор переноса в класс наших объектов — то работать будет очень медленно.
Можно было попробовать использовать std::deque. Ну и проблема скорее не в перемещении, а в том что все указатели на созданные объекты устаревают.
Хм, я никак не ввязываюсь в дела portage и с помощью etc-update мерджу обновления прямо в рабочее дерево. А потом делаю коммит, или несколько, или не делаю, если мне кажется, что даже потеря смердженной версии не будет сильно критична в ближайшем будущем.
Насколько я понимаю, это отличается от отдельной полноценной гитовой ветки только тем, что ветка нетронутых конфигов хранится в виде понятных для etc-update, а не git, файлов.
Консольный GUI? Тот самый, который Graphical? :)
Я бы назвал Tig интерактивным клиентом для Git, ну или альтернативным TUI (текстовым/консольным интерфейсом) для Git.
[/pedantic]
Один из многих случаев симбиоза дверного глазка и электроники.
Поколение HL-геймеров будет ощущать внутреннюю неудовлетворённость без монтировки.
Можно было попробовать использовать std::deque. Ну и проблема скорее не в перемещении, а в том что все указатели на созданные объекты устаревают.
Насколько я понимаю, это отличается от отдельной полноценной гитовой ветки только тем, что ветка нетронутых конфигов хранится в виде понятных для etc-update, а не git, файлов.