system("PAUSE") è certamente meno che ideale. l'utilizzo di una chiamata al sistema crea un sottoprocesso, che su Windows è piuttosto costoso e in ogni caso non eccessivamente economico su nessun sistema operativo. Sui sistemi embedded l'overhead della memoria è significativo.
Se c'è un modo per farlo senza molto dolore in modo nativo, allora fallo. Nel caso in cui si desideri che l'utente preme un singolo pulsante, cin.get() sarà molto difficile da battere. In questo caso, il processo delle applicazioni bloccherà solo su stdin, impostando solo pochi flag visibili al kernel e, soprattutto, non alloca nuova memoria e non crea nuove entità di pianificazione, nemmeno un gestore di interrupt.
Inoltre, funzionerà allo stesso modo su tutti i sistemi operativi con tutti i compilatori C++, poiché utilizza solo una funzione di base di una parte molto standard della lingua, piuttosto che dipendere da tutto ciò che il SO fornisce.
MODIFICA: prevedi la tua preoccupazione che non importa se è costoso perché l'intera idea è di mettere in pausa. Bene, prima di tutto, se è costoso, allora danneggerà le prestazioni per qualsiasi altra cosa che potrebbe accadere. Mai notato (su Windows) all'avvio di un'applicazione, anche altre app già aperte diventano meno reattive? Inoltre, il tuo utente potrebbe non essere un live human, ma piuttosto un altro programma che lavora per conto di un utente umano (Say, uno script di shell). Lo script sa già cosa fare dopo e può pre-riempire lo stdin con un personaggio per saltare l'attesa. Se hai utilizzato un sottoprocesso qui, lo script subirà un ritardo (evidente da un essere umano). Se lo script esegue centinaia di volte (o centinaia di milioni!) Di volte, uno script che potrebbe richiedere secondi per essere eseguito richiede ora giorni o anni.
EDIT2: quando usare system(): quando è necessario fare qualcosa che fa un altro processo, che non è possibile fare facilmente. system() non è sempre il miglior candidato perché fa due cose che sono un po 'limitanti. Innanzitutto, l'unico modo per comunicare con il sottoprocesso è tramite gli argomenti della riga di comando come input e il valore restituito come output. Il secondo è che il processo genitore blocca fino al completamento del processo figlio. Questi due fattori limitano i casi in cui il sistema è utilizzabile.
su sistemi unixy, la maggior parte dei sottoprocessi si verifica con fork perché consente allo stesso programma di continuare nello stesso posto di due processi separati, uno come figlio dell'altro (che è quasi impercettibile a meno che non venga richiesto dal sistema operativo). Su Linux, questo è particolarmente ben ottimizzato e conveniente quanto la creazione di un pthread. Anche su sistemi dove non è così veloce, è ancora molto utile (come dimostrato dalla metodologia del pool di processi apache) (non disponibile su windows/link to unix docs)
altri casi (anche su Windows!) Sono spesso gestiti da popen o exec famiglia di funzioni.popen crea un sottoprocesso e una nuova pipa che si collega allo stdin o allo stdout dei sottoprocessi. Entrambi i processi padre e figlio possono quindi essere eseguiti contemporaneamente e comunicare abbastanza facilmente. (link to windows docs/link to unix docs)
exec * famiglia di funzioni (ci sono diversi, execl, execv e così via) dall'altro provoca il programma aggiornato da sostituire dal nuovo programma. Il programma originale esce invisibilmente e il nuovo processo prende il sopravvento. Quando poi il nuovo processo ritorna, ritornerà a quello che ha chiamato il processo originale, come se quel processo fosse ritornato a quel punto invece di scomparire. Il vantaggio di questo corso exit(system("command")) è che non viene creato nessun nuovo processo, il tempo e la memoria (anche se non sempre terribilmente molto) (link to windows docs/link to unix docs) risparmio
system potrebbe plausibilmente essere utilizzato da qualche strumento di script per richiamare diversi passaggi in qualche ricetta azione. Ad esempio, a un certo punto, un programma potrebbe utilizzare system per richiamare un editor di testo per modificare alcuni file di configurazione. Non deve preoccuparsi troppo di ciò che accade, ma dovrebbe certamente aspettare fino a quando l'utente non ha salvato e chiuso l'editor prima di continuare. Può quindi utilizzare il valore di ritorno per scoprire se la sessione di modifica ha avuto esito positivo, nel senso che l'editor ha effettivamente aperto il file richiesto (e che l'editor stesso esisteva del tutto!), Ma leggerà i risultati effettivi della sessione da il file modificato direttamente, piuttosto che comunicare con il sottoprocesso. (link to windows docs/link to unix docs)
Quindi, come è andata, all'improvviso hai pensato "hey, è davvero giunto il momento di apportare alcune modifiche estetiche a una domanda presentata più di un anno fa"? :) –