Errori, bug, domande - pagina 1749
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Ho fatto un indicatore di tick in kodobase. Ma non riesco ad allegare le fonti - premo "Attach files", l'iscrizione scompare, ma l'interfaccia per selezionare i file non appare.
forse è installato un adblock che blocca tutti i pop-up
Non ho cambiato nulla. Tutto funzionava prima.
Quando faccio il check-out, premo questo pulsante
Non torna niente, tranne questo.
Sì, ho capito la sua domanda. C'è una funzione con una firma più appropriata, ma non può essere chiamata perché è protetta. Sì, il comportamento è diverso da Studio: in MKL, c'è un controllo più stretto del tipo (in questo caso). Non so se questo dovrebbe essere considerato un bug. Se si controlla il tipo di argomento passato alla funzione, non c'è nessun problema.
Il controllo è piuttosto selettivo e quindi più incoerente, che segue da qui
class A {
}public:
void f( int ) const {} /*(1)*/
void f( int ) {} /*(2)*/
};
class B : public A {
public:
void f( int ) const {} /*(3)*/
};
void OnStart()
{
B b; //не const B
b.f( 0 ); //(*)
Ma il C++ non analizza sempre una classe base per un metodo più adatto se quella derivata ne ha solo uno adatto.
E MQL - nell'esempio precedente, ha analizzato la classe base per un metodo più adatto, mentre in questo non lo fa (qui così come C++ chiamerà B::f/*(3)*/), il che significa che non c'è un approccio unificato
Un altro esempio di controllo incoerente: C++ trova il seguente codice
void f( int i ) const {}
void f( uint i ) {}
};
void OnStart()
{
A a;
a.f((int)0 );
}
Il controllo è piuttosto selettivo e quindi più incoerente, che segue da qui
class A {
}public:
void f( int ) const {} /*(1)*/
void f( int ) {} /*(2)*/
};
class B : public A {
public:
void f( int ) const {} /*(3)*/
};
void OnStart()
{
B b; //не const B
b.f( 0 ); //(*)
Ma C++ non analizza sempre una classe base per un metodo più adatto se quella derivata ne ha già uno adatto.
E MQL - nell'esempio precedente, ha analizzato la classe base per un metodo più adatto, mentre in questo non lo fa (qui così come C++ chiamerà B::f/*(3)*/), il che significa che non c'è un approccio unificato
Un altro esempio di controllo incoerente: C++ trova il seguente codice
void f( int i ) const {}
void f( uint i ) {}
};
void OnStart()
{
A a;
a.f((int)0 );
}
Che compilatore C++ usi? Io uso gcc e tutto passa senza errori
void f( int i ) const {} //1
void f( unsigned int i ) {} //2
};
void OnStart()
{
A a;
a.f((int)0 );
}
(1) o (2). Ora inserirò il messaggio del compilatore
Questo è davvero un controllo rigoroso: un metodo è più adatto in termini di firma, l'altro in termini di costanza.
Questo è davvero un controllo rigoroso: un metodo è più adatto per firma, l'altro per costanza
E non è chiaro perché lei dovrebbe scrivere una cosa del genere.
Sostituisci f -> operatore[], prendi il tuo recente esempio - pensa a come rendere [] sia a sinistra che a destra. Aggiungete la costanza al gusto - poi avvolgetelo in una sagoma e avrete qualcosa di simile.
Se fare const - considerare senza se
Se non ci può essere ambiguità, si dovrebbe almeno emettere un avvertimento
Sostituisci f -> operatore[], prendi il tuo recente esempio - pensa a come rendere [] sia a sinistra che a destra. Aggiungete la costanza a piacere - poi avvolgetelo in una sagoma e avrete qualcosa di simile.
Di quale esempio stiamo parlando? Potresti dare non la fonte, ma la voce finale che dovrebbe funzionare?
Dovresti finire con qualcosa come questo
{
A<int> a;
int b = a[ 0 ];
a[ 0 ] = a[ 1 ];
a[ 1 ] = b;
}
Dovresti finire con qualcosa come questo
{
A<int> a;
int b = a[ 0 ];
a[ 0 ] = a[ 1 ];
a[ 1 ] = b;
}