Re: [FUG-BR] RES: C/C++
Em Sáb, 2007-02-24 às 08:40 -0300, Anderson P. Matos - LINHARES ON LINE escreveu: Paulo, a função main nem sempre deve retorna um valor, somente se você quiser, quando a função começa com void, significa que não retorna valor nenhum, e ainda você falou que a função main DEVE retornar um valor inteiro, isso também esta errado, a função pode retornar um char, float, double, usigned float...e mais um monte... Att. Sei que to uns dias atrasados mas quero ser mais um a frisar que você está viajando na maionese, a função main **SEMPRE** retorna um valor inteiro, você pode até fazer ela void só que nesse caso quando seu programa terminar ele VAI SIM retornar um inteiro, o 0. Vai ser sempre sucesso, o que nem sempre é verdade dependendo do que o programa fará, se quiser andar mais na linha do correto, faça sempre ela int. []s Nilson - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
On Mon, 26 Feb 2007 09:14:09 -0300
Nilson Debatin [EMAIL PROTECTED] wrote:
Paulo, a função main nem sempre deve retorna um valor, somente se você
quiser, quando a função começa com void, significa que não retorna valor
nenhum, e ainda você falou que a função main DEVE retornar um valor
inteiro, isso também esta errado, a função pode retornar um char, float,
double, usigned float...e mais um monte...
Att.
Sei que to uns dias atrasados mas quero ser mais um a frisar
que você está viajando na maionese, a função main **SEMPRE**
retorna um valor inteiro, você pode até fazer ela void só
que nesse caso quando seu programa terminar ele VAI SIM
retornar um inteiro, o 0. Vai ser sempre sucesso, o que
nem sempre é verdade dependendo do que o programa fará, se
quiser andar mais na linha do correto, faça sempre ela int.
Pela semântica da linguagem void main() não retorna nada. Se retornasse
algo, o compilador estaria fazendo algo errado. E ainda assim, muito depende
da parceria entre compilador e o sistema operacional. Os padrões querem
que os programas em C funcionem (ou pelo menos compilem) independente do
sistema operacional e compilador. É difícil garantir isso na prática.
De volta ao main, ele retornará algo útil se o programador assim quiser, ou
então, durante a ligação do programa, o compilador decidirá pelo programador
o que será retornado. Se o programador não especificou nada, então será
retornado o que estiver ao alcance da mão.
Quem quiser ler adiante, apresento alguns fatos que podem ser interessantes
apenas para curiosos. Para os demais, basta saber que main é especial para a
fase de ligação do programa (momento de geração do executável), e espera-se
que ela retorne um inteiro para indicar o status de finalização do programa.
% cat main.c
void main() {}
% gcc main.c
main.c: In function `main':
main.c:1: warning: return type of 'main' is not `int'
% ./a.out
Exit 16
Claramente 16 não é zero. O que houve afinal?
% objdump -d a.out
...
0804848c main:
804848c: 55 push %ebp
804848d: 89 e5 mov%esp,%ebp
804848f: 83 ec 08sub$0x8,%esp
8048492: 83 e4 f0and$0xfff0,%esp
8048495: b8 00 00 00 00 mov$0x0,%eax # eax = 0
804849a: 83 c0 0fadd$0xf,%eax # eax = 0xf
804849d: 83 c0 0fadd$0xf,%eax # eax = 0x1e
80484a0: c1 e8 04shr$0x4,%eax # eax = 1
80484a3: c1 e0 04shl$0x4,%eax # eax = 16
80484a6: 29 c4 sub%eax,%esp # esp -= 16
80484a8: c9 leave
80484a9: c3 ret
80484aa: 90 nop
80484ab: 90 nop
...
Ainda assim, da onde veio esse 16? A última instrução executada antes do
programa finalizar foi a do endereço 0x08048326, sendo que a entrada nesse
trecho se deu pelo endereço 0x08048350:
Disassembly of section .plt:
08048320 .plt:
8048320: ff 35 34 96 04 08 pushl 0x8049634
8048326: ff 25 38 96 04 08 jmp*0x8049638
804832c: 00 00 add%al,(%eax)
804832e: 00 00 add%al,(%eax)
8048330: ff 25 3c 96 04 08 jmp*0x804963c
8048336: 68 00 00 00 00 push $0x0
804833b: e9 e0 ff ff ff jmp8048320 _init+0x14
8048340: ff 25 40 96 04 08 jmp*0x8049640
8048346: 68 08 00 00 00 push $0x8
804834b: e9 d0 ff ff ff jmp8048320 _init+0x14
8048350: ff 25 44 96 04 08 jmp*0x8049644
8048356: 68 10 00 00 00 push $0x10
804835b: e9 c0 ff ff ff jmp8048320 _init+0x14
O conteúdo dos registradores antes desta última chamada para biblioteca
externa era:
(gdb) info registers
eax0x10 16
ecx0x1 1
edx0x10 16
ebx0x1 1
esp0xbfbfe744 0xbfbfe744
ebp0xbfbfe778 0xbfbfe778
esi0xbfbfe788 -1077942392
edi0x2804e2a0 671408800
eip0x80483260x8048326
eflags 0x282642
cs 0x33 51
ss 0x3b 59
ds 0x3b 59
es 0x3b 59
fs 0x3b 59
gs 0x1b 27
Só que neste ponto, a função main já foi executada há muitas instruções
atrás, e não retornou nada pra ninguém. Mas o ligador não sabe disso, e azar
do programador, pois ele vai ligar a crt0.o de qualquer jeito. E na crt0.o
se assume que o topo da pilha (e registrador eax, em x86) contém o parâmetro
que será usado como valor de retorno.
Nesse exemplo, tanto a última coisa empilhada (8048356: push $0x10) quanto o
eax contêm 0x0010, ou 16 em base decimal. O byte menos significativo é
usado como valor de
[FUG-BR] RES: C/C++
Paulo, a função main nem sempre deve retorna um valor, somente se você
quiser, quando a função começa com void, significa que não retorna valor
nenhum, e ainda você falou que a função main DEVE retornar um valor
inteiro, isso também esta errado, a função pode retornar um char, float,
double, usigned float...e mais um monte...
Att.
Anderson P. Matos
Analista de Suporte
Linhares Serviços On-Line
Tel: (27) 2103-8100
E-mail: [EMAIL PROTECTED]
-
Tel.: (27) 2103-8105
Cel: (27) 9936-4186
E-mail: [EMAIL PROTECTED]
Messenger: [EMAIL PROTECTED]
Skype: andersonpmatos
-Mensagem original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
nome de Paulo Pires
Enviada em: sexta-feira, 23 de fevereiro de 2007 08:00
Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Assunto: Re: [FUG-BR] C/C++
On 2/21/07, Rodrigo Ferreira [EMAIL PROTECTED] wrote:
Bom dia lista, venho tentando a algum tempo compilar/rodar arquivos .c
e
.cpp, porem não obtive sucesso, antes de migrar para o FreeBSD eu
utilizava o turbo c++ no win, e agora no Free estou tentando usar o
gcc/g++, só que no programa mais simples que estou tentando fazer
aparece erro.
Programa teste:
#include /usr/include/stdio.h
#include /usr/include/conio.h
void main (void)
{
puts (Alo Mundo);
getch();
}
dai quando eu dou g++ teste.cpp, aparece esses erros:
teste.cpp:2:32: /usr/include/conio.h: No such file or directory
teste.cpp:5: error: `main' must return `int'
teste.cpp: In function `int main(...)':
teste.cpp:7: error: `getch' undeclared (first use this function)
teste.cpp:7: error: (Each undeclared identifier is reported only once
for each function it appears in.)
Um dos erros que eu ia apontar já foi apontado pelo compilador C++ (em
C não seria indicado como erro): a função main() deve retornar um
valor inteiro (int), de modo que tem que ser declarada como int
main() ou int main(int argc, char **argv) (ou ainda int main(int
argc, char *argv[])). A isso está ligado ou outro erro no seu
programa, mas que não está indicado acima: para sair da função que
retorna int, você tem obrigatoriamente que ter um comando return
valor;, onde valor é uma expressão com valor inteiro (geralmente --
especialmente no UNIX -- main() retorna 0 quando é bem sucedido), ou
uma chamada exit(valor);, onde valor também é inteiro.
Quando você está incluindo arquivos de cabeçalho da biblioteca padrão,
a convenção é usar '#include cabeçalho.h', ao invés de '#include
cabeçalho.h'. Esta última forma, usando aspas, é usada para
arquivos de cabeçalho criados pelo próprio programador, para
distingüi-los dos cabeçalhos padronizados. Também não é usual colocar
o caminho completo dos arquivos, especialmente quando se está usando
cabeçalhos da biblioteca padrão (com , e não com aspas, pois o
compilador sabe como encontrá-los).
Como outros já disseram, conio.h não é um cabeçalho padrão e a função
getch(), que seria declarada nesse cabeçalho específico dos
compiladores da Borland, também não é comumente aceita no UNIX (pelo
menos não com o mesmo sentido que teria no compilador da Borland).
Principalmente enquanto você está aprendendo, procure aprender a
linguagem padrão, ao invés de uma implementação específica.
Outra coisa: seu arquivo indica programa em C++, mas o código que você
escreveu é C. Não que esteja estritamente errado, mas a minha
recomendação pessoal é que se você vai usar apenas C em um módulo de
programa, use o compilador C (costuma ser mais rápido) e coloque nos
arquivos a extensão .c, ao invés de .cpp ou .cc. Ou, então,
aprenda logo C++ através de exemplos usando recursos próprios do C++,
se quiser usar os recursos que essa linguagem oferece antes de ficar
viciado em C puro e simples.
--
Um abraço.
Paulo A. P. Pires
... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Acho que ele estava se referindo ao padrão ANSI:
http://www.delorie.com/djgpp/v2faq/faq22_25.html
E todos nós escrevemos código que respeita os padrões, certo? :)
--
Diego Aranha
On Saturday 24 February 2007 11:40, Anderson P. Matos - LINHARES ON LINE
wrote:
Paulo, a função main nem sempre deve retorna um valor, somente se você
quiser, quando a função começa com void, significa que não retorna valor
nenhum, e ainda você falou que a função main DEVE retornar um valor
inteiro, isso também esta errado, a função pode retornar um char, float,
double, usigned float...e mais um monte...
Att.
Anderson P. Matos
Analista de Suporte
Linhares Serviços On-Line
Tel: (27) 2103-8100
E-mail: [EMAIL PROTECTED]
-
Tel.: (27) 2103-8105
Cel: (27) 9936-4186
E-mail: [EMAIL PROTECTED]
Messenger: [EMAIL PROTECTED]
Skype: andersonpmatos
-Mensagem original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
nome de Paulo Pires
Enviada em: sexta-feira, 23 de fevereiro de 2007 08:00
Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Assunto: Re: [FUG-BR] C/C++
On 2/21/07, Rodrigo Ferreira [EMAIL PROTECTED] wrote:
Bom dia lista, venho tentando a algum tempo compilar/rodar arquivos .c
e
.cpp, porem não obtive sucesso, antes de migrar para o FreeBSD eu
utilizava o turbo c++ no win, e agora no Free estou tentando usar o
gcc/g++, só que no programa mais simples que estou tentando fazer
aparece erro.
Programa teste:
#include /usr/include/stdio.h
#include /usr/include/conio.h
void main (void)
{
puts (Alo Mundo);
getch();
}
dai quando eu dou g++ teste.cpp, aparece esses erros:
teste.cpp:2:32: /usr/include/conio.h: No such file or directory
teste.cpp:5: error: `main' must return `int'
teste.cpp: In function `int main(...)':
teste.cpp:7: error: `getch' undeclared (first use this function)
teste.cpp:7: error: (Each undeclared identifier is reported only once
for each function it appears in.)
Um dos erros que eu ia apontar já foi apontado pelo compilador C++ (em
C não seria indicado como erro): a função main() deve retornar um
valor inteiro (int), de modo que tem que ser declarada como int
main() ou int main(int argc, char **argv) (ou ainda int main(int
argc, char *argv[])). A isso está ligado ou outro erro no seu
programa, mas que não está indicado acima: para sair da função que
retorna int, você tem obrigatoriamente que ter um comando return
valor;, onde valor é uma expressão com valor inteiro (geralmente --
especialmente no UNIX -- main() retorna 0 quando é bem sucedido), ou
uma chamada exit(valor);, onde valor também é inteiro.
Quando você está incluindo arquivos de cabeçalho da biblioteca padrão,
a convenção é usar '#include cabeçalho.h', ao invés de '#include
cabeçalho.h'. Esta última forma, usando aspas, é usada para
arquivos de cabeçalho criados pelo próprio programador, para
distingüi-los dos cabeçalhos padronizados. Também não é usual colocar
o caminho completo dos arquivos, especialmente quando se está usando
cabeçalhos da biblioteca padrão (com , e não com aspas, pois o
compilador sabe como encontrá-los).
Como outros já disseram, conio.h não é um cabeçalho padrão e a função
getch(), que seria declarada nesse cabeçalho específico dos
compiladores da Borland, também não é comumente aceita no UNIX (pelo
menos não com o mesmo sentido que teria no compilador da Borland).
Principalmente enquanto você está aprendendo, procure aprender a
linguagem padrão, ao invés de uma implementação específica.
Outra coisa: seu arquivo indica programa em C++, mas o código que você
escreveu é C. Não que esteja estritamente errado, mas a minha
recomendação pessoal é que se você vai usar apenas C em um módulo de
programa, use o compilador C (costuma ser mais rápido) e coloque nos
arquivos a extensão .c, ao invés de .cpp ou .cc. Ou, então,
aprenda logo C++ através de exemplos usando recursos próprios do C++,
se quiser usar os recursos que essa linguagem oferece antes de ficar
viciado em C puro e simples.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Bom, creio que ele deve estar se referindo ao padrão mais atual da linguagem, C99. O padrão ANSI já está meio obsoleto pelos padrões ISO C89 e C99. Teve um cara que liberou o C Completo e Total na rede um tempo atrás. Puxa, logo o livro do Herbert Schildt, o pior autor de todos os tempos. PS. A função main não retornar um valor é considerado um ERRO NÃO-FATAL. gethostbyname Diego Aranha escreveu: Acho que ele estava se referindo ao padrão ANSI: http://www.delorie.com/djgpp/v2faq/faq22_25.html E todos nós escrevemos código que respeita os padrões, certo? :) -- Diego Aranha On Saturday 24 February 2007 11:40, Anderson P. Matos - LINHARES ON LINE wrote: Paulo, a função main nem sempre deve retorna um valor, somente se você quiser, quando a função começa com void, significa que não retorna valor nenhum, e ainda você falou que a função main DEVE retornar um valor inteiro, isso também esta errado, a função pode retornar um char, float, double, usigned float...e mais um monte... Att. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
On Sat, 24 Feb 2007 08:40:25 -0300, Anderson P. Matos - LINHARES ON LINE wrote
Paulo, a função main nem sempre deve retorna um valor, somente se
você quiser, quando a função começa com void, significa que não
retorna valor nenhum, e ainda você falou que a função main DEVE
retornar um valor inteiro, isso também esta errado, a função pode
retornar um char, float, double, usigned float...e mais um monte...
Essa exigencia é da linguagem c++ faça esse exemplo e veja
que o erro persiste
#include stdio.h
void main (void);
void main (void)
{
printf (teste);
}
g++ -o teste teste.cpp
teste.cpp: In function `int main(...)':
teste.cpp:8: declaration of C function `int main(...)' conflicts with
teste.cpp:4: previous declaration `void main()' here
Att.
Anderson P. Matos
Analista de Suporte
Linhares Serviços On-Line
Tel: (27) 2103-8100
E-mail: [EMAIL PROTECTED]
-
Tel.: (27) 2103-8105
Cel: (27) 9936-4186
E-mail: [EMAIL PROTECTED]
Messenger: [EMAIL PROTECTED]
Skype: andersonpmatos
-Mensagem original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em
nome de Paulo Pires
Enviada em: sexta-feira, 23 de fevereiro de 2007 08:00
Para: Lista Brasileira de Discussão sobre FreeBSD (FUG-BR)
Assunto: Re: [FUG-BR] C/C++
On 2/21/07, Rodrigo Ferreira [EMAIL PROTECTED] wrote:
Bom dia lista, venho tentando a algum tempo compilar/rodar arquivos .c
e
.cpp, porem não obtive sucesso, antes de migrar para o FreeBSD eu
utilizava o turbo c++ no win, e agora no Free estou tentando usar o
gcc/g++, só que no programa mais simples que estou tentando fazer
aparece erro.
Programa teste:
#include /usr/include/stdio.h
#include /usr/include/conio.h
void main (void)
{
puts (Alo Mundo);
getch();
}
dai quando eu dou g++ teste.cpp, aparece esses erros:
teste.cpp:2:32: /usr/include/conio.h: No such file or directory
teste.cpp:5: error: `main' must return `int'
teste.cpp: In function `int main(...)':
teste.cpp:7: error: `getch' undeclared (first use this function)
teste.cpp:7: error: (Each undeclared identifier is reported only once
for each function it appears in.)
Um dos erros que eu ia apontar já foi apontado pelo compilador C++
(em C não seria indicado como erro): a função main() deve retornar
um valor inteiro (int), de modo que tem que ser declarada como int
main() ou int main(int argc, char **argv) (ou ainda int main(int
argc, char *argv[])). A isso está ligado ou outro erro no seu
programa, mas que não está indicado acima: para sair da função que
retorna int, você tem obrigatoriamente que ter um comando return
valor;, onde valor é uma expressão com valor inteiro (geralmente -
- especialmente no UNIX -- main() retorna 0 quando é bem sucedido),
ou uma chamada exit(valor);, onde valor também é inteiro.
Quando você está incluindo arquivos de cabeçalho da biblioteca
padrão, a convenção é usar '#include cabeçalho.h', ao invés de '#include
cabeçalho.h'. Esta última forma, usando aspas, é usada para
arquivos de cabeçalho criados pelo próprio programador, para
distingüi-los dos cabeçalhos padronizados. Também não é usual
colocar o caminho completo dos arquivos, especialmente quando se
está usando cabeçalhos da biblioteca padrão (com , e não com aspas,
pois o compilador sabe como encontrá-los).
Só um parentses nesse bapo, se me permite PAPiris...
o include com significa que o compilador irar procurar pelo arquivo
nos PATH padrão de pesquisa (INCLUDE) e com só irá pesquisar no
diretório atual
por exemplo:
#include stdio.h
ele irá procurar em /usr/include e /usr/X11R6/include. Essa procura
é feita adicionando o PATH ao nome do arquivo e o compilador tenta abri-lo
caso vc precise de arquivos system net ou outro qualquer
deve ser feito da forma:
#include sys/time.h
caso voce queira incluir ou modificar a pesquisa olhe as opções -I (include)
e -L (lib) do gcc
e veja também sobre variáveis de ambiente (INCLUDE/LIB/CC e outras)
Como outros já disseram, conio.h não é um cabeçalho padrão e a função
getch(), que seria declarada nesse cabeçalho específico dos
compiladores da Borland, também não é comumente aceita no UNIX (pelo
menos não com o mesmo sentido que teria no compilador da Borland).
Principalmente enquanto você está aprendendo, procure aprender a
linguagem padrão, ao invés de uma implementação específica.
Outra coisa: seu arquivo indica programa em C++, mas o código que
você escreveu é C. Não que esteja estritamente errado, mas a minha
recomendação pessoal é que se você vai usar apenas C em um módulo de
programa, use o compilador C (costuma ser mais rápido) e coloque nos
arquivos a extensão .c, ao invés de .cpp ou .cc. Ou, então,
aprenda logo C++ através de exemplos usando recursos próprios do C++,
se quiser usar os recursos que essa linguagem oferece antes de
ficar viciado em C puro e
Re: [FUG-BR] RES: C/C++
On 2/24/07, Anderson P. Matos - LINHARES ON LINE [EMAIL PROTECTED] wrote: Paulo, a função main nem sempre deve retorna um valor, somente se você quiser, quando a função começa com void, significa que não retorna valor nenhum, e ainda você falou que a função main DEVE retornar um valor inteiro, isso também esta errado, a função pode retornar um char, float, double, usigned float...e mais um monte... Obrigado pela lembrança. Eu já trabalhei com compilador C para outras arquiteturas e outros sistemas operacionais, e já fiz muito void main() -- mas nunca um double main() -- , mas vale o recado para que os outros saibam que em C é possível ter outros tipos de retorno para main() em determinadas situações. Entretanto, note que eu disse que era um erro em C++, que era a linguagem do programa original, e disse explicitamente que não seria indicado como erro em C. Note também que não estamos falando de CP/M-80 ou de alguma dispositivo embarcado usando microPIC, mas de UNIX, onde um comando return dentro de main(), mesmo em C, retorna ao sistema operacional um valor para ser informado como estado de saída do processo, e que esse valor de estado é um inteiro. -- Um abraço. Paulo A. P. Pires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
On 2/24/07, gethostbyname [EMAIL PROTECTED] wrote: Bom, creio que ele deve estar se referindo ao padrão mais atual da linguagem, C99. O padrão ANSI já está meio obsoleto pelos padrões ISO C89 e C99. Você está fazendo alguma confusão. C89 é ANSI, cujo correspondente ISO (praticamente idêntico, apenas recredenciado) é o C90. Teve um cara que liberou o C Completo e Total na rede um tempo atrás. Puxa, logo o livro do Herbert Schildt, o pior autor de todos os tempos. Não sei se é *o* pior, mas é um cara que claramente escreve sobre o que ele acha que vai lhe render uns trocados. É provável que o compromisso dele seja mais com fazer dinheiro rapidamente do que com a qualidade do que escreve. Nessa linha, o mais lamentável é quando, ao invés de ensinar a linguagem de programação a que se propõe na capa, ele começa a fazer apologia de determinadas tecnologias e de certos fabricantes de software (sobretudo do estado de Washington), talvez a fim de dar impulso a outros de seus livros. PS. A função main não retornar um valor é considerado um ERRO NÃO-FATAL. Eu freqüentemente compilo com -Werror -Wall; existem motivos para que o compilador emita warinings, ou eles não estariam lá. Um exemplo que volta e meia acontece comigo é usar = em lugar de ==; às vezes é intencional e às vezes por distração ou erro de digitação, mas um warning é bem-vindo nos dois casos. Todos sabemos fazer e às vezes somos forçados a fazer bacalhaus no código, mas também sabemos como usar a linguagem para, de forma sintaticamente correta e estilisticamente mais produtiva (no sentido de dar clareza que facilite a manutenção de código no futuro), fazer calar qualquer warning, mesmo quando se usa -pedantic. -- Um abraço. Paulo A. P. Pires ... Qui habet aurem audiat quid Spiritus dicat ecclesiis. - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Essa exigência não é apenas da linguagem C++:
*ISO/IEC 9899:1999 (E)©ISO/IEC*
*5.1.2.2.1 Program startup*
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined **with a
return type of int** and with no parameters:
*int *main(void) { /*...*/ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
*int *main(int argc, char *argv[]) { /*...*/ }
or equivalent [ver a Nota]; or in some other implementation-defined manner.
*Nota*:
Thus, int can be replaced by a typedef name defined as int,or the type
of argv can be written as char ** argv, and so on.
gethostbyname
Nilton Jose Rizzo escreveu:
Essa exigencia é da linguagem c++ faça esse exemplo e veja
que o erro persiste
#include stdio.h
void main (void);
void main (void)
{
printf (teste);
}
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Paulo Pires escreveu: Você está fazendo alguma confusão. C89 é ANSI, cujo correspondente ISO (praticamente idêntico, apenas recredenciado) é o C90. Exatamente. Foi um equívoco: C90[ISO - o padrão ANSI com pequenas modificações] por C89 [ANSI]. Teve um cara que liberou o C Completo e Total na rede um tempo atrás. Puxa, logo o livro do Herbert Schildt, o pior autor de todos os tempos. Não sei se é *o* pior, mas é um cara que claramente escreve sobre o que ele acha que vai lhe render uns trocados. É provável que o compromisso dele seja mais com fazer dinheiro rapidamente do que com a qualidade do que escreve. Nessa linha, o mais lamentável é quando, ao invés de ensinar a linguagem de programação a que se propõe na capa, ele começa a fazer apologia de determinadas tecnologias e de certos fabricantes de software (sobretudo do estado de Washington), talvez a fim de dar impulso a outros de seus livros. Acho que o pior é um livro de C++ dele cuja boa parte é uma introdução a C, que por sua vez é a cópia de alguns capítulos do C Completo e Total. PS. A função main não retornar um valor é considerado um ERRO NÃO-FATAL. Eu freqüentemente compilo com -Werror -Wall; existem motivos para que o compilador emita warinings, ou eles não estariam lá. Um exemplo que volta e meia acontece comigo é usar = em lugar de ==; às vezes é intencional e às vezes por distração ou erro de digitação, mas um warning é bem-vindo nos dois casos. Todos sabemos fazer e às vezes somos forçados a fazer bacalhaus no código, mas também sabemos como usar a linguagem para, de forma sintaticamente correta e estilisticamente mais produtiva (no sentido de dar clareza que facilite a manutenção de código no futuro), fazer calar qualquer warning, mesmo quando se usa -pedantic. Mudando de assunto, vocês usando quais ferramentas para programação? Emacs? falou, gethostbyname - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Essa exigência não é apenas da linguagem C++:
*ISO/IEC 9899:1999 (E)©ISO/IEC*
*5.1.2.2.1 Program startup*
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined **with a
return type of int** and with no parameters:
*int *main(void) { /*...*/ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
*int *main(int argc, char *argv[]) { /*...*/ }
or equivalent; or in some other implementation-defined manner.
*Nota*:
Thus, int can be replaced by a typedef name defined as int,or the type
of argv can be written as char ** argv, and so on.
gethostbyname
Nilton Jose Rizzo escreveu:
Essa exigencia é da linguagem c++ faça esse exemplo e veja
que o erro persiste
#include stdio.h
void main (void);
void main (void)
{
printf (teste);
}
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Paulo Pires escreveu: Você está fazendo alguma confusão. C89 é ANSI, cujo correspondente ISO (praticamente idêntico, apenas recredenciado) é o C90. Exatamente. Foi um equívoco: C90[ISO - o padrão ANSI com pequenas modificações] por C89 [ANSI]. Teve um cara que liberou o C Completo e Total na rede um tempo atrás. Puxa, logo o livro do Herbert Schildt, o pior autor de todos os tempos. Não sei se é *o* pior, mas é um cara que claramente escreve sobre o que ele acha que vai lhe render uns trocados. É provável que o compromisso dele seja mais com fazer dinheiro rapidamente do que com a qualidade do que escreve. Nessa linha, o mais lamentável é quando, ao invés de ensinar a linguagem de programação a que se propõe na capa, ele começa a fazer apologia de determinadas tecnologias e de certos fabricantes de software (sobretudo do estado de Washington), talvez a fim de dar impulso a outros de seus livros. Acho que o pior é um livro de C++ dele cuja boa parte é uma introdução a C, que por sua vez é a cópia de alguns capítulos do C Completo e Total. PS. A função main não retornar um valor é considerado um ERRO NÃO-FATAL. Eu freqüentemente compilo com -Werror -Wall; existem motivos para que o compilador emita warinings, ou eles não estariam lá. Um exemplo que volta e meia acontece comigo é usar = em lugar de ==; às vezes é intencional e às vezes por distração ou erro de digitação, mas um warning é bem-vindo nos dois casos. Todos sabemos fazer e às vezes somos forçados a fazer bacalhaus no código, mas também sabemos como usar a linguagem para, de forma sintaticamente correta e estilisticamente mais produtiva (no sentido de dar clareza que facilite a manutenção de código no futuro), fazer calar qualquer warning, mesmo quando se usa -pedantic. Mudando de assunto, vocês usando quais ferramentas para programação? Emacs? falou, gethostbyname - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
On 2/25/07, gethostbyname [EMAIL PROTECTED] wrote:
Essa exigência não é apenas da linguagem C++:
*ISO/IEC 9899:1999 (E)(c)ISO/IEC*
*5.1.2.2.1 Program startup*
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined **with a
return type of int** and with no parameters:
*int *main(void) { /*...*/ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
*int *main(int argc, char *argv[]) { /*...*/ }
or equivalent [ver a Nota]; or in some other implementation-defined manner.
*Nota*:
Thus, int can be replaced by a typedef name defined as int,or the type
of argv can be written as char ** argv, and so on.
Eu não se se foi coisa da lista, mas aqui apareceu um monte de
asteriscos (acho que você que usou negritos), fazendo parecer
ponteiros; eu achei um PDF do padrão através do Google (talvez o mesmo
que você achou, em
http://www.nirvani.net.nyud.net:8090/docs/ansi_c.pdf), onde vi que
eu não estava louco com um bando de ponteiros. :)
Mas veja o ponto-e-vírgula antes de or some other
implementation-defined manner. Visualmente, acho que outra arrumação
poderia aumentar mais a clareza, mas o que entendo é que uma
implementação hosted (isto é, aquela que executa em um sistema
operacional) pode optar entre retornar int _ou_ alguma outra maneira
definida pela implementação. Se optar por int, então deve aceitar
int main(void){/*...*/} *e* int main(int argc, char *argv[]){/*...*/}.
Mas que o fraseamento e a composição visual não ajudam na clareza,
não ajudam mesmo.
--
Um abraço.
Paulo A. P. Pires
... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Depende do tamanho do projeto. Se for pequeno, uso o vi/vim mesmo. Se não for, gosto do Eclipse (o que eu realmente gosto nele é aquele Navigator do lado esquerdo da janela). :) -- Diego Aranha Mudando de assunto, vocês usando quais ferramentas para programação? Emacs? falou, gethostbyname - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
On 2/25/07, gethostbyname [EMAIL PROTECTED] wrote:
Mudando de assunto, vocês usando quais ferramentas para programação? Emacs?
Não. Eu sempre usei o vi que vinha com o BSD (nvi) e compilava tudo
na linha de comando mesmo. Como eu comecei com Turbo C, acostumei-me
a usar syntax-highlighting, e passei a usar vim, para ter esse
recurso. Nunca usei e-macs além de uns poucos testes, há mais de dez
anos.
Já tentei IDEs para UNIX. Achei todos pesados e pouco producentes, e
voltei à combinação emulador de terminal (ou
console)+shell+{,n}vi{,m}+gcc/g++/make/rcs. Mas, é claro, eu não faço
sistemas de grande porte, que justificariam um ambiente mais cheio de
gueriguéris.
--
Um abraço.
Paulo A. P. Pires
... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Paulo Pires escreveu:
Eu não se se foi coisa da lista, mas aqui apareceu um monte de
asteriscos (acho que você que usou negritos), fazendo parecer
ponteiros; eu achei um PDF do padrão através do Google (talvez o mesmo
que você achou, em
http://www.nirvani.net.nyud.net:8090/docs/ansi_c.pdf), onde vi que
eu não estava louco com um bando de ponteiros. :)
Mas veja o ponto-e-vírgula antes de or some other
implementation-defined manner. Visualmente, acho que outra arrumação
poderia aumentar mais a clareza, mas o que entendo é que uma
implementação hosted (isto é, aquela que executa em um sistema
operacional) pode optar entre retornar int _ou_ alguma outra maneira
definida pela implementação. Se optar por int, então deve aceitar
int main(void){/*...*/} *e* int main(int argc, char *argv[]){/*...*/}.
Mas que o fraseamento e a composição visual não ajudam na clareza,
não ajudam mesmo.
Foi mal pessoal. Estava alterando as configurações aqui.
Acho que eu dupliquei duas mensagens e fazendo essa lambança também :-)
Bom, não entendi muito bem sobre o que você quis dizer com a questão da
composição visual e da outra arrumação.
Os compiladores podem até aceitar outros retornos de main além de int,
mas isso não é portável. Essa é a minha concepção.
Estive pesquisando sobre o assunto agora e veja que engraçado:
FYI, the first Google Usenet msg use of '*void main*' was in 1984:
http://groups.google.com/group/net.lang.c/msg/644f6489bb23c5ab?hl=en
gethostbyname
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Em Domingo 25 Fevereiro 2007 00:58, gethostbyname escreveu: Mudando de assunto, vocês usando quais ferramentas para programação? Emacs? falou, gethostbyname - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd Eu costumava usar o Jed, muito bom mesmo. Hj em dia prefiro usar ferramentas gráficas como o KDevelop, que também é muito bom, o que realmente ajuda é o word-completation, que evita muitos erros de digitação no código. Mas se precisar editar um código em modo texto eu vou pelo VI mesmo que já estou acostumado a usa-lo para a maioria das coisas. -- THIAGO DE SOUZA COSTA e-mail: [EMAIL PROTECTED] jid: [EMAIL PROTECTED] fotolog: http://fotolog.com/thiagodk - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Thiago Costa escreveu: Eu costumava usar o Jed, muito bom mesmo. Hj em dia prefiro usar ferramentas gráficas como o KDevelop, que também é muito bom, o que realmente ajuda é o word-completation, que evita muitos erros de digitação no código. Mas se precisar editar um código em modo texto eu vou pelo VI mesmo que já estou acostumado a usa-lo para a maioria das coisas. Estou ansioso para ver o Anjuta 2.x estável. Eu tentei usar a versão instável 2.0.2: demorei um tempo grande para compilar no FreeBSD, não deu para usar porque realmente era muito instável, mas deu para perceber que esse Anjuta 2.x vai ficar bonito. Nunca me animei a usar o KDevelop. A disposição das ferramentas é muito desorganizada e nas versões que experimentei, ele tentava forçar um Qtzinho na gente. gethostbyname - Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
On 2/25/07, gethostbyname [EMAIL PROTECTED] wrote:
Foi mal pessoal. Estava alterando as configurações aqui.
Acho que eu dupliquei duas mensagens e fazendo essa lambança também :-)
Bom, não entendi muito bem sobre o que você quis dizer com a questão da
composição visual e da outra arrumação.
Apenas que a composição do texto na norma, tanto na construção da
frase como na apresentação visual, torna difícil a interpretação do
que quer dizer.
Os compiladores podem até aceitar outros retornos de main além de int,
mas isso não é portável. Essa é a minha concepção.
Até concordo com você, mas é porque nós estamos acostumados com
máquinas e sistemas que trabalham com números. Não precisaria ser o
caso. Eu não se um CP/M da vida tinha alguma coisa como exit status
de um programa, nem tenho muita dificuldade em imaginar um sistema em
que um processo retornasse, ao invés de um mero valor, algo que
pudesse ser interpretado como um comando/ação ou um objeto mais
complexo.
Estive pesquisando sobre o assunto agora e veja que engraçado:
FYI, the first Google Usenet msg use of '*void main*' was in 1984:
http://groups.google.com/group/net.lang.c/msg/644f6489bb23c5ab?hl=en
Assutador... Se o PCC (Portable C Compiler, que se destinava a
encontrar potenciais problemas de portabilidade e encorajar um uso
elegante e pouco sujeito a problemas da linguagem, e serviu de base
para ferramentas como lint(1)) aceitava coisas como
struct A { int a, b, c; };
void f(struct A x){
printf(%d %d %d\n, x);
}
tenho até medo das outras coisas de que o carinha reclamava não
conseguir fazer. Por mais que eu entenda que ainda não houvesse
padrão naquela época, acho o código acima perigosamente
implementation-dependent para o PCC deixar passar sem abrir o bico.
--
Um abraço.
Paulo A. P. Pires
... Qui habet aurem audiat quid Spiritus dicat ecclesiis.
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
Re: [FUG-BR] RES: C/C++
Paulo Pires escreveu:
On 2/25/07, gethostbyname [EMAIL PROTECTED] wrote:
Foi mal pessoal. Estava alterando as configurações aqui.
Acho que eu dupliquei duas mensagens e fazendo essa lambança também :-)
Bom, não entendi muito bem sobre o que você quis dizer com a questão da
composição visual e da outra arrumação.
Apenas que a composição do texto na norma, tanto na construção da
frase como na apresentação visual, torna difícil a interpretação do
que quer dizer.
Compreendi. Foi um erro meu ter misturado o negrito no meio do código,
além de ter duplicado a mensagem.
Os compiladores podem até aceitar outros retornos de main além de int,
mas isso não é portável. Essa é a minha concepção.
Até concordo com você, mas é porque nós estamos acostumados com
máquinas e sistemas que trabalham com números. Não precisaria ser o
caso. Eu não se um CP/M da vida tinha alguma coisa como exit status
de um programa, nem tenho muita dificuldade em imaginar um sistema em
que um processo retornasse, ao invés de um mero valor, algo que
pudesse ser interpretado como um comando/ação ou um objeto mais
complexo.
Esse objeto mais complexo ou comando poderia ser enviado ao OS por
outros modos, não? Chamar system, por exemplo. Seria mais prático e
simples, não? Imagine a main retornando algo que não seja o número, que
complicação isso geraria.
Estive pesquisando sobre o assunto agora e veja que engraçado:
FYI, the first Google Usenet msg use of '*void main*' was in 1984:
http://groups.google.com/group/net.lang.c/msg/644f6489bb23c5ab?hl=en
Assutador... Se o PCC (Portable C Compiler, que se destinava a
encontrar potenciais problemas de portabilidade e encorajar um uso
elegante e pouco sujeito a problemas da linguagem, e serviu de base
para ferramentas como lint(1)) aceitava coisas como
struct A { int a, b, c; };
void f(struct A x){
printf(%d %d %d\n, x);
}
tenho até medo das outras coisas de que o carinha reclamava não
conseguir fazer. Por mais que eu entenda que ainda não houvesse
padrão naquela época, acho o código acima perigosamente
implementation-dependent para o PCC deixar passar sem abrir o bico.
hehehehe. Isso era em 1984!
gethostbyname
-
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
