протобаф - это кодо генерация, в моем случае как из пушки по воробьям. Мне на самом деле это не особо важно. У меня там просто массивы флоатов и других данных. Вопрос в том, как их сохранять, что бы везде одинаково сохранялось. Но я прочитал что и на андроиде le используется, выходит на всех моих платформах le и не надо мудрить.
ну смотрите, мне надо что б работало на маке линуксе и виндоус. Клиентами будут также приложения на андроиде например. Так что хотелось бы независимо ни от чего иметь одинаковый порядок байт в файле, который я сохраняю.
@VoloshinAlex777 Так по реализации возможно вы не до конца ее поняли. Вам необходимо реализовать длинную арифметику. Т.е. если у вас ключ 512 бит, то вы должны уметь умножать числа длиной в 512 бит. Если вы будете просто с помощью рса кодировать по букве, то у вас реальнор шифр превратится в шифр подстановки.
Предположим вы используете упрощенную реализацию без длинной арифметики, и у вас ключ длинной всего 32 бита.
1) у вас могут быть проблемы с переполнением поэтому рекомендую для операций использовать инт64.
2) У вас есть строка байтов, положим длинной не кратной 4, например 102, вЫ еще расширяете двумя нулями до длины 104, и используете каждые 4 байта как один инт, у вас получается массив интов, которые вы шифруете вашей функцией, и на выходе тоже получите массив интов.
Который можно сохранять в файл например функцией fwrite: devoid.com.ua/functions-about/c-functions/fwrite.html
Прошу прощения, я не верно вас понял. У нас тоже проблемы потери производительности при использовании юниттестов. Да и как я говорил, если человек не понимает зачем оно, он будет делать тесты на отъе... Ну вообще насчет прыжков всеравно не до конца понял, поменял код в либе, запустил тест который его юзает и дебажимся.
А я и не утверждаю что идеально ТДД. У нас нету цель делать полное покрытие всех классов. Только тех, которые решают разные мат задачи. А в этом случае все довольно тривиально, так как заумных связей нет. Есть просто данные на входе и на выходе.
Все зависит от человека. Я в данный момент лид проекта. Вот если лень человеку юниттест писать, то он его даже если и напишет но толку от него не будет совсем. У нас в проекте очень много мат. алгоритмов поэтому их тестирование вполне тривиальное. И большинство тестов работает менее секунды. И что значит летаете над основным кодом? Туда сюда не более 1-2 раза. Написал код, написал тест(или наоборот;)) запустил, убедился что работает. Дальше запускает билдсервер, если что не так упадет еще там.
по разному, на предыдущем месте работы было так. Сейчас только один тест, но мы не ставим задачу покрыть все. Задача - покрыть основные алгоритмы. Т.е. обьем тестов небольшой.
ничего не усложняется, все одинаковые действия выносятся в базовый класс, одинаковый код писать не надо. Но вот в вашем случае такая ситуация, ты ушел в отпуск, вместо тебя сел человек, начал писать еще пару тестов, но он не знал, что у тебя порядок важен и все поломал добавлением новых тестов. В итоге тебе звонят прямо в Турцию)
В том виде, в котором вы это пишите я бы такие юниттесты не принял бы у программиста:
1) Тест который проверяет создание объекта - создаете объект с разными вариантами создания, в каждом проверяете что все создалось как хотели, в конце все уничтожаете.
2) Тест на уничтожение, создаете объекты, уничтожаете, убеждаетесь что его больше нет.
3) Тест на работу с объектом, опять создаете, меняете, проверяете, уничтожаете.
Код, который вы предложили выглядит же ужасно. Как его отлаживать и тд? Если для вас RAII это хаки и ужас явно видно, что вы совсем не разобрались в теме и даете ужасные советы. Особено, сравните тот код на макросах с обычным std::vector. Или эмуляция виртуальных функций на Си вместо использование нормальных классов.
