system("PAUSE"), конечно, не идеально. использование вызова системы создает подпроцесс, который в Windows довольно дорогой и в любом случае не очень дешевый в любой операционной системе. На встроенных системах накладные расходы памяти значительны.
Если есть какой-то способ сделать это без особой боли, то сделайте это. В случае ожидания нажатия пользователем одной кнопки, cin.get () будет очень трудно победить. В этом случае процесс вашего приложения будет просто блокироваться на stdin, устанавливая только несколько флагов, видимых для ядра, и, что наиболее важно, не выделяет новую память и не создает никаких новых объектов планирования, даже обработчика прерываний.
Кроме того, он будет работать одинаково на всех операционных системах со всеми компиляторами c ++, поскольку он использует только очень базовую функцию очень стандартной части языка, а не зависит от того, что предоставляет ОС.
РЕДАКТИРОВАТЬ: предсказывая вашу обеспокоенность тем, что не имеет значения, стоит ли это дорого, потому что вся идея состоит в том, чтобы сделать паузу. Ну, во-первых, если это дорого, то это повредит производительности для всего, что может происходить. Когда-нибудь замечали (на окнах), когда запускается одно приложение, другие уже открытые приложения тоже становятся менее отзывчивыми? Кроме того, ваш пользователь может быть не живым человеком, а другой программой, работающей от имени пользователя (скажем, сценарий оболочки). Сценарий уже знает, что делать дальше, и может предварительно заполнить стандартный ввод символом, чтобы пропустить ожидание. Если вы использовали здесь подпроцесс, сценарий будет испытывать (заметную для человека) задержку. Если сценарий выполняет это сотни (или сотни миллионов!) Раз, сценарий, выполнение которого может занять несколько секунд, занимает дни или годы.
EDIT2: когда использовать system(): когда вам нужно сделать что-то, что делает другой процесс, что вы не можете сделать легко. system() не всегда лучший кандидат, потому что он делает две вещи, которые несколько ограничивают. Во-первых, единственный способ связаться с подпроцессом - использовать аргументы командной строки в качестве входных данных и возвращаемые значения в качестве выходных данных. Во-вторых, родительский процесс блокируется, пока дочерний процесс не завершится. Эти два фактора ограничивают случаи использования системы.
в unixy системах большинство подпроцессов происходит с fork, потому что он позволяет одной и той же программе продолжаться в том же месте, что и два отдельных процесса, один как потомок другого (что вряд ли заметно, если вы не попросите об этом у ОПЕРАЦИОННЫЕ СИСТЕМЫ). В Linux это особенно хорошо оптимизировано и примерно так же дешево, как создание pthread. Даже в системах, где это не так быстро, это все еще очень полезно (как продемонстрировано в методологии пула процессов Apache) (недоступно в Windows / ссылка на документацию Unix )
другие случаи (также и в Windows!) Часто обрабатываются семейством функций popen или exec. popen создает подпроцесс и совершенно новый канал, соединяющийся с stdin или stdout подпроцессов. И родительский, и дочерний процессы могут работать одновременно и взаимодействовать довольно легко. ( ссылка на документы Windows / ссылка на документы Unix )
exec* семейство функций (их несколько, execl, execv и т. Д.), С другой стороны, вызывает замену текущей программы новой программой. Исходная программа незаметно завершает работу, и новый процесс вступает во владение. Когда затем новый процесс возвращается, он вернется к тому, что называется исходным процессом, как если бы этот процесс вернулся в этот момент вместо исчезновения. Преимущество этого по сравнению с exit(system("command")) в том, что новый процесс не создается, что экономит время и память (хотя и не всегда ужасно) ( ссылка на документацию Windows / ссылка на документацию Unix )
system может использоваться некоторыми скриптовыми инструментами для вызова нескольких шагов в некоторых действиях с рецептами. Например, в определенный момент программа может использовать system для вызова текстового редактора для редактирования какого-либо файла конфигурации. Ему не нужно слишком беспокоиться о том, что происходит, но, безусловно, следует подождать, пока пользователь сохранит и закроет редактор, прежде чем продолжить. Затем он может использовать возвращаемое значение, чтобы узнать, был ли сеанс редактирования успешным, в том смысле, что редактор действительно открыл запрошенный файл (и что сам редактор вообще существует!), Но будет считывать фактические результаты сеанса отредактированный файл напрямую, а не связывается с подпроцессом. ( ссылка на документы Windows / ссылка на документы Unix )