[FUG-BR] OT: Re: RES: C/C++

[gethostbyname]

Paulo Pires escreveu:
> On 2/25/07, gethostbyname <gethostbyname at gmail.com> 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