10
votes

C ++: COUT AVEC UN TERNAIRE IF-Déclaration

i Obtenir cette erreur: "Erreur: fonction surchargée sans information de type contextuel".

cout << (i % 5 == 0) ? endl : "";

c++ if-statement cout

17 commentaires

Pourquoi pas seulement si (i% 5 == 0) COUT << endl; ?


                                        
                                                                            Parce que, il veut utiliser un opérateur ternaire.
                                        
                                                                            @Kalyan: Cela mendie la question. "Comment puis-je faire x?" " pourquoi  x?" "Parce que je veux x". Ne répond pas à la question:  Pourquoi  utilise une expression conditionnelle ici? C'est laid, trop compliqué et ne fonctionnera jamais jamais.

                                        
                                                                            @Gman: Dans ce cas, il y a quelque chose qui est très similaire fonctionnel (et probablement ce qui a été utilisé pour que de nouveaux utilisateurs comprennent rarement que  endl  flushes et quand vous devez vous soucier). En utilisant ce style, je me trouve souvent en utilisant des opérateurs ternaires pour sélectionner des parties des chaînes. "Ugly, trop compliqué"? IMHO, c'est concis et joliment localisé, lisible et global bon code de code. C / C ++ se différencie de Pascal, etc. en fournissant ce niveau d'expressivité concise ... et je suis puty heureux.

                                        
                                                                            @Tony: ajout  ""  à  cout  n'a pas d'effet pertinent, alors pourquoi le faire du tout  dans ce cas ?

                                        
                                                                            @Tony: Quels sont les autres cas à voir avec ce cas? Je dis  Cette utilisation  est laide et trop compliquée. Considérez cette expression des versets de Georg: ce qui est plus facile à lire?

                                        
                                                                            @Georg: Il y a deux facteurs à considérer. Premièrement,  std :: COUT << ...  met l'accent sur l'impression sur quoi et si. Si vous n'êtes pas intéressé par l'impression, vous savez immédiatement à ignorer cette ligne.  Si (Expr) instruction;  vous oblige à numériser le long de la ligne pour voir si cela est d'intérêt. Deuxièmement, pas dans  Ceci  cas, mais dans un grand nombre, il est utilisé dans une partie d'une sortie plus grande comme  pour (... chaque élément ...) std :: COUT << élément < <(is_last_expr? "": ","); : C'est souvent Messier (lisibilité du code source / concision sage, besoin d'accolades) ayant une déclaration supplémentaire juste pour obtenir une nouvelle amélioration de l'efficacité.

                                        
                                                                            @Gman: Nous  Demander  (je dois parfois prier presque :-)) Personnes à poster des échantillons minimaux qui illustre leur question, alors ne le prenez pas trop littéralement - comme si c'était le seul et exact Utilisez le cas et toutes les considérations connexes ne sont pas pertinentes.

                                        
                                                                            @Tony: Le reste du code est également assez non pertinent. C'est vraiment juste cette expression qui est terrible code. Une méthode supérieure existe. L'expression conditionnelle est, conceptuellement, une expression if-then-else, mais le problème à la main n'est qu'un si-alors; No -else. Mauvais outil pour le travail, période.
                                        
                                                                            @Gman: Merci pour la "période" ... si peu d'absolus dans la programmation, il est bon de savoir où venir quand je veux regarder un ;-).
                                        
                                                                            @Tony: Avez-vous une réfutation, ou vous ignorez-vous toujours des choses lorsque vous ne voulez pas y répondre?
                                        
                                                                            @Gman: Je suis désolé - je n'ai pas réalisé que vous avez fait un nouveau point. "Le reste du code est ... non pertinents" - est-ce que c'est sur mon commentaire que cela pourrait être une simplification? J'ai illustré ci-dessus comment  std :: COUT << TOUJOURS << (EXPR? ",": "");  a) met l'accent sur la production et la dépose du séparateur qui est un détail vraiment trivial. Avez-vous répondu à cela (peut-être la revendication «non pertinente»)? "C'est vraiment juste cette expression qui est terrible"? Voulez-vous dire "cette déclaration"?, C'est-à-dire une utilisation d'accord comme si j'ai décrit pourrait avoir un sens, mais le cas exact posté est indéfendable? Avez-vous un autre point?

                                        
                                                                            @Tony: J'ai dit qu'il veut un si, puis, et que le ternaire est si, alors, d'autre; Une inadéquation, Ergo n'est pas la bonne approche.
                                        
                                                                            @Gman: Je ne vois pas que cela soit significativement différent de beaucoup d'autres endroits où les gens choisissent d'avoir des déclarations non ops / vides ou de ne pas faire de l'exercice de soutien prévu pour la ramification des raisons stylistiques, par exemple.  tandis que (vrai) {... si (x) cassure; } ,  pendant (expr); ,  pour (;;) instruction; . Parfois également, les chaînes exactes peuvent être fournies par les macros, la génération de codes, les stratégies de modèle, etc. où elles peuvent ne pas être connues ni garanties s'ils sont vides, et ? "x": ""  est comme ça que ça se débrouille.

                                        
                                                                            @Tony: Et encore, quand ces autres cas se posent, nous allons traiter avec eux. Ce n'est pas le cas  ici .

                                        
                                                                            @Gman: D'accord, et arrondi nous allons. C'est normal sur s.o. Pour essayer de couvrir un peu l'espace, plutôt que de coller à la question exacte. Pour l'utilisation  exacte  Publié ici (ignorant le fait qu'il ne compilera pas) Je conviens que les aspects stylistiques que je mentionent ne sont pratiquement jamais justifiés. Je n'ai jamais contesté ça. Vous contestez-vous que dans d'autres déclarations de streaming, des valeurs conditionnelles où l'on est "" peut être utile, ou simplement de maintenir que je ne devrais pas divertir la discussion si sauvagement de sujet? ;-)

                                        
                                                                            @Tony: Eh bien, alors nous sommes fixés, c'est une mauvaise idée d'essayer de faire fonctionner cela dans cette situation. Si vous souhaitez mentionner la question des autres utilisations, vous pouvez le faire, mais il est probablement préférable de les traiter quand ils se présentent.

7 Réponses : -1 votes opérateur <<< / code> a une priorité plus élevée que ?: . Essayez ceci: xxx 2 commentaires L'avez-vous essayé vous-même? Cela va-t-il compiler? Il est temps de regarder dans les vieux trucs? 15 votes Les deux arguments sur le ? code> doivent être du même type (au moins après des promotions potentielles, des constructeurs implicites, des opérateurs de coulée, etc. STD :: endl code> est en fait un modèle de fonction (Détails ci-dessous) que le flux invoque ensuite à affecter son état: ce n'est pas un littéral de chaîne comme "" code>. . Donc, vous ne pouvez pas faire cela exactement em>, mais vous pouvez probablement obtenir le comportement que vous voulez réellement - considérez si ... p> template<typename _CharT, typename _Traits> inline basic_ostream<_CharT, _Traits>& endl(basic_ostream<_CharT, _Traits>& __os) { return flush(__os.put(__os.widen('\n'))); } 1 commentaires J'ai suscité Andreyt pour ses explications, mais +1 pour fournir une solution réellement :) 3 votes Les deux alternatives de ?: doivent avoir le même type ou une convertible à l'autre. endl est un modèle et le contexte ne donne pas assez d'informations pour lesquelles choisir. Donc, il n'a même pas de type. (C'est votre message d'erreur). comme autre déjà dit, la liaison n'est pas celle que vous attendez. 0 commentaires 33 votes Cela ne fonctionnera pas de cette façon (même si vous réparez l'erreur de prime). Vous avez deux problèmes ici, plus sévère que le premier. Le premier problème est que std :: endl code> est un modèle. C'est un modèle de fonction. Un modèle doit être spécialisé. Afin de spécialiser ce modèle, le compilateur doit savoir (à déduire) les arguments du modèle. Lorsque vous faites p> xxx pré> le type de pointeur de fonction spécifique attendu par opérateur est ce que le compilateur utilise pour déterminer comment spécialiser le Std :: endl code> modèle. P> Cependant, dans votre exemple, vous avez essentiellement "détaché" le std :: endl code> de opérateur en déplaçant le std :: endl dans un ?: code> subexpression. Maintenant, le compilateur doit compiler cette expression d'abord p> xxx pré> Cette expression ne peut pas être compilée car le compilateur ne sait pas comment spécialiser le std :: endl code> modèle. Il n'y a aucun moyen de déduire les arguments de modèle sans aucun contexte. p> Par exemple, ce programme C ++ simple P> $ cat qq.cpp #include <iostream> using namespace std; int main (void) { int i = 5; cout << ((i % 5 == 0) ? endl : ""); return 0; } $ g++ -o qq qq.cpp qq.cpp: In function 'int main()': qq.cpp:5: error: overloaded function with no contextual type information 2 commentaires +1 Et s'il a été explicitement sélectionné, cela échouerait toujours car un pointeur de fonction et un littéral à chaîne n'ont rien de commun. Couvre beaucoup de terrain que je manquais de patience. +1. 2 votes Cela pourrait bien être possible (j'en doute moi-même). Cependant, il est également stupide, effectivement aussi idiot que: xxx ce que vous devriez-vous faire dans ce cas est un simple: xxx < / Pré> Vous ne devriez pas utiliser ternaire uniquement pour l'utilisation de l'utilisation. En fait, vous ne devriez pas utiliser aucune fonctionnalité de langue juste pour l'utilisation de celui-ci. Je n'écris pas de code comme: xxx juste parce que je peut. un simple doSomething (); est beaucoup mieux. 0 commentaires 2 votes Essayez ceci, cela fonctionne: cout << ((i % 5 == 0) ? "\n" : ""); 0 commentaires 1 votes Voici comment il est censé avoir l'air de le faire fonctionner correctement: cout << ((i % 5 == 0) ? '\n' : " "); 0 commentaires

Articles qui pourrait vous intéresser : Catalina C ++: L'utilisation d'en-têtes <cmath> génère une erreur: aucun membre nommé 'signbit' dans l'espace de noms global installation du compilateur c ++ 11 (+) sans autorisation d'administrateur Application de console C ++ VS2019 - Le débogueur n'acceptera pas les arguments de commande Meilleur moyen en C ++ de garder une grosse structure atomique?