Perguntas de um "boneco" - página 125

 
MetaDriver:

Oh, agora vejo.

Renat, tenho uma sugestão há muito tempo, e é exactamente sobre o assunto. Por favor, faça uma dactilografia nomeada para as arrays, pelo menos para as estáticas (todos os outros tipos já a têm).

Isto é, possibilidade de declarar por exemplo: typedef Int8 = int[8];.

Pode ser feito facilmente através de estruturas. Não vamos complicar em demasia.

struct Int8 { int arr[8]; };
 
Renat:

Isto é feito facilmente através de estruturas. Não o vamos complicar demasiado.

Oh, óptimo. Fácil. É isso que estamos a fazer! Mas do que é que eu preciso? Uma coisa simples ??

Não pense que a sua navalha Occam e a nossa navalha (utente) Occam são duas navalhas muito diferentes. Com o seu minimalismo, tende a criar um tal excedente de utilizadores, que é altura de pendurar Occam na cerca mais próxima.

Se se preocupa tanto com a simplicidade, então torne possível passar os subarrays habituais em funções! Todos ficarão felizes, e os minimalistas ficarão felizes.

// A propósito, funciona bem em F4 - também para os dinâmicos. :)

 
Renat:
Estático, é claro.
Bem, aí está. Demasiado tarde para verificar :/
 
MetaDriver:

Óptimo, é fácil, é o que fazemos! Mas do que é que eu preciso? A nível ??

As estruturas que propus são uma forma padrão de criar novas entidades.

Não há necessidade de ficar excitado por nada.

 
MetaDriver:

Actualmente, em mql5, temos de fazer muitos passos extra e escrever muito código torto devido à impossibilidade de passar subarrays em funções.

Está a falar de apontadores para pedaços de memória incontroláveis, o que é completamente proibido na MQL5.

Na MQL5 todos os objectos/tipos devem ser controláveis - isto é um requisito directo para a segurança linguística.

Se precisar de passar parte de uma matriz, deve utilizar a passagem de referência à própria matriz e à sua posição. Isto dar-lhe-á o controlo total sobre a própria matriz.

 
Renat:

Está a falar de apontadores para pedaços de memória incontroláveis, o que é completamente proibido na MQL5.

Na MQL5 todos os objectos/tipos devem ser controláveis - isto é um requisito directo para a segurança linguística.

2. se quiser passar parte de uma matriz, utilize a passagem de uma referência à própria matriz e à posição na matriz. Isto funcionará para o controlo total da própria matriz.

Além disso, é o único lugar onde a nomeação não é implementada, por isso enquadra-se bem na ideologia da universalização das entidades linguísticas.

2. Mesmo assim: primeiro, é torto, e segundo, não é de todo universal. Sugira uma forma(1) de copiar um mql-array bidimensional para um buffer OpenCL sem reescrever e envolver desnecessariamente em estruturas, ou(2) usando (para uso rápido) a sua própria função ArrayCopy(...) para arrays não uniformes.

// Desculpem a brusquidão do posto anterior. Realmente desnecessário. Fiquei entusiasmado com "não vamos complicar as coisas". Uma vez que apenas conduz a complicações.

2a. Penso que a sua "restrição unidimensional" para funções como ArrayCopy() pode ser suavizada sem dor em muitos casos com uma cláusula elementar nos comentários: "A função funciona também com matrizes multidimensionais, desde que a matriz multidimensional seja copiada na sua totalidade. "

Muitos problemas iriam desaparecer. // Mas nem tudo, é claro.

Документация по MQL5: Основы языка / Переменные
Документация по MQL5: Основы языка / Переменные
  • www.mql5.com
Основы языка / Переменные - Документация по MQL5
 
MetaDriver:

1. essa foi a minha sugestão de introduzir a nomenclatura e, portanto, a dactilografia rígida, especialmente porque é o único lugar não abrangido pela nomenclatura, encaixando-se assim bem na ideologia da universalização das entidades linguísticas.

Receio que não tenha querido reparar na coincidência da descrição:

typedef Int8 = int[8];
struct   Int8 { int arr[8]; };

A segunda via é muito mais limpa, mais poderosa e controlável. Não há qualquer razão para inventar outro mais fraco utilizando o método existente.

2. a fazer a mesma coisa. Mesmo assim: primeiro, é tortuoso, e segundo, não é de todo universal. Sugerir uma forma(1) de copiar um mql-array bidimensional para um buffer OpenCL sem reescrever e envolver desnecessariamente em estruturas, ou(2) utilizar (para velocidade) a sua própria função ArrayCopy(...) para arrays não-dimensionais.

Em primeiro lugar, não é tortuosa. Em segundo lugar, a segurança é superior a quaisquer métodos de optimização ao estilo de acesso directo e descontrolado à memória. Ou seja, a questão "como posso verter directamente um bloco binário numa entidade supervisionada" é uma questão geral e fundamental (pouco resolúvel) para todas as línguas.

Se tiver de lidar com transferências de matriz entre diferentes sistemas (em OpenCL), é importante pensar numa estrutura de dados simples e directamente compatível.

Veja a mais simples CLBufferWrite classe encadernada de funções multi-digrafadas para uma fácil transferência de dados.

Arquivos anexados:
 
Renat:

Está a falar de apontadores para pedaços descontrolados de memória, o que é completamente proibido na MQL5.

E, a propósito, está a condensar. O compilador sabe o tamanho da matriz a ser passada no ponto em que o parâmetro é passado.

Até gera um erro ao tentar fazê-lo. :) Outra coisa é que teria de introduzir uma parametrização implícita adicional em cada chamada de função (mais ou menos como me aconselha a fazer explicitamente). Mas a solução do seu lado seria muito mais universal - por exemplo, utilizando a sua própria biblioteca padrão de funções e objectos. O mesmo ArrayCopy() e FileWriteArray() funcionariam sem problemas.

Документация по MQL5: Основы языка / Функции / Передача параметров
Документация по MQL5: Основы языка / Функции / Передача параметров
  • www.mql5.com
Основы языка / Функции / Передача параметров - Документация по MQL5
 
papaklass:
Pode acompanhar as suas declarações com exemplos simples, para pessoas como eu. MetaDriver compreende-o, mas pessoas como eu não compreendem do que estamos a falar sem quaisquer exemplos? E quer estar ciente do que se está a passar.

Receio que isto seja um substituto para a documentação. Procure-o numa pesquisa - há apenas uma tonelada de informação por aí.

Acesso seguro a alguns membros da matriz:

void MyFunc(double& array[],uint pos,uint size)
  {
   while(size>0)
     {
      Print("[",pos,"] = ",array[pos]);
      pos++;
      size--;
     }
  }

Tendo em conta que o compilador é muito afiado para funções em linha, de facto, a função pode ser completamente integrada no local de chamada e todas as despesas gerais serão reduzidas a zero.

Isto significa que, na MQL5, não se pode ter medo de escrever pequenas funções "correctas" - elas têm um destino padrão em linha com a optimização apropriada.

Isto significa que os custos de transferência e indexação de parâmetros são reduzidos.

 
MetaDriver:

E, a propósito, está a condensar. O compilador sabe o tamanho da matriz a ser passada no ponto de passagem dos parâmetros.

Desde quando é que todas as matrizes se tornaram estáticas, assim como todos os índices e tamanhos?

Uma vez que as matrizes são quase sempre dinâmicas e os índices são variáveis, não podemos fazer qualquer verificação estática séria no momento de uma chamada. Só é necessário fazer verificações meta/rtti e é por isso que é tão importante ter acesso a todo o objecto/descrição e não trabalhar num pedaço de memória ao acaso.


O mesmo ArrayCopy() e FileWriteArray() funcionariam sem qualquer problema.

Não se preocupe, tudo já foi pensado há muito tempo.

As consequências da quebra dos princípios de segurança que conhecemos muito bem é que "em Abril corrigimos mais 12 bugs críticos para sair da máquina virtual e ganhar o controlo do sistema".