Question pour les experts en #define - page 2

 
Oh, mon Dieu, les garçons ne peuvent pas vivre sans coussinets.
 
Nikolai Karetnikov:

Merci ! )

Essentiellement.

C'est là que je me suis arrêté avec l'option de classe. Même des choses aussi élémentaires que la paramétrisation #define sont rapidement oubliées sans une utilisation quotidienne.

Sur les nerfs.

Mon Dieu, comme tout le monde est sensible ici ; on peut poser une question sans sous-entendu, sans intention d'offenser ou d'insulter, mais non, quelque part dans l'âme d'un génie méconnu, il y a un agacement et un désir de s'affirmer aux dépens d'un autre amateur. Je ne le rencontre pas sur le forum anglais, bien que j'y écrive régulièrement. Sachant cela, j'essaie habituellement de ne pas réagir à de telles remarques, mais si Dmitry, vous voulez vous ébattre dans une bataille verbale, je vous ferai le plaisir de vous plonger la tête la première dans vos propres émanations.

Coupe la mouche, bébé.

 
Vladimir Simakov:

Pourquoi n'avez-vous pas montré cette décision à l'homme tout de suite ?)

UPD : bezgovna - épelé sans sh..t ))))

Eh bien, tu apprécies juste l'idée que je ne le savais pas. Alors continue à te battre dans l'orgasme de ta propre génialité.

 
Dmitry Fedoseev:
Oh mec, les garçons ne peuvent plus vivre sans serviettes.

A propos des joints d'étanchéité.

Qu'est-ce qui est bon dans le singleton ? Parce que vous pouvez stocker l'état, traiter les journaux avec une logique complexe, etc., tout en gardant tout concis dans le code principal. De cette façon, une architecture de projet appropriée est créée et le code lui-même devient plus lisible.

PS. Sinon, oui, tout est pour un fan. Beaucoup de gens ici dans la communauté aiment le code spaghetti avec la notation hongroise, et le masochisme d'essayer tous les ordres et positions (tous en général) à chaque tick est génial).

 

Il y a longtemps (il y a de nombreuses années) .... Il y avait déjà un fil de discussion sur les meilleures bûches, que ce soit dans un fil séparé ou dans un autre fil, je ne me souviens pas.

Mais cela a été fait d'une manière légèrement différente. Ils y ont défiguré le nom de la fonction et y ont ajouté toutes sortes de macro-lignes de noms de fonctions et ainsi de suite... et ensuite vous pourriez changer le gestionnaire à la volée

quelque chose comme "#defin PRINT prepare ; Print"

et l'impression elle-même dans le style de

void Print (string a ; string a1="" ;string a2="" ; ...... // 64 fois. J'aimerais que nous puissions simplement écrire ...a[]

{

Imprimer (Notre préparation, arguments) ;

}

La définition aurait pu être traitée comme une impression ordinaire, et en changeant le gestionnaire, nous pouvons écrire des données dans un fichier ou les afficher. Le nombre d'arguments peut être quelconque (jusqu'à 64) // pour ceux qui n'ont pas encore appris.

D'ailleurs, c'esten partie ce que l'auteur demandait))

 
Dmitry Fedoseev:
Mais, malheureusement, vous n'impressionnerez pas les pigeons.

Vous voulez bien ?

Désolé, mais si je me souviens de l'époque où l'assembleur était encore utilisé, l'extension de macro (macro ) est un outil qui vous permet de remplacer sa définition par son code juste avant la compilation.

C'est juste que la programmation en assembleur est un peu lourde et qu'il n'y a pas de sous-routines.

La programmation en MQL est un peu plus confortable.

Question : Seriez-vous plus à l'aise pour écrire un sous-routine, ou juste le Print("No sheet") ; ou quelque chose à prédéfinir dans le préprocesseur ?

 
Алексей Тарабанов:

(1) Voulez-vous ?

Désolé, mais si je me souviens de l'époque où l'assembleur était encore utilisé, l'extension de macro (macro ) est un outil qui vous permet de remplacer sa définition par son code juste avant la compilation.

(2) Simplement, il est assez lourd de programmer en Assembleur et il n'y a pas de sous-routines.

La programmation en MQL est un peu plus confortable.

(3) Question : Vous sentiriez-vous plus à l'aise en écrivant un sous-programme, ou juste le Print("No sheet") ; ou en prédéfinissant quelque chose dans le préprocesseur ?

1) La question ne s'adresse pas à moi.

2) Il existe des sous-routines en assembleur.

3) Je suis plus à l'aise pour ne pas faire de conneries sur des questions qui ne valent pas un œuf pourri.

 
Alexandr Andreev:

Il y a longtemps (il y a de nombreuses années) .... Il y avait déjà un fil de discussion sur les meilleures bûches, que ce soit dans un fil séparé ou dans un autre fil, je ne me souviens pas.

Mais cela a été fait d'une manière légèrement différente. Ils y ont défiguré le nom de la fonction et y ont ajouté toutes sortes de macro-lignes de noms de fonctions et ainsi de suite... et ensuite vous pourriez changer le gestionnaire à la volée

quelque chose comme "#defin PRINT prepare ; Print"

et l'impression elle-même dans le style de

void Print (string a ; string a1="" ;string a2="" ; ...... // 64 fois. J'aimerais que nous puissions simplement écrire ...a[]

{

Imprimer (Notre préparation, arguments) ;

}

La définition aurait pu être traitée comme une impression normale, et en changeant le gestionnaire, nous pouvions soit écrire les données dans un fichier, soit les afficher à l'écran. Le nombre d'arguments peut être quelconque (jusqu'à 64) // pour ceux qui n'ont pas encore appris.

Au fait, c'estexactement ce que l'auteur demandait))

La chaîne aN="" et 63 fois - c'est une furie.

Laissez-moi vous expliquer :

  1. Une chaîne de caractères est un objet qui recouvre un wchar_t*.
  2. En faisant de string="" 63 fois, vous faites ce qui suit : vous allouez de la mémoire pour 63 objets string (sur la pile dans ce cas), vous appelez le constructeur paramétrique (63 fois), vous allouez un tampon wchar_t* d'une certaine taille dans le tas (juste là), dont les deux premiers octets sont initialisés avec 0x0000 (oui, cela arrive aussi 63 fois).

Si vous le faites de cette façon, faites string=NULL, dans ce cas vous économiserez des coûts importants d'allocation de mémoire inutile dans le tas.

UPD. Non, je me trompe, si c'est fait correctement, il n'y aura pas d'allocation de mémoire dans le tas.

 
Vladimir Simakov:

La chaîne aN="" et 63 fois est féroce.

Laissez-moi vous expliquer :

  1. string est un objet qui recouvre wchar_t*.
  2. En faisant de string="" 63 fois, vous faites ce qui suit : vous allouez de la mémoire pour 63 objets string (sur la pile dans ce cas), vous appelez le constructeur paramétrique (63 fois), vous allouez un tampon wchar_t* d'une certaine taille dans le tas (juste là), dont les deux premiers octets sont initialisés par 0x0000 (oui, cela se produit également 63 fois).

Si vous le faites de cette façon, faites string=NULL, dans ce cas vous économiserez des coûts importants d'allocation de mémoire inutile dans le tas.

UPD. Non, je me trompe, si c'est fait correctement, il n'y aura pas d'allocation de mémoire dans le tas.

Encore une fois, vous ne comprenez pas de quoi nous parlons. Alexander écrit sur le remplacement de Print() par define (pour éviter de ramper dans tout le fichier et de chercher toutes les impressions). Le problème est que Print peut avoir plusieurs paramètres, bien que personne ne les distingue en tant que paramètres - juste une chaîne reliée par des virgules. Ainsi, pour remplacer la fonction standard Print, vous avez besoin d'une fonction qui accepte 64 paramètres facultatifs (pour correspondre parfaitement à la fonction Print()). Et vous avez besoin de lui pour ajouter des données avant le journal, peut-être une bande avec une flèche (==>) pour une meilleure visibilité, peut-être un numéro de ligne, une date ou une sortie dans un fichier. Personne ne peut se soucier de la rapidité de cette opération, car elle est effectuée dans les cas particulièrement complexes d'erreurs de recherche, puis supprimée.

 
string _info;
void _Print(string s,string s1="",string s2="",string s3="",string s4="",string s5="",string s6="",string s7="",string s8="")//.....
   {
   string ss;
   StringConcatenate(ss,s,s1,s2,s3,s4,s5,s6,s7,s8);//....
   //Comment(_info,ss);
   Print(_info,ss);
   }
#define Print _info=__FILE__+" line "+__LINE__ +" "+__FUNCSIG__+" Print: "; _Print

void OnStart()
  {
   
   Templ();
  }
  
void Templ()
   {
   Print("Error, a!=",5," and other....",3,4,5);
   Print("a=",5);
   Print("Hi");
   }


Tout le monde semble comprendre.....

C'est donc pour ceux qui commencent leur chemin.....

Nous pouvons envelopper tout cela dans une classe stat et retourner une référence, qui ensuite égaliser le reste puisque cette méthode a un moins lors du travail avec if (a!=5) Print(a) ; cela ne fonctionnera pas, vous devriez toujours écrire if (a!=5) {Print(a);}, dans les classes vous pouvez corriger ce moment, mais je suis trop paresseux)) et en général, il semble que tout est dans les archives de l'histoire

comme avec les classes, initialiser nos données via une méthode statique et combiner l'appel de l'opérateur à notre print..... alorssi (a!=5) Print(a) ; cela fonctionnera