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
non importa cosa inizializzare, anche int - qualsiasi numero per chiamare questo costruttore
e ho scelto 0.0 per evitare errori di stampa - qualsiasi cifra, cioè 0.0. È più difficile da scrivere e sbagliare rispetto a 123
(doppio)0
ma neanche così)))) appena adesso ha guardato il codice normalmente, c'è ancora un modo per guardarlo in modo anomalo))(doppio)0
no
Scrivo solo 0,0 - non sono previsti altri numeri - non c'è nemmeno una variabile nel costruttore
in generale, come stile di un autore alla moda, probabilmente non il migliore
il punto non è la x) ma che ci può essere un float sul ricevitore, e non è affidabile nemmeno specificare 0,0
0.0 è un doppio inequivocabile per il compilatore, float sarà 0.f
credito)
Mentre la sezione "domande over 50" è aperta, permettetemi di interporre la mia sull'argomento dei calchi.
- Quali sono alcuni modi per migliorare il codice in termini di tolleranza agli errori o non ridondanza?
- È necessario il controlloCheckPointer()!=POINTER_INVALID? O decisamente non necessario? Spiega perché.
- portando a non-const, in modo che sia possibile chiamare metodi non-const. I metodi non-const possono essere chiamati direttamente nel metodo Compare ? Cioè sbarazzarsi del giallo evidenziato const ?
Mentre la sezione "domande over 50" è aperta, permettetemi di interporre la mia sull'argomento dei calchi.
- Quali sono alcuni modi per migliorare il codice in termini di tolleranza agli errori o non ridondanza?
- È necessario il controllo CheckPointer()!=POINTER_INVALID? O decisamente non necessario? Spiega perché.
- portando a non-const, in modo che sia possibile chiamare metodi non-const. I metodi non-const possono essere chiamati direttamente nel metodo Compare ? Cioè sbarazzarsi del giallo evidenziato const ?
È un po' come il tuo, solo con meno lettere. È una questione di gusti, a chi piace di più, ma ho rimosso la variabile extra (il compilatore probabilmente la rimuoverebbe anche nel quadro dell'ottimizzazione).
Per quanto riguarda il mio controllo dei nodi. Deve essere sostituito con CheckPointer(node)==POINTER_INVALID, ma è un overhead - una chiamata di funzione. Anche se è inlined, è comunque almeno dereferenziato e controlla il flag di stato. Se solo library o concrete, avete scritto il programma userà i metodi Compare, meglio !node e sul codice per guardare se il puntatore non è valido. Se siete troppo pigri per fare attenzione ai puntatori o se è una libreria per sfigati, solo CheckPointer(node)==POINTER_INVALID.
Se rimuovete lo specificatore const che avete evidenziato, non potete chiamare questi metodi da un oggetto costante.
UPD: il controllo evidenziato può essere rimosso, perché è nei metodi chiamati.
Mentre la sezione "domande over 50" è aperta, permettetemi di interporre la mia sull'argomento dei calchi.
- Quali sono alcuni modi per migliorare il codice in termini di tolleranza agli errori o non ridondanza?
- È necessario il controllo CheckPointer()!=POINTER_INVALID? O decisamente non necessario? Spiega perché.
- portando a non-const, in modo che sia possibile chiamare metodi non-const. È possibile chiamare un metodo non-const direttamente nel metodo Compare ? Cioè sbarazzarsi del giallo evidenziato const ?
L'idea è di scrivere due metodi della stessa funzione con e senza il corpo const - a dir poco - non ne vale la pena))))
Ma la probabilità di incontrare due metodi è vicina allo zero.... Perché la possibilità di esistenza diCChartObjectRectangle::Price - senza const nel corpo - penso sia improbabile.
La chiamata di questa funzione dall'esterno non ha alcun effetto. Cioè la const funziona solo con le funzioni interne e si assicura che nulla sia stato scritto nella memoria dell'oggetto (non ha cambiato il valore della variabile). In altre parole, non potete chiamare Set(a) durante la cost... Spesso, in un po' di confusione, per assicurarsi che questa funzione non sovrascriva nulla, si possono sistemare rapidamente queste consts (anche se questa è probabilmente la mia cancellazione).
Considerate che le consts dovrebbero essere infilate proprio ovunque senza ottenere)))) per rendere più facile controllare qualcosa in seguito.
CheckPointer()!=POINTER_INVALID ha bisogno di un controllo?
E perché no.... farne uno bool Check(<template> &T) { retun CheckPointer(T)!=POINTER_INVALID } Il compilatore dovrebbe renderlo il più semplice possibile. E sarà ancora più bello.
È più veloce.
Beh, non ho cambiato molto.
Questo è tutto il tuo codice.
Sembra essere lo stesso del tuo, solo con meno lettere. Quindi, è una questione di gusti, ma ho rimosso la variabile extra (molto probabilmente, il compilatore l'avrebbe rimossa come parte dell'ottimizzazione).
Per quanto riguarda il mio controllo dei nodi. Deve essere sostituito con CheckPointer(node)==POINTER_INVALID, ma è un overhead - una chiamata di funzione. Anche se è inlined, è comunque almeno dereferenziato e controlla il flag di stato. Se solo library o concrete, avete scritto un programma che userà i metodi Compare, meglio !node e sul codice per guardare se il puntatore non è valido. Se siete troppo pigri per fare attenzione ai puntatori o se è una libreria per sfigati, solo CheckPointer(node)==POINTER_INVALID.
Se rimuovete lo specificatore const, non potete chiamare questi metodi da un oggetto costante.
mi ci è voluto molto tempo per aprire la scheda
Immagino che 4 anni di università non abbiano aggiunto molto alla mia conoscenza (la spiegazione è in ritardo nella spazzatura).
la variante senza la costituzione, poiché la classe base non ha alcun riferimento ai parametri di input, funzionerà anche correttamente, sebbene questo non sia uno stile molto intelligente
Anche una variante dello stesso codice.
È lo stesso con le costanti.