Здравствуйте, Андрюха, Вы писали:

А>Если не нравится, то реализуйте свои версии MPI_Gather и MPI_SendForGathering, и работайте с ними. В чем проблема?
А>Будет у вас хорошая обертка, люди начнут пользоваться ею.

вопрос был, почему сделали так, как сделали — часто в таких ситуациях есть какие-то подводные камни, которые "неестественная" на первый взгляд реализация и пытается обойти.

__>>приходится мешать все в кучу, наподобие
__>>

__>>std::vector<int> MPIGatheredValues(nMPIProcessesCount, 0);

__>>const int value = <something>;

__>>MPI_Gather(&value, 1, MPI_INT, MPIGatheredValues.data(), 1, MPI_INT, 0, MPI_COMM_WORLD);
__>>

А>Это непривычно поначалу, но мне особых проблем не доставляет. К тому же, второй вариант выглядит компактней и понятней. Ветвления воспринимаются сложнее.
А>Все-таки MPI — это дитя научного сообщества, а не программистов, так что тут могут быть немного другие приоритеты.

ну так тут ветвление тоже есть, токо оно спрятано внутри MPI_Gather. получается, один и тот же код в разных процессах имеет разную семантику, что, имхо, не есть гуд.

__>>UPD. Возникла мысль — может быть, так сделано, для того, чтобы гарантировать, что всегда будет отсылающий и собирающий?

А>Программист гарантирует наличие отправителя и получателя, функции сами по себе этого сделать не могут.

еще как могут — если функция такова, что ее нельзя написать без отправителя и получателя, то можно говорить, что она гарантирет наличие того и другого