Ir ao conteúdo
  • Cadastre-se

C++ Problema com o Prompt no codeblock 17.12


Posts recomendados

 Olá a todos. Estou encontrando problemas no prompt de execução de meu codeblocks, coisa que eu não encontrava antes.

 Meus programas quando eu executava eles abriam a tela de prompt para execução, eu aumentei a tela de prompt pelas propriedades do prpóprio prompt, até aí tranquilo. Rodava super bem. Hoje fui pegar novamente os MESMOS programas e a tela piscava no tamanho grande que eu tinha setado, e diminuía logo depois para um tamanho mínimo, praticamente impossível de ver a execução do programa. 

 Fora isso, ele não aceitava os system("pause") no programa.

 Realmente não sei o que aconteceu. Não executo eles na forma de projeto, e sim como empty file.

 Até mudei para projeto para tentar executar pela GUI....mas nem a GUI abria, ele retornava a abrir o prompt clássico.

 Meus códigos são feitos em um fonte somente, por isso não via a necessidade de construir projetos.

 Mesmo durante uma execução eu novamente setava a tela de prompt para o tamanho que eu queria, mas logo depois, no meio da execução, acredito quando eu limpo a tela com system("cls") ele retoma o tamanho pequeno da tela.

 Eu buguei nessa. Estou no final do doutorado, e preciso confirmar uns resultados, e isso me bem agora.

 Por favor, vejam se me dão uma luz.

 valeu.

Link para o comentário
Compartilhar em outros sites

32 minutos atrás, Max Robert Marinho disse:

Hoje fui pegar novamente os MESMOS programas e a tela piscava no tamanho grande que eu tinha setado, e diminuía logo depois para um tamanho mínimo, praticamente impossível de ver a execução do programa

 

Isso eu não entendi. Se vai rodar os mesmos programas porque precisa desse CodeBlocks?

 

Que versão usa? Em que sistema? Com que compilador?

 

Link para o comentário
Compartilhar em outros sites

 Rodar eu quero dizer compilar novamente. Preciso verificar certos dados.

 Uso a versão 17.12, no Win 10, com o compilador MinGW.

 A tela que pisca é a do prompt quando mando executar o código. Ela pisca no tamanho grande que eu tinha setado previamente e retoma um tamanho muito pequeno.

Link para o comentário
Compartilhar em outros sites

1 hora atrás, Max Robert Marinho disse:

Rodar eu quero dizer compilar novamente. Preciso verificar certos dados.

 Uso a versão 17.12, no Win 10, com o compilador MinGW.

 

Então...

Os dados não são o programa. se o programa é o mesmo na pasta de saída está o executável, criado na última vez em que você rodou Build, Run ou Build And Run no IDE. Não precisa do IDE ou do compilador para rodar o mesmo programa. Apenas rode o programa
 

Eu tinha me prometido nunca fazer isso mas um dia desses instalei esse ambiente em meu computador. Usei uma única vez porque tinha ficado curioso com algo de que não me lembro, e a experiência não foi nada boa. Nunca mais usei.

Mas vi agora que é a mesma versão e o mesmo sistema e tal. E então posso ver aqui também.

 

Se mudou algo no programa ou se os dados estão dentro do programa... basta usar control-F9 e ele vai gerar um novo prgrama executável pra você. Na mesma pasta onde está o cpp. E você pode rodar isso em qualquer janela do Windows. Basta digitar o nome do programa e teclar ENTER.

 

Como está usando Windows 10 e o compilador gcc pode usar o novo terminal do Windows, que você pode instalar da loja com um click e é muito melhor e mais rápido que as outras janelas, como o PowerShell e o CMD além de usar o jeito Unix/Linux da console --- não precisa mais desses system() por exemplo --- e de usar aceleráção via GPU para a tela...

 

Veja mais informações no link no seu terminal mesmo em "novos recursos do console" ou aqui https://www.microsoft.com/pt-br/p/windows-terminal-preview/9n0dx20hk701?activetab=pivot:overviewtab

 

info.png.abd39f57fad149a311b74cb804a35f97.png

 

 

 

 

 

 

Link para o comentário
Compartilhar em outros sites

 Bem, não sei se não consegui me explicar muito bem ou se não entendi sua explicação, mas vamos lá. Só estou meio nervoso mesmo por ter dado este problema nos 45 min do 2ª tempo....dói.

 Bem, ja compilei e executei novamente várias vezes e a tela do prompt continua tendo o mesmo comportamento.

 Baixei o Windows Terminal, mas não sei como configuro o code block para que quando for executar, ele execute no terminal do windows mesmo.

 Sobre a compilação, eu preciso rodar ela de novo porque os dados são os mesmos só que as técnicas que preciso aplicar aos dados eu mudo cada vez que compilo, para poder pegar os tempos de execução comparativos.

 Vou ter que achar como configuro o terminal para ser aberto pelo codeblock.

Link para o comentário
Compartilhar em outros sites

Não precisa.

 

Apenas faça o que eu disse: se o IDe está dando problemas apenas use control-f9 e gere o novo programa e rode no terminal

 

Se precisa mudar as técnicas e não os dados talvez  fosse mais produtivo ter um programa para cada técnica já pronto, lendo os dados do disco e gravando o resultado e os tempos em arquivo e assim comparando depois.

 

De todo modo, para programas como os seus provavelmente o Terminal do Windows é só uma tela, só que mais funções e muito mais rápido e compatível.

 

Se o seu programa fosse dd.exe na pasta por exemplo M:\Public\SW você iria no terminal e 

M:
cd \public\sw
.\dd

Só isso.

 

Exemplo

terminal.thumb.png.e988e92918acadb717203063e217a3ea.png

 

 

 

adicionado 4 minutos depois

O codeblocks é só um IDE. Ele vai usar o compilador para gerar um arquivo executável a partir do seu programa. Só isso. Aí você pode pegar esse programa, gravar em um pen-drive e rodar em qualquer outro lugar por exemplo.

 

Eu nada disse sobre configurar o codeblocks. Se o seu programa de fato mudou devido ao modo que escolheu para construir seu sistema de comparações, apenas abra o programa no editor, use control-f9 para gerar novo exe. abra o terminal em outra janela e rode seu programa EXE.

 

Depois que conseguir seu resultado alguém pode te ajudar a restaurar o codeblocks com mais tempo

Link para o comentário
Compartilhar em outros sites

 Olá.

 Fiz tudo isso e a tela do Power Shell diminui para o mesmo tamanho da tela de prompt quando eu mando executar o código. Enquanto eu estou colocando as informações para então executar o código a tela fica tranquila, tamanho normal. Quando eu executo, a tela diminui.

Link para o comentário
Compartilhar em outros sites

1 hora atrás, Max Robert Marinho disse:

Fiz tudo isso e a tela do Power Shell diminui para o mesmo tamanho da tela de prompt quando eu mando executar o código. Enquanto eu estou colocando as informações para então executar o código a tela fica tranquila, tamanho normal. Quando eu executo, a tela diminui

 

Então nada tem a ver om o IDE, certo? Ou com a janela de prompt. "Tudo isso" seria apenas digitar o nome do programa e teclar ENTER ao invés de abrir o tal IDE, carregar o programa e compilar de novo para gerar o executável de novo e então rodar o programa?

 

talvez possa postar um desses programas pra gente ver

Link para o comentário
Compartilhar em outros sites

 Bem, acredito que sim, mas não sei o que poderia ser no programa uma vez que estava tudo normal ha umas 2 semanas.

 Vamos ver se mandando o programa resolve, mas não mudei nada nele para este problema no prompt ocorrer.

 Estou mandando 3 arquivos, o .cpp e 2 arquivos .txt que são os que o programa carrega.

14 barras.rar

Link para o comentário
Compartilhar em outros sites

Dei uma olhada no programa aqui na hora do  ☕

 

Provavelmente está havendo corrupção de memória. Não pude ir muito longe com o programa porque meu compilador sequer aceita essas construções, e não posso mudar de ambiente agora.

 

Depois lembrei de que tem uma máquina aqui com esse ambiente, code::Blocks 17:12 (ultima versão, de 2017) e até rodei seu programa. Vou te mostrar o resultado a seguir

 

Antes, uns palpites

 

  • Seu programa é práticamente um programa C. Não parece haver razão para compilar em C++. C é mais rápido, C++ tem vantagens. Escrever C em C++ não soma nada, só fica potencialmente mais lento
  • Construções como essa do trecho abaixo são complicadas. Não vejo isso nunca em programas de produção. Use malloc()/free() ou new()/delete para laocar memória do jeito oficial. Por alguma razão isso nunca chegou ao padrão da linguagem, certo?
    Só vejo isso em programas de estudantes. Fuja disso. 

    fscanf(arq1, "%d", &barras);
    fscanf(arq1, "%d", &ramos);
    fscanf(arq1, "%d", &subst);
    fscanf(arq1, "%f", &v_init_real);
    v_init_imag = 0.0;
    fscanf(arq1, "%f", &v_base);
    fscanf(arq1, "%f", &p_base);
    fscanf(arq1, "%f", &lim);

    //Solução corrente, cada solução vizinha por iteração, melhor solução encontrada na vizinhança
    struct Node N[ramos], N_aux[ramos], N_best[ramos], N_worst[ramos], N_top[ramos];

Para ficar bem claro, estou falando dessa construção:

	fscanf(arq1, "%d", &ramos);
	struct Node N[ramos];

Isso não existe na prática. Não está no padrão. Não se vê isso em programas de produção.
 

  • Em C Use malloc()/free() e fuja do realloc()
  • Em C++ use new()/delete/delete[]

 

Entenda também que toda a família scanf() retorna um int por um motivo e se acostume a testar isso, porque é melhor pra você. E não é má ideia também mostrar na saída de imediato todos os valores lidos. sancf() trabalha com ponteiros e se você errar em algo pode zoar seu programa inteiro e levar a comportamentos bizarros...

 

Mudei seu programa aqui

    if( argc < 2) return -1;
    op = atoi(argv[1]);
    switch(op)
    {
        case 1:
            printf("\n***** op 1 - Formato de Porcentagem.\n");
            break;

        case 2:
            printf("\n***** 2 - Formato Comumgem.\n");
            break;

        default:
                return -2; // so aceita 1 ou 2
    };  // switch()

//    while((op!=1)&&(op!=2)){
//        system("cls");
//        printf("\nEscolha a forma de tratamento para a Impedancia Base - Z_base.");
//        printf("\n1 - Formato de Porcentagem.");
//        printf("\n2 - Formato comum.");
//        printf("\n\nDigite sua opcao: ");
//        scanf("%d",&op);
//    }

Para que?

 

Troquei aquele while() chato para poder testar na linha de comando e gravar a saida. É muito chato ter que limpar a tela e mostrar um menu só para ler duas opções. Lembre do que te falei ontem e veja essa tela. E eu não posso ficar mostrando a tela pra ninguém...

 

Se seu programa for C14.exe você pode rodar

C14 1
ou 
C14 2

e ter o mesmo resultado...

 

Mas aí você pode rodar assim

 

1441568467_saidaex.png.b1da4eaf47815a99e716d151264e3095.png

 

como te expliquei, simples, na janela do terminal, e ter a saída gravada em out1.txt e out2.txt para as duas opções. E não perder tempo.

 

Eis o out1.txt por exemplo

Pressione qualquer tecla para continuar. . . 
Pressione qualquer tecla para continuar. . . 

***** op 1 - Formato de Porcentagem.

GRASP solucao 1.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

GRASP solucao 2.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

GRASP solucao 3.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

GRASP solucao 4.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

GRASP solucao 5.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

GRASP solucao 6.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

GRASP solucao 7.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

GRASP solucao 8.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

GRASP solucao 9.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

GRASP solucao 10.
Ramos fechados: (6) (7) (15) 
Media FC: 5086.876953

Tempo de execucao da Solução Inicial: 3 ms<14<4<2<1>><3<7>>><9<8<5>>><13<11<10>><12<6>>>>

Solucao Inicial !!!
Ramos Desligados:  (6)  (7)  (15) 
Perdas Ativas da Sol. Inicial: 466.126855
Perdas Reativas da Sol. Inicial: 544.899469
Media de fluxo de carga da solucao inicial: 5086.876803

Perdas Ativas antes de piorar a solucao: 466.126855
Perdas Reativas antes de piorar a solucao: 544.899469
Break: 1 --- Media de fluxo: 5086.876803

Ramos desligados:  (6)  (7)  (15) 

Piorando a solucao.
Break: 1 --- Pior Perda Ativa: 483.868923
Break: 1 --- Perda Reativa: 563.196931
Break: 1 --- Media de fluxo: 5043.224159

Ramos desligados:  (6)  (13)  (15) 

ENTROU NO BREAK em bt_cont = 3

Tempo de execucao da BT - Procedimento 1: 1 ms
Tempo de execucao da BT - Procedimento 2: 8 ms
Tempo de execucao da BT: 9 ms
Perdas Ativas da Sol. Final: 466.126855
Perdas Reativas da Sol. Final: 544.899469
Break: 3 --- Media de fluxo: 5086.876803
Ramos deligados:  (6)  (7)  (15) 

Partindo para PR!!!!!!
Total de solucoes geradas no PR_1: 0!

Tempo de execucao do PR: 1 ms
Tempo de execucao TOTAL: 3149 ms
Perdas Ativas da Sol. Final: 466.126855
Perdas Reativas da Sol. Final: 544.899469
Ramos Desligados:  (6)  (7)  (15) 

 

programas interativos são um porre, em especial em programas de cálculo. Não faz sentido ficar esperando um enter ou uma opção numa simulação que pode levar minutos ou horas ou dias.... Pense nisso.

 

Conclusão

 

Não sei o que dizer além disso. Em meu modesto computador de teste rodou. Os resultados para as opções 1 e 2 estão aqui para ver ou para baixar em sua máquina.

 

 

 

Link para o comentário
Compartilhar em outros sites

Crie uma conta ou entre para comentar

Você precisa ser um usuário para fazer um comentário

Criar uma conta

Crie uma nova conta em nossa comunidade. É fácil!

Crie uma nova conta

Entrar

Já tem uma conta? Faça o login.

Entrar agora

Sobre o Clube do Hardware

No ar desde 1996, o Clube do Hardware é uma das maiores, mais antigas e mais respeitadas comunidades sobre tecnologia do Brasil. Leia mais

Direitos autorais

Não permitimos a cópia ou reprodução do conteúdo do nosso site, fórum, newsletters e redes sociais, mesmo citando-se a fonte. Leia mais

×
×
  • Criar novo...

Ebook grátis: Aprenda a ler resistores e capacitores!

EBOOK GRÁTIS!

CLIQUE AQUI E BAIXE AGORA MESMO!