Но вот с добавлением библиотек из системы тоже возникла проблема. Как я понимаю cpack может добавлять в пакет только из поддиректорий?
Если очень нужно притащить с собой зависимости, то можно воспользоваться вот этим: https://cmake.org/cmake/help/v3.11/module/GetPrere...
Весь полученный выхлоп пихаем через install в пакет. Желательно при этом через свой пакет не устанавливать библиотеки по штатным путям, лучше положить их в собственной директории и запускать свое приложение с указанием LD_LIBRARY_PATH
Оригинальное начало разработки ОС - создание полосочки :) Для начала определитесь с терминологией. Если хотите создать оформление для MS Windows, это одно (ну для чего то же упомянута оная ОС в тегах ). Если хотите создать именно свою ОС - это другое, и начинать нужно с понимания принципов работы ОС. Будете понимать принципы работы - можете начинать определяться с тем, что вы хотите от будущей ОС. Когда оформите ТЗ - вопросов, с чего начать, быть не должно.
Pavel K: если фактически a является экземпляром класса A, т.е. наследуется в том числе и от IB, то ошибки не будет. Если не является - то вызов метода класса IB некорректен в любом случае.
Антон Жилин: да, что-то запало у меня про конструктор, прошу прощения :) Здесь никак не обойти это ограничение. Другое дело, что, если используется ссылка, копирование объекта практически никогда и не нужно( обычно это объект, реализующий некую логику ) . Но это уже другой вопрос.
"Ссылки нельзя использовать ввиду технических ограничений" - можно, но их необходимо инициализировать в конструкторе.
"std::shared_ptr не находит применение в стандартных ситуациях" - незаменим в многопоточной среде (в паре с std::weak_ptr ), где к одному объекту необходим доступ из нескольких потоков( например, общее хранилище, с которым взаимодействуют потоки-обработчики )
Максим Тимофеев: Найти ноутбук с топовой версией процессора, достаточным объемом оперативки, и при это не в игровом исполнении? Единственный вариант - ноутбук с профессиональной видеокартой, но он ни разу не дешевле.
Все возможности покрыть невозможно :) Всегда есть такой тонкий момент - на проце Х проект собирается за 20 минут, при этом жрет N оперативки, а на проце Y проект собирается уже за 10 минут, и при этом жрет N * 2 оперативки
maaGames: " Если вызов конструктора копирования неприемлем, то вектор вообще лучше не использовать" А чем emplace и std::move не угодили? Вектор - отличный универсальный контейнер. Для использования любого другого нужно найти веские аргументы.
maagames.ru: "если при создании/копировании объекта может случиться исключение" - в этом случае полезно, да. Но исключение при создании, а уж тем более при копировании объекта - редкость ( единственное, что приходит в голову, если не рассматривать нехватку памяти - необходимость использования ограниченного ресурса. И то нужно подумать, не будет ли в этом случае уместней использовать фабрику ).
Если очень нужно притащить с собой зависимости, то можно воспользоваться вот этим: https://cmake.org/cmake/help/v3.11/module/GetPrere...
Весь полученный выхлоп пихаем через install в пакет. Желательно при этом через свой пакет не устанавливать библиотеки по штатным путям, лучше положить их в собственной директории и запускать свое приложение с указанием LD_LIBRARY_PATH