Зачем писать статью если есть замечательная книга — Working effectively with legacy code. Хочу обратить ваше внимание на определение понятия legacy code, которое там даётся.
Мне кажется что ваша проблема в том, что вы тестируете без спецификации, что вообще говоря, делать бессмысленно.
Если программист может вот так вот взять и поменять checkInt() на проверку чисел со знаком когда до этого она проверяла только беззнаковые и его это ни капельки не смутило и не нужно было менять спецификацию (да, пусть это будет одно предложение в документационном комментарии перед функцией) — то нужно исправлять программистов, а не занижать значимость юнит-тестов.
> Этот способ не эффективен, поскольку придется устанавливать много соединений
На количество соединений количество сообщений не влияет.
> Если расположить зоны исполнителей горизонтально, то можно использовать MPI_Type_contiguous или в MPI_Send указывать необходимое число элементов, но это, на мой взгляд, красивее.
Главное — это будет быстрее. Процессоры обожают бегать по памяти последовательно.
Статье поставил плюс, но честно — если бы я такое уже не писал, ничего бы не понял из этой статьи.
Вот в только таких хорошо отлаженных случаях кросс-компиляция работает хорошо — когда этот юзкейс предусмотрен и оттестирован разработчиками тулчейна и IDE.
[...]
A reference shall be initialized to refer to a valid object or function. [ Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior.
[...]
1. Кросс-компиляция, копирование на девайс, запуск.
2. Копирование на девайс, компиляция, запуск.
3. Кросс-компиляция, запуск под эмулятором.
4. Компиляция, запуск. (Всё на девайсе.)
Выбирайте какой вариант проще. Я считаю что если уже возиться с кросс-компиляцией, то лучше вариант (3). А если запускать на девайсе, (а мы говорим о ресурсоёмких задачах), то можно и компилировать там же — вариант (2). Вариант (1) сочетает недостатки всех подходов.
Пробовали? Баг зафайлили?
Если в этом смысле — тогда согласен.
Разве тесты в этом виноваты? Или, я начинаю догадываться, цель статьи — выяснить какие тесты более полезны при условии что тесты делаются для галочки?
В общем, ещё раз: с в принципе неправильным подходом к разработке не стоит винить юнит- (или какие-либо ещё) тесты в чём-либо.
Если программист может вот так вот взять и поменять checkInt() на проверку чисел со знаком когда до этого она проверяла только беззнаковые и его это ни капельки не смутило и не нужно было менять спецификацию (да, пусть это будет одно предложение в документационном комментарии перед функцией) — то нужно исправлять программистов, а не занижать значимость юнит-тестов.
На количество соединений количество сообщений не влияет.
> Если расположить зоны исполнителей горизонтально, то можно использовать MPI_Type_contiguous или в MPI_Send указывать необходимое число элементов, но это, на мой взгляд, красивее.
Главное — это будет быстрее. Процессоры обожают бегать по памяти последовательно.
Статье поставил плюс, но честно — если бы я такое уже не писал, ничего бы не понял из этой статьи.
UB.
Просто замените лямбды на function objects с виртуальными методами.
2. Копирование на девайс, компиляция, запуск.
3. Кросс-компиляция, запуск под эмулятором.
4. Компиляция, запуск. (Всё на девайсе.)
Выбирайте какой вариант проще. Я считаю что если уже возиться с кросс-компиляцией, то лучше вариант (3). А если запускать на девайсе, (а мы говорим о ресурсоёмких задачах), то можно и компилировать там же — вариант (2). Вариант (1) сочетает недостатки всех подходов.