Question sur la dactylographie - page 7

Nouveau commentaire
 
Dmitry Fedoseev:

Quel problème ont les gens))) Je vivrai longtemps !

À propos, écrired=array[5].to_double() est beaucoup plus facile qued=(double)array[5]. C'est juste un point à souligner. Mais nous ne cherchons pas la facilité.

Pourquoi écrire d=(double)array[5] ? C'est l'idée - ne pas s'embêter avec ces futilités. Voici un morceau de code réel :

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] returns struct {price ; time} Et pourquoi je continue à y ajouter .time/.price, alors que dans la plupart des cas, on peut le comprendre à partir du contexte ? Oui, vous aurez parfois besoin d'inciter (comme dans l'avant-dernière ligne), mais dans la plupart des cas, la vie sera plus facile et il y aura moins d'écriture.

 
Dmitry Fedoseev:

Quel problème ont les gens))) Je vivrai longtemps !

À propos, écrired=array[5].to_double() est beaucoup plus facile qued=(double)array[5]. C'est juste un point à souligner. Mais nous ne cherchons pas la facilité.

Oui, bien sûr, on doit nécessairement écrire d=(double)array[5] alors qu'on sait déjà au moment de la compilation que d ne peut être que double. Les souris pleuraient et suppliaient mais continuaient à mordre le cactus...

 
Ilya Malev:

Oui, bien sûr, il est obligatoire d'écrire d=(double)array[5], alors que l'on sait déjà lors de la compilation que d ne peut être que double... les souris ont pleuré et supplié, mais ont continué à ronger le cactus...

En C++ ils surchargent Oregatog<=> pour d, ronger et ne pas pleurer ;-)

PS/ et en vue de l'associativité et des priorités utiliser l'opérateur << comme plus approprié
 
pavlick_:

Pourquoi écrire d=(double)array[5] ? C'est l'idée - ne pas s'embêter avec ces futilités. Voici un vrai fragment de code :

chart[index] returns struct {price ; time}. Et pourquoi je continue à y ajouter .time/.price, alors que dans la plupart des cas nous pouvons le comprendre à partir du contexte? Oui, vous aurez parfois besoin d'inciter (comme dans l'avant-dernière ligne), mais dans la plupart des cas, la vie sera plus facile et il y aura moins d'écriture.

Le programmeur a l'intention de surcharger (double) pour quearray[5] renvoie le nombre double au lieu d'un objet quelconque. N'est-ce pas ?

Où se trouve ce contexte dans l'exemple donné où nous pouvons le comprendre ? S'agit-il du type de paramètre MYCRTMFLT ? Il s'agit d'une surcharge sur le type de la valeur de retour.

 
fxsaber:

Si tu le veux vraiment, tu peux faire ça.

etc.

 _W(Color)[2] = (uchar)230;              // Записали по смещению 2 значение (uchar)230.
  PRINT(Color)                           // Убедились, что Color теперь C'241,248,230'
N'est-ce pas lamême chose quePrint(ColorToString(Color&(uint(-1)&65535)|(230<<16)) ; ?

J'ai peur de me casser le cerveau si je continue à étudier vos codes.

Je veux dire que tout dans vos méthodes est admirable (sans blague) sauf l'abondance de lettres majuscules avec des underscores et les opérations de résolution de contexte:)

Je pense que si l'on permet à cette opération de résolution de contexte de se surcharger, vous et vos bibliothèques irez dans l'astral :lol :

 
Maxim Kuznetsov:

PS/ et, en raison de l'associativité et des priorités, utiliser l'opérateur << comme plus approprié

Ça m'a traversé l'esprit aussi, franchement. Surchargez << avec >> et ne souffrez pas. Mais cela ne supprime pas l'intérêt d'autoriser la surcharge de T()

 
Dmitry Fedoseev:

Si je comprends bien, ils vont le surcharger ici, de sorte quearray[5] ne renvoie pas un objet, mais un nombre double. N'est-ce pas ?

Où se trouve, dans cet exemple, ce contexte qui peut être compris ? S'agit-il du type de paramètre MYCRTMFLT ? Il s'agit d'une surcharge sur le type de valeur retournée.

Je ne vois pas de problème :

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

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

La macro se terminera par un identifiant ou un appel de fonction et le compilateur comprendra ce qu'il attend d'elle. Et s'il ne le fait pas (erreur de compilation avec jurons sur l'ambiguïté), alors vous pouvez toujours l'aider : chart[i].price

 
Ilya Malev:

Oui, bien sûr, on doit nécessairement écrire d=(double)array[5], alors que l'on sait déjà lors de la compilation que d ne peut être que double... les souris pleuraient et pleuraient, mais continuaient à ronger le cactus...

En outre, il y a aussi quelque chose d'autre avec le nom array.

Ce n'est pas mal du tout quand le compilateur prévient de l'affectation de types inappropriés. Nous devons montrer au compilateur que ceux qui ont écrit ce code assument l'entière responsabilité du résultat afin qu'ils ne se plaignent pas plus tard de l'absence d'avertissements générés par le compilateur.

 
pavlick_:

Je ne vois pas de problème :

...

Moi non plus.
 
Dmitry Fedoseev:

Il n'est pas mauvais du tout que le compilateur mette en garde contre l'affectation de types inappropriés. Nous devons montrer au compilateur que ceux qui ont écrit ce texte assument l'entière responsabilité du résultat, afin qu'ils ne se plaignent pas plus tard de l'absence d'avertissements du compilateur.

Seulement pas dans ce cas où il a lui-même défini la méthode operator double(){...} pour cette affectation, évidemment pour ne pas écrire (double) après une variable de type double ou recevoir des avertissements générés par le compilateur.

En général, la conversation tourne déjà en rond, espérons que la surcharge de type sera autorisée un jour, personnellement ça ne me dérangerait pas si pour l'activer je devais mettre une coche quelque part dans les options et confirmer que "j'accepte d'être entièrement responsable du résultat".

12345678910
Nouveau commentaire