[compilation] problème avec functexcept.h

Version imprimable

:salut:

J'ai un petit soucis de compilation avec un programme.
Je dispose de deux fichiers buffer.cpp/h qui contiennent quasiement rien, juste de quoi faire 2 buffers sous forme de fifo.

Voici leurs codes :
buffer.h
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #include <queue> // taille des 'frames' des buffers #define TAILLEFRAMEYUV 576 * 720 * 2 // taille de chaque buffer #define NBFRAMEBUFFERYUV 100 #define NBFRAMEBUFFERSOCKET 100 using namespace std ; extern queue <unsigned char*> bufferYUV ; extern queue <unsigned char*> bufferSocket ;
ainsi que le .cpp correspondant :

buffer.cpp
Code:

1 2 3 4 5 6 7 8 9 10 #include "buffer.h" using namespace std ; // les buffers YUV queue <unsigned char*> bufferYUV ; // le buffer de la socket queue <unsigned char*> bufferSocket ;
Mon soucis, c'est que lors de la compilation j'ai systématiquement le message d'erreur suivant :
Code:

1 2 3 4 5 6 7 8 9 In file included from /usr/lib/gcc/i486-slackware-linux/3.4.6/../../../../include/c++/3.4.6/queue:67, from includes/buffer.h:8, from src/decodeSocketTStoSDI.cpp:20: /usr/lib/gcc/i486-slackware-linux/3.4.6/../../../../include/c++/3.4.6/bits/functexcept.h:36: error: expected initializer before "namespace" In file included from /usr/lib/gcc/i486-slackware-linux/3.4.6/../../../../include/c++/3.4.6/queue:67, from includes/buffer.h:8, from src/threads.cpp:21: /usr/lib/gcc/i486-slackware-linux/3.4.6/../../../../include/c++/3.4.6/bits/functexcept.h:36: error: expected initializer before "namespace"
le fichier src/decodeSocketTStoSDI.cpp inclut à la ligne 20 le fichier includes/buffer.h qui lui meme inclut <queue>, comme vous avez pu le voir dans le code source.

L'erreur provient de functexcept.h qui a la ligne 36 déclare le namespace std.

Vu que c'est un fichier que je n'ai jamais touché, je me demande bien pourquoi cette erreur vient de là ...

Quelqu'un aurait-il une idée ?

merci d'avance !

Raph

27/08/2007, 13h45
r0d

Bonjour,

je ne suis pas certain que ça vient de là, mais:
1/ Il ne faut pas utiliser la directive using namespace dans un fichier en-tête. (voir cette faq).
2/ L'utilisation systématique d'un pare-feu de compilation est fortement conseillée.

Et puis (ça n'a aucun rapport avec ton problème par contre), les #define sont à proscrire. Utilise un const type plutôt.
27/08/2007, 14h38
Dark Raph

merci de tes conseils, j'étais au courant pour les using namespace à proscrire dans les fichier .h.

Par contre, qu'est ce qu'un pare feu de compilation ? (j'ai l'impression de poser une question bête).
27/08/2007, 14h45
r0d
Citation:

Envoyé par Dark Raph

Par contre, qu'est ce qu'on pare feu de compilation ?

C'est lorsqu'on rajoute #ifndef MACHIN #define MACHIN /* déclarations */ #endif
Par exemple:
Code:

1 2 3 4 5 6 7 8 9 #ifndef MA_CLASSE_H #define MA_CLASSE_H class MaClasse { // mon code }; #endif
Ca évite que ce qui est céclaré dans ce fichier le soit plusieurs fois.
27/08/2007, 15h25
Dark Raph

Merci !

D'accord, ça s'appelle comme ça donc :) Grace à ton explication je viens de comprendre l'intérêt d'un tel pare feu ! Et je me suis empressé d'en mettre un dans chacun de mes headers ...

... par contre le problème est toujours là.

Qu'est ce que l'erreur error: expected initializer before "namespace" peut-elle laissait sous entendre ?
27/08/2007, 15h26
r0d

As-tu enlevé le using namespace du .h ?

oui tout à fait,

Voici mon nouveau buffer.h :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
#ifndef BUFFER_H
#define BUFFER_H
 
 
 
#include <queue>
 
// taille des 'frames' des buffers 
const int TAILLEFRAMEYUV = 576 * 720 * 2 ;
 
// taille de chaque buffer
const int NBFRAMEBUFFERYUV = 100 ;
const int NBFRAMEBUFFERSOCKET = 100 ;
 
std::queue <unsigned char*> bufferYUV ;   
 
std::queue <unsigned char*> bufferSocket ; 
 
#endif

27/08/2007, 15h35
swirtel
le fait d'ajouter un identifiant au début et fin d'un header file via le pré-processeur s'appelle GUARDIAN.
Code:

1 2 3 4 5 #ifndef __FICHIER_H__ #define __FICHIER_H__ #endif // __FICHIER_H__
27/08/2007, 15h40
r0d

J'avoue que je ne sais pas trop ... :(

Fais voir la ligne de code qui génère l'erreur.
Sinon, es-tu bien certain de n'avoir plus aucun using namespace dans tous tes headers?

Je viens de regarder mes headers (4 au total) et seul buffer.h contenait un using namespace std. :(

Sinon, voici le code de functexcept.h.

Code:

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
 
// Function-Based Exception Support -*- C++ -*-
 
// Copyright (C) 2001 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library.  This library is free
// software; you can redistribute it and/or modify it under the
// terms of the GNU General Public License as published by the
// Free Software Foundation; either version 2, or (at your option)
// any later version.
 
// This library is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
// GNU General Public License for more details.
 
// You should have received a copy of the GNU General Public License along
// with this library; see the file COPYING.  If not, write to the Free
// Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307,
// USA.
 
// As a special exception, you may use this file as part of a free software
// library without restriction.  Specifically, if other files instantiate
// templates or use macros or inline functions from this file, or you compile
// this file and link it with other files to produce an executable, this
// file does not by itself cause the resulting executable to be covered by
// the GNU General Public License.  This exception does not however
// invalidate any other reasons why the executable file might be covered by
// the GNU General Public License.
 
//
// ISO C++ 14882: 19.1  Exception classes
//
 
#include <exception_defines.h>
 
namespace std // La ligne 36 est ici
{
  // Helper for exception objects in <except>
  void
  __throw_bad_exception(void);
 
  // Helper for exception objects in <new>
  void
  __throw_bad_alloc(void);
 
  // Helper for exception objects in <typeinfo>
  void
  __throw_bad_cast(void);
 
  void
  __throw_bad_typeid(void);
 
  // Helpers for exception objects in <stdexcept>
  void
  __throw_logic_error(const char* __s);
 
  void
  __throw_domain_error(const char* __s);
 
  void
  __throw_invalid_argument(const char* __s);
 
  void
  __throw_length_error(const char* __s);
 
  void
  __throw_out_of_range(const char* __s);
 
  void
  __throw_runtime_error(const char* __s);
 
  void
  __throw_range_error(const char* __s);
 
  void
  __throw_overflow_error(const char* __s);
 
  void
  __throw_underflow_error(const char* __s);
 
  // Helpers for exception objects in basic_ios
  void
  __throw_ios_failure(const char* __s);
} // namespace std

J'ai indiqué dans le code où se trouvait la ligne 36, qui génère l'erreur.
Comme je le disait, ce fichier est utilisé par Linux (il faut être root pour le modifier), et je n'y ai jamais touché auparavant ...

27/08/2007, 15h49
r0d
Ha oui, peut-être une idée. Lorsque tu inclus functexcept.h, est-ce que tu inclus d'autres fichiers avant? Par exemple:
Code:

1 2 #include "toto.h" #include "functexcept.h"
Si c'est le cas, vérifie que le fichier toto.h est valide (typiquement, s'il ne manque pas un ';' quelque part).
27/08/2007, 15h58
Dark Raph

effectivement, le fichier buffer.h est inclus dans 2 fichiers decodeSocketTStoSDI.cpp et threads.cpp .

Je viens de remplacer l'ordre des includes, et ça change pas mal de choses : l'erreur correspondante pour le fichier disparait, mais en laisse place à une multitude d'autres (sans doute car le compilateur s'était arréter, et qu'il me reste des erreurs à corriger).

Je vais essayer ça, je te tiens au courant.

En tout cas, merci de tes réponses rapides r0d !
27/08/2007, 16h19
Dark Raph

Ayé !

J'avais un autre header, comme tu le disais (toto.h) inclus avant le buffer.h dans mes fichiers. Je viens de le checker, il manquait effectivement bien un ";" tout à la fin, à la dernière déclaration de fonction.

Donc, franchement bravo. Parce que celle là, elle était pas facile à trouver !

Avant de mettre ce post sur résolu, j'avais une dernière petite question sur le "guardian"

Prenons l'exemple de mon buffer.h avec son petit guardian en guise de pare feu de compilation :)

Si j'inclus buffer.h dans 2 fichiers différents. Au premier include, pas de soucis, la variable du préprocesseur correspondant au guardian n'étant pas défini, le préprocesseur va donc "copier" le contenu de buffer.h (entre le #ifndef et le #endif + tout ce qui est en dehors ...), à l'endroit de l'inclusion.
Donc, ça me semble logique, ça marche.

Par contre, pour la deuxième inclusion, dans un autre fichier. La variable du préprocesseur pour buffer.h étant déjà définie, le contenu entre le #ifndef et #endif ne sera pas copié !? J'imagine que c'est l'effet voulu ... mais dans le code du deuxième fichier incluant buffer.h, il y aura sans doute des références à des fonctions / variables définies dans buffer.h. Comment le compilateur va-t-il gérer ça ?

voilà, c'était ma petite interrogation du moment ...

Et, le fait de nommer les variables du préprocesseur pour le "guardian" avec deux "__" avant et aprés, c'est pour le style ou bien une convention d'écriture entre programmeur :) ?
27/08/2007, 16h24
Laurent Gomila

Citation:

Par contre, pour la deuxième inclusion, dans un autre fichier. La variable du préprocesseur pour buffer.h étant déjà définie, le contenu entre le #ifndef et #endif ne sera pas copié !?

Si si, ce sera copié. Lorsque tu vas inclure ton en-tête la première fois cela va créer la macro correspondante, mais seulement pour le fichier courant. Dans les autres fichiers .cpp cette macro ne sera pas définie.
En fait ces gardes anti-réinclusion servent à éviter d'inclure le même en-tête plusieurs fois dans un même fichier source.
27/08/2007, 16h28
r0d
Citation:

Envoyé par Dark Raph

Et, le fait de nommer les variables du préprocesseur pour le "guardian" avec deux "__" avant et aprés, c'est pour le style ou bien une convention d'écriture entre programmeur :) ?

C'est une notation que l'on retrouve assez fréquemment. En fait, il est important de donner un nom le plus "compliqué" possible afin d'éviter d'utiliser des noms qui existent déjà.
Cela dit, la norme déconseille de créer des variables qui commencent par '_'. Je pense que chacun à ses petites habitudes, mais en ce qui me concerne, je préfère la respecter, même pour les pare-feu de compilation. Je vais plutôt rajouter des trucs à la fin, par exemple:
Code:

1 2 3 4 5 6 7 8 9 #ifndef MA_CLASSE_H_R0D__ #define MA_CLASSE_H_R0D__ class MaClasse { // code }; #endif;
Mais bon, chacun a ses petites habitudes :)
27/08/2007, 16h33
Dark Raph

Citation:

Envoyé par Laurent Gomila

Si si, ce sera copié. Lorsque tu vas inclure ton en-tête la première fois cela va créer la macro correspondante, mais seulement pour le fichier courant. Dans les autres fichiers .cpp cette macro ne sera pas définie.

Ah d'accord ! :) Je ne savais pas qu'une variable de préprocesseur était spécifique à un fichier...
C'est un petit garde fou bien pratique en effet :)

Si deux fichiers inclus un header où des variables sont déclarées, l'édition de lien va donc planter ... car les variables seront définies plusieurs fois !
Dans le cas où l'on souhaite utiliser une varialbe globale à plusieurs fichiers .cpp par exemple, il est nécessaire de ne faire qu'une seule déclaration (dans un fichier .cpp), et d'indiquer dans le header correspondant qu'elle a été déclaré (avec le mot clé extern ) ?
27/08/2007, 17h11
Laurent Gomila

Citation:

Dans le cas où l'on souhaite utiliser une varialbe globale à plusieurs fichiers .cpp par exemple, il est nécessaire de ne faire qu'une seule déclaration (dans un fichier .cpp), et d'indiquer dans le header correspondant qu'elle a été déclaré (avec le mot clé extern ) ?

C'est ça.
27/08/2007, 17h38
Dark Raph

boudiou ! Je viens d'apprendre plein de trucs !

Merci à tous pour votre aide, très sympa !
Je tag tout ça en [résolu]