one_eight_seven

Думаю, тут лучшим будет - это перейти на g++ и отказаться от IDE для таких тестовых вещей. Основной проект можно вести и в IDE, и кнопочками тыкать, но для понимания того, как компилировать, линковать и т.п. лучший вариант - это командная строка. Буквально за вечер подобные вопросы как рукой снимет.

Вы правда этим руководствуетесь? Тогда выбор Windows вообще удивителен. FreeBSD, ну какой-нибудь из RedHat'овских линуксов, Arch. Но никак не Windows. Хотя, с другой стороны, ваш пост может быть простой рационализацией заблуждений, а на самом деле обозначенные проблемы вам до лампочки.

Гостевая ОС не знает, что она виртуальная. Поэтому если они могут работать с современными драйверами, то проблем не будет. Да то же самое. Они (эти видеокарты) всё-равно работают через PCI-E. Кроме того, что это за софт такой, которому нужны мощности современных видеокарт, с 2Д и 3Д ускорением, иначе всё будет тормозить, а писаны они только под WinXP? Как они вообще работали в те времена, когда были написаны?

Только nVidia об этом не говорите, а-то у них целый бизнес есть, связанный с виртуализацией видео. nVidia grid называется. Не могу сказать про все системы виртуализации, но KVM точно может "отдать" видеокарту гостевой ОС (только одной), и та ОС будет напрямую работать с железом. Без тормозов, со всем, что позволяет драйвер видеокарты. Когда выбирал себе систему виртуализации, то видел, что у vSphere тоже заявлено прямое подключение видеокарты (что не удивительно, vmware - среди лидеров на рынке виртуализации), и у HyperV, даже для virtualbox заявлено PCI-Passthrough, но решение редкое, не видел, чтобы им пользовались. Я понимаю, что вы не хотите по каким-то вашим причинам пользоваться виртуальными машинами, но подумайте над тем, чтобы прекратить упорствовать в том, о чём вы понятия не имеете.

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

Это не вопрос веры. А как вы подключите старенький программатор к ком-порту нового компьютера 2020 года выпуска? Через USB? Так не проблема, USB без вопросов пробрасывается в виртуальную машину. Если параноить, то можно весь USB контроллер пробросить в виртуалку. Только вот сама шина USB не real-time. Через PCI-E? тоже без проблем подключается к виртаульной машине. IOMMU уже давно поддерживается и Intel, и AMD. Думаю, что больше 10 лет.

Вы просто не умеете их готовить. Ради интереса играл в Ведьмака 3 на виртуальной машине, поднятой в Fedora 29. Производительность 95-98% от нативного запуска в Win10. В более современной ОС уже не пробовал этот трюк, но нет причин, чтобы было хуже. vfio, pci-passthrough, и пожалуйста, видеокарта напрямую подключена к виртуальной машине. https://www.linux-kvm.org/page/FAQ#Can_KVM_run_a_32-bit_guest_on_a_64-bit_host.3F_What_about_PAE.3F Даже не знаю, какие ещё свежие новости рассказать... Ельцин умер, ССCР распался. Это, как правило, делается, чтобы зарезервировать ядра только под нужды хоста. Вообще, никто не мешает включить все ядра в виртуалке, в том числе через CPU host-passthrough. Но, в общем и целом так, действительно, не делают.

Если все заголовочные файлы подключены, то настало время переменных, например, буква не из той раскладки, вы ведь на глаз не сможете различить 'e' и 'е', а они очень даже могут быть разными.

Ошибка-то с этим не связана.

Ошибка скорее всего не там, где вы смотрите. Есть ощущение, что или заголовочный файл не подключён, или есть ошибка где-то пораньше, а вы смотрите на последнюю. Если "рафинировать" ваш пример, то всё собирается: M_BLEServer.h: #include <cstddef> // size_t class M_BLEServer { private: size_t foo; public: size_t * get_foo() { return &foo; } }; SNTPTime.h: #include "M_BLEServer.h" class SNTPTime { private: M_BLEServer *_bleServer = nullptr; public: char const * get_timezone(void); }; SNTPTime.cpp #include "SNTPTime.h" char const * SNTPTime::get_timezone(void) { size_t * characteristic = _bleServer->get_foo(); return (char const* )(*characteristic); } Собирается без ошибок и предупреждений: $ g++ -c SNTPTime.cpp -o lib.o -Wall -Wextra -pedantic $ Если уверены, что всё подключаете, то действуйте стандартно - инжектируйте ошибку. Например, у вас файл SNTPTime.h может подключаться из другой директории и быть защищён инклюдгардом. Напишите некомпилируемую ересь в свой заголовочник и убедитесь, что компилятор ругаетеся на эту ересь.

1. Я цитировал не вас 2. К словам придираетесь вы. 3. Даже не подумаю читать все ваши посты, потому что мне хватило этого бреда, в котором прекрасно всё: и упоминание какого-то "разговора в общем", когда топикстартера спросили о конкретике, и то, что попытку вернуться к конкретике вы называете "придиркой к словам", и попытки указать мне что делать... вы кем себя возомнили? Боженькой пресвятым? Так нет, вы просто несмешной твинк какой-то, вам бы книжку по логике почитать, для средней школы.

Извините, а где вас так "научили", что вы думаете, что форсить - это читать?

UVM Primer. Vanessa's Guide. После этого уже будет не страшно просто писать, сверяясь с UVM User Guide.

Bingo! Ничего себе "на троечку". Я такое, как и вы, называю "не работает". Просто я не делаю тут различий между Элвисом и Миландром. Для меня это в обоих случаях "не работает", потому, сам я достаточно много сил прикладываю, чтобы отказаться от проектов с российской электронной базой (даже транзисторами или светодиодами).

Насчёт "всё нерабочее". Если это рассматривать как "не работает так, как написано в документации", - тут соглашусь. Так и говорили: "за что ни возмёшься, всё не работает" Если "невозможно запустить", то нет, это не так. Запускается, работает, некоторые вещи, конечно, работают странно, например, нельзя запускать какую-то периферию с DMA, потому что от этого зависнет ядро. Но такое и с Миландром было. Там чип просто не запускался, и через третьи руки (не от техподдержки) узнали, что какие-то пины на чипе нужно подтянуть к противоположным указанным в документации логическим уровням, и тогда как-то зашевелится.