Discussion :

[3DArchi]

Bonjour,
J'ai beau lire la n2535 et la n1344, les inline namespace me semblent assez anecdotiques.
Effectivement, dans le code suivant, la différence de comportement pour l'appel de g peut surprendre :

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
namespace Lib
{
  namespace Lib_1
  {
    struct A{};
  }
  struct B{};
 
  template <typename T> void g(T){}
}
 
int main()
{
  Lib::Lib_1::A a;
  g(a); // Erreur
  Lib::B b;
  g(b); // OK
  return 0;
}

Ne maîtrisant pas sur les doigts les name lookup et en particulier les argument-dependent name lookup, j'aurais de toute façon tendance à écrire :

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
namespace Lib
{
  namespace Lib_1
  {
    struct A{};
  }
  struct B{};
 
  template <typename T> void g(T){}
}
 
int main()
{
  Lib::Lib_1::A a;
  Lib::g(a);
  Lib::B b;
  Lib::g(b);
  return 0;
}

Ce code fonctionne sans problème. Et je pense que j'aurais toujours tendance à écrire ce dernier code plutôt que celui-ci :

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
namespace Lib
{
  inline namespace Lib_1
  {
    struct A{};
  }
  struct B{};
 
  template <typename T> void g(T){}
}
 
int main()
{
  Lib::Lib_1::A a;
  g(a);
  Lib::B b;
  g(b);
  return 0;
}

De la même façon, pour les spécialisations de template, j'écrirais plus volontiers la spécialisation dans l'espace de nom approprié :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
namespace Lib
{
  namespace Lib_1
  {
     template<class T>
    struct A{};
  }
  struct B{};
  namespace Lib_1
  {
      template<> struct A<B>{};
  }
}

qu'avec une association de nom :

Code :

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

1
2
3
4
5
6
7
8
9
10
namespace Lib
{
  inline namespace Lib_1
  {
     template<class T>
    struct A{};
  }
  struct B{};
  template<> struct A<B>{};
}

Du coup, je me demande si je ne passe pas à côté de quelque chose avec cette évolution. Je n'arrive pas à vraiment saisir son intérêt.
Qu'en pensez-vous ?

[Lavock]

Je pense que l'essentielle est dans :

Members of an inline namespace can be used in most respects as though they were members of the enclosing namespace. Specifically, the inline namespace and its enclosing namespace are considered to be associated namespaces ([basic.lookup.argdep]) of one another, and a using directive ([namespace.udir]) which names the inline namespace is implicitly inserted into the enclosing namespace. Furthermore, each member of the inline namespace can subsequently be explicitly instantiated ([temp.explicit]) or explicitly specialized ([temp.expl.spec]) as though it were a member of the enclosing namespace. Finally, looking up a name in the enclosing namespace via explicit qualification ([namespace.qual]) will include members of the inline namespace brought in by the using directive even if there are declarations of that name in the enclosing namespace..

En gros, c'est de la "fusion" de namespace... Du moins, c'est ce que je crois en avoir compris.

[JolyLoic]

Je pense que tu prend le problème dans le mauvais sens. A ce que j'ai compris (je n'ai suivi ça que de très loin, donc tout ce que je dis est encore plus sujet à caution que d'habitude), la problématique n'est pas : j'ai un namespace dans un autre namespace, comment rendre le name lookup plus simple.

La problématique est plutôt comment gérer le versionnement. Et la solution proposée avait des problèmes de name lookup, ce qui fait qu'il a fallu détailler ce qui se passe dans ce genre de situations. Mais c'est plutôt un détail technique qu'une vraie fonctionnalité.

Le versionnement part de l'idée :
J'ai une bibliothèque dans un namespace V1, j'en ai une version plus récente dans un espace de noms V2. Comment faire pour :
- que les gens qui veulent spécifiquement utiliser V1 puissent le faire
- que les gens qui veulent spécifiquement utiliser V2 puissent le faire
- que les gens qui s'en moquent ne précisent rien, et qu'ils basculent sans effort de V1 vers V2.
Tout ça dans un seul code (donc les deux versions sont présentes dans l'environnement de compilation)

Solution proposée : Les utilisateurs classiques utilisent les objets dans un espace de nom MaLib, qui en interne contient V1 et V2, et un inline rend l'un des deux accessible par défaut. Donc selon un choix global, MaLib::A référencera implicitement V1::A ou V2::A, et MaLib::V1::A ou MaLib::V2::A seront explicites.

Et puis, du coup, ce qui reste commun à V1 et V2, plus besoin de le définir 2 fois, on le met juste dans MaLib.

L'idée est assez simple. Après seulement arrivent les détails scabreux...

[3DArchi]

Salut,
Merci pour cette réponse.

Je pense que tu prend le problème dans le mauvais sens.

C'est bien ce que je me disais

La problématique est plutôt comment gérer le versionnement. Et la solution proposée avait des problèmes de name lookup, ce qui fait qu'il a fallu détailler ce qui se passe dans ce genre de situations.

C'est exactement ce que raconte le papier de sutter (le n1344 du premier post ou sur gotw).
Mais, en le lisant ça m'a eu l'air très 'exercice de style'. Je n'ai jamais eu à utiliser de bibliothèque qui gère conjointement 2 versions. En général, tu changes de versions == tu migres, avec éventuellement quelques changements de code.
Sutter pose le problème std/std2. Auquel cas, je peux comprendre. Mais, au final, il y aura un espace de nom std2 ? Et à part la STL, est-ce que se problème va vraiment se poser ?

Mais c'est plutôt un détail technique qu'une vraie fonctionnalité.

Vue ainsi ça risque de s'ajouter à la liste de ceux qui pensent que le C++ est un langage trop compliqué car trop subtil

[Lavock]

Vue ainsi ça risque de s'ajouter à la liste de ceux qui pensent que le C++ est un langage trop compliqué car trop subtil

Je sais pas trop, pour moi cela s'ajoute au nombreux "truc pratique". Un peu comme si le c++ était bourré d'astuces.

C'est plutôt au compilateur d'être subtil pour ça, pas au codeur. Rien ne t'oblige à l'utiliser... Contrairement à des langage tout objet par exemple ou tu es OBLIGE de faire parfois quelque chose de rudement compliquer pour rien...

[Jean-Marc.Bourguet]

Mais, en le lisant ça m'a eu l'air très 'exercice de style'. Je n'ai jamais eu à utiliser de bibliothèque qui gère conjointement 2 versions

C'est un probleme que nous avons. Je pense que n'importe quel produit soft assez gros fini par l'avoir. Certains se donnent comme contraintes de l'eviter a tout prix, mais quand il y a des clients et des partenaires dans la boucle, le prix peut etre tres eleves. (Je connais mal, pour ne pas dire pas, le monde Windows, mais sous Unix les bibliotheques systemes sont ainsi versionnees. C'est un peu plus facile dans ce cadre -- il suffit de jouer avec l'editeur de liens -- mais quand on a des inlines et des templates, un support du langage aide a mettre en place des solutions robustes qui ne sont pas a base de macros et de scripts immondes).

[3DArchi]

Salut,

C'est un probleme que nous avons. Je pense que n'importe quel produit soft assez gros fini par l'avoir.

Comme je l'ai dit, dans les projets où je suis intervenu, c'est plus souvent géré à coup de gestion de conf et de migration. Mais, il est vrai que je ne suis intervenu que sur des projets 'prduits finis' (pas de bibliothèques) et pas dans des contextes multi-partenaires (plutôt le grand écart : mono client ou grand public et bibliothèques/framework du marché). D'où probablement mon biais de perception.
Merci pour ce complément.
Donc, si je résume, l'objectif des associations d'espaces de noms est bien la gestion des différentes versions comme le présente Sutter dans l'article.

[Klaim]

J'ai bossé dans une boite ou il y avait ce problème avec un "produit fini", qui avait plusieurs versions selon les détails que voulaient changer les clients (principalement des resources graphiques, mais aussi des menus additionels ou retirés, et parfois des modifications plus importantes).

Par contre il m'a toujours semblé qu'utiliser les branches d'un système de controle de source était suffisant.

J'ai lu la description de cette feature aussi et l'avais compris comme un moyen de changer de version par défaut facilement (je crois que c'était l'explication de Stroustrup).

Personellement ca me fait bizarre une feature concernant le versionning dans un language de programmation...

Mais si ça peut permettre d'implémenter une autre feature plus importante alors pourquoi pas, la plupart des gens ignoreront ce point de toutes manières.

[Alp]

Comme le dit Loïc, ça permet juste d'appuyer sur un levier pour promouvoir un namespace à une portée au-dessus (au niveau enclosing). C'est juste quelque chose qui permettra de faire joujou un peu plus avec les namespaces et l'ADL. Comme ça ne cassera aucun code et qu'apparemment la demande était assez forte, ç'a fait son chemin

[Jean-Marc.Bourguet]

Un des exemples où utiliser des variantes dans un même programme a du sens est quand les versions différentes sont debug/non debug (p.e. pour la lib standard).