Adicionando bibliotecas no code blocks.

viana3
(usa openSUSE)

Enviado em 21/07/2013 - 08:53h

Olá pessoal.
Algumas programas em C que tento compilar no code blocks, requerem algumas bibliotecas para rodarem, por exemplo conio.h ou iostream.h. Alguém saberia me orientar em como incluir estas e outras bibliotecas no code blocks?

DarkLinnux
(usa openSUSE)

Enviado em 05/11/2014 - 23:36h

baixa o código fonte da internet e coloca no diretório usr/include

http://www.rogercom.com/pparalela/ControlLinux.htm

Thihup
(usa Manjaro Linux)

Enviado em 06/11/2014 - 09:51h

Bom , conio.h só windows e iostream é do c++ (e é sem o '.h')

ESpero ter ajudado

[]'s

T+

paulo1205
(usa Ubuntu)

Enviado em 06/11/2014 - 12:59h

Arquivos com sufixo “.h” não são exatamente bibliotecas, mas apenas cabeçalhos que contêm somente as definições daquilo que as bibliotecas propriamente ditas, que geralmente ficam em arquivos com sufixos “.o”, “.a” ou “.so” (ou, no Windows, “.obj”, “.lib” ou “.dll”), efetivamente implementam.

A inclusão dos cabeçalhos <conio.h> e <iostream.h> indica que você está trabalhando com código muito antigo.

Com a padronização do C++ em 1998 (olha aí: 16 anos, já), ficou decidido que os cabeçalhos do C++ não teriam mais o sufixo “.h” nem qualquer outro. Assim se decidiu para não confundir com cabeçalhos de mesmo nome da linguagem C, que já os adotava tradicionalmente (um caso real de conflito que foi evitado é o <string> do C++, que de outra forma poderia confundir-se diretamente com o <string.h> do C, cujo conteúdo é completamente diferente).

A maneira de você corrigir esses programas velhos (isto é: de antes do padrão de 1998) em C++ começa por retirar o sufixo “.h” dos nomes usados na inclusão dos cabeçalhos. Mas há um pouco mais a fazer do que apenas isso: o padrão de 1998 criou o conceito de namespaces, para diminuir a possibilidade de conflito de funções com mesmo nome em bibliotecas diferentes que pudessem ser usadas no mesmo programa. Todas as bibliotecas definidas no padrão, inclusive aquelas que tem definições em <iostream>, colocam seus símbolos no namespace chamado std. No entanto, um programa que não diga coisa alguma sobre namespaces, fica num namespace global sem nome, e só enxerga inicialmente símbolos desse namespace global. Para enxergar o que está declarado no namespace std, você precisa ser explícito ao se referir a cada símbolo, ou importar todos os símbolos do namespace desejado para dentro do global.

Assim sendo, o seguinte programa exemplo de código anterior à padronização

#include <iostream.h>



int main(void){

  cout << "Hello, World!\n";

  return 0;

} 

poderia ser corrigido para ficar conforme o padrão usando uma das seguintes opções.

#include <iostream>   // Sem sufixo



int main(){   // Sem o void na lista de argumentos

  std::cout << "Hello, World!\n";   // Colocando o namespace antes de cada símbolo

}   // “return 0;” implícito ao final da função main() (e só de main()!). 

#include <iostream>



using namespace std;   // Importa todos os símbolos de std



int main(){

  cout << "Hello, World!\n";   // cout foi importado, dispensa designação explícita

} 

#include <iostream>



using std::cout;   // Importa apenas std::cout



int main(){

  cout << "Hello, World!\n";   // cout (e apenas ele) foi importado

} 

A referência a <conio.h> também é um anacronismo. Ela servia para trazer definições de funções de uma biblioteca usada principalmente nos compiladores da Borland para MS-DOS (olha a velharia aí) para entrada e saída diretamente no console do PC monousuário e monoprogramado. Em muitos programas listados em apostilas de décadas passadas (mas que ainda assombram a Internet), muitas vezes o uso de funções da ConIO é só para limpar a tela (clrsrc()) no início do programa e para ter uma pausa ao final (getch() sem atribuir para variável nenhuma o valor retornado pela função). Se os programas que você tem em mãos só fazem isso, simplesmente remova tais funções; elas não agregam valor algum ao programa.

Se for muito mais do que isso, há mais de uma abordagem.

A primeira, que eu recomendo evitar, é arranjar algum “clone” da ConIO para o seu compilador/sistema operacional. O problema com essa abordagem é que provavelmente nunca haverá um clone perfeito, porque mesmo os vários compiladores para MS-DOS diferiam entre si a respeito de quais funções eram implementadas e de como elas se comportavam. A implementação da Borland era a mais usada porque o Turbo C ou Turbo C++ eram relativamente comuns porque eram baratos (ou, no caso brasileiro, ostensivamente pirateados), mas mesmo que um clone para Linux ou Windows da ConIO simule perfeitamente a ConIO da Borland, pode ser que você encontre código que tenha sido escrito para outra implementação.

A segunda abordagem é adequar o código ao que o seu sistema operacional oferece. É Windows? Então utilize as funções de console oferecidas nativamente pelo Windows. É UNIX/Linux? utilize curses/ncurses. Vai dar algum trabalho, mas você não vai inflar o programa com uma biblioteca que, no fim das contas, vai apenas funcionar como máscara sobre a interface nativa, apresentando-a com cara de ConIO e possivelmente reduzindo sua funcionalidade, em vez de estendê-la. Você também evita, com isso, eventuais inconvenientes de ter de empacotar mais uma biblioteca externa junto com o seu programa. O problema, no entanto, é que se você tiver um programa que deveria rodar em mais de um SO com interfaces nativas diferentes, vai ter dificuldades.

Uma terceira opção é usar uma biblioteca mais moderna e completa que a ConIO e que esteja disponível em qualquer ambiente. A Curses é um caso assim. Ela é nativa no mundo UNIX e possui implementações para Windows (por exemplo, a PDCurses, ou código compilado com Cygwin). É uma abordagem parecida com o uso de ConIO, principalmente do ponto de vista de quem usa Windows, mas tem uma vantagem: existe um padrão bem definido de funcionalidade mínima da Curses, coisa que nunca existiu com ConIO.

A quarta opção é uma modernização profunda. Se o programa puder se beneficiar do uso de interface gráfica ou interface web, considere-as. A portabilidade entre sistemas operacionais diferentes é possível com bibliotecas multiplataforma, como Qt, FLTK, Gtk, wxWidgets ou outras. O programa pode aumentar significativamente de tamanho, mas se houver algum ganho de usabilidade, pode ser que você entenda que compensa.