paulo1205
(usa Ubuntu)
Enviado em 01/06/2018 - 15:03h
washingtonBCS escreveu:
Muito obrigado por responder!
Vou melhorar! Sobre as chamadas system eu não sei como fazer sem, acho que não existe comando nativo para limpar a tela.
O C e o C++ são intencionalmente definidas para um computador genérico, que não necessariamente possui um dispositivo específico, tal como a tela. Desse modo, realmente não existe um comando para limpá-la. E as bibliotecas padronizadas das duas linguagens seguem mais ou menos na mesma linha, mesmo quando falam em entidades como arquivos ou em invocar o sistema (este último é o caso de
system()), fazem-no sem se remeter a dispositivos específicos (tais como disco, fita ou rede, por exemplo) ou detalhes de implementação (tais como limitações sobre os nomes de arquivos, como eles dispostos em disco, ou quais são os comandos externos que podem ser invocados e como isso se fará).
E, de fato, quando você aborda computadores específicos, como os nossos PCs, mesmo um tipo específico de dispositivo pode ser tratado de modo distinto por diferentes sistemas. Você e eu temos na nossa frente uma tela, mas você, com Windows, procede de um jeito diferente para mandá-lo limpar a tela do que eu tenho de proceder ao usar Linux. E não apenas o comando passado à função
system() é diferente (no Windows, é
CLS, no Linux, é
clear), mas os passos que o comando toma internamente são diferentes.
Mas chamar comandos externos é especialmente ruim porque tal operação é geralmente lenta e insegura. Lenta porque, tanto no Windows como no Linux, ela envolve criar um processo novo, invocar um programa separado nesse processo novo para interpretar o comando (no Windows, é o
CMD.EXE, no DOS, é o
COMMAND.COM, no POSIX, que inclui vários UNIXes e o Linux, é o
/bin/sh), nos custos da execução do comando, depois de interpretado (que podem, inclusive, implicar criar novos processos e invocar outros programas externos), e depois tratar os término da execução dos programas externos e subprocessos. E insegura porque frequentemente dependem de entidades que não estão sobre controle total do seu programa, tais como o tipo e a versão do sistema operacional, variáveis de ambiente, e a própria presença e disponibilidade dos comandos que terão de ser executados.
Se você precisa mesmo de funções particulares, que excedem aquilo que o computador genérico da linguagem nativa ou de sua biblioteca padrão é poderia fazer, é melhor, na medida do possível, trazer para dentro do seu programa o que quer que você quisesse inicialmente fazer através de um programa externo, por meio de uma invocação a
system(). Fazendo isso, você eliminará alguns riscos de desempenho e de segurança mencionados acima, e poderá ficar um pouco menos dependente de condições externas.
Ao fazer isso, você pode ainda escolher entre abordagens mais particulares, que funcionem na sua máquina e em máquinas mais ou menos semelhantes à sua, ou mais genéricas, que podem funcionar em máquinas mais distintas. Por exemplo, você poderia usar funções da Win32 API para manipulação de console do Windows, que lhe permitem limpar a tela, manipular cores do texto e atributos de ambiente do console. Alternativamente, você poderia instalar e usar uma biblioteca de compatibilidade que coloca uma camada fina antes das funções nativas da Win32 API, permitindo usar funções com a mesma forma daquelas disponíveis outros sistemas operacionais, permitindo que seu programa funcione em outras plataformas. Um exemplo de biblioteca assim é a PDCurses, que é compatível com a biblioteca Curses, que é amplamente utilizada em sistemas POSIX, e outro é a ConIO/ConIO2, que é compatível com a ConIO disponível em compiladores do velho MS-DOS.
Análogos do que vai acima poderia ser feito no mundo UNIX/Linux: dá para embutir comandos de terminal no meio das
strings para eles enviadas, mas também dá para subir um pouquinho de nível e mandar comandos que levem em consideração tipos de terminais diferentes (biblioteca Termcap/Terminfo). Subindo mais um pouco de nível, pode-se usar a biblioteca Curses, que oferece recursos de mais alto nível, tais como molduras, menus, painéis etc.
No que diz respeito às diferentes interfaces nativas, a Win32 API me parece de muito mais baixo nível que as APIs do POSIX (mesmo em nível de Termcap/Terminfo — veja, por exemplo, o código que está na postagem número 12 do seguinte tópico:
https://www.vivaolinux.com.br/topico/C-C++/Preciso-fazer-um-programa-em-C-para-cadastra-alunos-consu...). Por esse motivo, eu entendo que você ganharia produtividade (a um custo de desempenho que me parece muito pequeno) colocando uma versão de Curses (que inclui Termcap/Terminfo) no Windows do que eventualmente tentando colocar um clone da parte de console da Win32 API no Linux. Quanto a clonar a ConIO no Linux, acho que não vale o esforço, porque a mesmo a Termcap/Terminfo é muito mais rica.
