10
votes

Size_t ne peut pas être trouvé par g ++ - 4.1 ou d'autres sur Ubuntu 8.1

Cela s'est passé avant moi, mais je ne me souviens pas comment je l'ai réparé.

Je ne peux pas compiler certains programmes ici sur une nouvelle installation Ubuntu ... Quelque chose est autrefois avec mes en-têtes. P >

J'ai essayé g ++ - 4.1 et 4.3 en vain. p> xxx pré>

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
...



@ubuntu:~/work/zpk/src$ cat /usr/include/linux/types.h | grep size_t
typedef __kernel_size_t    size_t;
typedef __kernel_ssize_t   ssize_t;

linux c++ header size-t

0 commentaires

6 Réponses :

4
votes

Il est difficile de dire quelle est la question sans voir votre source complète. Le meilleur moyen de déboguer des problèmes tels que celui-ci consiste à utiliser le paramètre G ++ 'S »pour produire une sortie de pré-processeur, puis examinez cela pour déterminer ce qui se passe dans votre inclusion. Voici ce que la page Info de g ++ dit à propos de "-e":

STOP après la phase de prétraitement; Ne pas exécuter le compilateur approprié. La sortie est sous la forme de code source prétraitée, qui est envoyé à la sortie standard.
aussi, pourquoi pas simplement inclure SYS / Tys.h en haut du fichier?
addendum:
sur mon système, j'ai créé un Fichier court appelé FOO.CC qui contient uniquement: xxx
puis j'ai exécuté:

g ++ -e /tmp/foo.cc> /tmp/foo.pp
regarder cette sortie dans beaucoup de détails est très important. Par exemple, j'ai appris que /usr/include/bits/types.h a un typedef pour __time_t, et que /usr/include/types.h utilise ensuite ce typedef à dire "Typef __time_t Time_T". Mais il y a d'autres macros intéressantes entourant ce définissant. Portez une attention particulière aux choses comme la macro «__ebegin_namespace_std» dans /usr/include/time.h, qui sur mon système semble être une définition vide. Mais je peux imaginer que certains autres systèmes peuvent avoir une valeur différente pour cette macro, forçant la définition du temps_t dans un autre espace de noms.
Lire la page d'information du CPP, section "9 PRÉPROCESSOR SORTIE" qui définit le format des lignes du fichier. De la note particulière est la section sur:

Nom du fichier source et numéro de numéro de ligne est acheminé par des lignes du formulaire
# drapeaux de nom de fichier linenum
puis continue à décrire les "drapeaux" qui intéressent ce niveau de débogage.

2 commentaires

merci ... j'ai essayé d'ajouter des systèmes / types.h et types.h en vain. mais -e est définitivement utile - un grep sur celui de taille_t et je ne peux pas trouver un typlef pour cela ... hmm

Une autre chose à essayer serait de comparer la sortie de "GCC -E /Tmp/foo.c" et "g ++ -e / /t /tmp/foo.cc" L'ancien invoque le compilateur C et ce dernier le compilateur C ++. (foo.c et foo.cc ne devrait avoir rien d'autre que "#include ".

4
votes

Généralement, vous ne devriez pas utiliser c .h fichiers pour C ++. Bien que vous puissiez trouver un moyen facile de vous en tirer et, bien que beaucoup de ceci aient été autorisés dans les versions précédentes de G ++ et dans d'autres compilateurs, la norme C ++ définit Taille_t à être dans CSTDDEF (voir la section 18.2 / Tableau 17). G ++ n'a été que devenu plus strict.

Supprimer tous les chemins Inclus que vous avez ajoutés à votre commande (ils sont redondants) et ajouter au sommet de votre code source si non inclus: p>

#include <cstddef>
using namespace std;

4 commentaires

Ce n'est pas vrai. Les en-têtes C sont autorisés dans les unités de traduction C ++ et il n'est pas nécessaire de ne pas vous soucier d'utiliser des équivalents C ++ comme CSTDDEF.

CSTDDEF est juste comme STDDEF.H Sauf que le CSTDDEF est dans NAMESPACE STD. Les équivalents C ++ sont plus pratiques pour éviter la pollution des espaces de noms, c'est tout.

Oui, les développeurs Compiler C ++ gaspillent leur temps. Compte tenu de la quantité de code existant comprenant des en-têtes C, tous les fournisseurs de compilateur qui enfreint les en-têtes C se mettront en faillite du matin après. Donc, le seul "avantage" de est qu'ils sont en noms d'espace std. L'exemple de code que vous avez donné a «Utilisation de Namespace Std», donc ne change rien. Il n'est pas évident pour moi que "std" est avantage - si votre propre code dans l'espace de noms, comme si c'était le cas, vous pouvez utiliser n'importe quel nom que vous aimez.

@ Vladimir Prus: Tous les grands fournisseurs de compilateurs qui sont en commerce ont de nos jours cassé au moins certaines parties des en-têtes STD C décennie il y a plusieurs décennies et conservent ces implémentations brisées depuis lors de la compatibilité à l'envers.

9
votes

Commencez par supprimer -i / usr / include / linux et -i / usr / include. L'ajout de répertoires système à inclure les chemins manuellement n'a pas d'effet ni ne casse des choses. En outre, retirer -freepo pour une sécurité supplémentaire.

0 commentaires

3
votes

Avez-vous installé l'emballage essentiel de la construction?

sudo apt-get install build-essential

0 commentaires

1
votes

Il devrait être dans STDDEF.H ou CSTDDEF. Types.h n'est pas une bibliothèque standard et je crois que cela fait référence aux besoins des systèmes d'exploitation.

0 commentaires

3
votes

oublié de faire un suivi à ce sujet. Il s'avère que / usr / include code> ne peut pas être inclus avec / usr / include / linux code> sur cette distribution particulière. Taille_T CODE> semble être effacé par la seconde inclut.

Mes inclut sont maintenant simplement / usr / incluent code> et cela fonctionne bien. P>

-I/usr/include -I/usr/include/ace -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0...

0 commentaires