Discussion :

[MXYZFTU]

Bonjour,

Je ne sais pas si c'est bien l'endroit pour parler de ces erreurs.
Je me suis aperçu que ces erreurs de l'éditeur de liens étaient dû
à une mauvaise utilisation des espaces de noms.
En effet dans un fichier cpp si on utilise "using namespace NomDeEspace;",
et que dans le fichier d'entête .h on a pas indiqué aussi le même "using namespace NomDeEspace;".
Il se produit cette erreur bien connue "erreur de jeton no résolu LNK2028 et LNK2019,
surtout si on a déclarer des fonctions dans ce fichier .h.

Voila je suis totalement débutant en C++, mais je voulais faire profiter de cette expérience aux
débutants comme moi.
Cette solution n'est bien entendu qu'une parmi plusieurs possibles.

[Bousk]

On ne met jamais de using namespace dans un fichier header

[Médinoc]

Il me semble que Visual, hélas, ne se gène pas pour le faire dans les projets Windows Forms (notamment parce qu'il implémente pratiquement toute la classe dans sa définition, délaissant le .cpp).

Un Form1.h auto-généré typique commence par ceci:

Code C++/CLI :

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
#pragma once
 
 
namespace TestWinForms {
 
using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Windows::Forms;
using namespace System::Data;
using namespace System::Drawing;
using namespace System::Text;
 
/// <summary>
/// Summary for Form1
///
/// WARNING: If you change the name of this class, you will need to change the
///          'Resource File Name' property for the managed resource compiler tool
///          associated with all .resx files this class depends on.  Otherwise,
///          the designers will not be able to interact properly with localized
///          resources associated with this form.
/// </summary>
public ref class Form1 : public System::Windows::Forms::Form
{
public:
	Form1(void)
	{
		InitializeComponent();
		//
		//TODO: Add the constructor code here
		//
	}

C'est extrêmement sale, ça va à l'encontre du principe C++ de séparer l'interface de l'implémentation, et Microsoft propage cet état d'esprit en montrant le mauvais exemple!

[lemmel]

C'est extrêmement sale, ça va à l'encontre du principe C++ de séparer l'interface de l'implémentation, et Microsoft propage cet état d'esprit en montrant le mauvais exemple!

Ce n'est pas tout à fait pareil en ce que l'espace global n'est pas pollué avec System::* : tout est rangé dans TestWinForms, qui doit être local à ta fenêtre.

T'en es-tu sorti de ton erreur de link ?

[lemmel]

Oups : j'ai confondu réponse avec auteur. Sorry.

Sinon sur le sujet : de toute manière il s'agit de code généré, donc il vaut mieux ni trop regarder, ni chercher à modifier quoique ce soit là dedans.

[Bousk]

Non Medinoc, dans ton cas le using est limité dans TestWinForm et pas propagé à tout le programme. Pour peu que ce namespace définisse cette seule et unique classe (une fenêtre ? Un morceau d'application ?), ça ne gène à priori en rien.

[ternel]

Ce n'est pas tout à fait pareil en ce que l'espace global n'est pas pollué avec System::* : tout est rangé dans TestWinForms, qui doit être local à ta fenêtre.

En fait, pas du tout.
Un using namespace bidule prends tous les noms présents dans le namespace bidule et les injecte dans le plus proche namespace contenant simultanément bidule et l'instruction using.
Ici c'est dans le namespace global, puisque le using est dans ::TestWinForms, et concerne ::System.

[lemmel]

Je ne suis pas sûr de bien comprendre ton propos.
Voici un exemple :

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 tata
{
  struct s_toto{};
}
namespace tutu
{
  using namespace tata;
  struct s_test
  {
    s_toto toto;
  };
}
int main(int argc, char *argv[])
{
  tutu::s_test test;
  tata::s_toto test2;
  //s_toto toto; // ne build pas si décommenté
  return 0;
}

s_toto n'est pas accessible dans le main, mais l'est dans tutu.
Disais-tu que using namespace dans un namespace (ici dans tutu) importe tout le namespace dans l'espace global ?

[Médinoc]

Non Medinoc, dans ton cas le using est limité dans TestWinForm et pas propagé à tout le programme. Pour peu que ce namespace définisse cette seule et unique classe (une fenêtre ? Un morceau d'application ?), ça ne gène à priori en rien.

Le namespace est (par défaut) le même pour toute l'application, et c'est surtout la partie "tout dans la définition de classe" que je trouve antithétique du C++... On dirait une tentative de faire du C# en C++.

[ternel]

Je ne suis pas sûr de bien comprendre ton propos.
Voici un exemple :

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 tata
{
  struct s_toto{};
}
namespace tutu
{
  using namespace tata;
  struct s_test
  {
    s_toto toto;
  };
}
int main(int argc, char *argv[])
{
  tutu::s_test test;
  tata::s_toto test2;
  //s_toto toto; // ne build pas si décommenté
  return 0;
}

s_toto n'est pas accessible dans le main, mais l'est dans tutu.
Disais-tu que using namespace dans un namespace (ici dans tutu) importe tout le namespace dans l'espace global ?

En fait, le problème intervient un peu autrement.

Code :

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

1
2
3
4
5
6
7
8
9
10
struct Bidule;
 
namespace bidules {
struct Bidule;
}
 
namespace autre {
using namespace bidules;
Bidule* fonction();
}

Ici, fonction() ne compile pas, parce que Bidule est ambigü.
En effet, bidules::Bidule a été injecté non pas dans autre:: mais dans ::, le namespace global, le seul espace engloblant commun entre autre::using namespaces bidules; et bidules::Bidule.
Du coup, comme un ::Bidule a été déclaré, il y a deux Bidules dans ::.

Dans ton exemple, s_toto n'est pas accessible dans main, parce que le using namespace a été fait dans un scope restreint (ici, dans le namespace tutu)

[lemmel]

Encore une fois j'ai un peu de mal à comprendre.
Voici un exemple :

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
struct s_toto{};
 
namespace tata
{
  struct s_toto{};
}
namespace tutu
{
  using namespace tata;
  struct s_test
  {
    ::s_toto     toto1;
    tata::s_toto toto2;
  };
}
int main(int argc, char *argv[])
{
  tutu::s_test test;
  tata::s_toto test2;
  s_toto test3;
  return 0;
}

Le but du jeu de using namespace est d'injecter dans l'espace de nom courant un autre namespace.
Ainsi définir s_toto en contexte global et l'injecter dans tutu permet d'accéder à ces deux s_toto : il est donc normal d'avoir une ambiguïté et d'être dans l'obligation d'indiquer explicitement comme dans l'exemple lequel des deux tutu ont désire.

Le problème que tu souligne doit nécessairement se produire si il existe de toute manière dans le contexte courant deux symboles ayant un nom court approchant, mais comme je le disais les System::* sont injectés dans TestWinForms : on en a besoin ici, c'est du code généré qu'il vaut mieux ne pas modifier (il faudrait l'hériter et spécialiser les comportements), donc il est normal d'y avoir accès à cet endroit.

L'espace de nom TestWinForms a été créé pour cette unique raison (isoler du reste du programme), et si le gars hérite, comme il le devrait, le code alors, à l'image du main de mon exemple, il n'y aura aucun soucis et aucune pollution.

S'il décide de travailler directement dedans, alors à mon avis (mais là je spécule) il aura besoin des using qui ont été ajoutés. Donc pas très gênant.

En bref : je suis d'accord avec la règle qu'il vaut mieux éviter de mettre des using dans des headers, mais dans ce cas là, je n'y vois pas trop de problèmes. Mais bon c'est juste une opinion :-)

P.S. : J'utilise injecter parce que c'est commode mais cela me paraît impropre : cela donne accès mais cela n'ajoute rien.