Errori, bug, domande - pagina 2415

Nuovo commento
 

Questa restrizione è stata vissuta per molti anni.

La questione è sorta per la prima volta in assoluto

 
Stanislav Korotky:

Questa è una specie di restrizione draconiana. Qual è la logica al giorno d'oggi? E come è conveniente specificare gruppi di un mucchio di caratteri? Per moltiplicare una dozzina di parametri diversi? È conveniente?

La logica è nel protocollo di scambio con l'agente di prova.

Per impostare un mucchio di caratteri, scrivete quel mucchio in un file di testo e passatelo usando #property tester_file

 

Ma con un singolo test, viene anche passato all'agente di prova e funziona senza restrizioni.

Perché c'è una restrizione anche per l'input statico, potrebbe non essere passato all'agente.

Se non è nemmeno un bug, prendilo come una richiesta di miglioramento.

 
Alexey Navoykov:

Bug del compilatore: genera un errore di ambiguità, anche se qui tutto non è ambiguo. Ilprimo metodo dovrebbe essere chiamato come il più adatto. Testato in C++.

Come viene definito il metodo best-fit?

 
Slava:

La logica è nel protocollo di scambio con l'agente di prova.

Per specificare un mucchio di caratteri, scrivete quel mucchio in un file di testo e passatelo usando #property tester_file

Come si concilia questo con i prodotti per l'utente finale? Il limite potrebbe essere stato giustificato prima, ma ne dubito, sulla base di altre quantità di dati trasmessi. L'aumento del limite non comporta la minaccia di incompatibilità.

 
fxsaber:

Come si determina l'idoneità?

Se stiamo parlando dello standard C++, allora:

13.3 Risoluzione del sovraccarico. La risoluzione di sovraccarico è un meccanismo per selezionare la migliore funzione da chiamare data una lista di espressioni che devono essere gli argomenti della chiamata e un insieme di funzioni candidate che possono essere chiamate in base al contesto della chiamata. I criteri di selezione per la migliore funzione sono il numero di argomenti, quanto bene gli argomenti corrispondono alla lista dei parametri-tipo della funzione candidata, quanto bene (per le funzioni membro non statiche) l'oggetto corrisponde al parametro oggetto implicito, e certe altre proprietà della funzione candidata. [Nota: la funzione selezionata dalla risoluzione del sovraccarico non è garantita per essere appropriata al contesto. Altre restrizioni, come l'accessibilità della funzione, possono rendere il suo uso nel contesto chiamante malformato.

In altre parole, dovrebbe funzionare così:

class A { };

class B
{
  A _a[];
 public:
        A * operator[](uint i)       { return &_a[i]; }
  const A * operator[](uint i) const { return &_a[i]; }  
};

void OnStart()
{
  B b1;
  const B b2;
  b1[0]; // []
  b2[0]; // [] const
}
 
Andrey Pogoreltsev:

Se stiamo parlando dello standard C++, allora:

13.3 Risoluzione del sovraccarico. La risoluzione di sovraccarico è un meccanismo per selezionare la migliore funzione da chiamare data una lista di espressioni che devono essere gli argomenti della chiamata e un insieme di funzioni candidate che possono essere chiamate in base al contesto della chiamata. I criteri di selezione per la migliore funzione sono il numero di argomenti, quanto bene gli argomenti corrispondono alla lista dei parametri-tipo della funzione candidata, quanto bene (per le funzioni membro non statiche) l'oggetto corrisponde al parametro oggetto implicito, e certe altre proprietà della funzione candidata. [Nota: la funzione selezionata dalla risoluzione del sovraccarico non è garantita per essere appropriata al contesto. Altre restrizioni, come l'accessibilità della funzione, possono rendere il suo uso nel contesto chiamante malformato.

In altre parole, dovrebbe funzionare così:

Per b2, piena univocità. b1 non lo è.

 
fxsaber:

Come si determina quello appropriato?

In questo esempio, viene richiesto un metodo oggetto non costante, quindi, a parità di altre condizioni, dovrebbe essere chiamato.

Se rimuoviamo il casting e facciamo un argomento di tipo int per entrambi i metodi, il codice verrà compilato normalmente. Quindi, il problema in MQL riguarda il casting. Questo casting non deve influenzare il codice perché è identico.

 
fxsaber:

Per b2 c'è un'ambiguità completa. b1 non lo è.

Non c'è bisogno di ambiguità qui. Dovrebbe essere semplicemente l'ordine in cui i metodi sovraccaricati vengono applicati. Cioè il compito di risolvere il sovraccarico non è quello di creare un dilemma, ma di scegliere il metodo più adatto. Mettendo da parte il modificatore di accesso, è il primo metodo della tabella o dipende dall'implementazione del compilatore, ma non c'è ambiguità.

Ma se ci fossero 2 metodi, con diversi parametri di input, per esempio:

class B
{
  A _a[];
 public:
        A * operator[](int i)  {...}
        A * operator[](bool i) {...}  
};
B b;
b[0];    // ok
b[true]; // ok
b[0 u];   // ambiguous call to overloaded function

Tornando al C++, lo stesso vettore ne ha uno:

reference       operator[]( size_type pos );
const_reference operator[]( size_type pos ) const;

Quindi questa è una situazione perfettamente normale.

 
Stanislav Korotky:

Come si concilia questo con i prodotti per l'utente finale? Il limite potrebbe essere stato giustificato prima, ma ne dubito, sulla base di altre quantità di dati trasmessi. L'aumento del limite non comporta la minaccia di incompatibilità.

Per cominciare, nella cache di ottimizzazione, sia in MT5 che in MT4 i parametri delle stringhe sono sempre stati troncati a 63 caratteri.

Quando si inviano eventi, la stringa non può nemmeno essere più lunga di 63 caratteri.

Cioè, ciò che viene da fuori è limitato

Per quanto riguarda i prodotti per l'utente finale. Il venditore deve tenere conto delle limitazioni. E se non li conosce, allora non ha testato sufficientemente il suo prodotto prima di venderlo

1...240824092410241124122413241424152416241724182419242024212422...3184
Nuovo commento
Motivazione: