2009-11-28 7 views
1

m'a vraiment dérangé par l'inclusion de C stdlib fonctions sur l'espace de noms global et a fini par écrire des choses comme :: snprintf ou :: errno ou struct :: stat , etc, pour différencier de certaines de mes propres fonctions dans l'espace de noms englobant où ces fonctions c stdlib ont été utilisées. Puis j'ai découvert qu'il y avait un moyen de déclarer chaque fonction C stdlib dans l'espace de noms std (comme STL): il suffit d'inclure < c (lib)> au lieu de < (lib) .h> alors j'ai modifié mon codez l'utilisation de ces nouveaux "c pour C++".C stdlib .h est sur C++ et malloc/realloc

Sur Debian/GCC 4.3.4 J'ai eu 2 problèmes:

1) #error Ce fichier nécessite le support du compilateur et de la bibliothèque pour la prochaine \ norme ISO C++, C++ 0x. Ce support est actuellement expérimental et doit être \ activé avec les options du compilateur -std = C++ 0x ou -std = gnu ++ 0x.

2) utilisant std = C++ 0x mon programme compile très bien, mais je n'ai pas modifié :: snprintf ou :: temps, etc .. toutes les fonctions C stdlib est toujours sur l'espace de noms global = (! (non, je ne suis pas using namespace std même pas une fois)

Toute pensée?

Par exemple .. comment arrêter le c stdlib d'envahir mon espace de noms global? < c (lib)> est une fonctionnalité expérimentale de la prochaine norme C++ ou pourrait être utilisé en toute sécurité dès maintenant?

Ensuite, j'ai un autre doute qui mérite peut-être une nouvelle question .. il n'y a pas cmalloc. Je connais toute l'histoire du nouveau remplacement de malloc et pourquoi. mais pour les buffers simples à octets simples, il n'y a pas d'équivalent C++ de realloc. Je sais que les blocs de mémoire et la réallocation sont implémentés/si spécifiques, mais quand il y a des blocs de mémoire libres contigus, realloc fonctionne mieux qu'une nouvelle allocation de tampon et une nouvelle copie de mémoire.

Merci =)!

+3

Pourquoi avez-vous d'autres fonctions de 'snprintf' et autres? – Blindy

+0

D'ailleurs, pourquoi utilisez-vous snprintf dans un programme C++? – jalf

+2

@jalf: Parce que c'est plus propre, plus lisible et beaucoup plus rapide que les flux C++? –

Répondre

4

Pour votre première question, cela dépend des en-têtes que vous essayez d'inclure. La plupart des en-têtes C sont disponibles dans le formulaire c(lib) dans la version existante de C++. Quelques-uns ne le sont pas, et peuvent être ajoutés en C++ 0x. Donc, si vous avez essayé d'inclure l'un de ces éléments, vous avez peut-être obtenu cette erreur.

Deuxièmement, tous les en-têtes de ce formulaire garantissent que les fonctions seront rendues disponibles dans l'espace de noms std. Mais ils ne promettent pas de laisser l'espace de noms global seul. Souvent, ils placent les symboles dans les deux espaces de noms.

Je ne sais pas pourquoi ::snprintf vous dérange plus que std::snprintf si. Vous devez spécifier un préfixe dans les deux cas.

Comme pour realloc, un équivalent C++ n'existe pas, probablement parce qu'il y a plus de problèmes que de valeur, en particulier avec la sémantique plus compliquée de C++ pour copier des objets. (En particulier, si vous tentez de l'utiliser, ne stockez pas d'objets non-POD dans le tampon, car realloc les ajoutera simplement à un tampon nouvellement alloué, ce qui casse les objets non-POD.

Bien sûr, vous pouvez toujours utiliser l'ancien realloc de C en incluant son en-tête. Mais je dirais que vous êtes probablement mieux d'utiliser new/delete, et simplement de trouver une stratégie d'allocation de tampon raisonnable.

+1

Je crois que tous les en-têtes C90 sont disponibles en tant que 'c ...' dans C++ 03. Les seuls nouveaux éléments de C++ 0x sont des en-têtes C99. –

+2

"si vous essayez de l'utiliser, ne stockez aucun objet non-POD dans le tampon" - Je ne pense pas que "cela ne joue pas bien avec le placement nouveau" implique nécessairement "c'est plus de problèmes que ça en vaut la peine ". Mais chaque fois que vous pensez que vous avez besoin de 'realloc', vous devriez probablement vous arrêter pour savoir exactement ce qu'il en est de chaque' vecteur' et 'deque' qui ne répond pas à vos besoins. –

0

c <lib>, qui entoure à peu près <lib> .h dans un namespace std { }, est une fonctionnalité standard de C++. Voir §17.4.1.2 si vous avez accès à l'une ou l'autre norme.

Ce n'est pas une fonctionnalité expérimentale - quel fichier d'en-tête vous pose des problèmes de compatibilité?

En utilisant malloc et al. est bien, mais assurez-vous de ne jamais les mélanger avec new/delete. (Par exemple ne pas delete un tampon ed malloc().)

0

Il y en a de la norme C < lib.h> en-têtes qui ne sont pas encore transmise à < clib>. Probablement vous avez utilisé < cstdint> ou similaire quelque part.

Avec le standard actuel, vous disposez des bibliothèques c répertoriées here. Notez que < cstdint> est et non partie de celui-ci.

Je n'ai pas trouvé de référence décrivant si et quand < cstdint> fera partie de C++, mais si j'essaie de l'inclure, je reçois aussi un message d'erreur me disant que je devrais utiliser -std = C++ 0x , donc je suppose qu'il est prévu d'être inclus dans la prochaine norme C++.

+0

Référence? Ils devraient tous être là. –

+0

Stackoverflow a tué les mots, qui étaient inclus entre crochets. Désolé, corrigé. – hirschhornsalz

+0

oui, j'inclus cstdint. – conejoroy

4

La fonction malloc(), dans la norme C, n'est pas déclarée dans l'en-tête "<malloc.h>". Il est déclaré au <stdlib.h>. Idem pour realloc() et free().

Je ne sais pas C++, mais au lieu de

#include <cmalloc> 

essayer

#include <cstdlib> 
Questions connexes