[gcc][bug?] warning: will never be executed

Version imprimable

Voilà, j'ai une classe très simple :

Object.hh

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
#ifndef _OBJECT_HH_
#define _OBJECT_HH_
 
#include <string>
 
namespace Core
{
  class Object
  {
  public:
    Object( std::string & );
 
    std::string GetName();
    void SetName( std::string & );
 
  private:
 
    std::string m_name;
  };
}
 
#endif

Object.cc :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
#include "Object.hh"
 
namespace Core
{
  Object::Object( std::string & n )
    : m_name(n)
  {
 
  }
 
  std::string Object::GetName( void )
  {
    return m_name;
  }
 
  void Object::SetName( std::string & n )
  {
    m_name = n;
  }
}

J'ai la ligne de compilation suivante :

Code:

1
2
 
g++ -O2 -Wuninitialized -W -Wall -pedantic -Werror -g -Wchar-subscripts -Wcomment -Wformat=2 -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused -Wunknown-pragmas -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wwrite-strings -Wconversion -Wsign-compare -Waggregate-return -Wmissing-noreturn -Wformat -Wmissing-format-attribute -Wno-deprecated-declarations -Wpacked -Wredundant-decls -Winline -Wlong-long -Wunreachable-code -c Object.cc

Et j'ai les warning suivant :

Code:

1
2
3
4
5
6
 
cc1plus: warnings being treated as errors
Object.cc: In constructor ‘Core::Object::Object(std::string&)’:
Object.cc:9: warning: will never be executed
Object.cc: In constructor ‘Core::Object::Object(std::string&)’:
Object.cc:9: warning: will never be executed

Sachant que la neuvième ligne est l'accolade fermante du constructeur, j'ai du mal à comprendre pourquoi j'ai un warning ici.

PS : il s'agit de gcc 4.1.2 sur une debian unstable.

21/08/2006, 12h48
hegros

Ce n'est pas parce que ton constructeur a la forme du constructeur par recopie (indiqué par le passage par référence) ?
21/08/2006, 14h08
PRomu@ld

Non, ça ne règle pas le problème, en essayant sans les références, ça ne change rien ...

Est ce qu'il y aurait quelque chose qu'on ne m'aurait pas dit avec l'utilisation de std::string ?

La classe Object n'existerait pas déjà sous gcc ?

Sous mac avec gcc 4.0.1 ça donne exactement la même chose.
21/08/2006, 14h13
PRomu@ld

Avec g++ 3.3 ça me donne ceci :

Citation:

In file included from Object.cc:359:
/usr/include/gcc/darwin/3.3/c++/bits/basic_string.h: In member function `_Alloc
std::basic_string<_CharT, _Traits, _Alloc>::get_allocator() const [with
_CharT = char, _Traits = std::char_traits<char>, _Alloc =
std::allocator<char>]':
/usr/include/gcc/darwin/3.3/c++/bits/basic_string.h:209: instantiated from `void std::basic_string<_CharT, _Traits, _Alloc>::_Rep::_M_dispose(const _Alloc&) [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'
Object.cc:359: instantiated from `std::basic_string<_CharT, _Traits, _Alloc>::~basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'
Object.cc:359: instantiated from `std::basic_string<_CharT, _Traits, _Alloc>::~basic_string() [with _CharT = char, _Traits = std::char_traits<char>, _Alloc = std::allocator<char>]'
Object.cc:7: instantiated from here
/usr/include/gcc/darwin/3.3/c++/bits/basic_string.h:912: warning: function
returns an aggregate
Object.cc: In member function `std::string Core::Object::GetName()':
Object.cc:12: warning: function returns an aggregate
Object.cc:14: warning: function returns an aggregate
make: *** [all] Error 1

Moi quand j'utilise un namespace dans un .h je fais toujours ainsi :

using namespace std;

donc ca donnerai :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
#ifndef _OBJECT_HH_
#define _OBJECT_HH_
 
#include <string>
 
using namespace Core;
 
  class Object
  {
  public:
    Object( std::string & );
 
    std::string GetName();
    void SetName( std::string & );
 
  private:
 
    std::string m_name;
  };
 
#endif

21/08/2006, 14h57
PRomu@ld

J'ai peur de ne pas avoir compris ce que tu fais ...

Ma classe object doit être déclarée dans l'espace de nom Core.

J'utilise habituellement ce qui est ici (j'ai déjà effectué plusieurs classes selon le même principe):

http://cpp.developpez.com/cours/cpp/
21/08/2006, 15h01
SnakemaN

A la boulette.....:?

J'ai cru que tu UTILISAIS un namaspace par qu tu voulais le DEFINIR....:traine:
21/08/2006, 15h04
hegros

Il doit y avoir plusieurs façons de faire car pour ma part le using namespace Core; je le mets plutot dans le fichier de définition de la class.
21/08/2006, 15h15
PRomu@ld

Citation:

J'ai cru que tu UTILISAIS un namaspace par qu tu voulais le DEFINIR....

J'en était sur !:mouarf2:
21/08/2006, 16h31
SnakemaN

Bon ben ca resoud pas le probleme...ca en est ou ?

tu compile comment ?
c koi la ligne de commande, un makefile peut etre ?
21/08/2006, 16h36
PRomu@ld

Toujours rien :cry:
21/08/2006, 17h08
Médinoc

Citation:

Envoyé par SnakemaN

Moi quand j'utilise un namespace dans un .h je fais toujours ainsi :
using namespace std;

:fessee:

JAMAIS de using namespace en liberté dans un .h!
21/08/2006, 17h17
SnakemaN

Citation:

Envoyé par Médinoc

:fessee:
JAMAIS de using namespace en liberté dans un .h!

aiyeuuhhh :pleure:
mais pourquoi ? 8O
il est pas en liberté il entre le #ifndef et le #endif :(
21/08/2006, 17h28
PRomu@ld

Parce qu'à chaque fois que tu vas inclure ce .h le using sera actif et donc il n'y aura plus aucun interêt à l'utilisation des espaces de noms.
21/08/2006, 17h36
SnakemaN

Malgré les conditions de définition ifndef et endif ??

Mais alors comment faire ?
21/08/2006, 17h58
Médinoc

J'ai déjà vu mettre des using namespace dans un namespace nommé {}, mais je ne sais pas si c'est limité à ce bloc ou à tout le namespace (donc, tous les blocs définissant un namespace de ce nom)...

Sinon, tu peux toujours mettre un using namespace dans un corps de fonction inline, mais sinon, il vaut mieux toujours mettre le préfixe.
22/08/2006, 16h58
PRomu@ld

Bon, j'ai du nouveau.

Si j'utilise des char * à la place des std::string, ça passe sans problème.

Le problème viendrait donc de l'utilisation des std::string dans les constructeurs.

Mais donc dans ce cas pourquoi cette erreur ?