Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
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.
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. :)
Estático, é claro.
Ó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.
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.
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.
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:
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.
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.
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:
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.
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".