Re: [FUG-BR] OT: Re: RES: C/C++
Paulo Pires escreveu:
On 2/25/07, gethostbyname [EMAIL PROTECTED] wrote:
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.
Não falo nem do negrito. O próprio PDF da norma é confuso.
Ah, sim.
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.
system() não devolve algo ao SO, mas requisita algo dele (se pensarmos
no UNIX, system(3) é uma composição de fork(2), execve(2) e
waitpid(2)/wait4(2)).
Eu pensei nisso porque você disse algo que pudesse ser interpretado
como um comando/ação.
Deixe-me dar um exemplo do que eu quis falar. Digamos que você fez um
programa chamado -- digamos -- beethoven, que utiliza alguma técnica
que você vai patentear para gerar uma sinfonia completa a partir de
uma seqüência incial de bits. Se esse programa existisse hoje num
sistema operacional corrente, o resultado ou seria gravado em arquivo
ou seria enviado a um outro processo através de um pipe ou socket,
como parte da própria execução do programa, e, somente após essa etapa
final de manualmente depositar a sinfonia em algum canto, o programa
devolveria 0 se fosse bem sucedido ou outro valor se falhasse. Se, ao
invés disso, você tivesse um SO que permitisse devolver um objeto
sinfonia ao término do programa, você não precisaria se preocupar com
manualmente gravar ou serializar sua sinfonia. Esse peso ficaria
com o sistema.
Claro que um SO assim teria que saber o que fazer com o objeto que
você lhe envia. Certamente seria um sistema mais complexo, mas não
sei se já não caminhamos para uma coisa assim, ainda mais nesses dias
de rede para todo mundo e processamento cada vez mais distribuído.
MIME types são uma abordagem já em uso para identificação de objetos
arbitrários, assim como são as extensões de arquivo ou as assinaturas
de arquivos executáveis (incluindo aquela linha começando com #! no
topo dos nossos scripts em shell, PERL, AWK etc.).
Compare as duas versões do programa acima mencionado (em C++).
// beethoven.cc -- SO de hoje
// stdout deve ser redirecionado para
// arquivo ou pipe.
#include iostream
#include beethoven.h
int main(int argc, char **argv){
try {
symphony S(argc, argv);
std::cout S;
}
catch(...){
return 1;
}
return 0;
}
// beethoven.cc -- SO viajante
#include beethoven.h
symphony main(argc, argv){
return symphony(argc, argv);
}
Você gostaria de mais ou menos um SO orientado a objetos que não
seguisse padrões rigorosos? Algo dinâmico como a API de JAVA, diferente
de C++?
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] OT: Re: RES: C/C++
Você gostaria de mais ou menos um SO orientado a objetos que não seguisse padrões rigorosos? Algo dinâmico como a API de JAVA, diferente de C++? Não sei se eu gostaria, mas, como disse, consigo vislumbrar algo para o qual um processo, ao terminar, possa devolver mais do que um simples valor 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
[FUG-BR] OT: Re: RES: C/C++
Só maluco responde a sua própria mensagem?
On 2/25/07, Paulo Pires [EMAIL PROTECTED] wrote:
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.
Por outro lado, exigir de um PCC de 1984 cuidar de abrir uma função
declarada com argumento ..., só porque essa função era printf(),
talvez seja um anacronismo meu. O erro não é do PCC, mas do cara que
assume que a forma de colocar os campos dentro de um struct vai ser
universalmente uniforme.
--
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
[FUG-BR] OT: Re: RES: C/C++
On 2/25/07, gethostbyname [EMAIL PROTECTED] wrote:
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.
Não falo nem do negrito. O próprio PDF da norma é confuso.
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.
system() não devolve algo ao SO, mas requisita algo dele (se pensarmos
no UNIX, system(3) é uma composição de fork(2), execve(2) e
waitpid(2)/wait4(2)).
Deixe-me dar um exemplo do que eu quis falar. Digamos que você fez um
programa chamado -- digamos -- beethoven, que utiliza alguma técnica
que você vai patentear para gerar uma sinfonia completa a partir de
uma seqüência incial de bits. Se esse programa existisse hoje num
sistema operacional corrente, o resultado ou seria gravado em arquivo
ou seria enviado a um outro processo através de um pipe ou socket,
como parte da própria execução do programa, e, somente após essa etapa
final de manualmente depositar a sinfonia em algum canto, o programa
devolveria 0 se fosse bem sucedido ou outro valor se falhasse. Se, ao
invés disso, você tivesse um SO que permitisse devolver um objeto
sinfonia ao término do programa, você não precisaria se preocupar com
manualmente gravar ou serializar sua sinfonia. Esse peso ficaria
com o sistema.
Claro que um SO assim teria que saber o que fazer com o objeto que
você lhe envia. Certamente seria um sistema mais complexo, mas não
sei se já não caminhamos para uma coisa assim, ainda mais nesses dias
de rede para todo mundo e processamento cada vez mais distribuído.
MIME types são uma abordagem já em uso para identificação de objetos
arbitrários, assim como são as extensões de arquivo ou as assinaturas
de arquivos executáveis (incluindo aquela linha começando com #! no
topo dos nossos scripts em shell, PERL, AWK etc.).
Compare as duas versões do programa acima mencionado (em C++).
// beethoven.cc -- SO de hoje
// stdout deve ser redirecionado para
// arquivo ou pipe.
#include iostream
#include beethoven.h
int main(int argc, char **argv){
try {
symphony S(argc, argv);
std::cout S;
}
catch(...){
return 1;
}
return 0;
}
// beethoven.cc -- SO viajante
#include beethoven.h
symphony main(argc, argv){
return symphony(argc, argv);
}
--
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
