Minha abordagem. O núcleo é o motor. - página 50
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
Vitaly, o problema é que Peter é um titã da memorização. Ele não esquece onde e que índices tem, o que significam, que conexões têm e onde.
Com uma memória tão incrível, as melhorias do OOP são apenas gestos desnecessários, e alguma degradação do desempenho. Para quê?
OOP é para aqueles que não se lembrarão em uma semana porque podem mudar a variável em um determinado lugar e não no local vizinho. São eles que precisam de encapsulamento, seções de classe públicas, protegidas e previstas, interfaces virtuais, polimorfismo... E quando você tem tudo na memória, como um computador, é muito mais fácil acessar cada objeto diretamente, sem nenhum aprimoramento do OOP.
Sugira a Peter uma classe de "smartpointers", que leve em conta o número de referências ao passar objetos, e depois, quando ninguém se referir a eles, apague-os! Peter ficará surpreso, ele se lembra bem quando cada objeto é criado, quantos usuários ele tem, quanto tempo ele deve existir e quando ele deve ser apagado. Qual é o objetivo de usá-los?
Não, também se pode fazer isso. A única pergunta que eu tenho é para quem? Peter diz que "isso criará uma camada de tais usuários". Bem, bem... Veremos.
Uma boa memória é certamente boa :) Mas a memória tem esta propriedade que com a idade, ela piora ou se torna seletiva. O que você se lembra muito bem e o que você pensa ser insignificante, imediatamente lhe escorrega a mente. :)
Você tem um estranho espírito competitivo :)
Só por interesse, você poderia usar sua astúcia para criar um análogo de um programa desse tipo:
O programa foi escrito em dois meses em 2013, com outro projeto paralelo ainda em andamento.
O programa foi compilado pela última vez em 2014, portanto alguns percalços são possíveis :)
É melhor executar o programa em instrumentos negociados em bolsa.
Esclarecimento para os moderadores: Este programa não está no mercado.
Uma boa e poderosa GUI. Eu posso reproduzir 85% de sua mecânica com o construtor. Também tenho janelas dinâmicas de arrastar e soltar. O resto é a tarefa do programa (números cintilantes em células, chamadas funções).
Quanto às janelas de instrução - isso também é reprodutível. Em resumo, em minha versão, a aparência será ligeiramente diferente, mas a funcionalidade será quase a mesma.
Mas, a escala e os números não são implementados em minha versão. E não há escalada.
No entanto, ao contrário desta GUI, meus gráficos serão mais bonitos. Gradientes, ícones, molduras bonitas, sombras... Os elementos são todos desenhados.
Mas, para um mercado moderno - seu produto é muito poderoso. Provavelmente, um dos mais poderosos.
E o fato de que não foram muitas as pessoas que o compraram - você pode agradecer aos testers grails. Eles tornaram todos os produtos sem sentido, exceto para si mesmos.
e por que este novo estilo?
Você escreveu que a cada 30-100 pedidos se depara com um pedido para o painel de desenvolvimento, mais frequentemente não acontece, menos frequentemente acontece
se você quiser trabalhar por conta própria, acessehttps://www.mql5.com/ru/search#!keyword=%D0%BF%D0%D0%D0%B0%D0%BD%D0%B5%D0BB%D1%8C&module=mql5_module_jobs
é toda a demanda, e note que os painéis são necessários para o comércio, e ninguém está interessado em análises e calendários em um painel
ZS: Você já ouviu a piada sobre Joe esquivo? Com todo respeito, mas sua GUI é boa, mas muito poucas pessoas estão interessadas, menos esforço pode obter qualquer resultado com um dll, fazer um painel que na sua opinião os usuários precisam e no Mercado, um mês serão estatísticas ...
PS: nunca tive qualquer desejo de lidar com C# .Net, mas como os desenvolvedores fizeram suporte, tive que gastar uma hora para encontrar um simples compilador c com um designer de formulários - SharpDevelop (14 Mb) e pesquisar no Google como rodar um formulário de .dll, tudo funciona e tudo "gira", o próprio código, que prescreveu as mãos literalmente - 3 linhas!!!
Os desenvolvedores da MQL facilitaram o trabalho com .dll em C#, basta colocar uma dll pronta na pasta Bibliotecas e escrever nas primeiras linhas do Expert Advisor o nome .dll - isso é tudo ;)
Você simplesmente não quer entender. Que diferença isso faz? Sua variante não é para as massas.
As pessoas estão em busca de lucro. Nesta busca, eles estão presos em um único e mesmo tester-grails. Ou seja, programas que prometem enriquecimento com base em leituras de teste. É isso aí. É um beco sem saída a partir daqui.
Vai durar para sempre? Eles sempre confiarão no testador? Será que eles nunca ficarão desapontados olhando para dezenas de milhares de robôs "mortos"?
Eu proponho uma saída para o impasse. Programas semi-automatizados onde o usuário será responsável por suas próprias ações.
Você acha que ninguém quer isso? Você está enganado.
Peter, a questão é essa - não há nada para usar. Qualquer janela é apenas uma decoração ou um ponto de diálogo. O ponto de diálogo implica a necessidade deste diálogo.
Imagine que você é um comerciante e o programa lhe pergunta algo. Precisa saber isso de você. O que ele pode lhe perguntar, e você pode responder a esta pergunta com um botão ou um formulário? Estou seriamente interessado na sua opinião sobre isto - responda-me se não se importar.
E a segunda situação: você considera necessário intervir no trabalho do programa - que botão/formulário lhe permitirá fazê-lo de forma eficiente?
Concordo absolutamente com você que a automação de uma atividade é tarefa daqueles que a automatizam, mas você finge ser um criador de ferramentas para desenvolver uma interface homem-máquina nesta área. Uma interface de botões e formulários, ou uma GUI normal que permite o trabalho completo com todos os objetos gráficos da MT; uma interface de objetos, ou também interrompe?
Você afirma criar um padrão; eu, ao automatizar algo, reivindico que qualquer, ou quase qualquer operação gráfica que eu gerar será aceita por sua interface. Caso contrário, não precisamos um do outro.
Qualquer janela pode ter várias funções possíveis:
Qualquer janela pode ter várias funções possíveis:
Essa é a razão e a resposta!
Uma boa memória é certamente uma coisa boa :) Mas a memória tende a deteriorar-se ou a se tornar seletiva com a idade. O que você se lembra muito bem e o que você pensa ser insignificante, imediatamente lhe escorrega a mente. :)
Essa é a sua memória (e a minha também).
Peter tem uma memória diferente e fica melhor com a idade, como um bom vinho. Peter sempre se lembra de tudo o que escreveu, e como e por quê, e no que estava pensando. Portanto, ele realmente não precisa de OOP.
Eu invejo a memória de Peter.
Eu posso reproduzir 85% de sua mecânica com um construtor.
Tenho minhas dúvidas :) Se apenas janelas, botões, controles ... Mas isso é o mínimo que existe.
Sua interface nem sequer será capaz de processar o tráfego tumblr, e você ainda precisará render alguns indicadores.
Ah, e esta é a primeira versão da biblioteca gui, com uso mínimo de kanvas, tudo já está implementado em kanvas agora, exceto a entrada de texto.
As pessoas estão em busca de lucro. Nesta busca, eles são fixados nos mesmos grais de teste. Ou seja, programas que prometem enriquecimento com base em leituras de teste. É isso aí. É um beco sem saída a partir daqui.
Vai durar para sempre? Eles sempre confiarão no testador? Será que eles nunca ficarão desapontados olhando para dezenas de milhares de robôs "mortos"?
Por que estaria "morto"?
QUALQUER robô tem períodos de ganho. QUALQUER UM. Até mesmo os mais lamechas das minhas MUs da Liga têm curto intervalo de ganhos. Portanto, não há maneira de chamá-los de "mortos".
É como com as roupas. É claro, calções, chinelos de dedo e um terno panamá para a vida em algum lugar em Arkhangelsk. Mas você não vai afirmar que são "roupas mortas". Além disso, em alguns dias você pode usá-los até mesmo em Arkhangelsk.
E vice-versa - na costa do Mar Negro, o tulup e as botas de pele parecem bobas no verão. Embora, às vezes, elas sejam muito necessárias mesmo na costa do Mar Negro.
O mesmo ocorre com os robôs comerciais: cada mercado tem seu próprio robô comercial. E a tarefa do comerciante é selecionar o robô que se adapta ao mercado. É por isso que não se pode dizer que "as pessoas ficarão desapontadas", assim como ninguém fica desapontado com shorts ou calças panamá e ninguém fica desapontado com uma capa de chuva. Basta usar o primeiro quando está quente e o segundo quando está frio.
O testador não é um empecilho ou uma panacéia. Ele lhe diz qual tem sido o mercado ultimamente e permite que você pegue um TS que se adapte às suas necessidades. Mas isto não significa que o mercado não mudará nos próximos dias, e o TS não mais se ajustará a ele. Entretanto, é preferível um robô que tenha lucrado com a história do que um robô que tenha perdido com a história.
O comércio manual só pode ser consistentemente lucrativo se a pessoa tiver muita experiência. Só para entender quando e que técnica usar. Você acha que muitas pessoas têm isso?
Tenho minhas dúvidas :) Se apenas janelas, botões, controles ... Mas isso é o mínimo que existe.
Sua interface nem sequer será capaz de processar o tráfego de vidro, e você ainda precisará render alguns indicadores.
Sim, e esta é a primeira versão da biblioteca gui, com uso mínimo de kanvas, tudo já está implementado em kanvas agora, exceto a entrada de texto.
O construtor é projetado para soluções genéricas. Seu programa é personalizado para tarefas específicas.
Você pode fazer e operar um secador no construtor e ele vai funcionar. Mas o desenho de todos os tipos de indicadores não está incluído nas tarefas do construtor até agora.
Isto pode ser feito pelo usuário em seu programa.
E quanto ao fato de não puxar o trânsito do vidro:
Clique na foto para ver o gif. Como você pode ver, a velocidade de redesenho dos elementos da mesa é rápida o suficiente para puxar o tráfego do secador (há ainda mais células).
E quanto a não puxar o trânsito do tumblr:
Clique na foto para ver o gif. Como você pode ver nele, a velocidade de renderização dos elementos da mesa é rápida o suficiente para puxar o tráfego do copo (há ainda mais células).
Eu não estava falando da velocidade de renderização, eu estava falando do tráfego (troca) entre seu engano e o programa do usuário.
É claro que qualquer programa é adaptado para uma tarefa específica, mas usando, por exemplo, a biblioteca padrão, você pode adicionar um objeto animado na janela, e em seu erro não, você tem que pedir por ele :(