A OOP será procurada na MQL5? - página 6
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
Se você quiser, pode encontrar o OOP no BASIC, que também é um intérprete.
Acho que precisamos esperar e ver o quanto o OOP será demandado em indicadores, consultores especializados e roteiros. E sobre o fato de decidir como realmente é.
HideYourRichess писал(а) >>
Acho que devemos esperar e ver o quanto o OOP será exigido em indicadores, EAs e roteiros. E depois decidir como realmente funciona.
No momento estou tentando automatizar a cópia dos buffers de dados com todos eles em indicadores. É um processo difícil, sempre enfrento tais problemas como ausência de referências, construtores com parâmetros (a RAII é irrealizável), etc.
E eu não estou satisfeito com uma coisa semelhante que vem com ele. De forma alguma.
C-4 escreveu >>
Z.U. A maioria das pessoas associa o OOP a uma linguagem de programação particular C++
Por que, está mal implementado? Imho, muito bem implementado. Como em qualquer outra linguagem normal orientada a objetos.
O MQ5 é um OOP,
Mas é pobre em características.
OOP existe até mesmo em C, mas por alguma razão muitos não o conhecem, o que mais uma vez fala de conhecimento superficial.
Por favor, explique um pouco mais sobre este ponto.
Agora estou tentando automatizar a cópia dos dados do buffer com todos os acompanhamentos nos indicadores. Está indo duro, é complicado, estou constantemente esbarrando em paredes como falta de referências, construtores com parâmetros (a RAII é irrealizável), etc.
E eu não estou satisfeito com uma coisa semelhante que vem com ele. De forma alguma.
Para dizer a verdade, eu também tentei isso. Não foi nada de especial, apenas um golpe. Eu desisti, não consegui nada de bom com isso. Ou eu preciso me reciclar muito, ou o OOP precisa ser ampliado. Nenhum deles é esperado ainda. Em geral, eu revisei o ancinho e não entendi se eu era tão tolo ou se deveria enviar passagens para o suporte técnico, - por enquanto desisti de tudo isso.
Por favor, eu posso elaborar:
INCAPSULAÇÃO:
struct mail
{
int zipcode;
char adr[50];
char comment[10];
...
}
POLIMORFISMO ESTÁTICO:
double d=3.12, c;
int i=5;
c=d+i;
POLIMORFISMO DINÂMICO:
void qsort(void *buf, size_t st, size_t s,int (*compare) (const void *, const void *));
INCLAPSULAÇÃO:
Mesmo exemplo como no polimorfismo dinâmico, neste caso a função qsort assume as propriedades de comparação()
Por favor, eu posso elaborar:
Algo como isto era o que eu esperava ver. Somente o polimorfismo estático é contado. Não vejo nenhum sentido em continuar a discussão sobre este assunto (OOP em C) e não o farei.
Pensei que você realmente me surpreenderia.
Para resumir alguns resultados muito preliminares, podemos dizer que o OOP na implementação de metacotas não é aceito nem mesmo por programadores experientes. Talvez seja por causa da implementação. Talvez tenhamos que nos acostumar a isso e o OOP se torne realmente mais conveniente. Mas até agora temos o que temos. Parece ser mais conveniente sem ele. Isto é, provavelmente você pode escrevê-lo, mas apenas para o OOP, não para a usabilidade, velocidade de escrita, sem mencionar o desempenho do próprio código, que de qualquer forma será mais lento contra o PP.
Esse é o caso...
A necessidade de OOP é realmente tão importante (não importa quem entenda sob esta abreviação)? Para mim é mais importante quais novas funções de negociação e serviços aparecerão que facilitarão o trabalho do negociante e programador, e quão bem/completamente serão implementadas.
Se você me mostrar pelo menos dez certificados de conformidade da MQL5 com os padrões OOP, mas sem a criação de objetos por indicadores, nenhum OOP o salvará das complexidades de exibir texto simples na tela. De que serve um uso orgulhoso do OOP, se você não pode sequer usar uma roda de pulso comum neste objeto gráfico? Um botão que funciona como uma caixa de seleção, e a falta de uma caixa combinada padrão, de modo que, por exemplo, em um Expert Advisor você poderia apenas selecionar o prazo para os cálculos, e a capacidade de agrupar vários objetos em um só. Não estou nem mesmo falando do editor de formulários de diálogo, porque a plataforma é desenvolvida para auto-comercialização... :(
IMHO: Na MQL5 há apenas uma versão (fortemente) truncada das possibilidades inerentes ao OOP clássico. Os desenvolvedores fizeram um ótimo trabalho e isso certamente simplifica a escrita de um código fonte, mas é tudo em vão, e eu ainda quero um táxi, e espero que os desenvolvedores não comecem a trabalhar na MQL6 em breve, mas que trabalhem por muito tempo para "finalizar" a MQL5 ;)
Mas a demanda pelo OOP é tão importante (quem entende esta sigla)? Para mim é muito mais importante quais novas funções comerciais e de serviços aparecerão, o que facilitará o trabalho do comerciante e do programador, e quão bem/completamente serão implementadas.
Sim, é claro. E muito tem sido dito sobre isso nos fios correspondentes. Parece-me, por exemplo, que a MC, em vez de resolver problemas antigos, só tornou sua solução mais complicada com inovações.
Não estou falando de OOP neste momento. Mas a energia gasta nesta característica poderia muito bem ter sido gasta em algo realmente útil e em demanda.
Sim, é claro. E muito tem sido dito sobre isso nos tópicos relevantes. Parece-me, por exemplo, que o MC, em vez de resolver os antigos problemas, só complicou sua solução com inovações.
Não me refiro agora à OLP. Mas a energia gasta nesta oportunidade, seria bem possível gastar em algo realmente útil e em demanda.
Na verdade, não é uma pergunta simples. De fato. Não vemos nenhum redesenho no servidor. De acordo com informações incompletas na Internet, é mais legal do que era. Tudo certamente não é para nós, para os DTs, mas por outro lado o serviço pode melhorar, em geral.