Bogue de compilation avec le paramètre template = void* - page 7

Nouveau commentaire
 
Alexey Navoykov:

Je l'aurais fait de cette façon :

Je trouve ce style inconfortable. C'est-à-dire qu'il s'agit de "feutres".

 
fxsaber:

Alors vous voulez aussi des avertissements ? C'est quoi ce double standard : dans les deux endroits, le comportement est sans ambiguïté, mais avec les parenthèses vous êtes contre les avertissements et ici vous êtes pour ?

Vous avez besoin d'un avertissement pour ne pas faire des erreurs difficiles à trouver. La difficulté est donc une évaluation subjective. Avec les parenthèses, on ne fait pas d'erreurs, et ici, on peut en faire. Et pour moi, c'est vice versa.

Alors, pour lequel d'entre nous les règles d'émission des avertissements doivent-elles être adaptées ?

Vous ne semblez pas comprendre l'essentiel : le casting dynamique doit toujours être une opération explicite. Dans n'importe quel langage normal, que ce soit C++, C#, Java ou tout autre langage OOP, un tel code ne compilera pas. C'est la base d'une POO fiable. Mais il a été oublié ici pour une raison quelconque. Je ne pensais pas que la comparaison avec le support était appropriée ici.

 
Alexey Navoykov:

La base des principes fondamentaux d'une POO fiable.

La base de la non-ambiguïté.

 
Ilya Malev:

Je ne vois pas l'intérêt du code de référence (bien que je n'utilise pas non plus les bibliothèques standard). Si la mise en place d'un objet dans un tableau implique la création d'une copie de celui-ci, alors la méthode d'affectation ou le constructeur de copie doit être déclaré et décrit explicitement dans cette classe, sinon aucun wrapper ne sera utile de toute façon. Si vous avez seulement besoin de placer une référence à un objet dans un tableau, vous n'avez pas besoin de wrappers (pourquoi ?).

Pourquoi avez-vous besoin d'un tel tableau ? Parce qu'il est presque analogue à un vecteur plus, il devrait fonctionner comme vector<int>, vector<class_name>, vector<class_name*>. Si vous pouvez l'implémenter sans envelopper au moyen de µl, tant mieux pour vous (je ne pense pas que vous le puissiez). Vous n'avez pas la possibilité de parcourir un tableau et d'appeler des destructeurs ( _data[i].~Destr() ), pas de spécialisation partielle et pas d'astuces SFINAE. Cet habillage rend le tableau adapté aux pointeurs vers des objets du tas sans rompre la possibilité de travailler avec vector<int>, par exemple.

vector<unique_ptr<my_class>> v1;

vector<my_class> v2;

vector<int> v3;

ZS : que dire, vector<class_name*> ne fonctionnera pas comme prévu même dans les plus (appel du destructeur à la fin de la vie du vecteur) il faut aussi du wrapping.
 
pavlick_:

ZS : que dire, vector<class_name*> ne fonctionnera pas comme prévu même dans les plus (appel au destructeur à la fin de la vie du vecteur), il a besoin d'être enveloppé aussi.

Est-ce que ça va marcher ? )

template<typename T>
void del(T par){printf("%s не удаляем",typename(T));}

template<typename T>
void del(T *par){printf("%s удаляем",typename(T));delete par;}

class A{public:void~A(void){printf("удаляем %i",&this);}};

void OnStart()
 {
  int var1;
  A *var2=new A;
  del(var1);
  del(var2);
 }

P.S. Par analogie, une fonction peut retourner n'importe quoi au lieu de void, et vous n'avez pas besoin de SFINAE.

 
Oui, c'est bien. Mais nous avons toujours besoin d'une enveloppe : nous avons besoin d'un tableau universel, donc parfois il a des pointeurs qui doivent être supprimés, et parfois non (enfin, juste un ensemble de pointeurs - le résultat de la recherche de quelque chose dans un autre tableau).
 
pavlick_:

Du côté positif, la suppression de void* est UB.

D'ailleurs, je n'y avais pas pensé avant, merci pour le tuyau. Il s'avère que delete dans ce cas est similaire à free(). Il devrait être interdit, puisque delete est positionné pour les objets et qu'il libère simplement la mémoire en contournant les règles.

Les destructeurs sont également appelés ici, mais en cas de portage de code vers C++, on peut rencontrer des problèmes.

 
pavlick_:
Oui, ça fera l'affaire. Mais nous avons toujours besoin d'un emballage : après tout, nous avons besoin d'un tableau universel, donc parfois il a des pointeurs qui doivent être supprimés, et parfois non (enfin, juste un tas de pointeurs - le résultat de la recherche de quelque chose dans un autre tableau).

Eh bien, personne n'interdit de passer une option supplémentaire lors de la création d'un tableau - si l'on veut supprimer les éléments lors de la suppression ou non, et de l'activer ou de la désactiver par défaut (à votre convenance). Après tout, vous ne pouvez jamais deviner si vous voulez supprimer des éléments ou non)).

P.S. A propos, envelopper un pointeur avant de le mettre dans un tableau ne résoudra pas la question de savoir si vous devez ou non supprimer son objet de base lors de la suppression du tableau)).
 
fxsaber:

Les parenthèses supplémentaires ont permis d'éliminer complètement l'influence des priorités linguistiques. Tout devient complètement sans ambiguïté. Cela permet de garantir à 100% que rien ne sera cassé après la prochaine version.

C'est dans cet esprit que je vais résumer :


A100
Développeurs
fxsaber
parenthèses
uniquement dans les endroits où ils sont indispensables
peut-être même dans des endroits où MQL4 était différent avant
on en a besoin partout
avertissements inutiles
pas nécessaire
seulement dans les endroits où MQL4 était différent avant
nécessaire partout
priorités
est nécessaire
requis
pas nécessaire en principe (car les parenthèses les remplacent)

Si je ne l'ai pas énoncé correctement - corrigez-moi s'il vous plaît - j'ai fait en sorte que mon concept soit court et sans ambiguïté là où des avertissements sur les parenthèses sont nécessaires.

 
Ilya Malev:

Eh bien, personne n'interdit de passer une option supplémentaire lors de la création d'un tableau - si l'on veut supprimer les éléments lors de la suppression ou non, et de l'activer ou de la désactiver par défaut (à votre convenance). Parce que c'est difficile de deviner, si vous devez supprimer des éléments ou non)).

En général, oui, vous pouvez le faire de cette façon.

P.S. Au fait, ce n'est pas parce que vous enveloppez un pointeur avant de le mettre dans un tableau que la question de savoir si vous devez supprimer son objet de base ou non lors de la suppression du tableau ne sera pas plus claire ;))


Si vous ne l'emballez pas, vous ne le supprimez pas, si vous l'emballez, vous le supprimez, c'est clair comme de l'eau de roche.

ZS : mais si je le faisais, je me rapprocherais le plus possible de la bibliothèque standard plus (noms, comportement, etc.), donc pas de choix pour moi. Pourquoi s'embêter à créer une autre spécification alors que tout est déjà écrit ?

1234567891011121314...20
Nouveau commentaire