IZ
treg
понял, спасибо за помощь
Я ещё не помогал...
1. man fflush
2. @supapro
Size: a a a
2021 March 12
FS
IZ
/s@SupaproBot
IZ
treg
Добрый день, не подскажите как решить следующую проблему:
есть класс который хочу протестировать с помощью google test:
class RawModelReceiver в классе используется класс ChunkManager с не виртуальными методами, поэтому что бы заменить его на мок класс делаю основной шаблоном. В итоге в заголовке
template<class T>
class RawModelReceiver
в cpp классе специализация RawModelReceiver<ChunkManager>::. Для тестов создал класс MockChunkManager и для него надо тоже сделать специализацию, копировать код или использовать какие-то скрипты не хотелось,
могу я как-то переопределить специализацию с ChunkManager на MockChunkManager только для тестов. В качестве системы сборки Cmake
есть класс который хочу протестировать с помощью google test:
class RawModelReceiver в классе используется класс ChunkManager с не виртуальными методами, поэтому что бы заменить его на мок класс делаю основной шаблоном. В итоге в заголовке
template<class T>
class RawModelReceiver
в cpp классе специализация RawModelReceiver<ChunkManager>::. Для тестов создал класс MockChunkManager и для него надо тоже сделать специализацию, копировать код или использовать какие-то скрипты не хотелось,
могу я как-то переопределить специализацию с ChunkManager на MockChunkManager только для тестов. В качестве системы сборки Cmake
У тебя есть
ChunkManager, который работает с недоступным устройством и
MockedChunkManager, который должен имитировать его логику.
Тебе надо иметь возможность подставлять в RawModelReceiver один или другой класс, в зависимости от тест/реальная работа.
Это можно сделать двумя путями:
- за счёт рантайм полиморфизма в ChunkManager - надо выделить общий интерфейс, и унаследовать оба ChunkManager-а от него, а RawModelReceiver будет работать только с интерфейсом.
- за счёт статического полифорфизма на шаблонах в RawModelReceiver и инстанциации его с ChunkManager, либо MockedChunkManager
В обоих случаях MockedChunkManager должен имитировать работу реального ChunkManager и у них может быть какой-то общий код, который будет повторяться.
С этим общим кодом можно бороться опять-таки теми двумя методами выше (одним из двух):
- за счёт рантайм полиморфизма
- за счёт статического полифорфизма на шаблонах
То есть либо надо опять выделять базовый класс из ChunkManager и учить его работать с абстрактным устройством, либо выделять общую часть в шаблонный класс, и инстанциировать
его с одним или другим устройством.
При этом пока именно специализация классов-шаблонов тут не нужна, ну не видно совсем зачем бы это было нужно.
ChunkManager, который работает с недоступным устройством и
MockedChunkManager, который должен имитировать его логику.
Тебе надо иметь возможность подставлять в RawModelReceiver один или другой класс, в зависимости от тест/реальная работа.
Это можно сделать двумя путями:
- за счёт рантайм полиморфизма в ChunkManager - надо выделить общий интерфейс, и унаследовать оба ChunkManager-а от него, а RawModelReceiver будет работать только с интерфейсом.
- за счёт статического полифорфизма на шаблонах в RawModelReceiver и инстанциации его с ChunkManager, либо MockedChunkManager
В обоих случаях MockedChunkManager должен имитировать работу реального ChunkManager и у них может быть какой-то общий код, который будет повторяться.
С этим общим кодом можно бороться опять-таки теми двумя методами выше (одним из двух):
- за счёт рантайм полиморфизма
- за счёт статического полифорфизма на шаблонах
То есть либо надо опять выделять базовый класс из ChunkManager и учить его работать с абстрактным устройством, либо выделять общую часть в шаблонный класс, и инстанциировать
его с одним или другим устройством.
При этом пока именно специализация классов-шаблонов тут не нужна, ну не видно совсем зачем бы это было нужно.
t
ChunkManager не могу переписать просто, там методы не виртуальные соответственно не могу использовать наследование
t
Но я общий посыл понял
ГH
treg
ChunkManager не могу переписать просто, там методы не виртуальные соответственно не могу использовать наследование
А тестирование какого типа? Для юнит-тестов слишком крупно, для интеграционного тестирования слишком изолировано.
IZ
treg
ChunkManager не могу переписать просто, там методы не виртуальные соответственно не могу использовать наследование
Так сделай их виртуальными.
Не всегда возможно сделать тесты без изменения кода, да.
Не всегда возможно сделать тесты без изменения кода, да.
IZ
А тестирование какого типа? Для юнит-тестов слишком крупно, для интеграционного тестирования слишком изолировано.
Ну, юнит, но с недоступным устройством.
ГH
Мок устройства тогда должен быть без внутреннего состояния. В идеале.
t
Так сделай их виртуальными.
Не всегда возможно сделать тесты без изменения кода, да.
Не всегда возможно сделать тесты без изменения кода, да.
Так код не мой же, это надо идти просить переделать, объяснять почему мне это надо, просто думал есть какой-то простой кейс для этого, самый простой это и получается просить переделать
IZ
treg
Так код не мой же, это надо идти просить переделать, объяснять почему мне это надо, просто думал есть какой-то простой кейс для этого, самый простой это и получается просить переделать
да, надо.
IZ
treg
Так код не мой же, это надо идти просить переделать, объяснять почему мне это надо, просто думал есть какой-то простой кейс для этого, самый простой это и получается просить переделать
Либо делай на статическом полиморфизме...
Ну и не жалуйся, что придётся часть кода копировать.
Ну и не жалуйся, что придётся часть кода копировать.
AG
По неиспользанным 16 битам адреса на x64:
сейчас уже есть x86_64 процы от интела, которые поддерживают 57-битные адреса (https://en.wikipedia.org/wiki/Intel_5-level_paging),
arm64 поддерживает 52-битные адреса (https://opensource.com/article/20/12/52-bit-arm64-kernel).
Кроме того, на arm с расширением Top-byte Ignore (TBI) имплементация может использовать эти биты для чего-то, например для санитайзера (https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html)
Так что для переносимого кода с этим надо быть осторожным)
сейчас уже есть x86_64 процы от интела, которые поддерживают 57-битные адреса (https://en.wikipedia.org/wiki/Intel_5-level_paging),
arm64 поддерживает 52-битные адреса (https://opensource.com/article/20/12/52-bit-arm64-kernel).
Кроме того, на arm с расширением Top-byte Ignore (TBI) имплементация может использовать эти биты для чего-то, например для санитайзера (https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html)
Так что для переносимого кода с этим надо быть осторожным)
IZ
Andrey Glebov
По неиспользанным 16 битам адреса на x64:
сейчас уже есть x86_64 процы от интела, которые поддерживают 57-битные адреса (https://en.wikipedia.org/wiki/Intel_5-level_paging),
arm64 поддерживает 52-битные адреса (https://opensource.com/article/20/12/52-bit-arm64-kernel).
Кроме того, на arm с расширением Top-byte Ignore (TBI) имплементация может использовать эти биты для чего-то, например для санитайзера (https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html)
Так что для переносимого кода с этим надо быть осторожным)
сейчас уже есть x86_64 процы от интела, которые поддерживают 57-битные адреса (https://en.wikipedia.org/wiki/Intel_5-level_paging),
arm64 поддерживает 52-битные адреса (https://opensource.com/article/20/12/52-bit-arm64-kernel).
Кроме того, на arm с расширением Top-byte Ignore (TBI) имплементация может использовать эти биты для чего-то, например для санитайзера (https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html)
Так что для переносимого кода с этим надо быть осторожным)
А я вот всегда в верхних разрядах адреса свои данные храню, ну, чтоб место не пропадало...
Фоточки там всякие, и т.п.
Фоточки там всякие, и т.п.
DF
Ядро и щас использует эти биты для kasan
DF
Другой вопрос что перед возвратом поинтера в юзерспейс они затираются
DP
не особо понятно как их используют, мне всегда казалось что адрес должен быть в каноничной форме, иначе будет фолт при дерефе
In 64-bit mode, an address is considered to be in canonical form if address bits 63 through to the most-significant implemented bit by the microarchitecture are set to either all ones or all zeros.
DF
Вот тут хз
DF
Я тоже чето такое помню слышалт