Discussion :

[Kalite]

Bonjour,

Le warning c4661 apparait sur une de mes templates. Le code est le suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
template<class T> class Buffer
{
public:
....
   Buffer<T> operator += (const Buffer<T>& buffer);  
private
   Buffer<T> operator += (const T*);
};
 
template <class T>
Buffer<T> Buffer<T>::operator += (const Buffer<T>& buffer)
{
....
}

Je déclare l'opérateur de += privée pour être sur que le compilateur n'en créé pas un ou qu'il ne fasse pas une convertion implicit.

Avez vous une idéé pour retirer ce warning ?

[Rewpparo]

Les seules fonctions implicites en C++ sont le constructeur par défaut, le constructeur de copie, et l'opérateur =. Jamais le compilateur ne générera de += de lui même, enfin je crois

[koala01]

Salut

Les seules fonctions implicites en C++ sont le constructeur par défaut, le constructeur de copie, et l'opérateur =. Jamais le compilateur ne générera de += de lui même, enfin je crois

Je confirme...

Les seules fonctions qui sont générées automatiquement par le compilateur sont les "big four" de la (première je crois) forme canonique de Coplien, à savoir:

• le constructeur ne prenant aucun argument
• le constructeur par copie
• l'opérateur d'affectation ( = )
• le destructeur

Tous étant, lorsque générés par le compilateur, public et non virtuels (bien que la virtualité ne puisse s'appliquer qu'au destructeur).

Tous les autres opérateurs sont traités comme des fonctions classiques : s'il ne sont pas déclarés, il n'existent simplement pas aux yeux du compilateur

De plus, une fonction ne pourra (éventuellement) être appelée avec des arguments de type différents de celui attendu que que:

1. si l'argument est passé par valeur ou par référence constante
2. si le constructeur du type d'argument attendu n'est pas déclaré explicit ou
3. s'il existe un opérateur de conversion entre le type de l'argument passé et le type de l'argument attendu

Tu peux donc sans crainte retirer la déclaration privée de ton opérateur += si tu ne veux pas l'utiliser

Cependant, en fonction de ce que tu prévois de faire avec ton opérateur +=, je me demande si tu ne devrais pas plutot envisager d'utiliser une fonction nommée telle que append, par exemple.

Le résultat sera tout à fait équivalent, bien sur, mais l'idée est que cela pourrait apporter une précision supplémentaire quant à la manière dont le buffer passé en argument est ajouté au buffer existant : le contenu de l'argument est, effectivement ajouté à la fin du contenu du buffer sur lequel on invoque la fonction

Il serait, en effet, tout à fait possible d'envisager comme "potentiellement intéressant" un comportement par lequel chaque élément du buffer passé en argument serait inséré après l'élément équivalent (en terme de position) du buffer sur lequel la fonction est invoquée, voire, envisager le fait que le buffer passé en argument s'insère au début du buffer sur lequel la fonction est appelée

Dans de telles éventualités, le fait de fournir une fonction qui indique clairement ce qu'elle va faire permet à l'utilisateur de choisir le comportement le mieux adapté à ce qu'il souhaite effectivement obtenir

N'oublie pas non plus que, si tu définis l'opérateur +=, il est souvent "de bon ton" de définir un opérateur + qui renvoie un nouveau buffer composé de l'addition des deux buffers passés en paramètres, qui est "classiquement" défini comme
friend

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Buffer<T> operator +(Buffer<T> const & first, Buffer<T> const & second)
{
    Buffer<T> temp(first); // utilise le constructeur par copie
    temp +=second;
    return temp;
}

PS : En fonction des membres de Buffer, il sera sans doute utile de penser à implémenter l'idiome "Copy and swap" (au moins pour l'opérateur d'affectation )

PPS : je ne connais pas par coeur l'ensemble des code d'erreur / d'avertissement de visual studio, car j'ai appris à traduire le message qui suit après le fameux warining (CXXXX), mais n'oublie pas que, si tu implémente ta fonction en dehors de ta classe template, il faut soit:

• la déclarer inline et l'implémenter dans le fichier d'en-tête, soit
• l'implémenter dans un autre fichier ( *.impl par exemple) et veiller à inclure ce fichier dans tout fichier d'implémentation (C++) qui utilise la fonction, de manière à ce que le compilateur puisse générer le code binaire adapté au type réel de l'argument template

[JolyLoic]

Les seules fonctions qui sont générées automatiquement par le compilateur sont les "big four" de la (première je crois) forme canonique de Coplien, à savoir:

• le constructeur ne prenant aucun argument
• le constructeur par copie
• l'opérateur d'affectation ( = )
• le destructeur

Tous étant, lorsque générés par le compilateur, public et non virtuels (bien que la virtualité ne puisse s'appliquer qu'au destructeur).

Il faut ajouter à cette liste en C++11 :

• le constructeur par déplacement
• l'opérateur d'affectation par déplacement ( = )

[Kalite]

Merci pour ces informations.

En faite, je réalise le portage du code Borland C++ 5.02 vers Visual C++ 2010 donc j'ai des différences.

[koala01]

Merci pour ces informations.

En faite, je réalise le portage du code Borland C++ 5.02 vers Visual C++ 2010 donc j'ai des différences.

Nonnn Sans blagues ...

Ce n'est déjà pas le meme compilateur ni la meme bibliothèque d'objet graphiques (car je présumes que tu travailles avec une IHM ), mais, en plus, borland C++ 5.02 date à peu près de matuzalem!!!!

[Niark13]

Nonnn Sans blagues ...

Ce n'est déjà pas le meme compilateur ni la meme bibliothèque d'objet graphiques (car je présumes que tu travailles avec une IHM ), mais, en plus, borland C++ 5.02 date à peu près de matuzalem!!!!

1997 C'est toujours beaucoup mieux que le Turbo C++ du thread d'à côté. Toujours pré-standard, mais plus récent.

[koala01]

1997 C'est toujours beaucoup mieux que le Turbo C++ du thread d'à côté. Toujours pré-standard, mais plus récent.

Disons que c'est moins mal, mais, quand tu vois les évolutions de la fin des années 90, on estimes que, à cette époque, un an d'évolution en informatique équivalait, peu ou prou, à 10 d'évolution dans la vie de tous les jours...

Utiliser Borland 5.x à l'heure actuelle revient donc, à peu de chose près, à rouler dans une voiture du début des années 1900

[Niark13]

On est bien d'accord, mais il faut voir le bon coté des choses, il migre à VC++ 2010 justement !