A nova sintaxe MQL4 - página 3

 

Tenho uma pergunta sobre os tipos de variáveis, int, uint, char, short ushort etc. O novo compilador dá avisos sobre a possível perda de dados devido à conversão do tipo, portanto, é a melhor prática;

a) utilizar o que melhor se ajustar às exigências da variável ou,

b) evitar a conversão entre tipos e, portanto, usar int para tudo. (bem, tudo que não precise de ponto flutuante)

 
SDC:

Tenho uma pergunta sobre os tipos de variáveis, int, uint, char, short ushort etc, é a melhor prática;

a) utilizar o que melhor se adequar às exigências da variável ou

b) evitar a conversão entre tipos e, portanto, usar int para tudo. (bem, tudo que não precise de ponto flutuante)

Se você precisar de um int longo não assinado não o cortará... use o tipo correto e a conversão explícita do tipo. IMO
 

por conversão explícita do tipo você pretende fazer a conversão antes de qualquer cálculo entre diferentes tipos ?

 
RaptorUK:
Se você precisar de um int longo não assinado não o cortará... use o tipo correto e a conversão explícita do tipo. IMO

Concordar.
 
SDC:

por conversão explícita do tipo você pretende fazer a conversão antes de qualquer cálculo entre diferentes tipos ?

Veja aqui : https://www.mql5.com/en/docs/basis/types/casting
 

Bom artigo graças ao angevoyageur eu vou ler isso corretamente quando chegar em casa do trabalho.

 
SDC:

por conversão explícita do tipo você pretende fazer a conversão antes de qualquer cálculo entre diferentes tipos ?

Não, eu quero dizer que você pode converter um ulong para uma int como esta ...

ulong VariableUlong;

int VariableInt;

VariableUlong = 100;

VariableInt = (int) VariableUlong;   // explicit typecasting . . .  
 

OK, sim, era isso que eu pensava que você queria dizer.

Só que eu não estava realmente perguntando sobre o ulong. Raramente precisaria trabalhar com valores tão grandes que não poderiam ser acomodados por um inteiro de 32 bits. Eu não sei nem mesmo como dizer o número que um inteiro de 64 bits pode conter rs...

Provavelmente eu deveria ter sido mais específico, não tive tempo esta manhã para escrever minha pergunta como deve ser, mas agora estou em casa e o farei.

No antigo mql4 nós usávamos inteiros para tudo. Escreveríamos para(int i=0; i<100; i++) Não precisamos de valores negativos, e não precisamos de um valor maior que 100 para que pudéssemos usar um uchar para isso. Isso significa que é isso que devemos fazer?

Quando olho para o código de outros programadores, muitos deles parecem usar tipos inteiros de 32 bits em toda a linha. Existe uma razão válida para isso? O que eles sabem que eu ainda tenho que descobrir? O uso dos menores tipos de variáveis footprint ao longo de um programa cria uma dor de cabeça de problemas de digitação por nenhuma razão a não ser um arquivo de tamanho um pouco menor? Ou isso economiza muita RAM ? É seguro assumir que desde que o valor de um tipo possa ser acomodado por outro tipo, é possível fazê-lo? A digitação entre tipos diferentes usa muito mais CPU do que para usar o mesmo tipo?

Atualização: Eu li esta resposta a uma pergunta similar no stackoverflow.com

"Em termos de desempenho, uma int é mais rápida em quase todos os casos. A CPU é projetada para trabalhar eficientemente com valores de 32 bits.

Valores mais curtos são complicados de se lidar. Para ler um único byte, digamos, a CPU tem que ler o bloco de 32 bits que o contém, e depois mascarar os 24 bits superiores.

Para escrever um byte, ele tem que ler o bloco de destino de 32 bits, sobrescrever os 8 bits inferiores com o valor de byte desejado e escrever todo o bloco de 32 bits de volta.

Em termos de espaço, é claro, você economiza alguns bytes ao utilizar tipos de dados menores. Portanto, se você estiver construindo uma tabela com alguns milhões de linhas, então talvez valha a pena considerar tipos de dados mais curtos. (E o mesmo pode ser uma boa razão pela qual você deve usar tipos de dados menores em seu banco de dados).

E, em termos de exatidão, uma int não transborda facilmente. E se você acha que seu valor vai caber dentro de um byte e, em algum momento no futuro, alguma mudança de aparência prejudicial no código significa que valores maiores são armazenados nele?

Estas são algumas das razões pelas quais a int deve ser seu tipo de dados padrão para todos os dados integrais. Somente use byte se você realmente quiser armazenar bytes de máquina. Só use shorts se você estiver lidando com um formato de arquivo ou protocolo ou similar que realmente especifique valores inteiros de 16 bits. Se você estiver lidando apenas com números inteiros em geral, faça-os ints".

 
SDC:

OK, sim, era isso que eu pensava que você queria dizer.

Só que eu não estava realmente perguntando sobre o ulong. Raramente precisaria trabalhar com valores tão grandes que não poderiam ser acomodados por um inteiro de 32 bits. Eu não sei nem mesmo como dizer o número que um inteiro de 64 bits pode conter rs...

Provavelmente eu deveria ter sido mais específico, não tive tempo esta manhã para escrever minha pergunta como deve ser, mas agora estou em casa e o farei.

No antigo mql4 nós usávamos inteiros para tudo. Escreveríamos para(int i=0; i<100; i++) Não precisamos de valores negativos, e não precisamos de um valor maior que 100 para que pudéssemos usar um uchar para isso. Isso significa que é isso que devemos fazer?

uchar - Unsigned Character, porque você usaria isto para um loop ? não faz sentido para mim ... usar um int. Você estará trabalhando com ulongs, isso é o que é uma nova data, e quando você digita sem pensar nisso no futuro, você será avisado . . . lidar com o aviso ou ignorá-lo. Mas não espere apenas pelo melhor, faça como está fazendo agora, aprenda e compreenda

O que você postou do stackoverflow faz sentido para mim, eu acho que é um bom conselho.

 
SDC: A digitação entre tipos diferentes usa muito mais CPU do que para usar o mesmo tipo?

Entre diferentes tamanhos utiliza mais CPU, não muito mais. Apenas instruções diferentes como as mencionadas 32 bit fetch, isolar, operar, colocar, escrever, ao modificar o char em uma estrutura. Assim como multiplicar por 0,5 usa um pouco menos de CPU do que dividir por 2,0

Economizar 16 bits por elemento de matriz não faz sentido em máquinas GB, eu fiz isso quando implementei aplicação, banco de dados, GUI (vt100) em 8 KB (sic.) Ir para 64 bits por (para tudo,) não fará sentido até que plataformas de 128 bits sejam lugar comum.

Assinado contra não assinado não há diferença. É apenas uma atribuição, nenhuma parte é alterada. A diferença é o código que usa a variável. Por exemplo A[índice] faz Endereço(a) + índice * tamanho de(a[0]) onde o mais é uma adição assinada ou não assinada.

Para clareza de codificação, eu usaria uint para indexar arrays já que A[-1] não faz sentido, mas então a contagem regressiva é problemática FOR(uint iA=n; iA >= 0; iA--){} iA>=0 é sempre verdade.

Use int (ou uint) a menos que seja necessário por outros motivos.
Razão: