Erreurs, bugs, questions - page 2325

 
TheXpert:
Y avait-il des raisons sérieuses d'abandonner l'opérateur -> ?

Non, il n'y avait pas de raisons sérieuses.

La seule justification de son absence est le souci des esprits immatures des utilisateurs non familiarisés avec le C++.

 
fxsaber:

La double négation est-elle optimisée par le compilateur ?

Oui, c'est vrai.

 
Ilyas:

Non, il n'y avait pas de raisons sérieuses.

La seule justification de son absence est de ménager les esprits fragiles des utilisateurs non familiarisés avec le C++.

Je ne pense pas que quelque chose de mauvais se produira si vous l'ajoutez.

Vous pouvez autoriser l'utilisation d'un point avec des pointeurs où il n'y a aucune ambiguïté pendant un certain temps.

Et, bien sûr, émettre un avertissement.


 
Comment ajouter un bouton aux produits de la place de marché : "Télécharger l'essai" ?
 
Koldun Zloy:

Je ne pense pas que quelque chose de mauvais se produira si vous l'ajoutez.

Pendantun certain temps , vous pouvez être autorisé à utiliser un point avec des pointeurs où il n'y a aucune ambiguïté.

Et, bien sûr, émettre un avertissement.

Pourquoi le rendre si compliqué ? C'est suffisant pour faire de . et -> des enregistrements équivalents, interchangeables.

Au sens figuré

#define ->   .
 
fxsaber:

Oui, il y a une ambiguïté dans votre cas. Dans le bon sens du terme, il devrait y avoir au moins un avertissement du compilateur pour ce genre de chose.

Dans mon cas, qui est beaucoup plus simple, tout est clair. Je pense que C++ est d'accord avec ça aussi.

Ce que je veux dire, c'est que dans mon cas, MQL implique l'option (2), tandis que C++ implique l'option (1). C'est-à-dire que vous avez une clarté imaginaire - un petit changement (de classe A) et la signification change radicalement.
 
A100:
Vous avez une clarté imaginaire - un petit changement (de classe A) et le sens change radicalement.

Il s'agit d'une modification de la classe qui devrait entraîner un message correspondant du compilateur.

S'il n'est pas là, c'est la clarté totale.

 
Ilyas:

Comme solution temporaire, utilisez l'opérateur " !". (logique non).
Nous allons réfléchir à la solution (peut-on changer le comportement maintenant, alors qu'il y a beaucoup de code ?)
Il est possible que pour un pointeur, une opération de conversion bool soit une opération sur le pointeur et non sur l'objet vers lequel il pointe.

Sans changer les codes existants, ça ne marchera pas... Tout le concept de pointeurs en tant qu'objets dynamiques s'effondre.

Je veux dire, au lieu de juste écrire

class A {
public:
        bool operator*( A* a ) { return true; }
};
void OnStart()
{
        A *a, *b;
        if ( a * b );  //(1)
}

nous devrons en écrire un qui prête à confusion.

        if ( *a * *b );//(2)

Et tout ça pour quoi ? Pour qu'un pointeur puisse être vérifié pour NULL ? - Il existe un opérateur de comparaison pour cela :

        if ( a != NULL );//(3)

Pourquoi le dupliquer ?

 
A100:

tout le concept de pointeurs en tant qu'objets dynamiques s'effondre.

il n'y a pas de concept maintenant, un objet et un pointeur vers lui sont mélangés dans une même pile
 
TheXpert:
il n'y a plus de concept maintenant, un objet et un pointeur vers lui sont mélangés dans une même pile

Cela permet de traiter les pointeurs comme des objets, ce qui dans certains cas donne une notation plus simple et plus claire sans *.

et de tels pointeurs peuvent également être utilisés comme références

Et maintenant, ils proposent de tout détruire et de retourner à l'âge de pierre pour le bien de personne ne sait quoi...