O texto seguinte foi movido de: comentário no artigo Uma das tentações em que caem mais facilmente algumas pessoas, é adaptar directamente uma palavra numa língua original e colocando-lhe um sufixo pertencente à língua para a qual se pretende traduzir. É um erro crasso.

ENDIANamento = Endian + amento Porque não Endianidade? (Propriedade do que é "Endian") Endianamento (fim) não existe. caso contrário também existiria Beginiamento (início). Ao adaptar termos técnicos, devemos ser muito cuidadosos, para não caír em situações de improviso, ou seja inventar palavras que não existem. —o comentário precedente não foi assinado por Carlos Rosa PT (discussão • contrib.) O texto seguinte foi movido de: comentário no artigo

Por mim não importa se o artigo destino está em um dos nomes ou noutro. Fato é que, de alguma forma, a fusão dos dois conteúdos deve ser feita. Usei o outro como referência pois é o mais antigo, possui mais histórico. Se for o caso, move-se tudo para lá e depois redireciona-se para cá, por causa do histórico. Evitar usar o estrangeirismo é o correto, por mim tudo bem. Caso queira ajuda na fusão avise. --Leonardo Stabile ^msg 04h35min de 18 de Junho de 2008 (UTC)

A minha opinião - (Carlos Rosa PT)[editar código-fonte]

É a primeira vez que estou a participar numa página de discussão, e como tal, não sei se é aqui que devo colocar o comentário. [De qualquer forma, gostaria de dizer o seguinte:

Não devem ser criados neologismo de maneira ad-hoc. Sempre que um termo técnico existe numa língua e não noutra, deve-se seguir uma das seguintes regras (de preferência pela ordem indicada a seguir):

Utilizar uma palavra que já exista, e traduza sem ambiguidade o termo da língua original (Ex. Memory => Memória)
Criar um neologismo que respeite as regras da morfologia e sintaxe da língua para a qual se vai fazer a tradução do termo técnico (Ex. Microprocessor => Microprocessador, etc.)
Caso não se consiga usar uma palavra que traduza o termo directa e correctamente, deve traduzir-se a palavra na língua original, por uma frase (o mais sintética possível) mas de forma que respeite as regras gramaticais da língua destino.
Finalmente, caso não seja possível aplicar nenhuma das três regras anteriores, e apenas quando um termo foi adoptado de forma generalizada e universal, deve manter-se o termo técnico na língua original (caso de Bit, Byte, Hardware, Software, etc.)

Repare-se nas Wikipédias noutras línguas:

A Wikipedia em Espanhol poderia ter utilizado termo Endianidad. Mas, em vez disso, mantiveram o termo em Inglês.
A Wikipédia em Italiano escolheu uma frase "Ordine dei byte".

Em ambos os casos o(s) autor(es) não utilizaram palavras que não existem nas suas respectivas línguas. E ambos procederam bem. Infelizmente, em Português, é muito comum as pessoas tomarem para si a liberdade de utilizarem a língua da forma que mais lhes agrada, e é por essa mesma razão que actualmente está em curso o Acordo Ortográfico da Língua Portuguesa, dada a situação a que se chegou.

Voltando ao nosso tema, enquanto o artigo "Endianamento" é uma tradução pura do mesmo asrtigo em inglês (até existe uma nota de rodapé onde é feita referência ao artigo original e mais completo), no artigo "Extremidade (Ordenação)" foram adaptados alguns tópicos úteis, mas algumas coisas já foram apagadas, muitas outras serão apagadas porque em minha opinião são redundanes, e o artigo final, terá poucas semelhanças com o em inglês, porque já neste momento, a maior parte do que lá está é de minha autoria.

Deste modo, a minha opinião é que não concordo com a fusão, pelas razões que apresentei, e também porque independentemente do histórico do artigo "Endianamento" ser maior, o conteúdo é muito menor, menos aprofundado e limita-se a traduzir iteralmente de forma resumida o artigo em inglês.

Se aparecer um artigo em português, mais completo do que o meu, e que não se limite a ir buscar informação ao meu artigo, eu proponho o apagamento do meu, desde que siga as regras de rigor gramatical, e caso aproveite conteúdo do meu artigo, faça referência ao facto, porque apesar de a Wikipédia ser livre, todos gostamos de ver o nosso trabalho reconhecido.

Para além disso, repare-se na palavra "Endianamento" (aliás, no histórico do artigo "Endianamento" eu já vi o termo "Endianismo", em que ficamos então? Cada um inventa a palavra que mais lhe agrada?

Por isso a minha opinião é que não concordo com a fusão dos artigos.

Obs.: Se não era aqui que eu devia colocar este texto, pedia o favor de me informarem, para eu o mover.

Saudações cordiais,

Carlos Rosa PT (discussão) 06h47min de 18 de Junho de 2008 (UTC)

Caro Carlos, o comentário está no local correto, não se preocupe. Creio que você havia entendido a fusão de artigos da forma como a Wikipédia entende, mas não há problemas. Procedi a fusão no caminho inverso: aquele artigo mais antigo endianamento foi fundido neste mais novo e completo. Como havia dito, não importa tanto a ordem da fusão, o que importa é que ela seja feita. Agora que pude ler todo o texto, posso dizer que gostei muito do conteúdo, parabéns! Além da fusão, outras mudanças que acabei fazendo no conteúdo incluem:

Revisão geral do texto para seguir o manual de estilo do projeto;
Correção de algumas ligações internas para apontar para os artigos de fato, que já existiam mas que tinham nomes diferentes dos usados no texto original;
Reorganização de algumas seções, como por exemplo a união das seções de ordenação de bytes em máquinas virtuais, redes e ficheiros no item "Uso em diferentes meios";
Na seção de exemplos, transformação das imagens de códigos em texto, tanto para assembly quanto para C++. Nesse caso, texto é melhor pois além de ser facilmente modificável (tive que mudar pontualmente o código C++, "void main" não existe ), e copiável.

Mas para mim ainda resta as dúvidas: (a) não seria melhor mudar o título para "Ordenação de bytes"? No texto é citado que o termo não é um caso específico e não abrange todo o conteúdo, mas esse é o termo em que o conceito é mais conhecido, e é majoritariamente usado no próprio artigo. (b) não seria melhor usar somente os termos lusófonos ao invés de big-endian e little-endian? "Extremidade maior primeiro" e "extremidade menor primeiro" são muito grandes para serem citados repetidamente, mas poderíamos usar abreviações como EMaP e EMeP ou M+P e M-P (apenas brainstorming...) Sds, --Leonardo Stabile ^msg 04h36min de 19 de Junho de 2008 (UTC)

______________________________________________________________________

Caro Leonardo

Em primeiro lugar quero agradecer-lhe por ter arrumado o meu artigo em termos gráficos. Gostei especialmente da reorganização que fez em "Uso em diferentes meios".

Como gostei mesmo do seu trabalho, e por uma questão de respeito não fiz duas pequenas alterações, mas pedia-lhe que as fizesse:

No programa em Assembly, era importante que as directivas estejam juntas com o código. Só assim o assemblador percebe o que o programador quer, e quem não saiba programar em Assembly, fica com a ideia que as directivas não fazem parte do texto. Para além disso a directiva "MODEL FLAT" são duas palavras e não uma, e começam com ponto => .MODEL FLAT

Pode parecer insignificante, mas a ausência do "." causa erro.

No programa em C++ (não me leve a mal que não é teimosia minha), ao alterar o meu programa, introduziu uma incorrecção (embora o programa funcione na mesma).

Passo a explicar:

Há muitos autores de livros de programação que dizem que a função main() deve obrigatoriamente ser declarada int main(). Erro!

Temos várias opções:

int main()
{
// corpo do programa
return 0; // obrigatório se declaramos a função assim: int main()
}

ou

void main()
{
// corpo do programa
}

ou ainda

void main(void)
{
// corpo do programa
}

e ainda há outras formas, quandos passamos argumentos na linha de comando.

Todas estas maneiras de declarar a função main() estão certas, só que se escrever-mos int antes de main() significa que o programa vai devolver um valor inteiro a algo que o chamou (embora não seja obrigado a isso). Normalmente esse int que é devolvido na instrução return serve para devolver códigos de erro, para o sistema operativo e são lidos numa variável chamada ERRORLEVEL (normalmente escreve-se em maiúsculas)

Se a função for escrita int main() podemos devolver um inteiro (normalmente a 8 bits) e temos assim 256 valores diferentes que podemos devolver.

Num ficheiro de comandos, podiamos assim escrever o seguinte:

IF ERRORLEVEL 0 ..... // OK, não houve nenhum erro
IF ERRORLEVEL 1 ..... // executar uma determinada acção
IF ERRORLEVEL 2 ..... // executar outra acção
IF ERRORLEVEL 3 ..... // executar outra acção
.
até
if ERRORLEVEL 255 ..... // executar uma última acção

Pode confirmar em [1]

Assim, como o programa que eu fiz, não vai devolver nenhum código de erro, o correcto é

void main()
ou
void main(void) // porque também não vai receber nenhum parâmetro.

Pode confirmar no site da Microsoft
Por isso meu caro Leonardo, peço desculpa mas void main() existe mesmo.
O problema é que os compiladores de C/C++ não fazem verificação do retorno de tipos de funções, e por essa razão até a função printf(), devolve um valor, no entanto ninguém utiliza esse valor para nada (algumas vezes utiliza-se, mas raramente). Experimente o programa que eu fiz e experimentei, e veja se funciona ou não.
Se não funcionar, diga-me qual o compilador que usa, ok?

Finalmente há duas coisas que eu gostava de lhe confessar:

Penso que o formato em que se escreve a Wikipedia é muito limitativo. Prefiro de longe HTML. Bom, mas isto é apenas um pequeno pormenor. Cada um é livre de ter a sua opinião.
O facto de os artigos não deverem ser maiores que 30K, limita muito o conteúdo dos artigos.

Esperando vir a ter possibilidade de falar consigo mais vezes, porque há coisas muito interessantes que se podem discutir, apresento-lhe as minhas

Cordiais saudações

Carlos Rosa PT (discussão) 19h21min de 19 de Junho de 2008 (UTC)

Caro Leonardo

Depois de escrever o texto acima lembrei-me da sua sugestão de criar uma sigla para evitar os nomes grandes "extremidade menor primeiro" e "extremidade maior primeiro".
Há um provérbio português que diz: "O hábito faz o monge.", por isso, se as pessoas que escrevem livros e dão aulas de informática passarem a usar uma terminologia menos anglófona e mais lusófona, será positivo para todos.
Eu pessoalmente detesto o exagero da utilização de termos estrangeiros quando existe uma palavra correspondente em português, mas ainda gosto menos do "aportuguesamento" de palavras estrangeiras.
Foi o que aconteceu com "endianamento" e "endianismo". Assim escrevi o meu artigo, ao qual dei um título que considerei ser ilustrativo do significado que se queria dar.
Mas, nenhuma língua é propriedade de ninguém, e como tal, eu também não sou dono da língua portuguesa.
Ela pertence a todos nós luso-falantes (portugueses, brasileiros, africanos e timorenses).
Vamos todos escrever mais artigos na wikipedia em português, e a terminologia consolidar-se-á de forma natural.
Pessoalmente, eu tentarei dar o meu contributo, o melhor que souber.

Cordiais saudações

Carlos Rosa PT (discussão) 20h03min de 19 de Junho de 2008 (UTC)

Fiz a mudança em relação às diretivas do código assembly, aquilo estava muito estranho, mas não sei a mudança que fiz melhorou muito. Entretanto, sinta-se à vontade para editar o artigo quando quiser, wiki é para isso mesmo. Em relação ao C++, creio que há uma confusão aí. A norma ISO/IEC 14882 (que padroniza o C++) é explícita em definir que a assinatura do main deve retornar int, e não há outra opção. Parece-me que em C há a opção, em C++ não. Pena que eu perdi (sim, perdi) minha ISO/IEC 14882:1998, senão citava diretamente da norma. Mas o autor do C++ Bjarne Stroustrup cita isso num FAQ sobre a linguagem em sua página pessoal: [2]. Ele inclusive cita que no ISO C também não é possível. A ISO/IEC 14882 também define que o retorno (return) do main pode ser omitido, e nesse caso o valor é zero, garantido pela norma. Vários implementadores disponibilizam versões alternativas que incluem void, até porque muitos livros acabaram popularizando esse uso, mas para a norma padrão o que vale é somente int, opcionalmente com retorno omitido. O padrão também define (na <cstdlib>) dois retornos: EXIT_FAILURE e EXIT_SUCCESS. Qualquer outro valor é particular a uma implementação, e é válido a um conjunto específico de plataformas que a implementação suporta. --Leonardo Stabile ^msg 03h03min de 20 de Junho de 2008 (UTC)

Caro Leonardo

Agradeço por ter reposto o código Assembly na forma que o assemblador "exige".

Em relação ao C++, percebi a sua posição. Eu também tenho a norma ISO/IEC 14882 nas duas edições (1998 e 2003) e de facto, seguindo escrupulosamente o que lá consta deve ser int main(). Ok.
Percebo que o Leonardo deve ser programador e que segue à letra as normas ISO/IEC.
Mas, como sabe, seguindo à risca a norma, o meu programa não podia utilizar o __int64 (não faz parte da norma), e eu uso-o sempre que necessário. Aliás, se eu seguisse apenas o que está especificado nas normas ISO/IEC, no mínimo, cerca de 75% dos programas que eu já fiz, ficaria impossibilitado de os realizar. Quase todos os compiladores têm muitas funcionalidades que não estão padronizadas, mas que são extremamente úteis e nalguns caso até, imprescindíveis.
Só mais um ponto:
Apesar da norma ISO/IEC 14882:2003, pág. 234, no capítulo 13 (Overloading), parágrafo 13.5.7 (Increment and decrement), fazer algumas considerações sobre pré e pós incremento (e decremento), no caso do meu programa não precisamos de chegar a tanto preciosismo.

Se n=10, ao fazer n++ , ++n , n+=1 ou n=n+1 são quatro maneiras diferentes de ficarmos com n=11.
Mas já seria diferente o seguinte:
n=10;
a=n++ é diferente de a=++n
No caso do meu ciclo "for" ao mudar os pós-incrementos para pré-incrementos, o programa funciona exactamente da mesma maneira.

Aliás, nem era preciso ler a norma. Todos os livros de referência de C++, utilizam indistintamente as duas formas.

Para terminar. Estas normas de que temos andado a falar, são revistas de 5 em 5 anos, e às vezes, mal acabam de ser publicadas precisam de nova revisão.
Uma da revisões que deveria ser feita com urgência é precisamente o formato da função main(), já que sendo uma função, não respeita o formato da declaração das restantes funções!
Por uma questão de coerência, deveriamos poder declarar a função main() a devolver qualquer tipo de objecto, ou referência para objecto. Seria muito útil.

Se seguiu o endereço que eu indiquei, reparou que a Microsoft também escreve void main(). O endereço que eu indiquei referia-se ao Visual C++ 6.0, mas a Microsoft no Visual C++ 2008 continua a utilizar funções que devolvem void.
Apesar de eles mostrarem uma função int main(), o parágrafo começa com a seguinte frase: "When used as a function return type, the void keyword specifies that the function does not return a value."
E a Microsoft têm milhões de cópias de software a funcionar em todo o mundo.

Saudações

Carlos Rosa PT (discussão) 08h25min de 20 de Junho de 2008 (UTC)