alors pour m'entraîner, voici un exemple de code que j'ai écrit :
#include <iostream>
#include <memory>
int main()
{
std::unique_ptr<double> p = std::make_unique<double>(3);
std::cout<<"Je passe au C++ correct "<<std::endl;
std::cout<<"Voici *p : "<<*p;
return 0;
}
J'aimerais comprendre pourquoi sans avoir ajouté l'option de compilation C++11 dans les options du compilateur, celui-ci accepte ce code ?
J'ai seulement mis
#include <memory>
dans le code mais pas C++11 dans les options du compilateur.
PS : Vous constatez que j'ai retiré le using namespace std; ça devrait plaisir à du monde ça
2) Si je retire la directive #include <memory> , mais que je mets l'option C++11 dans le compilateur, ça ne fonctionne pas.
D'où ma question : quelle est la différence entre le standard et les fichiers qui sont dans les includes pour être sûr de comprendre ?
Merci
- Edité par pseudo-simple 25 octobre 2018 à 14:37:18
Putain de cours OC, tu fais des efforts mais tes raisonnements sont complètement biaisés par les conneries de ce cours.
C++11 n'est pas un totem magique, c'est juste un flag qui indique au compilateur qu'il doit comprendre les extensions/modifications à la syntaxe qui ont été standardisés avec la norme C++11.
Il n'ai donc pas interdit que les compilateurs acceptent des syntaxes reprisent par la norme C++11, bien avant la normalisation de C++11 (et vue les délais de conceptions de C++11, c'est très probables).
Ce n'est pas parce que la norme a rendu "obligatoire" la fourniture de certaines classes de la STL, qu'elles ne pouvaient pas exister avant et utiliser un code qui n'a pas besoin extensions/modifications à la syntaxe qui ont été standardisés avec la norme C++11.
Bin oui, on pouvait "correctement" coder avant 2011.
Si votre compilateur est récent, il est très probable que la compatibilité C++11 soit le réglage par défaut, ce qui veut dire que même si l'implémentation de std::unique_ptr utilise les fonctionnalités rendues obligatoires par C++11, votre code compilera.
Le flag "C++11" ne dispense pas de faire du C++, donc de toujours inclure les headers des classes que vous utilisez.
"C++11" ne fait que rendre obligatoire la mise à disposition d'un header "memory", contenant directement ou indirectement, la déclaration de la classe std::unique_ptr implémentant l'interface spécifiée dans la norme. Rien de plus.
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
Les options de compilations ne sont que des directives qui indiquent au compilateur comment réagir face au code qui lui est présenté!!!
Ainsi, l'option -std=c++XX ne fait que dire au compilateur "tu dois respecter ce qu'indique la norme indiquée" (ou XX représente l'année de sortie de la norme).
Mais!!!
Si tu ne dis rien concernant la norme que tu veux que le compilateur utilise pour traiter ton code, il faut bien qu'il respecte une norme ou une autre! Et bien sur, a norme respectée dépend d'un choix "tout à fait arbitraire" effectué par l'équipe de développement du compilateur!!
Ainsi, les versions 6 et ultérieures de Gcc (ainsi que la version du compilateur fourni avec VisualStudio 2015 et ultérieurs) ont fait le choix d'activer "par défaut" le support des normes les plus récentes ( C++14, très certainement, sans doute C++17 pour certaines versions des compilateur), ce qui implique forcément ... le support intégral de C++11, vu que C++14 et C++17 ne sont que les "évolutions logiques" de tout ce qui a été mis en place par C++11 (plus quelques nouveauté par ci par là ).
Ceci étant dit, la manière de travailler du compilateur n'a absolument pas changé : si tu veux pouvoir profiter d'une fonctionnalité qui est fournie par la bibliothèque standard, tu dois toujours inclure le fichier d'en-tête qui permettra au compilateur de savoir que la fonctionnalité en question existe.
Pour que les pointeurs intelligents (std::unique_ptr et le couple std::shared_ptr + std::weak_ptr) soient connus du compilateur, tu dois inclure le fichier d'en-tête <memory>.
Si tu ne le fais pas, le compilateur n'a absolument aucun moyen de savoir que la fonctionnalité existe. Tout comme il n'a aucun moyen de savoir que std::cou ou std::cin existe si ... tu n'inclus pas le fichier d'en-tête <iostream>.
C'est "aussi simple" que cela
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
la dernière mise à jour du tuto date de 2013, ce qui fait CINQ ANS!!! (ou peu s'en faut).
Ce temps représente une véritable éternité dans le domaine, car, sur cette période, nous avons vu:
la version majeure 4.x passer passer par les "sous versions" 4.5, 4.6, 4.7, 4.8 et 4.9 (dernière mise à jour "bug fix" : 4.9.4 sortie le 3/8/2016)
la version majeure 5.x passer par les "sous versions" 5.1, 5.2, 5.3, 5.4 et 5.5(dernière mise à jour : 5.5 sortie le 18/10/2017)
La version majeure 6.x (quatre "sous versions itou", dernière mise à jour à peine avant la dernière mise à jour de la 5.5)
la version majeure 7.x avec ses sous version 7.1, 7.2 et 7.3 (dernière mise à jour le 25/1/2018)
la version majeure 8.x et ses sous version 8.1 et 8.2 (dernière mise à jour le 26/07/2018)
la norme C++14
la norme C++17
le support (à titre expérimental) de certaines fonctionnalités qui seront officialisées avec C++20
Nous te disons depuis maintenant près de deux ans que les ressources (tutos / cours) que tu pourras trouver par ici sont obsolètes!
Je ne peux donc que rejoindre gbdivers en espérant que tu finisse un jour par comprendre que ce n'est vraiment pas l'endroit où aller pour espérer trouver des informations fiables sur les nouveautés du langage
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Je comprends, et en attendant il y a aussi des connaissances sur ce forum qui sont quasi-intemporelles :
par exemple , sur ce tuto, j'ai mieux compris que la phase de compilation est composée de : pré-processeur, compilation, assemblage ,édition de liens
Et cela, ce tuto l'explique très bien.
Même si certaines choses sont dépassées. Je pense qu'il faut savoir discerner le grain de l'ivraie quand on en a la possibilité
Mon expérience m'a montré qu'à force de chercher la version idéale, parfois, on ne progresse pas du tout car on procrastine à chercher la ressource idéale.
Sur le fond, tu as aussi raison, et surtout, merci pour ces messages riches qui m'apportent énormément.
amicalement
- Edité par pseudo-simple 26 octobre 2018 à 6:51:51
Même si certaines choses sont dépassées. Je pense qu'il faut savoir discerner le grain de l'ivraie quand on en a la possibilité
On tourne en rond. Comment tu fais pour faire avoir ce discenement, alors que tu débutes ?
On fait un petit jeu si tu veux : relis ce tuto et note la liste des erreurs qu'il contient. (J'en ai trouvé au moins 7 avec une lecture rapide). Je fais la même chose et ensuite on compare nos listes.
Bon, j'avoue que l'argument donné par bacelar est convaincant.
unique_ptr , compilation, memory
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Discord NaN. Mon site.
Discord NaN. Mon site.