2009-07-23 8 views
15

Después de compilar los programas de la consola, la ventana de la consola se cierra inmediatamente después de ejecutarse. ¿Cuál es la mejor práctica para mantenerlo abierto? He buscado Google cargas, estoy acostumbrado a los bloques de código donde no tienes que preocuparte por eso, pero, quiero perder el tiempo con Visual Studio un poco y con VS, mi consola se cierra. En todo el interwebz hay varias formas diferentes de mantenerlo abierto, sin embargo, he leído que la mayoría de ellos son malas técnicas de codificación. ¿Cuál es el método preferido de todos?¿Cuál es la mejor práctica para combatir el problema de cierre de la consola?

Respuesta

5

cin es extremadamente poco elegante pero fácil para los olvidadizos para derivar:

{ 
    char c; 
    std::cin >> c; 
} 

que mantiene la ventana abierta hasta que escriba un carácter/* Editar */y pulsa enter.

std::cin.get() cerrará la ventana en el momento en que escriba un personaje, lo que, dependiendo de la facilidad con que se habitúa, corre un riesgo marginalmente mayor de "¡Uy, desearía no haber cerrado eso!" que las dos teclas operator>>(istream &).

Ambos se diferencian de un system("pause") en que devuelven de forma accesible el valor del carácter que escribió, por lo que, si no ocurre con poca frecuencia, un kludge lleva a otro, puede escribir un enunciado de conmutación basado en ha escrito (por ejemplo) salir inmediatamente, escribir algunos valores en un registro, ejecutarlo de nuevo, etc.

+3

std :: cin.get() tiene el mismo efecto y es más corto –

+3

Mantiene la ventana hasta que pueda obtener un carácter. Lo cual no ocurre hasta que se vacía el buffer (cin es buffer). Por lo tanto, se requiere que el usuario presione enter (o escriba muchos caracteres y complete el búfer). –

+0

@ robson3.1415, @martin ver edición :-) –

2

Uno muy común es simplemente poner el código para leer una clave de la consola después de que se cierra el código de la aplicación principal . La pulsación de tecla le acaba de tirar, pero mantiene la consola abierta.

No es bonito, necesariamente, pero a menudo hago esto envuelto en una definición de depuración, por lo que durante la depuración, la consola se mantiene abierta. Durante el lanzamiento, generalmente no me estoy ejecutando dentro de VS, y cuando se ejecuta desde una línea de comando, esto ya no es un problema.

+0

Me gusta la idea #define de depuración. definitivamente mejor que un punto de quiebre. – AShelly

13

Dado que siempre se ejecuta en el depurador, establezca un punto de interrupción en la declaración de devolución desde main().

El depurador es su mejor amigo, aprenda (y aprenda pronto) a usarlo en su beneficio en cada oportunidad.

+1

cada vez que hago esto, constantemente me encuentro entrando en crt0.c, que es realmente molesto. – AShelly

6

Ejecutar el programa en una consola, que sería la forma esperada de la ejecución de un programa de consola ...

Alternativamente, se puede hacer un pequeño archivo por lotes para ejecutar su programa que tendría:

REM batch file to launch program 
yourprogram.exe 
PAUSE 

y el comando PAUSE cmd.exe le solicitará al usuario que presione cualquier tecla.

+9

Es bastante fácil en realidad. Haga clic derecho en su proyecto en VS, elija Propiedades. En la sección de depuración puede indicarle que inicie un programa externo. En este caso, sería el archivo por lotes que inicia su aplicación. –

4

que tienden a utilizar system("PAUSE"); que le da un mensaje

Press any key to continue . . .

.

+1

Esto es específico de Windows, creo, pero hace el trabajo. – DeusAduro

+0

Tienes razón, solo es Windows, pero solo he encontrado que esto es un problema en Visual Studio, así que pensé que estaría bien. – irh

+2

-1 No uses llamadas al sistema para cosas como esta – Patrick

0

llamar a esta función antes de regresar al final del principal:

void onEnd() 
{ 
    printf("Press any key to exit..."); 
    _getch(); 
} 
21

Cuando estoy usando Visual Studio y no necesito depuración que simplemente se ejecuta utilizando Ctrl +F5 golpe de teclado – e impide que la consola se cierre.

3

que utilizo:

cin.get() 

me dijeron que era menos costoso que el sistema ("PAUSE") y funciona en sistemas POSIX también. Hay un gran link que entra en detalles sobre esto.

+4

¿Qué tiene que ver el costoso con algo? El objetivo del código es mantener la ventana del terminal colgando hasta que presione una tecla. ¿Qué tan lento crees que 'sistema (" PAUSE ")' es, en comparación con, por ejemplo, tus reflejos ;-) –

3

Resista la tentación de hacer cualquier cosa. Los programas de línea de comando que se comportan bien salen cuando terminan de ejecutar el informe de un estado a través de su código de salida. Esto les permite ser programables y 'buenos ciudadanos' en entornos automatizados. Incluso en un entorno interactivo, ¿por qué obligar al usuario a presionar una tecla adicional solo por su entorno de depuración?

Si ejecuta, en lugar de depurar, Visual Studio abrirá una ventana de consola que hace una pausa después de que la aplicación finalice para que pueda ver el resultado. No sé por qué el comportamiento es diferente cuando depura, quizás porque tiene puntos de interrupción disponibles, por lo que si desea ver el resultado en varias etapas puede colocar puntos de interrupción después de las declaraciones de salida relevantes, o al final de main o habilitar varios opciones 'parar en tiro de excepción'.

Cualquiera que sea la razón, nunca me he sentido obligado a comprometer el comportamiento de mi aplicación solo para mejorar mi experiencia de depuración.

+0

+1 por la diferencia en el comportamiento de ejecución vs. depuración. –

1

Las respuestas de "no hacer eso" en este hilo pueden parecer cortantes, pero son bastante razonables. Supe a través de esta pregunta porque estoy depurando una suite gtest que solía funcionar bien, pero ahora falla misteriosamente cuando se lanza. Cuando se ejecuta desde la consola, aparece un diálogo que dice "blah.exe ha dejado de funcionar"; pero, cuando se ejecuta desde el depurador, la consola aparece momentáneamente, se desvanece y el programa sale con el estado 0.

Debería haber estado pensando en cuán extraña era esta diferencia en el comportamiento, pero en cambio, estaba como: "Aw, hombre --- tengo que hacer que la ventana de la consola permanezca arriba para que pueda ver lo que dice". ¿Derecha?

Resulta que la máquina en la que estoy trabajando (un colega mío) tenía los 'Argumentos del Comando' para el depurador establecido en '--gtest_filter = * testMsg *'. Me di cuenta de esto también de inmediato, pero nunca se me ocurrió que todas las pruebas que coincidían con el filtro habían sido renombradas en una confirmación reciente. Entonces, cuando se lanzó desde el depurador, gtest no encontró ninguna prueba para ejecutar y simplemente estaba saliendo. Otros 90 minutos de mi vida nunca volveré. (-_-) Pude haber abandonado este bebé alquitranado mucho antes si mi reacción instintiva no hubiera sido pensar que necesitaba que la ventana de la consola permanezca abierta para resolver el problema ...

Cuestiones relacionadas