Erros, bugs, perguntas - página 706
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
1.
Criar conjuntos de ponteiros para estruturas (arrays) e depois inicializá-los para(i){ S[i] = GetPointer(StaticStruct[i]); }
2. manter conjuntos sólidos (embalados) de dados significativos.
Importante ao lidar com a saída de dados para os buffers em bruto do OpenCL (ou envio para DLL, escrita para ficheiros, etc.)
Ao mesmo tempo, é possível reordenar os acessos aos dados (por exemplo, ao ordenar os apontadores) sem reescrever os dados.
Uma língua com execução segura não deve expor/ dar acesso directo.
As classes têm mais protecções e é por isso que têm uma pega.
Não haverá pegas para outros objectos, uma vez que a segurança é mais importante.
No OpenCL, qualquer tipo de dados pode ser utilizado para a passagem de dados, incluindo estruturas. O vazio* é aí utilizado. Basta preparar os dados uniformes no formato requerido e começar a trabalhar. Antecipando a pergunta "Não quero fazê-lo dessa forma, quero fazê-lo à minha maneira", responderia que não se pode fazer isso - a segurança é mais importante.
1. qualquer tipo de dados pode ser usado para transferência de dados em OpenCL, incluindo estruturas. O vazio* é aí utilizado. Basta preparar os dados uniformes no formato requerido e começar a trabalhar. Antecipando a pergunta "Não quero fazê-lo dessa forma, quero fazê-lo à minha maneira", responderei que não o pode fazer - a segurança é mais importante.
2. uma língua com execução segura não deve expor/ dar acesso directo.
A questão é que para todas as classes, incluindo a mais primitiva, o compilador mql5 cria um VMT, com campo oculto correspondente nos objectos (ponteiro para VMT). E este ponteiro no buffer em bruto (ficheiro) é demasiado para mim. Não só é lixo ocupando espaço, como também quebra o alinhamento dos pacotes de forma inadequada (os amortecedores OpenCL têm alinhamento de 128 bits). É essa a questão. As classes são tentadoras de usar: são convenientes para trabalhar em mql. Mas... ver acima.
Em Delphi há um bom exemplo alternativo de implementação. VMT e, consequentemente, o ponteiro para VMT só aparece nas classes depois do primeiro método virtual aparecer na hierarquia de classes. Se fosse o mesmo em mql5, a situação seria muito mais controlável. Poder-se-ia usar classes sem métodos virtuais em vez de estruturas e não haveria "add-ons" prejudiciais à estrutura.
Agora encontrei uma situação em que a implementação de uma classe abstracta (destinada à herança) que encapsula uma série de estruturas não se presta a serviços herdados (tais como a triagem). A substituição de um conjunto de estruturas por um conjunto de classes resolve este problema, mas cria outra.... (ver acima).
E não estou a pedir qualquer "acesso directo" e não estou interessado em qualquer aritmética de endereços. Porque é que assusta as crianças por nada? :) cabo de mql5 não está nem perto de um ponteiro "bruto". E se for (sub-repticiamente) - então o verdadeiro buraco de segurança está aqui, não na implementação de pegas (pseudo-pontos) a quaisquer dados de utilizador.
---
Neste momento as suas estruturas são de facto classes sem funções virtuais (e VMT, respectivamente). Portanto, tudo bem, basta adicionar-lhes algumas características de classe (pegas). Então também não precisará tanto de indicações para as arrays (pode envolvê-las em estruturas, se necessário).
A questão não é que eu queira fazê-lo à minha maneira; a questão é que para todas as classes, incluindo as mais primitivas, o compilador mql5 cria VMT com campo oculto correspondente em objectos (ponteiro para VMT). E este ponteiro em buffer bruto (ficheiro) é demasiado para mim. Não só é lixo ocupando espaço, como também quebra o alinhamento dos pacotes de uma forma completamente inapropriada (os buffers OpenCL têm alinhamento de 128 bits). Usar classes é tentador: é conveniente trabalhar com elas em mql. Mas... ver acima.
Em Delphi há um bom exemplo alternativo de implementação. VMT e, consequentemente, o ponteiro para VMT só aparece nas classes depois do primeiro método virtual aparecer na hierarquia de classes. Se fosse o mesmo em mql5, a situação seria muito mais controlável. Poder-se-ia usar classes sem métodos virtuais em vez de estruturas e não haveria "add-ons" prejudiciais à estrutura.
Agora encontrei uma situação em que a implementação de uma classe abstracta (destinada à herança) que encapsula uma série de estruturas não se presta a serviços herdados (tais como a triagem). A substituição de um conjunto de estruturas por um conjunto de classes resolve este problema, mas cria outra.... (ver acima).
E não estou a pedir qualquer "acesso directo" e não estou interessado em qualquer aritmética de endereços. Porque é que assusta as crianças por nada? :) cabo de mql5 não está nem perto de um ponteiro "bruto". E se for (sub-repticiamente) - então o verdadeiro buraco de segurança está aqui, mas não na implementação de pegas (pseudo-pontos) a quaisquer dados de utilizador.
Quer construir um sistema complexo com dados abstractos (o que já significa muitos metadados e relações internas) e depois entregá-lo a um ambiente OpenCL descontrolado onde pode ser alterado de forma complicada. É por isso que só permitimos que objectos simples e matrizes funcionem livremente sem a capacidade de sobreescrever tabelas virtuais.
Na realidade, está indirectamente a pedir o acesso directo através da "liberdade de construções abstractas". Este é um tema que explorámos bem e cobrimos arquitectonicamente por uma questão de segurança. As aulas na MQL5 vivem segundo as suas próprias regras, com ênfase na segurança. Os outros tipos não terão pegas. Em vez de pegas para tipos e estruturas simples, pode usar índices em arrays.
As próprias pegas em MQL5 estão correctas (crescendo a partir de uma), pode verificar.
1. pretende construir um sistema complexo com dados abstractos (o que já significa muitos metadados e relações internas), e depois entregá-lo a um ambiente OpenCL descontrolado onde pode ser alterado de forma inteligente. é por isso que só permitimos que objectos simples e matrizes funcionem livremente sem a capacidade de sobreescrever tabelas virtuais.
2. Na realidade, está indirectamente a pedir acesso directo através da "liberdade de construções abstractas". Este tópico é bem investigado por nós e coberto arquitectonicamente por razões de segurança. As aulas na MQL5 vivem segundo as suas próprias regras, com ênfase na segurança.
Os cabos em MQL5 estão correctos (crescendo a partir de um), pode verificá-lo você mesmo.
Quero passar dados estritamente limpos para o buffer sem quaisquer metadados (pegas). Não preciso destes metadados no tampão. Eles atrapalham. E também não vou poder colocá-los lá - CLBufferWrite() não os vai deixar entrar. E isto é correcto.
2. não estou a pedir qualquer acesso directo, posso usar DLL para acesso directo (se precisar).
aPointer = memcpy(a,a);
resolverá o problema de obter um ponteiro em bruto. Renat, tenta entrar no verdadeiro problema. Não invente nada que não " realmente" exista. Tudo o que realmente existe - descrevi-o directamente e sem quaisquer subtilezas no pedido. Tão construtivamente quanto possível e com uma compreensão total das questões de segurança.
3. isso é óptimo.
--
Não se deve fazer criação e eliminação dinâmica de estruturas (novas, eliminar) de todo. Nem sequer de forma alguma. Então as questões de segurança também não surgirão. Compreendo qual é o problema "realmente" (para o colocar na sua língua). Há um problema de definição do tipo real de objectos dinâmicos. Para as aulas, é muito provável que seja resolvido através da análise de um ponteiro para VMT. No entanto : sem estruturas dinâmicas, sem problemas.
Pense nisto, o que é um "cabo" em relação a uma entidade de qualquer escala?
Pode fornecer pegas para objectos que sejam em número razoável (classes, ficheiros, etc.). Mas se entrar numa área de qualquer tamanho, qualquer pega só tem uma hipótese de ser uma referência directa a um pedaço de memória. Caso contrário, a tabela de mapeamento "handle -> memory" comerá ainda mais memória do que a entidade a ser referenciada.
E com base na disposição de segurança, não pode ter pegas que sejam indicadores directos para a memória. É por isso que não há pegas para "qualquer entidade não vinculada".
Renat:
1. pode fornecer pegas para objectos que sejam em número razoável (classes, ficheiros, etc.). Mas se entrar numa área de qualquer tamanho, qualquer pega só tem uma hipótese de ser uma referência directa a um pedaço de memória. Caso contrário, o cabo -> tabela de mapeamento de memória consumirá ainda mais memória do que a entidade a ser referenciada.
2. e com base na cláusula de segurança, não se podem ter pegas que sejam indicadores directos para a memória. É por isso que não há pegas para "qualquer entidade não vinculada".
1. Construtivo é uma coisa boa. Tenho andado a pensar. O problema foi levantado exactamente em relação a estruturas maciças. Para estruturas pequenas o tempo de cópia é curto de qualquer forma. Penso que os problemas podem surgir aqui apenas devido à falta de razoabilidade do utilizador, mas pode "tolamente" preencher a memória de qualquer forma (com amortecedores indicadores, por exemplo). Não suponho que alguém prefira trabalhar com pegas em estruturas estáticas sem qualquer necessidade particular. E se a memória transbordar, a culpa é sua. Não se preocupe tanto com os disparates populares, não há maneira de prevenir (e até mesmo prever) tudo de qualquer maneira. :)
2. não, não. Não há necessidade de indicações directas, mas não faria mal ter pegas, mesmo "para qualquer entidade irrestrita". O principal é que não há obrigação de os usar. Depois haverá memória suficiente para todos. :)
Não compreendo o que estás a ladrar aqui. Se quiser pegas, declare as suas estruturas como classes, é tudo.
Se quiser acesso directo à memória, escreva uma dll.
Não compreendo o que está a partir aqui o pescoço.
1. quer pegas, declare as suas estruturas como classes, é tudo.
2. se quiser ter acesso directo à memória, escreva uma dll.
1. esse é o ponto: é problemático. Não preciso de escrever um conjunto de classes no tampão (e é impossível). Preciso de escrever ali estruturas. E quero-o rapidamente (sem que haja uma verdadeira reescrita das aulas em estruturas). E são necessárias pegas para o acesso reordenado (para a triagem, além disso, com chaves diferentes).
Uma substituição poderia ser a minha própria tabela de índices - mas depois não posso fazer uma classe que encapsule o trabalho com um conjunto de estruturas com a capacidade de o herdar, juntamente com serviços uma vez prescritos (triagem e pesquisa binária).
2. Não o quero! !! Parem de me defender no local! :))
Não, não faremos tais charretes. Isto é um mal absoluto, pelo qual seremos responsabilizados até ao fim.
A solução ideal seria classes parametrizáveis
class MyClass<T> { T MyArray[]; .... };Mas já nem sequer estou a falar disso, talvez devesse?