Erros, bugs, perguntas - página 714

[[Excluído]]

victorg:

Uma macro e uma função em linha são de facto coisas diferentes. Mas não é isso que eu quero dizer. Eis um exemplo em que os valores dos argumentos são desconhecidos no momento da compilação

No primeiro caso, o código deve ser colado na função actual (suponho) e, no segundo caso, a função é chamada com parâmetros passados através da pilha (suponho). Mas para efeitos de optimização, o compilador pode de facto implementar a segunda variante também através de substituição. É assim? Não sei. Foi por isso que perguntei.

São os Metakvots que têm de ser torturados. Mas a minha opinião coincide com a sua (devido à optimização, o resultado pode ser diferente).

[Andrew Petras]

O objecto da elipse só é realçado com o rato se clicar nos pontos de ancoragem.

É um insecto ou uma característica? É implementado de forma muito inconveniente.

[Andrew Petras]

A escala vertical, se definida manualmente, não é lembrada no reinício. Também um incómodo.

[speedy]

MetaDriver:

Это что, юмор такой чёрный?

1.  Извини, - бред.  Я понимаю, тут паранойя в моде, и является ломовым аргументом за "почему так не надо делать".  Никакой опасности не вижу в упор. Смотрел внимательно, если чё.  Любое имя, в конечном счёте есть ссылка.  Индексация есть обычное расширение понятия имени. Не более.  Давай запретим присваивание вообще.  В целях безопасности.  Ссылки же крайне опасны так?

2.  Духу объектно-ориентированного программирования, при такой логике, яростно противоречат С++, С#, Делфи, пара дюжин менее популярных языков, в которых индексаторы совершенно нормально работают и справа и слева.  Причём здравому смыслу и моему духу это почему-то не противоречит.

Индексаторы делаются для связи с внешней средой.  Их функция именно интерфейсная.  Я могу инкапсулировать и прятать что угодно, но индексы мне нужны для оперирования объектами как массивами. Фактически все массивы как-то устроены. Например обычные динамические массивы mql. Может запретим их слева от оператора присваивания ставить?  Заменим функцией какой-нибудь типа SetArrayValue(array, i, j, value);  Заодно и в читабельности выиграем. Да и отладка станет куда проще.  Мля. Уф..

3.  А как насчёт того, чтоб сделать нормальный индексатор?  Горничная это конечно классно, но королева всё-таки лучше.

4.  Вот в этом месте у меня крыша конкретно начала ехать.  Это что, нечитабельно??

Вот это читабельнее, да?

  t.setDataElement(i, i*i);

Круто.  Пожалуй пойду лечиться.

5.  Ваще круто.

6. Я плакаль.

e(array, i, j, valor); Isto também melhorará a legibilidade. E a depuração também se tornará muito mais fácil. Merda. Ugh....

Bem, um setter tem a vantagem de poder fazer algo mais do que uma simples equação.

Por exemplo, pode registar informações, converter dados (se estamos a falar de strings ou dados mais complexos), enviar mensagens a outros objectos se algo importante acontecer (como dados de actualização).

Como é que o seu objecto saberá quando a data tiver mudado? Aparentemente, vai guardar citações...
Oh sim, isso é um falso problema, porque o seu objecto é mais como uma estrutura e não consegue realmente nada.
Tudo é feito noutra classe de lixo, que trata de tudo ou ainda pior, tudo acontece em onStart(), onTick(), ... ! :)

Tenha um bom dia

[TheXpert]

MetaDriver:

3. que tal fazer um indexador normal? empregada é fixe, mas rainha é melhor.

Junta muti. No entanto, em comparação com um valor normal, será muito mais caro em termos de tempo. Mas será exactamente o aspecto de que necessita.

______

Ah, inferno, não. Depois é necessário um operador fantasma do tipo sobrecarga. É uma pena.

[Vladimir Gomonov]

speedy:

Bem, a vantagem do compositor é que se pode fazer algo mais do que uma simples equação.

Por exemplo, pode registar informações, converter dados (se estamos a falar de strings ou de dados mais complexos), enviar mensagens a outros objectos se algo importante acontecer (como dados de actualização).

Como é que o seu objecto saberá quando a data tiver mudado? Aparentemente, vai guardar citações...
Oh sim, é um falso problema, porque o seu objecto é mais estruturante e não controla realmente nada.
Tudo é feito noutra classe de lixo, que trata de tudo ou ainda pior, tudo acontece em onStart(), onTick(), ... ! :)

Tenha um bom dia

A questão é que o indexador é o mesmo que o setter em termos de características . É implementado como uma função, cujo conteúdo pode ser qualquer coisa (o caso típico mais simples é a verificação e o tratamento de outros erros), e não é apenas devolver uma referência a um item da matriz.

Tenha também um bom dia.

(Desculpe pelo tom de ontem. Estava um pouco nervoso - problemas no trabalho. Não teve nada a ver com isso. Bem, a menos que esteja a ser demasiado categórico :)

[Vladimir Gomonov]

TheXpert:

Junta Muti. No entanto, em comparação com um valor normal, será muito mais caro em termos de tempo. Mas terá o aspecto que precisa.

______

Ah, inferno, não. É necessário então sobrecarregar o operador de conversão de tipo. Que pena.

Na verdade, penso que o farão. Há uma falha óbvia com os retornos de referência na língua.

Não é necessário fazer variáveis de referência, mas o retorno do valor l das funções é sagrado... :)

Não creio que não possa ser resolvido em princípio - a linguagem tem mql-arrays habituais e eles sentem-se muito bem em ambos os lados do operador de afectação. Mas são classes C++ por implementação !

Aqui está outro exemplo da mesma série. Este código compila mas não funciona.

#define _MyContainer(name,type,size)  struct name { public: type array[size]; type At(int i) {return array[i];} }
#define  ASize 8
#define  BSize 4

//+------------------------------------------------------------------+
//| Script program start function                                    |
//+------------------------------------------------------------------+
void OnStart()
  {
   _MyContainer(MyClass, int, ASize);
   MyClass MyVar;
   Print(sizeof(MyVar)); 
   for(int i=0;i<ASize;i++)
     {
      MyVar.array[i]=i*i;
     }
   for(int i=0;i<ASize;i++)
     {
      Print(MyVar.At(i));
     }
   _MyContainer(My2DBag, MyClass, BSize);
   My2DBag MyVar2D;
   for(int i=0;i<BSize;i++)
     {
      for(int j=0;j<ASize;j++) MyVar2D.array[i].array[j]=(i+1)*(j+1);
     }
   for(int i=0;i<BSize;i++)
     {
      for(int j=0;j<ASize;j++) Print(MyVar2D.At(i).At(j));
// Run-time ERROR:  DefTest (USDJPY,M30)  invalid pointer access in 'DefTest.mq5' (38,46)

//      for(int j=0;j<ASize;j++) Print(MyVar2D.array[i].At(j));
     }
  }

O meu ponto não é que não devam compilar - o meu ponto é que devem trabalhar. :)

[Ilyas]

MetaDriver:

...
Não estou a dizer que não deve compilar, estou a dizer que deve funcionar... :)

Sim, tem razão, é um erro de compilação, nós vamos corrigi-lo.

[Denis Kirichenko]

A MQL5 tem uma maravilhosa constante IS_DEBUG_MODE pertencente ao grupo Other Constants. Podemos acrescentar tal constante para um testador? Algo como IS_TESTER_MODE...

[Yedelkin]

denkir:

A MQL5 tem uma maravilhosa constante IS_DEBUG_MODE pertencente ao grupo Other Constants. Podemos acrescentar tal constante para um testador? Algo como IS_TESTER_MODE...

Será que estas constantes não funcionariam?

ENUM_MQL5_INFO_INTEGER

Identificador	Descrição	Tipo de propriedade
MQL5_PROGRAM_TYPE	Tipo de mql5-programa	ENUM_TIPO_DE_PROGRAMA
MQL5_DLLS_ALLOWED	Permissão para utilizar a DLL para oprograma actual em execução	bool
MQL5_TRADE_ALLOWED	Permissão paranegociar para este programa em execução	bool
MQL5_DEBUGGING	Sinal de um programa em execução a funcionar em modo de depuração	bool
MQL5_TESTING	Sinal de execução de um programa no testador	bool
MQL5_OPTIMIZAÇÃO	Sinal de execução de um programa durante a optimização	bool
MQL5_VISUAL_MODE	Sinal de execução de um programa em modo de teste visual	bool