Так, мой другой ответ был довольно прост в использовании. Но это - O (n*m) решение.
Вот является немного менее дружественный O (n+m) решением. Это должно использоваться, если надмножество ОГРОМНО. Это неоднократно старается не перечислять надмножество.
HashSet<int> hashSet = new HashSet<int>(superset);
bool contained = subset.All(i => hashSet.Contains(i));
Просто установите stdout для строчной буферизации в начале вашей программы C (перед выполнением любого вывода), например:
#include <stdio.h>
setvbuf(stdout, NULL, _IOLBF, 0);
или
#include <stdio.h>
setlinebuf(stdout);
Любой из них будет работать в Linux, но setvbuf
является частью стандарта C, поэтому он будет работать в большем количестве систем.
По умолчанию stdout будет буферизироваться блоком для канала или файла или буферизироваться строкой для терминала. Поскольку в этом случае stdout является конвейером, по умолчанию будет использоваться блочная буферизация. Если это блочная буферизация, то буфер будет сброшен при заполнении или при вызове fflush (stdout)
. Если это строчная буферизация, то она будет автоматически сбрасываться после каждой строки.
Вам нужно, чтобы ваша программа на C вызывала fflush (stdout) после каждой строки. Например, с помощью инструмента GNU grep вы можете вызвать параметр --line-buffered, который вызывает такое поведение. См. fflush .
Если вы можете изменить свою программу на C, значит, вы уже получили свой ответ , но я подумал, что включу решение для тех, кто не может / не хочет изменять код.
ожидайте содержит пример сценария под названием unbuffer , который поможет решить эту проблему.
Вы можете попробовать сбросить
поток stdout в программе cpp.
хорошо, это может показаться глупым, но это может сработать:
выведите свой pgm в файл
$ c_program >> ./out.log
разработайте программу на Python, которая читает из хвостовой команды
import os
tailoutput = os.popen("tail -n 0 -f ./out.log")
try:
while 1:
line = tailoutput.readline()
if len(line) == 0:
break
#do the rest of your things here
print line
except KeyboardInterrupt:
print "Quitting \n"
Все оболочки Unix (о которых я знаю) реализуют конвейеры оболочки через нечто иное, чем pty.
(обычно они используют каналы Unix! -); поэтому библиотека времени выполнения C / C ++ в cpp_program
ЗНАЕТ, что ее вывод НЕ является терминалом, и поэтому БУДЕТ буферизовать вывод (фрагментами по несколько КБ за раз). Если вы не напишете свою собственную оболочку (или semiquasimaybeshelloid), которая реализует конвейеры через pyt, я считаю, что нет способа делать то, что вам нужно, используя нотацию конвейера.
Рассматриваемая «шеллоидная» вещь может быть написана на Python (или на C , или Tcl, или ...), используя модуль pty
стандартной библиотеки или основанную на нем абстракцию более высокого уровня, такую как pexpect , и тот факт, что две программы быть подключенными через «конвейер на основе pty», написаны на C ++, а Python не имеет значения. Ключевая идея состоит в том, чтобы обмануть программу слева от канала, чтобы она поверила, что ее стандартный вывод является терминалом (поэтому pty должен быть в корне уловки), чтобы обмануть свою библиотеку времени выполнения, не буферизуя вывод. Написав такой шеллоид, вы должны вызвать его с помощью синтаксиса, например:
$ shelloid 'cpp_program | python_program.py '
Конечно, было бы проще предоставить «точечное решение», написав python_program
, зная, что он должен порождать cpp_program
как подпроцесс И трюк он считает, что его стандартный вывод является терминалом (например, python_program
будет напрямую использовать pexpect
). Но если у вас миллион таких ситуаций, когда вы хотите нарушить обычную буферизацию, выполняемую предоставляемой системой библиотекой времени выполнения C,