Pourquoi studio visuel a besoin de <string> pour compiler, mais codeblocks doesnt?

Fondamentalement, le program compile sur codeblocks, mais pas sur Visual Studio 2015, à moins ajouterPourquoi studio visuel a besoin de <string> pour compiler, mais codeblocks doesnt?

#include <string>

à l'un des fichiers, puis-je obtenir sur les erreurs de la première ligne du code

1>------ Build started: Project: ConsoleApplication2, Configuration: Release Win32 ------ 
1> pytanie.cpp 
1>pytanie.cpp(25): error C3861: 'getline': identifier not found 
1>pytanie.cpp(42): error C2679: binary '<<': no operator found which takes a 
right-hand operand of type 'std::string' (or there is no acceptable 
conversion)

et environ 200 lignes de ce genre de choses

'std::basic_ostream<char,std::char_traits<char>> 
&std::basic_ostream<char,std::char_traits<char>>::operator <<(const void *)'

la question est, pourquoi codeblocks peut compiler et exécuter ce programme, b ut besoin visual studio

#include <string>

j'ai découvert - grâce à ce forum - que l'utilisation getline et < opérateur < exige notamment la ligne « inclure chaîne », mais pourquoi peut codeblocks travailler sans elle, ou pourquoi visual studio 2015 NE PEUT PAS?

edit: oui, codeblock utilise le compilateur GNU GCC et VS2015 utilise par défaut

Source

2016-02-28 tubidubidam

Un autre en-tête inclut «» (ou un sous-ensemble de celui-ci) dans votre cas de codeblocks. C++ permet aux en-têtes standard d'inclure d'autres en-têtes standard de manière non spécifiée. Apparemment, cela se produit avec n'importe quel toolchain que vous utilisez dans les blocs de code, mais pas avec Visual Studio. –

cela n'a rien à voir avec Visual Studio vs CodeBlocks. Cela concerne les en-têtes de leurs chaînes d'outils sous-jacentes, à savoir celles de MSVC et de la chaîne d'outils apparemment non-MSVC utilisée par CodeBlocks (probablement GCC + glibc). Apparemment, l'en-tête iostream de glibc inclut '', tandis que celui de MSVC ne l'est pas. –

Ni Visual Studio ni CodeBlocks ne sont des compilateurs. Ce sont des programmes qui invoquent des compilateurs. Cela ne les rend pas compilateurs, tout comme 'cmd.exe' ne devient pas un compilateur juste parce que' cl.exe' est démarré à partir de là. –

Tout fichier d'en-tête standard est autorisé, mais pas nécessaire, d'inclure toute autre.

Donc sur un compilateur, l'un des en-têtes que vous incluez inclut <string>, et sur l'autre compilateur, aucun. Ceci est généralement difficile (ce qui signifie que c'est extrêmement difficile à obtenir, même pour les experts), mais pour la portabilité, je crains que vous ayez besoin de savoir quels en-têtes incluent les déclarations que vous utilisez, et assurez-vous d'inclure tous d'eux.

Source

2016-02-28 20:02:31

Merci beaucoup :) – tubidubidam

Si vous utilisez quelque chose qui est spécifié pour être déclaré/défini dans un certain en-tête, vous devez inclure cet en-tête parce que même pour une certaine plate-forme ou un compilateur les inclusions non spécifiées dans un fichier peuvent changer Il n'est ni difficile ni difficile je pense. S'appuyer sur n'importe quoi d'autre est une sorte d'UB. – Pixelchemist

@Pixelchemist Je trouve ça compliqué; YMMV. En particulier, vous devez savoir exactement quelles sont les surcharges que vous utilisez (pensez 'operator >>', ou 'getline'), et si vous faites une erreur, vous n'obtenez aucun avertissement tant que vous n'avez pas essayé un autre compilateur. Exemple: quels en-têtes sont requis pour 'std :: cout <<" hello world "<< std :: endl;'? (Ignorer l'opportunité ou non de 'endl'.) –

-5

Généralement, la plupart des implémentations STL ne sont pas très standardisées. Pour être sûr que le code compile avec chaque compilateur, il vaut mieux utiliser un bloc d'en-tête avec tous les modules STL que vous pouvez utiliser dans un projet et simplement le développer. Parce qu'ils sont des modèles, il n'y a pas de surcharge pour ceux qui ne sont pas utilisés.

Source

2016-02-28 20:06:15

La bibliothèque standard est très standardisée. La STL est antérieure à la norme C++ (il y a près de 20 ans maintenant) et n'est pas la même que la bibliothèque standard, bien que ce soit l'une des entrées. http://stackoverflow.com/questions/5205491/whats-this-stl-vs-c-standard-library-fight-all-about –

Les implémentations STL ne sont pas normalisées du tout. Les implémentations de bibliothèques standard (et celles que vous utilisez actuellement) sont 100% standardisées. C'est pourquoi on l'appelle la bibliothèque standard. –

Pourquoi studio visuel a besoin de <string> pour compiler, mais codeblocks doesnt?

Répondre

Questions connexes