Tema interessante para muitos: o que há de novo em MetaTrader 4 e MQL4 - grandes mudanças no caminho - página 10

[Renat Fatkhullin]

Não se esqueça que temos um inliner a funcionar muito bem, que drena muitas pequenas funções, pelo que não há perda de velocidade.

E, na maioria dos casos, as chamadas para funções virtuais através do vtable são optimizadas em chamadas directas. Este é um dos métodos eficazes do optimizador. O que, aliado a múltiplas linhas, permite livrar-se quase completamente de chamadas complexas de vários níveis e fazer o código parecer plano.

[Mykola Demko]

Renat:

Não se esqueça que temos um inliner a funcionar muito bem, que drena muitas pequenas funções, pelo que não há perda de velocidade.

E, na maioria dos casos, as chamadas para funções virtuais através do vtable são optimizadas em chamadas directas. Este é um dos métodos eficazes do optimizador. Isso, aliado a múltiplas linhas, permite livrar-se quase completamente de chamadas complexas de vários níveis e fazer o código parecer plano.

:) engraçado. E ninguém argumenta que o compilador optimiza perfeitamente o código, estou apenas a mostrar ao meu amigo porque não desço antes da SB.

Ok, vamos usar exemplos:

class CiCustom : public CIndicator : public CDoubleBuffer

                пользуется включением class CSeries : public CArrayObj который в свою очередь

                                                     пользуется включением class CArrayDouble : public CArray и

                                                                           class CArrayObj : public CArray ну и конечно куда как без

                                                                                  включения class CArray : public CObject который включает

                                                                                                           class CObject и #include "StdLibErr.mqh"

é substituído na prática por uma simples função padrão

CopyBuffer(...);

Temos a arte pela arte. E assim em cada elemento que faz alguma coisa (o resto, como compreende, é escrito para que os elementos finais funcionem).

Sim, concordo com a versatilidade, sim, concordo com o código bem estruturado (pode dizer-se que é uma amostra para análise).

Mas qual é a sua essência? A questão é que esta biblioteca é principalmente necessária para o MQL5 Wizard e como um tutorial sobre o OOP.

[Georgiy Merts]

Urain:

Estou simplesmente a fazer o camarada compreender porque não caio em frente ao SB.

Sim, sim, voltarei a salientar - não tenho qualquer objecção séria a nenhum dos vossos argumentos. Uma discussão sobre isto seria mais religiosa do que objectiva.

Bem, só no seu exemplo, pessoalmente eu, e no MEU CASO, acho mais aceitável a primeira variante do código, devido a todas aquelas inclusões multiníveis que proporcionam compatibilidade do indicador com todas as interfaces, desde o CObject até ao CiCustom.

Mas, por outro lado - todas as séries cronológicas e indicadores são criados a pedido, empilhados numa única colecção, e depois disponíveis para todos os utilizadores. E quando só precisamos de copiar um tampão uma vez, perguntamo-nos porque nos preocuparmos com todo este problema.

Assim, num caso simples, claro, seria muito mais fácil utilizar CopyBuffer().

Mas e se tivermos uma dúzia de utilizadores de um determinado tampão? No meu caso - todos eles o pedirão, o tampão será criado e todos os outros terão uma referência a ele. E se utilizarmos CopyBuffer() "directamente" - terei dez cópias em vez de uma. E quando se usa CopyBuffer() de forma mais astuciosa, obtém-se material com rastreio de quem e que tampão foi atribuído, o que é bastante equivalente ao custo do encapsulamento que mencionou.

Pessoalmente, sou a favor da razoabilidade - não faz sentido fazer uma parcela tão grande com o OOP para um único lugar. Se temos muitos utilizadores, então a abordagem OOP, na minha opinião, justifica-se a si própria.

[[Excluído]]

Urain:

Então é tempo de introduzir excepções para que um código possa ser compilado para mql4 e mql5.

A questão da unificação está a aproximar-se.

Concordo. Característica muito útil.

C-4:
Estava a pensar que ao fundir duas línguas, directivas de compilação condicional como #ifdef são absolutamente necessárias - isto simplificaria a unificação dos códigos entre as duas plataformas, e o API dependente da plataforma seria definido no momento da compilação.

Somos pelo menos quatro agora :)

[[Excluído]]

Renat:
Infelizmente, não. O testador permanecerá com um único fio e sem MQL5 Cloud Network.

E as moedas múltiplas?

[Renat Fatkhullin]

Em Mt4, a ideologia do testador permanecerá a mesma. Não faremos quaisquer mudanças fundamentais, pelo menos não num futuro próximo.

[Georgiy Merts]

Renat:

Não se esqueça que temos um inliner a funcionar muito bem, que drena muitas pequenas funções, pelo que não há perda de velocidade.

E, na maioria dos casos, as chamadas para funções virtuais através do vtable são optimizadas em chamadas directas. Este é um dos métodos eficazes do optimizador. Isso, aliado a múltiplas linhas, permite-lhe livrar-se quase completamente de chamadas complexas de vários níveis e fazer o código parecer plano.

Ahhhh... Agora vejo porque é que um dos meus erros mais frequentes ao escrever um programa é "A função deve ter um corpo".

É o inliner que requer... Estava a pensar porque pensava que um cabeçalho de função é suficiente para compilar um módulo, mas não... Precisa de um corpo...

Isso é bom.

[Renat Fatkhullin]

Laryx:

Ahhhh... Agora vejo porque é que um dos meus erros mais frequentes quando escrevo um programa é "A função deve ter um corpo".

É o inliner que requer... Estava a pensar porque pensava que um cabeçalho de função é suficiente para compilar um módulo, mas não... Precisa de um corpo...

É correcto, mas não tem nada a ver com o optimizador.

Se tiver descrito o protótipo de uma função de classe, o corpo deve estar lá. Mesmo que esteja vazio.

[[Excluído]]

Renat, sugiro que em MT4 façamos o controlo da visibilidade das posições no mapa não nos parâmetros gerais do terminal, mas separadamente para cada mapa (como foi feito em MT5).

A minha candidatura ao SR sobre este assunto está adormecida há já dois meses.

[Renat Fatkhullin]

Interesting:

Renat, sugiro que em MT4 façamos o controlo da visibilidade das posições no mapa não nos parâmetros gerais do terminal, mas separadamente para cada mapa (como foi feito em MT5).

A minha candidatura ao SR sobre este assunto está adormecida há já dois meses.

Enquanto trabalhamos nos objectos, vamos ver.