Porque há tão poucos peritos na base de dados MQL5? - página 9
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
MyStruct' - declaração prévia não é suportada
Aí está. Como é que se livra das dependências cíclicas na arquitectura?
Não me diga que eles não podem existir numa arquitectura normal. A única forma (muleta) é redesenhar a arquitectura, acrescentando um monte de classes base desnecessárias, o que se transforma numa verdadeira chatice devido à falta de herança múltipla, que rejeitou, como entendo, para não se preocupar em implementar dependências semelhantes a pastilhas de pastilha.
Mas poderia ter acabado de implementar a declaração...
Bem, vamos ver se "utilizadores novatos imparciais" são capazes de escrever "algo realmente fundamental" na MQL5, por oposição a "programadores profissionais de sistemas".
Onde escrevi que eles não podem, minha querida? Sim, eles podem, mas será algo rude e pesado.
Aí está. Como é que se livra das dependências cíclicas na arquitectura?
Ainda não permitimos descrições antecipadas devido ao sistema de segurança em casos de uso complexo.
Temos uma linguagem com controlos muito apertados tanto no tempo de construção como de execução. Não podemos dar-nos ao luxo de obter códigos potencialmente vazios devido a controlos relaxados. A questão é que estas descrições podem estar em bibliotecas completamente diferentes e ainda não existe uma forma rigorosa de controlar a utilização em tais casos. Grosseiramente falando, seria possível (não pode ser feito agora) conduzir um ataque aconchegando-se a uma classe canhota com outros métodos.
Já existe uma solução para o problema das declarações antecipadas de dependências externas e cíclicas, mas iremos implementá-la após o lançamento do terminal de 64 bits (compilador, terminal, editor e testador). Já preparámos hoje uma construção pública de 32/64 bits - vamos lançá-la esta semana.
Até começar você mesmo a escrever um compilador de código gerido, com ênfase directa na segurança para o terminal/ambiente de execução (C#/Java não tem nada a ver com isso, porque não são seguros para o ambiente), é difícil compreender as razões das acções dos programadores.
Bem, vamos ver se "utilizadores novatos imparciais" conseguem escrever "algo realmente fundamental" na MQL5 apesar dos "programadores profissionais de sistemas".
TheXpert:
Onde escrevi que eles não podem, minha querida? Sim, eles podem, mas será algo rude e duro.
Aí está. Como é que se livra das dependências cíclicas na arquitectura?
Não me diga que eles não podem existir numa arquitectura normal. A única forma (muleta) é redesenhar a arquitectura, acrescentando um monte de classes base desnecessárias, o que se transforma numa verdadeira chatice devido à falta de herança múltipla, que rejeitou, como entendo, para não se preocupar em implementar dependências semelhantes a pastilhas de pastilha.
Mas poderia ter acabado de implementar a declaração...
Onde é que eu escrevi que eles não podem, querida? Sim, podem, mas vai ser uma coisa complicada e pesada.
Com todo o respeito, deixem-me dizer que, a julgar pelo fórum 5, são os peritos que mais murmuram e resmungam. Enquanto os amadores comuns uivam e criam... És um perito, por isso vive até ao teu nível. Desculpe, se alguma coisa.
Isso é porque tudo é relativo,
Aqueles que nunca estiveram ao volante de um japonês de condução à direita não conseguem compreender como é possível deslocar a caixa de velocidades com a mão esquerda.
E um principiante não se importa, não sabe como o deslocar, nem para a direita nem para a esquerda.
Isso é porque tudo é relativo,
Aqueles que nunca estiveram ao volante de um japonês de condução à direita não conseguem compreender como é possível deslocar a caixa de velocidades com a mão esquerda.
e um principiante não se importa, não pode deslocá-la com a mão direita ou com a esquerda.
Aí está, fez uma confusão de tudo. :)
Alguém que está habituado a conduzir um carro estrangeiro com um automático não pode mover-se num shakha com uma caixa de velocidades fodida. Mas aquele que montou em "clássico" dará vantagem a qualquer profissional em "japonês", se ele conduzir em "japonês". Estou apenas a ser filosófico, estou de bom humor... Note-se que não disse "principiantes", disse "amadores".
Aí está, arruinou tudo. :)
Quem estiver habituado a conduzir um carro estrangeiro com um automático não pode mover-se num shakha com uma caixa de velocidades fodida. Mas ele, que monta um carro "clássico", dará um avanço a qualquer profissional num carro "japonês", se ele montar um carro "japonês". Estou apenas a ser filosófico, estou de bom humor... Note-se que não disse "principiantes", disse "amadores".
Já existe uma solução para o problema das declarações antecipadas de dependências externas e cíclicas, mas iremos implementá-la após o lançamento do terminal de 64 bits (compilador, terminal, editor e testador). Já preparámos hoje uma construção pública de 32/64 bits - vamos lançá-la esta semana.
Até que você mesmo comece a escrever um compilador de código gerido, com ênfase directa na segurança do terminal/ambiente de execução (C#/Java não tem nada a ver com isso, porque não é seguro para o ambiente), é difícil compreender as razões de certas acções dos programadores.
Aqui está a solução para os construtores de objectos - também. As razões para as tornar inúteis são pouco claras.
Eles não aceitam parâmetros. Devemos emular parâmetros agora, usando variáveis globais para o fazer?
Não existe nenhum mecanismo para reportar que um objecto não foi criado porque ocorreu um erro irrecuperável ao criar (inicializar) um dos subobjectos. Pode-se adicionar uma função inicializadora a todas as classes utilizadas em subobjetos, e chamar funções inicializadoras de subobjetos da função de classe correspondente do próprio objeto, o que proporcionará a possibilidade de retornar código de erro. Mas, em primeiro lugar, deve chamar-se explicitamente essa função logo após a criação do objecto e após o seu construtor "sob" ser executado (bem como a função de desinicialização antes de destruir o objecto por destruidor), e, em segundo lugar, ao modificar a classe principal, por exemplo, ao adicionar algum subobjecto, poderia facilmente esquecer-se de incluir, e também em lugar apropriado, para fornecer a sequência adequada, a função de chamada de iniciação de subobjecto adicionado da função de inicialização da classe principal (o mesmo se aplica à função de desinicialização). Afinal de contas, praticamente ninguém escreve uma coisa inteira ao mesmo tempo a partir do zero. Como resultado, obtém-se código semi-escrito e inseguro.
E a libertação declarada como tal há mais de um mês não incluía uma solução tão importante...
Está a mexer muito, misturando-o e inventando problemas que nem sequer são para si. Se tem tanto medo de escrever, então desista.
Sabe o que dificulta um mau bailarino.
Com o devido respeito, deixem-me notar: são os peritos que mais resmungam e resmungam, a julgar pelo 5º fórum.
Por isso, há muito para resmungar. Logo após o lançamento do primeiro beta público, comecei a escrever um sistema de negociação. Quase imediatamente senti falta de construtores normais, e depois desisti de tudo, porque era impossível obter um ponteiro sem o criar explicitamente com o novo operador. Mesmo assim, sugeri a possibilidade de importar classes, como adição lógica à luz da crescente complexidade dos programas e da sua estrutura (cabeçalho e biblioteca ou ficheiros de objectos -- em alguns apenas as declarações necessárias, noutros a implementação).
As classes de importação e as declarações de expedição resolvem completamente o problema da colocação do código.
Um construtor de cópias simplifica o problema dos construtores.
O problema que me levou a parar está resolvido. Existe agora uma construção GetPointer(isto). Tudo o resto é (até agora) resolúvel dentro da língua, mas está a arruinar a minha vida.
Você é o perito, seja apropriado ao seu nível, bcos o olhar conhecedor de oportunidades e o olhar ignorante por razões... Desculpe, se alguma coisa.
Por isso, continuo a escrever. Falar aqui não interfere com a escrita do código. Não há necessidade de pedir desculpa por isso - fui longe demais.