Domanda sulla digitazione - pagina 7

Nuovo commento
 
Dmitry Fedoseev:

Che problema ha la gente))) Vivrò una lunga vita!

A proposito, scrivered=array[5].to_double() è molto più facile did=(double)array[5] Solo un punto da premere. Ma non stiamo cercando vie facili.

Perché scrivere d=(double)array[5]? Questa è l'idea - non preoccuparsi di questa banalità. Ecco un pezzo di codice reale:

MYCRTMFLT(i+1, chart[MYSEG(MYSCNT-i).start].time,
               chart[MYSEG(MYSCNT-i).start].price,
               chart[MYSEG(MYSCNT-i).top].time,
               chart[MYSEG(MYSCNT-i).top].price, 
               chart[MYSEG(MYSCNT-i).top].price>chart[MYSEG(MYSCNT-i).start].price?
                 MYCLRUP : MYCLRDOWN, STYLE_SOLID, true);

chart[index] ritorna struct {price; time} E perché continuo ad aggiungere .time/.price, quando nella maggior parte dei casi si può capire dal contesto? Sì, a volte avrete bisogno di un suggerimento (come nella penultima riga), ma nella maggior parte dei casi la vita sarà più facile e ci sarà meno da scrivere.

 
Dmitry Fedoseev:

Che problema ha la gente))) Vivrò una lunga vita!

A proposito, scrivered=array[5].to_double() è molto più facile did=(double)array[5] Solo un punto da premere. Ma non stiamo cercando vie facili.

Sì, certo, si deve necessariamente scrivere d=(doppio)array[5] quando si sa già al momento della compilazione che d non può essere altro che doppio. I topi piangevano e imploravano ma continuavano a mordere il cactus...

 
Ilya Malev:

Sì, certo, è obbligatorio scrivere d=(double)array[5], quando si sa già durante la compilazione che d non può essere altro che double... i topi piangevano e imploravano, ma continuavano a rosicchiare il cactus...

In C++ sovraccaricano Oregatog<=> per d, rosicchiare e non piangere ;-)

PS/ e in vista dell'associatività e delle priorità usare << operatore come più adatto
 
pavlick_:

Perché scrivere d=(double)array[5]? Questa è l'idea - non preoccuparsi di questa banalità. Ecco un frammento di codice reale:

chart[index] restituisce struct {price; time}. E perché continuo ad aggiungere .time/.price, quando nella maggior parte dei casi possiamo capirlo dal contesto? Sì, a volte avrete bisogno di un suggerimento (come nella penultima riga), ma nella maggior parte dei casi la vita sarà più facile e ci sarà meno da scrivere.

Il programmatore intende sovraccaricare (double) in modo chearray[5] restituisca il numero double invece di qualche oggetto. Non è così?

Dov'è questo contesto nell'esempio dato dove possiamo capirlo? È il tipo di parametro MYCRTMFLT? Questo è un sovraccarico sul tipo di valore di ritorno.

 
fxsaber:

Se vuoi davvero, puoi fare così

ecc.

 _W(Color)[2] = (uchar)230;              // Записали по смещению 2 значение (uchar)230.
  PRINT(Color)                           // Убедились, что Color теперь C'241,248,230'
Non è lo stesso diPrint(ColorToString(Color&(uint(-1)&65535)|(230<<16)); ?

Ho paura di rompermi il cervello se continuo a studiare i vostri codici.

Voglio dire che tutto nei vostri metodi è ammirevole (non scherzo) tranne l'abbondanza di lettere maiuscole con sottolineature e operazioni di risoluzione del contesto:)

Penso che se (operazione di risoluzione di un contesto) sarà permesso di sovraccaricare, voi insieme alle vostre biblioteche andrete in astrale :lol:

 
Maxim Kuznetsov:

PS/ e, a causa dell'associatività e delle priorità, utilizzare l'operatore << come più appropriato

L'ho pensato anch'io, francamente. Sovraccaricate << con >> e non soffrite. Ma ciò non elimina l'opportunità di permettere l'overloading di T()

 
Dmitry Fedoseev:

Da quanto ho capito, stanno per sovraccaricarlo qui, in modo chearray[5] non restituisca un oggetto, ma un numero doppio. Non è così?

Dov'è in questo esempio questo contesto che può essere compreso? È il tipo di parametro MYCRTMFLT? Questo è un sovraccarico sul tipo di valore restituito.

Non vedo alcun problema:

double d;
d = chart[i];  // call operator double

void f(datetime t);
f(chart[i]);  // call operator datetime

La macro terminerà con qualche identificatore o chiamata di funzione e il compilatore capirà cosa ci si aspetta da essa. E se non lo fa (errore di compilazione con imprecazioni sull'ambiguità), allora potete sempre aiutarlo: chart[i].price

 
Ilya Malev:

Sì, certo, si deve necessariamente scrivere d=(double)array[5], quando si sa già durante la compilazione che d non può essere altro che double... i topi piangevano e piangevano, ma continuavano a rosicchiare il cactus...

Oltre a d c'è anche qualcos'altro con il nome array.

Non è affatto male quando il compilatore avverte di assegnare tipi inappropriati. Dovremmo mostrare al compilatore che coloro che hanno scritto questo codice si assumono la piena responsabilità del risultato, in modo che non si lamentino in seguito dell'assenza di avvertimenti generati dal compilatore.

 
pavlick_:

Non vedo alcun problema:

...

Nemmeno io.
 
Dmitry Fedoseev:

Non è affatto male che il compilatore avverta di assegnare tipi inappropriati. Dobbiamo mostrare al compilatore che chi ha scritto questo si assume la piena responsabilità del risultato, in modo che non si lamenti in seguito dell'assenza di avvertimenti del compilatore.

Solo non in quel caso quando lui stesso ha definito il metodo operator double(){...} per questa assegnazione, ovviamente per non scrivere (double) dopo una variabile di tipo double o ricevere avvisi generati dal compilatore.

In generale, la conversazione sta ovviamente già andando in circolo, speriamo che il sovraccarico di tipo sia permesso alla fine, personalmente non mi dispiacerebbe se per abilitarlo mettessi un segno di spunta da qualche parte nelle opzioni e confermassi che "Accetto di essere pienamente responsabile del risultato".

12345678910
Nuovo commento
Motivazione: