AxisPod

Разработка игр бывает разная, игры бывают разные. Да и куски программного кода бывают разные. С нуля делать игры сейчас совсем не просто, так что этот вариант отсеять нужно как можно быстрее. Если делать на готовом движке, то уже всё зависит от движка, от его скриптовой модели, от необходимости дописывать его и т.д.

Берите спеки процессоров, там всё расписано. Все алгоритмы в обязательном порядке будут расписаны. Как вариант можно поискать быстрые реализации для Z80, он не умеет умножать и делить из коробки, во времена разработки для Z80 находил быстрые реализации.

Всё зависит от направления, если надо GUI, то лучше браться за Qt, дело пойдет без проблем, документация довольно хороша. Библиотека stl аналогично, а местами даже и лучше реализована, зависит лишь от её версии. Опять же есть boost. Если особо не дёргать систему, то проблем с переходом нет. А именно системные вещи проще искать в интернет, чем ковырять книги.

Для разработки сетевых приложений я бы посоветовал использовать boost::asio. Возможностей много, да и очень хорошая кроссплатформенность.

Ну и еще одной проблемой при переходе с VS на Unix будет сборка проекта, да, конечно есть среды разработки, которые сокроют этот момент, но так как разнообразие сред разработки велико, то этот вариант не подходит. Тут уже надо разбираться с make, cmake, да и другими системами сборки проектов.

Опять же проблемой станет то, что необходимо тестировать на всех целевых платформах, системные вызовы могут очень сильно отличаться. И вот тут и возникает проблема, что в большинстве своём книги тут ничем не помогут. Поиск + официальная документация.

Ну стоит понять как ведется работа с памятью. К примеру сборщик мусор .NET при сборке проводит дефрагментацию для малых объектов и через некоторое время данные по известному адресу пропадут. Другие сборщики мусора могут поступать аналогично. Может быть защита и т.д. Так что проблема тут скорее всего в приложении из которого вы и читаете данные.

Может взять учебник по C/С++ и не задавать глупых вопросов?

А почему не должен? Конструируется новый объект, а старый при этом будет удалён, но move конструктор как бы намекает, что не нужно использовать глубокое копирование в конструкторе. Нужно просто скопировать указатели и всё, при этом да, в исходном объекте указатели нужно обнулить. А в вашем случае от move конструктора толку вообще нет и не будет. Ибо нет никакого смысла в move конструкторе для примитивных типов, которые при этом создаются на стеке.

Берите libicu если вам нужны богатые возможности по работе с UTF.

Как и в других? > и < ?

1. Уже есть готовые решения, которые дают доступ через CGI, FastCGI, Socket и т.д., в чем отличия от существующих?
3. Какой тогда смысл вообще в C++? Сетевая работа в скриптовых языках и так уже написана на C++.
2. Если делать всё же на контроллеры C++, то в рантайме роутинг не имеет смысла.
4. Ну обычно все заводят подобное под свою инфраструктуру или не заводят, это последнее о чём стоит думать на данном этапе
5. Будете реализовывать свой полноценный шаблонизатор? Почему бы не взять готовое решение и допилить? Либо подразумевается использование python?

Слишком странное решение, либо уж всё делать на C++11, при этом действительно появилось множество механизмов, которые позволят упростить реализацию и использование. Либо вообще этого не делать. Сколько уже начинали проектов и все к сожалению ныне мертвы.

После того, как увидел, что Resharper C++ разожрал визуалку до 2х гигов, больше просто не смог, я его очень быстро снёс. Ну и да, визуалка просто не работала, она выдавала в это время всё в виде слайдшоу. Вбил текст, отобразилось через секунд 10.

Ага, большинство игр разрабатываются на учебном языке. Он же учебный, все видимо учились на нём, знают, другие не знают, вот и делают игры на чём знают.

Во-первых, чем не устраивает -> и почему у вас <- ?
Во-вторых, ссылка это не объект и при удалении ссылки объект будет живым, ссылка ведет себя как указатель.
В-третьих вы не создаете никакого объекта, а создаете ссылку, которая дальше компилятора никуда не уйдет и в конечном коде её не будет.
В-четвертых вам стоит познакомиться с механизмами работы с памятью в C и реально узнать, что такое ссылка и указатель.

Судя по формулировке сделали не вы, а вам сделали это на форумах.

Ну могу сказать только одно. Какие будут востребованы языки ответить сложно. А вот гадалки востребованы уже сейчас, так что могу предложить стать гадалкой.

Код чума. Надо всё же наверное читать литературу по работе с памятью для начала.

Вы тоже хотите сделать мега быстрой копировщик файлов? Как-то видел подобный вопрос на форуме. А если же серьезно и вы действительно хотите сделать работу с кучей файлов, то в зависимости от системы надо юзать асинхронный ввод-вывод, реализации зависят от системы, но можно использовать и универсальные функции типа libevent, boost::asio и т.д. И это будет лучшим решением, на каждый HDD запускать свой обработчик событий и вперед. Ну а большое кол-во потоков тут ничем не поможет, IOPS от этого выше не станет, увеличивайте IOPS, кэшируйте в памяти.

Всё зависит от ситуации, но если уж и делать гуишное приложение под win, то C# в большинстве случаев лучшее решение. А новичку вот так браться за C++ не стоит. C++ очень недружелюбен, хотя при этом и эффективен. По сути в этом и нужно убедить работодателя. У новичка будут большие проблемы при работе с памятью, будут утечки, будут обращения как удалённой памяти, будет проблема с временными объектами. Нативное GUI решение под win на С++ это MFC, я бы не посоветовал это трогать даже под дулом пистолета. С Qt конечно всё куда как проще, но это не избавит от проблем при работе с памятью. В итоге на разработку потратите время, а вот на допиливание, правку багов и т.д. потратите в несколько раз больше. С тем же .NET будет всё проще, если работодателя не устраивает производительность (на деле основной тормоз это JIT компилятор), так для этого есть родная утилита ngen, избавит от тормозов связанных с JIT компилятором.

Нет конечно, если необходимы, можете посмотреть на boost::lockfree или Intel TBB. Ну либо сами закрывайте.

На деле всё очень сложно и часто без 2х реализаций сказать очень сложно. На жесткой гонке lock-free могут очень плохо себя показать, т.к. будут постоянно болтаться во внутренних циклах, пытаться записать данные, при этом другие потоки будут влезать и мешаться. Опять же всё зависит от того как использовать. Например вряд ли будет выгодным вытаскивание из одной очереди 5-10 элементов на одно действие, т.к. будет в лучшем случае 10-20 lock-free операций со сбросом кэша, тут выгоднее даже будет spinlock mutex.

Ну двумерных массивов в C++ нет, есть только jagged массивы.
Поэтому ручками создаете обычный массив, пихаете в unique_ptr и указываете свой делитер.