Erros, bugs, perguntas - página 2163

 
Комбинатор:


Creio que é muito melhor nas optimizações, mas da perspectiva de um utilizador comum parece estranho - afirma-se que o compilador MQL gera código comparável ao C++, mas depois verifica-se que as matrizes em MQL não são de todo rápidas.

Linguagem gerida/gerida significa claramente que as matrizes devem ser rigorosamente controladas. Sem isto, a língua não pode ser segura.

Para arrays estáticos, o controlo é mais simples e pode ser parcialmente simplificado na fase de optimização do código. Para as matrizes dinâmicas há mais controlo e é difícil de simplificar.

O código é gerado ao nível da qualidade C++, mas existe certamente uma sobrecarga nas coisas geridas. A matemática, os loops e tudo o resto está ao nível de C++.

 
Комбинатор:

o índice da matriz é, na melhor das hipóteses, também reduzido a um único comando de montagem directa, pelo que a questão continua a ser

Em linguagem gerida apenas em matriz estática com indexação constante. Isto é, se o optimizador estiver 100% seguro de que não há necessidade de verificar os limites e a disponibilidade de tampão.

Se as condições forem violadas, aparece o tampão e a[s] verificação[s] dos limites.

Este é um conhecimento básico a ter quando se programa.

 
Vladimir Pastushak:
Se uma função sobrecarregada tem enumToString, há um problema ao chamá-la para um número inteiro...

Tenho estado a prestar atenção a isto https://www.mql5.com/ru/forum/1111/page1297#comment_1382986

Mas não mudaram nada, por isso ::EnumToString em modelos é inútil em muitos casos

Ошибки, баги, вопросы
Ошибки, баги, вопросы
  • 2015.02.16
  • www.mql5.com
Общее обсуждение: Ошибки, баги, вопросы
 

Continuar a explorar projectos e tropeçar em

#resource "\\Experts\\[Project 2018]\\Expert Name\\Resources\\img\\open_buy.bmp"

resource name is too long '\Experts\[Project 2018]\Expert Name\Resources\img\open_buy.bmp' CPanel.mqh 6 1

Porque precisamos de projectos se somos limitados?

Um projecto é PROJECT!!!!! que poderia ter 1000 imagens, sons, ficheiros de ajuda e temos de colocar tudo numa só pasta ?

Não sou adepto de confusão em directórios, escrever muita qualidade deve estar em ordem não só na sua cabeça mas também em todo o lado...



 
A100:

Eu estava a prestar atenção a isto https://www.mql5.com/ru/forum/1111/page1297#comment_1382986

Mas nada foi alterado, por isso ::EnumToString em modelos é inútil em muitos casos

Olá de fxsaber:

// Для enum-ов
template <typename T>
string EnumToString2( T Value ) { return(EnumToString(Value)); }
 
// Для кастомных типов
template <typename T>
string EnumToString2( const T& ) { return(NULL); }
 
 
// Для стандартных типов
#define  ENUMTOSTRING(A) string EnumToString2( A ) { return(NULL); }
  ENUMTOSTRING(int)
  ENUMTOSTRING(string)
// .....
#undef  ENUMTOSTRING
 
#define EnumToString EnumToString2
 
template<typename T>
string ETS( T t ) { return ( typename( t ) == "int" ? "OK" : ::EnumToString( t ) ); }
enum ENUM {     ENUM__ };
 
void OnStart()
{
        ENUM i1 = ENUM__;       Print( ETS( i1 )); //нормально
        int  i2 = 0;            Print( ETS( i2 )); //"ошибка компиляции"
        string i3 = NULL;       Print( ETS( i3 )); //"ошибка компиляции"
}
 
Комбинатор:

Portanto, tirar um elemento por índice de uma simples matriz deveria ser uma operação muito rápida, não deveria?

Mas a não-recuperação é ainda mais rápida. De alguma forma notei que se utilizar números de ponto flutuante em vez de números inteiros, o meu programa funciona uma vez e meia mais rápido. Expliquei-me a mim próprio que o meu co-processador da FPU estava maioritariamente inactivo, utilizando na sua maioria inteiros. No meu caso também se pode ter em conta: SQRT é executado na FPU, ALU liberta tempo, eles começam a trabalhar em paralelo em grande medida.
 
Vladimir Pastushak:

Continuar a explorar projectos e tropeçar em

#resource "\\Experts\\[Project 2018]\\Expert Name\\Resources\\img\\open_buy.bmp"

resource name is too long '\Experts\[Project 2018]\Expert Name\Resources\img\open_buy.bmp' CPanel.mqh 6 1

Porque precisamos de projectos se somos limitados?

Um projecto é PROJECT!!!!! que poderia ter 1000 imagens, sons, ficheiros de ajuda e temos de colocar tudo numa só pasta ?

Não sou adepto de confusão em directórios, escrever muita qualidade deve estar em ordem não só na sua cabeça mas também em todo o lado...

Parcialmente correcto para objectos que são incluídos em tempo de compilação e que não entram em código como objectos nomeados.

O problema é que dentro do ficheiro EX existe um limite físico de 64 caracteres para os recursos nomeados.
 
Artyom Trishkin:

Olá de fxsaber:

O código acima é baseado numa falha de compilação

void f(       int  ) { Print( 1 ); } //(1)
void f( const int& ) { Print( 2 ); } //(2)
void OnStart()
{
    int i = 0;
    f( i ); //нормально ???
}

Resultado: 1... e porque não 2 ?

Porque C++ reporta um erro durante a compilação, porque ambas as funções encaixam obviamente e além da ordem actual no MQL não permite explicitamente a função de chamada (2)

Se este erro for eliminado, o código dado tornar-se-á, na sua maioria, inoperacional

 

Erro de compilação: erro de optimização da árvore

class A {
public:
    void f() {}
};
typedef A* (*fn)();
#import "Test.ex5"
    fn g();
#import
void OnStart() { g()().f(); }
 
Renat Fatkhullin:
Iremos corrigir parcialmente os objectos, que são incluídos em tempo de compilação e não entram no código como um objecto nomeado.

A questão é que existe uma limitação física de 64 caracteres para os recursos nomeados dentro do ficheiro EX.

Há muito pouco espaço para descrições de produtos.

3600 caracteres é muito pouco para programas grandes e sérios.

Penso que muitas pessoas estarão de acordo comigo.

Para descrever programas não precisa de menos de 5000 - 10000 caracteres. Ou pelo menos um separador com o nome das definições do programa

Um moderador pode sempre pedir para remover a água.

Agora estou a escrever uma descrição do programa, usei todos os 3600 caracteres apenas para a descrição das definições e nem sequer descrevi metade das características...
Razão: