#include <stdio.h>
void print(int *array, int *index, int n_indices)
{
int i;
for (i = 0; i < n_indices; ++i)
printf("%d ", array[index[i]]);
printf("\n");
}
void f(int *array, int start, int n, int *index, int n_indices)
{
int i;
for (i = start; i < n; ++i) {
index[n_indices] = i;
print(array, index, n_indices + 1);
f(array, i + 1, n, index, n_indices + 1);
}
}
int main()
{
int array[] = {1, 2, 3};
int index[3];
f(array, 0, 3, index, 0);
return 0;
}
Нет, непонятна. Что должна принимать на вход функция и какой вывод от неё ожидается?
А именно:
- должна ли она принимать упорядоченный массив или любой
- должна ли она печатать элементы массива по возрастанию индекса или по возрастанию значения
Попробуйте ответить на них и увидите, что некоторые варианты ответов тянут за собой другие вопросы.
> после отсылки всех данных нужно выполнить еще один send, передав какой-нибудь мусор, чтобы быть уверенным в том, что данные 100%-но доставлены?
Нет. "Один из последующих" -- это не обязательно следующий. Нужно либо организовать подтверждение в своём протоколе, либо закрыть сокет на передачу вызвав shutdown(socket, SHUT_WR).
> Тогда ОС будет ожидать восстановление канала?
Будет какое-то время, зависит от настроек TCP (keep-alive) и от того, есть ли принятые для передачи но не доставленные данные.
> как посылающая программа узнает об ошибке?
один из последующих вызовов send/recv завершится с ошибкой или select отметит этот сокет как имеющий данные для чтения или получивший исключение, после чего вызов recv завершится с ошибкой.
> Я правильно понимаю, что на момент выхода из функции send данные уже доставлены?
Не обязательно. На момент выхода из send локальный TCP стек взялся доставить ваши данные, ничего сверх этого не гарантируется.
> Я использую TCP, почему нет гарантии, что принято будет столько, сколько отправит send Bosca Bosca: потому что TCP -- потоковый протокол. Он гарантирует что все отправленные данные будут доставлены, но интерфейс BSD sockets, на котором основан winsock не гарантирует, что принимаемые блоки данных как-то будут соответствовать отправляемым.
> почему если не получилось принять весь блок, recv не возвращает ошибку
потому что для потокового протокола это не ошибка, вы получите остальные данные в следующем recv.
Если ваши прикладные данные -- это сообщения переменной длины, которые имеют смысл только целиком, вам нужно самому организовать фрейминг в потоке TCP, например посылая длину сообщения перед самим сообщением, а на приёмной стороне получать длину, а дальше читать данные в цикле.
> Пытаюсь на Android отлаживать нативные (NDK) приложения при помощи gdb. Rou1997: ваш вопрос про gdb. Вы задали его мне одному, как комментарий к ответу на совсем другой вопрос. Вы можете задать его нормально, и, я уверен, вам кто-нибудь ответит, может быть и я.
> А вы что хотите и зачем?
Я хочу порядка в примыкающей ко мне части вселенной. Мне так легче жить.
lada-guy: стандартная библиотека С не является частью gcc. Есть несколько реализаций этой библиотеки, которые можно использовать с gcc, например: glibc, musl, uClibc, newlib.
> subprocess.call('xcopy "%s" "%s*" /y /q' % (path1, path2)) - тоже не работает SalatProduction: subprocess.call принимает в качестве аргумента список, а не строку. Имя исполняемого файла запускаемой команды и каждый из аргументов команды -- это отдельные элементы этого списка.
Потом понимаешь, что зря это сделал, а make uninstall не работает.
Потом понимаешь, что ./configure принимает кучу параметров, в том числе --prefix.
Потом понимаешь, что устанавливать можно и без sudo и в домашний каталог.
Потом понимаешь, что вместо всего этого надо было собрать .deb и нагугливаешь checkinstall.
