writes:Une question subsidiaire serait : est-ce que le tout n'est pas un
peu trop compliqué ? Au point, même, que si on se sert des
templates, on ne peut plus savoir si son code est correct ou non.
Qu'est est l'antecedant de "tout"?
Quelles sont les alternatives?
Quel est la situation minimale acceptable?
La recherche des noms et les templates ont des interactions complexes,
mais je crains que pour trouver des alternatives significativement
plus simples, il faille perdre en fonctionnalite/facilite
d'utilisation.
kanze@gabi-soft.fr writes:
Une question subsidiaire serait : est-ce que le tout n'est pas un
peu trop compliqué ? Au point, même, que si on se sert des
templates, on ne peut plus savoir si son code est correct ou non.
Qu'est est l'antecedant de "tout"?
Quelles sont les alternatives?
Quel est la situation minimale acceptable?
La recherche des noms et les templates ont des interactions complexes,
mais je crains que pour trouver des alternatives significativement
plus simples, il faille perdre en fonctionnalite/facilite
d'utilisation.
writes:Une question subsidiaire serait : est-ce que le tout n'est pas un
peu trop compliqué ? Au point, même, que si on se sert des
templates, on ne peut plus savoir si son code est correct ou non.
Qu'est est l'antecedant de "tout"?
Quelles sont les alternatives?
Quel est la situation minimale acceptable?
La recherche des noms et les templates ont des interactions complexes,
mais je crains que pour trouver des alternatives significativement
plus simples, il faille perdre en fonctionnalite/facilite
d'utilisation.
Jean-Marc Bourguet writes:
[...]
| > > A mon avis, on trouve l'operator<< (qui a un linkage externe)
| > > par le recherche utilisant les namespace associes dans le
| > > contexte de l'instanciation (le dump dans main). Comme il n'y
| > > a qu'une unite de traduction et que le contexte
| > > d'instanciation comporte toutes les declarations de linkage
| > > externe de celle-ci, le dernier paragraphe n'est pas a
| > > considerer.
| >
| > C'est ce que je commence à croire moi-même. C'est que selon ma
| > premier analyse, C ne se trouvait pas dans un namespace ; c'est
| > donc que la recherche dépendante aux paramètres ne pourrait pas
| > le retrouver. Mais tout compte fait, je crois que la norme
| > considère le namespace global comme n'importe quel autre
| > namespace -- l'absense d'un namespace, c'est un namespace.
|
| C'est ce que je comprends.
Mais la portée globale est une portée de namespace. Pour quelles
raisons penses-tu que Koenig lookup ne devrait pas s'appliquer ?
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| > > A mon avis, on trouve l'operator<< (qui a un linkage externe)
| > > par le recherche utilisant les namespace associes dans le
| > > contexte de l'instanciation (le dump dans main). Comme il n'y
| > > a qu'une unite de traduction et que le contexte
| > > d'instanciation comporte toutes les declarations de linkage
| > > externe de celle-ci, le dernier paragraphe n'est pas a
| > > considerer.
| >
| > C'est ce que je commence à croire moi-même. C'est que selon ma
| > premier analyse, C ne se trouvait pas dans un namespace ; c'est
| > donc que la recherche dépendante aux paramètres ne pourrait pas
| > le retrouver. Mais tout compte fait, je crois que la norme
| > considère le namespace global comme n'importe quel autre
| > namespace -- l'absense d'un namespace, c'est un namespace.
|
| C'est ce que je comprends.
Mais la portée globale est une portée de namespace. Pour quelles
raisons penses-tu que Koenig lookup ne devrait pas s'appliquer ?
Jean-Marc Bourguet writes:
[...]
| > > A mon avis, on trouve l'operator<< (qui a un linkage externe)
| > > par le recherche utilisant les namespace associes dans le
| > > contexte de l'instanciation (le dump dans main). Comme il n'y
| > > a qu'une unite de traduction et que le contexte
| > > d'instanciation comporte toutes les declarations de linkage
| > > externe de celle-ci, le dernier paragraphe n'est pas a
| > > considerer.
| >
| > C'est ce que je commence à croire moi-même. C'est que selon ma
| > premier analyse, C ne se trouvait pas dans un namespace ; c'est
| > donc que la recherche dépendante aux paramètres ne pourrait pas
| > le retrouver. Mais tout compte fait, je crois que la norme
| > considère le namespace global comme n'importe quel autre
| > namespace -- l'absense d'un namespace, c'est un namespace.
|
| C'est ce que je comprends.
Mais la portée globale est une portée de namespace. Pour quelles
raisons penses-tu que Koenig lookup ne devrait pas s'appliquer ?
writes:
| Je me rappelle des histoires, mais l'objet dans
| le namespace global était toujours un type de base, comme double.
Ces histoires sont un peu différentes : la raison est que l'ensemble
des namespaces associés à un type fondamental ou composite de types
fondamentaux est vide -- donc Koenig lookup s'applique mais ne trouve
rien.
kanze@gabi-soft.fr writes:
| Je me rappelle des histoires, mais l'objet dans
| le namespace global était toujours un type de base, comme double.
Ces histoires sont un peu différentes : la raison est que l'ensemble
des namespaces associés à un type fondamental ou composite de types
fondamentaux est vide -- donc Koenig lookup s'applique mais ne trouve
rien.
writes:
| Je me rappelle des histoires, mais l'objet dans
| le namespace global était toujours un type de base, comme double.
Ces histoires sont un peu différentes : la raison est que l'ensemble
des namespaces associés à un type fondamental ou composite de types
fondamentaux est vide -- donc Koenig lookup s'applique mais ne trouve
rien.
drkm writes:
| Gabriel Dos Reis writes:
[static fait que le template n'est pas trouvé]
| C'est donc bien le comportement prescrit par la norme ?
Oui, monsieur.
| Il faut
| l'écarter, même si elle est trouvée dans la même TU (je demande
| confirmation, car cela m'étonne) ?
Oui, monsieur.
| Peux-tu me donner une référence de verset, stp ?
Oui, monsieur.
14.6.4.2/1
[...]
drkm <usenet.fclcxx@fgeorges.org> writes:
| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
[static fait que le template n'est pas trouvé]
| C'est donc bien le comportement prescrit par la norme ?
Oui, monsieur.
| Il faut
| l'écarter, même si elle est trouvée dans la même TU (je demande
| confirmation, car cela m'étonne) ?
Oui, monsieur.
| Peux-tu me donner une référence de verset, stp ?
Oui, monsieur.
14.6.4.2/1
[...]
drkm writes:
| Gabriel Dos Reis writes:
[static fait que le template n'est pas trouvé]
| C'est donc bien le comportement prescrit par la norme ?
Oui, monsieur.
| Il faut
| l'écarter, même si elle est trouvée dans la même TU (je demande
| confirmation, car cela m'étonne) ?
Oui, monsieur.
| Peux-tu me donner une référence de verset, stp ?
Oui, monsieur.
14.6.4.2/1
[...]
como refuse
#include <vector>
template <typename T>
int f(T t) {
return g(t);
}
int g(double) {
return 4;
}
int g(std::vector<double>const&) {
return 5;
}
namespace ns {
class Y {
};
int g(Y) {
return 6;
}
}
int foo(double x) {
std::vector<double> v;
ns::Y y;
return f(x)
+ f(v)
+ f(y);
}
avec des erreurs pour f<double> et f<std::vector<double> > et pas pour
f<ns::Y> comme je m'y attendais (double pas de namespace associe,
std::vector a std comme namespace associe). Donc pour moi c'est
bug/not implemented yet dans le compilateur que tu as essaye
como refuse
#include <vector>
template <typename T>
int f(T t) {
return g(t);
}
int g(double) {
return 4;
}
int g(std::vector<double>const&) {
return 5;
}
namespace ns {
class Y {
};
int g(Y) {
return 6;
}
}
int foo(double x) {
std::vector<double> v;
ns::Y y;
return f(x)
+ f(v)
+ f(y);
}
avec des erreurs pour f<double> et f<std::vector<double> > et pas pour
f<ns::Y> comme je m'y attendais (double pas de namespace associe,
std::vector a std comme namespace associe). Donc pour moi c'est
bug/not implemented yet dans le compilateur que tu as essaye
como refuse
#include <vector>
template <typename T>
int f(T t) {
return g(t);
}
int g(double) {
return 4;
}
int g(std::vector<double>const&) {
return 5;
}
namespace ns {
class Y {
};
int g(Y) {
return 6;
}
}
int foo(double x) {
std::vector<double> v;
ns::Y y;
return f(x)
+ f(v)
+ f(y);
}
avec des erreurs pour f<double> et f<std::vector<double> > et pas pour
f<ns::Y> comme je m'y attendais (double pas de namespace associe,
std::vector a std comme namespace associe). Donc pour moi c'est
bug/not implemented yet dans le compilateur que tu as essaye