Não execução do programa

arnaldoleao4
(usa Ubuntu)

Enviado em 24/07/2018 - 19:34h

Olá, pessoal!
Estou tendo um probleminha, no qual os programas que crio pelo codeblock não estão executando com deveriam. No começo pensei que fosse erro de digitação, mas não era.
Sempre aparece assim:

***Process returned 0 (0x0) execution time : 0.001 s
Press ENTER to continue.***



O código que fiz foi esse
#include <stdio.h>
#include <stdlib.h>

int main()
{
printf("IDE\n");

system("PAUSE");
return 0;
}

paulo1205
(usa Ubuntu)

Enviado em 25/07/2018 - 00:19h

Windows ou Linux?

Código de execução igual a zero geralmente significa execução bem sucedida (zero erros). E como você mesmo mandou o programa retornar com código zero, é provável que o zero informado seja o zero que você mandou informar.

removido
(usa Nenhuma)

Enviado em 25/07/2018 - 01:28h

O código não é portável, só funciona no Windows.

#include <stdio.h>

#include <stdlib.h>



int main()

{

printf("IDE\n");



system("PAUSE");

return 0;

} 

remova o

#include <stdlib.h>

system("PAUSE"); 

Esse código é portável, funciona no Linux, Windows e Mac.

#include <stdio.h>



int main()

{

printf("IDE\n");



printf("Pressione enter para continuar. . .\n");

getchar();



return 0;

} 

Isso é mensagem da IDE.
O programa executou normalmente, essa mensagem só mostra o código de retorno do programa que é zero.
A mensagem é normal, ela aparece quando o programa termina a execução na IDE Code::Blocks, quando o programa executa em um CLI ou com um click duplo ele executa sem essa mensagem.

paulo1205
(usa Ubuntu)

Enviado em 25/07/2018 - 09:58h

O código não é portável, mas não por causa do que você disse.

Quem garante que, se ele estiver rodando o programa num Linux ou outro UNIX, ou mesmo no MacOS, ele não tem um comando externo chamado “PAUSE”, instalado por ele mesmo ou por uma distribuição exótica que ele use? E quem garante que, se ele estiver no Windows, não vai usar o Cygwin para compilar o programa, de modo que system() use uma versão do Bash ou do Dash como interpretador de comandos, em lugar do CMD.EXE, resultando em que o comando “PAUSE” deixe de ser reconhecido (lembrando que “PAUSE” é um comando interno do COMMAND.COM e do CMD.EXE)?

Cenários improváveis não são cenários impossíveis.

Do ponto de vista do padrão do C e do programa em C, <stdlib.h> e system() são perfeitamente válidos. O que vai como argumento para system() está fora do escopo da linguagem.

Tendo dito isso, eu concordo que todo programa que chame system() deve ser visto com suspeição com relação a portabilidade. Funcionar hoje na máquina A, com a versão B do compilador C, executando sobre a versão D do sistema E com um conjunto de parâmetros F0...Fn não dá garantia nenhuma de que vai funcionar amanhã, se qualquer um dos aspectos A, B, C, D, E ou Fn mudar.


De um ponto de vista estrito de linguagem C, o que faz o código não-conforme com um padrão portável é a declaração de main().

Para sistemas operacionais como os nossos Windows e Linux do dia-a-dia (e, na verdade, para qualquer implementação de um ambiente de execução hospedado), a declaração de main() teria de ter sido feita de uma de duas maneiras.

// Se ele não desejar receber argumentos do ambiente de execução:

int main(void) 

// Se ele desejar receber argumentos do ambiente de execução:

int main(int argc. char **argv) 

A forma “int main()”, usada por ele e por você, é não-conforme com esse padrão. Em C, ela significa que main() pode ser invocada com qualquer quantidade de argumentos de quaisquer tipos. O fato de que que muitos compiladores, em vários sistemas diferentes, a aceitem (por causa de compatibilidade com versões muito antigas do C, anteriores à existência da palavra-chave void) não a faz conforme os padrões, nem remove dela o caráter de não-portável.

(Em C++, tal forma seria um sinônimo de “int main(void)”, e seria uma das formas aceitas pelo padrão. Mas C++ é outra linguagem!)



Falso.

Além do problema com a declaração não-conforme de main(), dependendo da implementação e de condições de contorno do ambiente, getchar() pode passar a diante com qualquer outro dado diferente daquele produzido pela eventual digitação da tecla Enter, ou pode também não seguir a diante mesmo que o usuário efetivamente a digite.

De novo se tem aqui um cenário improvável, mas não um cenário impossível. Cuidado, então.

E mais: no programa original, ele invocou o sistema operacional com a intenção de provocar uma leitura que garantidamente viesse do terminal. Quando você usa getchar(), você não oferece a mesma garantia, pois o dado pode vir de qualquer origem que possa ser mapeada para stdin. O programa fica análogo ao desejado originalmente, mas não é uma implementação rigorosamente equivalente.


O melhor a fazer nesse caso, na minha opinião, seria alterar o programa original (e a sua versão, também), para eliminar totalmente essa pausa antes de continuar com a finalização do programa. Ainda mais se o programa será executado dentro do Code::Blocks, uma vez que o próprio C::B já implementa essa pausa para você.