Erreurs, bugs, questions - page 1749

[fxsaber]

Vladislav Andruschenko:
peut-être qu'un adblock est installé ? qui bloque toutes les pop-ups

Je n'ai rien changé. Tout fonctionnait avant.

Lors du paiement, j'appuie sur ce bouton

Rien ne revient, sauf ceci.

[A100]

Sergei Vladimirov:
Oui, je comprends votre question. Il existe une fonction avec une signature plus appropriée, mais elle ne peut pas être appelée car elle est protégée. Oui, le comportement est différent de celui de Studio : dans MKL, le contrôle des types est plus strict (dans ce cas). Je ne sais pas si cela doit être considéré comme un bug. Si vous contrôlez le type de l'argument passé à la fonction, il n'y a pas de problème.

Le contrôle est plutôt sélectif et donc plus incohérent, ce qui découle d'ici

class A {
public:
        void f( int ) const {} /*(1)*/        
        void f( int )       {} /*(2)*/
};
class B : public A {
public:
        void f( int ) const {} /*(3)*/
};
void OnStart()
{
        B b; //не const B
        b.f( 0 ); //(*)

}

Ici, en (*) dans l'agrégat (en ne considérant pas const B b ) l'appel A::f/*(2)*/ est plus susceptible d'être

Mais le C++ n'analyse pas toujours une classe de base pour trouver une méthode plus appropriée si la classe dérivée possède déjà une méthode appropriée.

Et MQL - dans l'exemple précédent, il a analysé la classe de base pour trouver une méthode plus appropriée, alors que dans celui-ci il ne le fait pas (ici aussi bien que le C++ appellera B::f/*(3)*/), ce qui signifie qu'il n'y a pas d'approche unifiée

Un autre exemple de contrôle incohérent : C++ trouve le code suivant

class A { public:
        void f(  int i ) const {}
        void f( uint i )       {}
};
void OnStart()
{
        A a;
        a.f((int)0 );
}

erroné, et le MQL est bon

[coderex]

A100:

Le contrôle est plutôt sélectif et donc plus incohérent, ce qui découle d'ici

class A {
public:
        void f( int ) const {} /*(1)*/        
        void f( int )       {} /*(2)*/
};
class B : public A {
public:
        void f( int ) const {} /*(3)*/
};
void OnStart()
{
        B b; //не const B
        b.f( 0 ); //(*)

}

Ici, en (*), par agrégation (en tenant compte du fait que B b n'est pas constant), l'appel A::f/*(2)*/ est davantage

Mais le C++ n'analyse pas toujours une classe de base pour trouver une méthode plus appropriée si la classe dérivée possède justement une méthode appropriée.

Et MQL - dans l'exemple précédent, il a analysé la classe de base pour trouver une méthode plus appropriée, alors que dans celui-ci il ne le fait pas (ici aussi bien que le C++ appellera B::f/*(3)*/), ce qui signifie qu'il n'y a pas d'approche unifiée

Un autre exemple de contrôle incohérent : C++ trouve le code suivant

class A { public:
        void f(  int i ) const {}
        void f( uint i )       {}
};
void OnStart()
{
        A a;
        a.f((int)0 );
}

défectueux, et le MQL est bon

quel est votre compilateur C++ ? j'ai gcc et tout fonctionne sans erreurs

[A100]

coderex:
Quel compilateur C++ utilisez-vous ? J'utilise gcc et tout passe sans aucune erreur.

Et quelle fonction gcc appelle-t-il à la fin ?

class A { public:
        void f(          int i ) const {} //1
        void f( unsigned int i )       {} //2
};
void OnStart()
{
        A a;
        a.f((int)0 );
}

(1) ou (2). Je vais maintenant insérer le message du compilateur

C'est vraiment un contrôle strict : une méthode est plus adaptée en termes de signature, l'autre en termes de constance.

[fxsaber]

A100:

Il s'agit en fait d'un contrôle strict : une méthode est plus appropriée en raison de sa signature, l'autre en raison de sa constance.

Eh bien, si vous faites de const A un ;, alors (1) devrait être appelé. Sinon, c'est à la discrétion du compilateur. C'est-à-dire qu'il ne peut y avoir d'unicité. Et la raison pour laquelle un tel code devrait être écrit n'est pas claire.

[A100]

fxsaber:
Et on ne voit pas bien pourquoi vous écririez une telle chose.

Remplacez f -> opérateur[], prenez votre exemple récent - pensez à comment faire [] à la fois à gauche et à droite. Ajoutez la constance au goût - puis enveloppez le tout dans un modèle et vous obtenez quelque chose de similaire.

Si faire const - considérer sans si

S'il ne peut y avoir d'ambiguïté, vous devez au moins émettre un avertissement.

[fxsaber]

A100:
Remplacez f -> opérateur[], prenez votre exemple récent - pensez à comment faire [] à la fois à gauche et à droite. Ajoutez la constance à votre goût - puis enveloppez le tout dans un gabarit et vous obtiendrez quelque chose de similaire.

De quel exemple s'agit-il ? Pourriez-vous donner non pas la source, mais l'entrée finale qui devrait fonctionner ?

[A100]

fxsaber:
De quel exemple s'agit-il ? Pourriez-vous donner non pas la source, mais l'entrée finale qui devrait fonctionner ?

Vous devriez vous retrouver avec quelque chose comme ça

void OnStart()
{
        A<int> a;
        int b  = a[ 0 ];
        a[ 0 ] = a[ 1 ];
        a[ 1 ] = b;
}

[fxsaber]

A100:

Vous devriez vous retrouver avec quelque chose comme ça

void OnStart()
{
        A<int> a;
        int b  = a[ 0 ];
        a[ 0 ] = a[ 1 ];
        a[ 1 ] = b;
}

Les indices sont-ils constants ?

[A100]

fxsaber:
Les indices sont-ils constants ?

les indices sont numériques : 1 2 3 ... Il est sous-entendu qu'à la place de A<int> il peut y avoir aussi const A<int>.