Perguntas de um "boneco" - página 14

Novo comentário
 

Aqui está outra coisa em que pensar. Faça-o!// Comunicar os resultados. ;)

struct s_char8
  {
   char c[8];
  };
struct s_long
  {
   long l;
  };
void OnStart()
  {
    Print("//------ ");
    
    s_long L;
    L.l = 2387159478511726799;

    s_char8 Ch = L;

    string S = CharArrayToString(Ch.c, 0);
    
    Print(S);
   }
 
MetaDriver:

Estou francamente perplexo, rapazes. Estão apenas a brincar em pé de igualdade. Totalmente plano.

Queria apenas pedir desculpa e interceder por esta conversa "séria". Mas enquanto eu saía para comprar cigarros, fui espancado.

E não é como se fôssemos "bonecos", pois não? E este "boo-boo-boo" foi feito do nada.

Na classe CExpert, vou corrigi-lo para ulong.

 
Renat:

Está enganado.

Sim, esqueci-me da conversão do tipo.

 
uncleVic:

E não são "manequins", pois não?

Sou um boneco em muitos aspectos. Por isso, não compreendo como é que funções destinadas a regressar durante muito tempo irão regressar ULONG_MAX-1. As armadilhas de manipulação superficial de tipos inteiros estão escritas quase no próprio Manual. sergeev compreendeu correctamente a razão da pergunta: controlo de encomendas. Se eu especificar request.magic como ulong, então espero que as funções HistoryDealGetInteger(), PositionGetInteger() e OrderGetInteger() também devolvam o tipo ulong. Sem quaisquer conversões de tipo explícito-implícito.

No entanto, se osseus exemplos explicam que as conversões do tipo longo<->ulong não causam perda de valores (ao contrário do duplo -> int, por exemplo), então o processo de reflexão posterior torna-se claro.

tioVic:

E um tal "boo-boo-boo" foi criado num espaço vazio.

Na verdade, o fio "Perguntas de Chupeta" foi escolhido para obter explicações, não admoestações.

 
Yedelkin:

Eu sou um boneco para muitas coisas. Por isso, não compreendo como é que funções destinadas a regressar por muito tempo irão regressar ULONG_MAX-1. As armadilhas de manipulação superficial de tipos inteiros estão escritas quase no próprio Manual. sergeev compreendeu correctamente a razão da pergunta: controlo de encomendas. Se eu especificar request.magic como ulong, então espero que as funções HistoryDealGetInteger(), PositionGetInteger() e OrderGetInteger() também devolvam o tipo ulong. Sem quaisquer conversões de tipo explícito-implícito.

No entanto, se osseus exemplos explicam que as conversões de tipo longo<->ulong não causam perda de valores (ao contrário, por exemplo, double -> int), então o processo de reflexão posterior torna-se claro.

Na verdade, o fio "Perguntas do Dummie" foi escolhido para efeitos de elucidação, não de repreensão.

Ofendido? Desculpe, não pude evitar.
 
uncleVic:
Está ofendido? Desculpe, não pude evitar.
Não, não estou. Já tive a minha quota-parte de batalhas na Internet. Tento sempre conduzir a discussão numa direcção construtiva, por assim dizer.
 
sergeev:

Na realidade não são 64 mas apenas 63 bits (ou seja, um 8 bytes incompleto). 8 bytes seria se todo o longo alcance fosse utilizado.

Mas infelizmente...

Por um lado, o ulong mágico é passado para a estrutura MqlTradeRequest. Isso significa que só podem ser definidos valores positivos.

Poroutro lado, as funções PositionGetInteger/OrderGetInteger devolvem o tipo longo. Isto significa que metade da gama ulong está cortada.

No total, temos 63 bits em vez dos 64 acima descritos. Na verdade, não é tanto mau como um grande inconveniente para os princípios de verificação de encomendas.

Seria muito mais conveniente utilizar o mesmo sistema que no MT4 - permitir aos mágicos com um sinal. Uma vez que muitos sistemas comerciais se baseiam num princípio simples que utiliza o próprio símbolo de um mágico. Uma vez que é muito mais fácil dividir um sistema em dois e filtrar as suas encomendas usando a função habitual MathAbs( OrderMagicNumber() ).

todos os 64. De facto. Não se agarrar ao tipo assinado ou não assinado. Isto é para o compilador se certificar de que as operações aritméticas estão correctas (e há um deslocamento bitwise correcto, quer lógico quer aritmético, dependendo do tipo assinado).

Nenhuma informação é perdida durante a transferência (atribuição) e as peças fundidas sem assinatura de dados do mesmo tamanho. Tente saltar ULONG_MAX para a frente e para trás. Tente uma tarefa longa e longa e volte. Experimente a cópia da estrutura.

O melhor é certificar-se por si próprio. Então a questão será resolvida de uma vez por todas.

 
MetaDriver:

Aqui está outra coisa em que pensar. Faça-o!// Comunicar os resultados. ;)

Feito! Substituir a linha 14 no código por L.l = 4548887299649496524.

Da descrição da estrutura MqlTradeRequest resulta que a magia é do tipo ulong, ou seja, podem ser-lhe atribuídos valores superiores ao valor constante LONG_MAX. No entanto, as funções da ... As funçõesGetInteger() são concebidas para trabalhar com tipo longo, de modo que os valores mágicos serão implicitamente lançados ao tipo longo por estas funções. Mas como existe uma correspondência um-a-um entre variáveis de tipo longo e ulong, ao comparar o valor mágico com o resultado devolvido por funções de ... Com as funções GetInteger() ,podemos utilizar com segurança uma conversão de tipo explícita (por exemplo: magic == (ulong)OrderGetInteger(ORDER_MAGIC) ).

Obrigado por mostrar exemplos repetidamente.

 

stringo:

Nenhuma informação é perdida em qualquer lugar durante a transferência de dados (atribuição) e a assinatura de peças fundidas de dados do mesmo tamanho. Tente saltar ULONG_MAX para a frente e para trás. Tente uma tarefa longa e longa e volte. Experimente a cópia da estrutura. Convença-se e não espalhe mitos.

Já experimentei e devolve o resultado necessário ao forçar o tipo (bem, talvez mais uma "dança com diamantes" terá de ser feita adicionalmente). Mas não é tão importante).

tioVic:

Vou mudar a classe do CExpert para ulong.

Penso que é uma boa ideia, aqueles que usam valores negativos na magia terão de especificar à força o que devem devolver/definir.

Também seria muito agradável se a documentação indicasse não só o longo ou ulong, mas ambos os tipos (por exemplo, "longo / ulong").

 
stringo:

Nenhuma informação é perdida em qualquer lugar durante a transferência de dados (atribuição), ou durante as fundições sem assinatura de caracteresde dados do mesmo tamanho.

Uma pergunta adicional: existe alguma forma elegante de preservar a informação ao transferir duplo -> longo?
1...789101112131415161718192021...277
Novo comentário
Razão: