Discussion :

[camboui]

Je sais, le C++ ne le permet pas.

Ce code n'est pas valide:

Code :

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

1
2
3
4
5
6
7
struct query
{
	long get()
		{ return 5l; }
	std::string get()
		{ return "abc"; }
};

Comment contourner le problème sans passer par un variant géré au runtime.

Voici une solution:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
struct query;
struct my_variant
{
	query & f_q;
	my_variant(query & q) : f_q(q) {}
	template<typename T>
	operator T()
	{
		T t;
		f_q.get(t);
		return t;
	}
};
 
struct query
{
	void get(long & l)
		{ l=5l; }
	void get(std::string & s)
		{ s="abc"; }
	my_variant get()
	{
		return my_variant(*this);
	}
};
 
void main()
{
	query q;
	long i = q.get();
	std::string s = q.get();
}

Si quelqu'un a mieux je suis preneur

[ternel]

Et quelle est ta question?

Plus important, pourquoi te la poses-tu? Le savoir nous permettra probablement de te dire comment t'en passer.

[camboui]

Oui, désolé, j'ai malencontreusement cliqué sur Envoyer avant d'avoir fini le post

[ternel]

Un get template, non défini, et spécialisé pour get<long> et get<string>?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
struct query {
template <typename T>
T get();
};
 
template <>
long query::get<long>() {return 5l;}
 
template <>
std::string query::get<std::string>() {return "string";}
 
int main() {
std::cout << query().get<std::string>() << std::endl;
}

[camboui]

Je souhaite vraiment conserver cette écriture:

Code :

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

1
2
3
4
5
6
7
8
void main()
{
	long l;
	std::string s;
	query q;
	l = q.get();
	s = q.get();
}

Si c'est pour écrire ceci:

Code :

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

1
2
3
4
5
6
7
8
void main()
{
	long l;
	std::string s;
	query q;
	l = q.get<long>();
	s = q.get<std::string>();
}

Je préfère alors ceci:

Code :

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

1
2
3
4
5
6
7
8
void main()
{
	long l;
	std::string s;
	query q;
	l = q.get_long();
	s = q.get_string();
}

[ternel]

Alors tu ne peux vraiment pas comme ca.

Ou faire preuve d'astuce et retourner un Bidule™ qui se convertit tout seul dans le bon type.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
struct query_result {
    explicit operator long () const { return 5l; }
    explicit operator std::string () const { return "string"; }
};
 
struct query {
    query_result get() const {return query_result();}
};
 
int main() {
	long l;
	std::string s;
	query q;
	l = q.get();
	s = q.get();
}

En version plus constructive:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 struct query;
struct query_result {
    query const& q;
 
    template <typename T>
    explicit operator T () const { return q.get<T>(); }
};
 
struct query {
    query_result get() const {return {*this};}
 
    template <typename T>
    T get() const;
};
//les spécialisations...
 
int main() {
	long l;
	std::string s;
	query q;
	l = q.get();
	s = q.get();
}

[dragonjoker59]

Vu ton exemple d'utilisation, pourquoi ne pas utiliser un paramètre par référence non constante, plutôt qu'une valeur de retour ?

[Pyramidev]

Je souhaite vraiment conserver cette écriture:

Code :

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

1
2
3
4
5
6
7
8
void main()
{
	long l;
	std::string s;
	query q;
	l = q.get();
	s = q.get();
}

Si c'est pour écrire ceci:

Code :

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

1
2
3
4
5
6
7
8
void main()
{
	long l;
	std::string s;
	query q;
	l = q.get<long>();
	s = q.get<std::string>();
}

Je préfère alors ceci:

Code :

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

1
2
3
4
5
6
7
8
void main()
{
	long l;
	std::string s;
	query q;
	l = q.get_long();
	s = q.get_string();
}

Donc le but est seulement esthétique ?

L'avantage de la solution avec des templates, c'est que tu peux faire du polymorphisme paramétré :

Code :

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

1
2
3
4
5
6
7
 
template<class T>
void foo(const query& q) {
	T var1 = q.get<T>();
	T var2 = q.get<T>();
	...
}

ou du polymorphisme ad hoc :

Code :

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

1
2
3
4
5
6
7
 
typedef long TypeQuiPourraChanger;
void bar(const query& q) {
	TypeQuiPourraChanger var1 = q.get<TypeQuiPourraChanger>();
	TypeQuiPourraChanger var2 = q.get<TypeQuiPourraChanger>();
	...
}

ce que ne permettent pas les écritures q.get_long() et q.get_string().

[camboui]

Mon souhait est celui comme dit dans le titre du sujet: surcharge par valeur retour.
Comme la syntaxe de notre langage préféré ne le permet, j'essaie de le simuler.

Et donc pour cela, ma solution définitive ressemble à ceci (légère amélioration par rapport à ce que j'ai proposé dans le premier post)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
struct query;
struct my_variant
{
	query & f_q;
	my_variant(query & q) : f_q(q) {}
	template<typename T>
	T get()
	{
		T t;
		f_q.get(t);
		return t;
	}
	operator long() { return get<long>(); }
	operator std::string() { return get<std::string>(); }
	//operator etc...() { return get<etc...>(); }
};
 
struct query
{
	void get(long & l)
		{ l=5l; }
	void get(std::string & s)
		{ s="abc"; }
	my_variant get()
	{
		return my_variant(*this);
	}
};
 
void main()
{
	long i;
	std::string s;
	query q;
	i = q.get();
	s = q.get();
}

Au vu de vos réponses je suppose qu'il n'y a pas mieux.

En C++ le but de la surcharge, des templates, de la déduction automatique de type, des mots clés auto, delete, de la syntaxe étendue des boucles for, etc, est d'avoir un code concis, lisible et productif autant que possible.
Et, perso, je pense que la surcharge par valeur retour, autant que par paramètre, y contribuerait

[koala01]

Salut,

Il est vrai que les possibilités d'utiliser auto, decltype, delete, default ou final ont toutes pour but d'obtenir un code concis et "facilement lisible". Mais il reste une contrainte à laquelle on ne peut malgré tout pas échapper : le code doit impérativement éviter tout risque d'ambiguïté (non seulement au niveau de l'appel d'une fonction, mais aussi au niveau de la déclaration de celle-ci).

Or, le type de retour d'une fonction n'intervient absolument pas dans le prototype de celle-ci : il uniquement de s'assurer que la variable qui le récupérera est compatible avec la variable renvoyée.

En dehors de le la généricité, la seule possibilité dont on dispose pour faire varier le type de retour d'une fonction est connue sous le nom de "retour covariant" et prend une forme proche de

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
class ReturnType{
public:
    virtual ~ReturnType() = default;
};
class DerivedReturnType : public ReturnType{
 
};
class Base{
public:
    virtual ~Base() = default;
    virtual ReturnType const & get() const{
        static ReturnType r;
        return r;
    }
};
class Derived : public Base{
public:
    DerivedReturnType const & get() const{
        static DerivedReturnType r;
        return r;
    }
};
int main(){
    Base b;
    auto const & rdb = b.get();
    Derived d;
    auto const & rdd = d.get();
    std::cout<<typeid(rdb).name()<<"\n";
    std::cout<<typeid(rdd).name()<<"\n";
    return 0;
}

qui provoquera un affichage proche de

Code :

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

1
2
10ReturnType
17DerivedReturnType

(au convention de "mangling" près)

Mais qui présente un restriction majeure : tous les types que nous pourrions envisager de renvoyer doivent intervenir dans la même hiérarchie de classes (dériver --ou être de type -- de ReturnType, dans mon exemple)
Avec la généricité, nous pouvons effectivement envisager d'avoir un code proche de

Code :

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

1
2
3
4
5
6
7
class MaClass{
public:
    template <typename T>
    T /* const & */ get() const{
        /* ... */
    }
};

qui présente un avantage sympa, dans le sens où chaque spécialisation sera forcément considérée comme différente (c'est le principe même du paradigme générique). Ainsi, get<std::string>() sera forcément différent de get<size_t>() ou de get<double>().

Il y a cependant trois problèmes principaux :

• Comme je l'ai dit : ni type de retour ni (encore moins) le type de retour d'une fonction n'intervient absolument pas dans le prototype de celle-ci
• le compilateur doit disposer d'une spécialisation complète pour pouvoir générer le code binaire correspondant
• le code doit éviter toute ambiguïté.

(oui, je sais, je me répète )
Le premier point fait que le compilateur n'est pas en mesure de définir le type du paramètre template lorsqu'il se retrouve face à un code proche de

Code :

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

std::string str = obj.get(); // est-ce get<std::string>()? get<double>() ?, get<MachinChose>()??? aucune idée!!!

Le troisième point nous montre même pire, dans le sens où un code proche de

Code :

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

auto recup = obj.get()

serait tout à fait ambigu, en demandant au compilateur de définir le type de recup sur base d'un paramètre template dont il ignore absolument tout.

Et c'est là tout le problème : à un moment ou à un autre, il faut bien... en arriver à fournir le (tous les) parameter type(s) qui servira (serviront) à la spécialisation du template.

Mais cela permet de trucs sympa, magré tout, car, si tu n'a pas recours à la déduction de type, tu auras forcément une erreur avec un code qui pourrait être proche de

Code :

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

double d = obj.get<std::string>(); // erreur : aucune conversion connue entre std::string et double

A l'inverse, avec la déduction de type (l'impédance), face à un code proche de

Code :

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

1
2
3
4
5
6
 
template <typename T>
void foo(){
    auto var = obj.get<T>();
    /* manipulation de var, qui est de type T */
}

tu as la certitude que var sera, quoi qu'il arrive, du type désigné par le paramter type, tout en laissant au compilateur le soin de définir le type correspondant à T

[ternel]

Ma solution initiale est finalement assez équivalent à cela, la fonction cachant la template n'étant autre que la conversion de query.
J'ai utilisé cela dans divers contexte, dont l'extraction de valeur dans une sorte de map<string, string> (via boost::lexical_cast)
l'opérateur [] retournait un proxy, qui dispose d'un opérateur de conversion implicite utilisant boost::lexical_cast.

Cela dit, le besoin en lui-même est mal choisi.
Si l et s ont une signification, ce ne sont pas n'importe quel string et long de query. Auquel cas, les deux fonctions get mérite un nom significatif.
S'ils n'ont pas de signification, alors on est dans du code technique, dans lequel get<long> est probablement le bon choix.

Encore une fois, si ca a une signification concrête, qu'elle soit apparente, si ca n'en a pas, que ce soit caché.

@camboui:
ton main() n'est absoluement pas significatif, il n'a pas de sémantique visible.
Avec un vrai programme, on aurait des noms de variable signifiant quelque chose, par exemple age et nom.

Code :

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

1
2
3
4
5
6
int main() {
   query q(...);
    q.execute();
    int age = q.get();
    std::string nom = q.get();
}

ne me parait pas du tout plus lisible que

Code :

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

1
2
3
4
5
6
int main() {
   query q(...);
    q.execute();
    int age = q.age();
    std::string nom = q.nom();
}

Bien au contraire. Parce que si la chose à une signification, elle devrait avoir un nom.
Si query est capable d'avoir deux fonctions d'obtention de valeur (deux get()), alors ces valeurs sont distinctes, et ont deux significations distinctes. Pourquoi n'auraient-elles pas chacune leur nom?

Si query, au contraire, peut retourner un nombre arbitraire de valeurs de types arbitraires (ou presque), elle devrait retourner un tuple (ou avoir un opérateur d'indexation, dans le cas du "ou presque")

[Pyramidev]

@camboui : Si tu veux absolument utiliser la surcharge sur le type de retour, je conseille un code proche de :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
class Entreprise
{
public:
	// Surcharge sur le type de retour.
	class QueryNomDesEmployes
	{
	public:
		explicit QueryNomDesEmployes(const Entreprise& e) noexcept : m_entreprise(e) {}
		operator std::multiset<std::string>() const
		{
			return m_entreprise.nomDesEmployes_multiset_private();
		}
		operator std::vector<std::string>() const
		{
			return m_entreprise.nomDesEmployes_vector_private();
		}
	private:
		const Entreprise& m_entreprise;
	};
	QueryNomDesEmployes nomDesEmployesQuery() const { return QueryNomDesEmployes(*this); }
 
	// ...
 
private:
	std::multiset<std::string> nomDesEmployes_multiset_private() const;
	std::vector<std::string>   nomDesEmployes_vector_private()   const;
 
	std::vector<std::reference_wrapper<Employe>> m_employes;
};

Dans le ".cpp" :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
std::multiset<std::string> Entreprise::nomDesEmployes_multiset_private() const
{
	std::multiset<std::string> result;
	for(std::reference_wrapper<Employe> e : m_employes)
		result.insert(e.get().getNom());
	return result;
}
 
std::vector<std::string> Entreprise::nomDesEmployes_vector_private() const
{
	std::vector<std::string> result;
	result.reserve(m_employes.size());
	for(std::reference_wrapper<Employe> e : m_employes)
		result.push_back(e.get().getNom());
	return result;
}

Remarques :

• QueryNomDesEmployes est une classe locale suffixée par le nom de la fonction, afin d'éviter les collisions de nom. Du coup, le nom Entreprise::QueryNomDesEmployes est long à écrire, mais ce n'est pas très gênant, car on n'aura jamais à l'écrire.
• Au lieu de factoriser le code des opérations de conversion sous forme de template :
  

  Code :

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

  1
  2
  3
  4
  5
  template<class T>
  operator T() const
  {
  	return m_entreprise.nomDesEmployes_private<T>();
  }

  j'ai écrit explicitement chaque opérateur de conversion de QueryNomDesEmployes. Comme ça, on délimite explicitement sous forme de code les types de retour possible. Le code, c'est de la doc.