res2001

Вам нужна книга, которую прочитаешь и сразу в "сеньоры" можно идти?
Боюсь такой нет. Только практика и еще раз практика.

Из продвинутых книг могу посоветовать:
1. Эффективный и современный С++. 42 рекомендации по использованию C11 и C14
в ней очень толково описаны нововведения в стандартах уже не совсем свежих, но эти нововведения чуть ли не самое главное изменение в языке до сих пор.
2. Параллельное программирование на С++ в действии. Практика разработки многопоточных программ
3. Оптимизация программ на C++. Проверенные методы повышения производительности.

В WinAPI даже в user space нет аналога std::string.
Что уж говорить о kernel space - там вообще все очень скудно.
Перепишите функцию на использование Си строк и буфера фиксированного размера. Кроме того, загонять в драйвер функционал std::string видится избыточным - слишком много в stringе используется динамической памяти, что снижает производительность кода, обычно в драйверах это противопоказано.

Если писать код, соответствующий стандарту языка, то корректно, конечно, указывать return.
В большинстве современных ОС любой запущенный процесс возвращает код возврата. Это требование ОС. Кодом возврата процесса обычно является значение возвращаемое из main.

Но, если код возврата не нужен, то можно не указывать return и объявлять void main(). Тогда считается, что код возврата из программы нулевой. Обычно это нормально отрабатывает. Но это не стандартная фича и ваша программа может не собраться на какой-то платформе и/или компиляторе.

Не заню, что там в CArchive и вообще MFC давно не брал в руки, но предполагаю, что нужно использовать такой вариант:

Fruit fruit;
ar >> fruit;

Для сериализации/десериализации вызывается метод Serialize вашего же класса, т.е. сам CArchive не создает сериализуемые классы. Следовательно вы должны передать операции >> ссылку на существующий класс, а не указатель. ar просто перезапишет содержимое класса, точнее не ar перезапишет, а ваш же метод Serialize.

Например:
atoi(ex.c_str())+atoi(ex.c_str())
это выражение 2 раза преобразует в число одну и ту же строку, а затем складывает эти 2 одинаковых числа.
Так что "не дублирует", а выполняет то что написано у вас в коде.

Вам нужно сначала разделить строку на "токены", т.е. на операнды и операции.
Если вы на этом этапе расчитываете обрабатывать только простейшие действия, то вводите строку и разбиваете ее на 3 токена. Затем операнды преобразуете в числа и после этого уже выполняете действие.

Не нужно зацикливаться на С++, т.к. все сетевое API операционной системы на Си. Изучайте просто сетевое программирование. Когда разберетесь, то просто возьмете сетевую библиотеку для плюсов и будете ее использовать. Как правило, подобные библиотеки просто оборачивают Си интерфейс ОС в классы.
Так же рекомендую книгу Стивенса. Но она старая (последнее издание 2007 года) и в продаже вы ее сейчас не найдете. Электронная версия есть. Не смотря на возраст книга вполне актуальна. Подобные основополагающие технологии изменяются довольно не торопливо.

qtcreator - хорош
Eclipse - довольно тяжел для понимания, тормозит на больших файлах или когда открыто много файлов (Java дает о себе знать). Но если планируешь программировать для embeded, то полезно научиться с ним работать, т.к. многие IDE предоставляемые производителями железа основаны на Eclipse.
С clion не приходилось сталкиваться.

Если нет необходимости в подобной локальной переменной, то не нужно "кэшировать".
На уровне ассемблера все обращения к памяти происходят через регистры, так что в любом случае адрес из указателя будет записан в регистр и этот регистр будет индексироваться.

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

Часто удобно использовать локальную переменную, только потому, что указатель (ссылка) лежит где-то в третьей вложенности внутри класса - проще его сразу достать и дальше использовать короткую запись. Но это удобно программисту, а компилятору пофиг.

В любом случае, сделаете вы в коде кэширование или нет, если компилятор посчитает нужным кэшировать переменную в регистре он ее будет держать в регистре и кэширование никак не повлияет на производительность.

С restrict можно поиграть, но в чистом С++ его нет, на сколько я знаю, но можно включить расширения в gcc/clang и, возможно его можно будет использовть в плюсовом коде. Но применяйте его лучше сразу к локальному bufferу, а не к this.

Напоследок: подобного типа код выполняется достаточно быстро, оптимизировать тут особо нечего, есть смысл заморачиваться только если это очень-очень горячий код в вашем приложении. Ну и в плане оптимизации для подобных случаев лучше поискать варианты, как обойтись без копирования данных, чем надеятся, что restrict вам сильно поможет.

QtCreator + Qt