Matwey
Предсказуемо, что он внизу, дальше то что?
Дальше просто всякие эвент-лупы бесконечные и ожидание. Тот кто надо долбит ioctl-ы KVM_RUN. Все заняты своими делами. Проблема в том, что в гостевом ядре модуль virtio_blk виснет на ожидании workqueue, и дальше срабатывают всякие softlockup детекторы. По физике оно работает там внутри. Выглядит так будто где-то продолбалось сообщение внутри virtio-кольца, либо "забыли" отправить ответ (что не отвечает на вопрос почему на другой физ-машине всё работает).
🦥Alex Fails
Alexander "SonnySlave"
https://github.com/pyk/cmake-tutorial
Pavel
О, больная тема
Anatoly
https://github.com/pyk/cmake-tutorial
ну так, как-то не модерново. обслуживание тестов я бы оформил иначе:
cmake_minimum_required(VERSION 3.10)
project(prj LANGUAGES CXX)
find_package(GTest REQUIRED)
....
// хоть и говорят, что это плохой стиль, но удобно
file(GLOB_RECURSE TESTS test/*.cpp)
set(TEST_PROJECT_NAME ${PROJECT_NAME}_test)
add_executable(${TEST_PROJECT_NAME} ${TESTS})
target_link_libraries(${TEST_PROJECT_NAME} GTest::Main GTest::GTest ...)
enable_testing()
add_test(${TEST_PROJECT_NAME}_runner ${TEST_PROJECT_NAME})
Stanislav
ну сделать cmake toolchain file и вперед
Pavel
Stanislav
https://github.com/swift-nav/libswiftnav/blob/master/cmake/Toolchain-gcc-arm-embedded.cmake
как то так примерно для arm-none-eabi
Pavel
Pavel
# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)
# which compilers to use for C and C++
SET(CMAKE_C_COMPILER i486-mingw32-gcc)
SET(CMAKE_CXX_COMPILER i486-mingw32-g++)
SET(CMAKE_RC_COMPILER i486-mingw32-windres)
# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /usr/i486-mingw32)
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Matwey
Ага, пасяп. Не совсем понял, что делать когда нужно одновременно собрать таргет под целевую платформу и под таргет вспомогательной утилиты под хостовую
Matwey
Ну вернее понял что как то нужны импорты
Stanislav
Pavel
И директории лучше под разные платформы разные юзай
Matwey
И мне два раза его запускать что-ли?
Stanislav
ну да
Matwey
Это какое-то гонево
Matwey
Linux и u-boot как то сами соображают
Matwey
Что и чем надо собрать
Matwey
По одной команде
Matwey
Хочу так же
Pavel
Хорошее желание
Matwey
Ну законное желание, на самом деле
Matwey
Например, mkimage - хостовая цель, а uboot.bin - кросс.
Constantine
хм... а кто-нибудь разбирался в Class template argument deduction (тот который since C++17)?
Alexander "SonnySlave"
Constantine
а что именно интересует?
ну грубо говоря
template <typename T>
void f(some_type<T> argument) { //будет ли здесь проведен deduction для T, если у some_type есть конструктор, допускающий implicit?
}
Constantine
Constantine
вообще, похоже, стоит подняться по XY.
Представим себе класс-обертку статического концепта, на примере std::function для operator(). Такие обертки реализуются грубо говоря через некоторый интерфейс FunctionEngineInterface и некоторый набор FunctionEngine, наследующих этот интерфейс и представляющих из себя контейнеры для оборачивания различных случаев входных параметров std::function.
Представим теперь некоторую шаблонную функцию. Она хочет получить std::function, но получать именно std::function как тип это потеря информации о типе, лишние динамические аллокации и так далее, деоптизация короче. Возникает острое желание вытащить наружу из detalis класс FunctionEngine<typename T /*unspecified*/> и шаблонить такие функции параметром T
Александр
Артем
вопрос, можно ли например собрать .dll на с++ и подключить к проекту на c#??
Ender
Berkus
Maks
Я имею солидный опыт программирования на разных языках, но не могу разобраться с С++ с одним моментом.
Перед тем как опубликовать это здесь я уже ознакомился с десятью первыми ссылками от Google, но ответа не нашел.
В каком месте правильно ставить * у указателя?
Node* node; // или
Node *node;
Я пересмотрел большое количество проектов на GitHub и Cpp-гайдлайнов, но не смог найти однозначого ответа.
Александр
Субъективно
Ender
Да ты издеваешься
Александр
#holywar
Maks
Если использовать первый вариант, то запись вида
Node* node, next_node.
выглядит неоднозначно и ухудшает читаемость кода.
Maks
Черт, сделал ошибку
Александр
В телеграме можно редактировать сообщения
Maks
Aleksander
Denis
Я предпочитаю писать Foo* bar;
А в одной строчке объявлять больше одной переменной — это плохой стиль.
Denis
Просто никогда так не делай.
Maks
Dmitry
больше пробелов богу пробелов! Node * node;
Ender
Ender
Первая ссылка в Гугле
Maks
Denis
Ну просто плохой тон в качестве иллюстрации — плохая иллюстрация. Если ты не объявляешь в одной строчке больше одной переменной, то у тебя нет проблем и можно лепить астериск к имени типа везде.
Ender
Proof https://imgur.com/gallery/a2wCo
Maks
Maks
Ender
Ender
Not ZVYOZDO4KA
Maks
Vladislav
Скорее что написание кода должно быть неотрывно от написания тестов
Joy
Я не ходил по ссылкам, просто чтобы попробовать угадать - правильней ставить ее у типа, потому что она относится к типу, т.е. int* это тип "указатель на инт". Так? Сейчас пойду прочитаю)
Denis
У тебя может не быть имени переменной, а тип и астериск может быть. Т.е. например
void foo(Bar*, Moo**);
void foo(Bar *, Moo **);
Второй вариант как-то странно выглядит. А если лепить к имени типа всегда, то единообразно во всех случаях, кроме случая объявления нескольких переменных на одной строчке, который плохой.
Ender
А ** это возведение в степень?))
Denis
Ты серьёзно?
Ender
Нет.
Denis
https://cdecl.org/
Плодове ягідне вино
Всем здрасти
Matwey
Ender
Второй вариант нормально выглядит. Тебе же сказали, если ты сам пишешь, то стиль это вкусовщина. Например стиль кода с типом результата для функций на отдельной строке или открывающаяся фигурная скобка на одной строке с if (...) для меня выглядят очень мерзко. Но кому-то нравится. А если все в проекте так пишут, то тут надо соответствовать, просто ради приличия. Я например всегда (foo *, bar *, ...) пишу. Мне так удобнее. или так же (foo &, bar &)
Denis
Не совсем.
Denis
Вкусовщина — это если нет практических проблем.
Pavel