Warum gibt es keine benannten Parameter verwendet öfter?
Habe ich einen parameter-Klasse die es mir erlaubt, code zu schreiben, wie diese:
//define parameter
typedef basic_config_param<std::string> name;
void test(config_param param) {
if(param.has<name>()) { //by name
cout << "Your name is: " << param.get<name>() << endl;
}
unsigned long & n = param<ref<unsigned long> >(); //by type
if(param.get<value<bool> >(true)) { //return true if not found
++n;
}
}
unsigned long num = 0;
test(( name("Special :-)"), ref<unsigned long>(num) )); //easy to add a number parameter
cout << "Number is: " << num; //prints 1Die Leistung der Klasse ist ziemlich schnell: alles ist nur eine Referenz auf den stack. Und speichern alle Informationen, die ich verwenden einen internen Puffer von bis zu 5 Argumente vor geht es um die heap-Allokation zu verringern Sie die Größe jedes einzelnen Objekts, aber dies kann leicht geändert werden.
Warum ist dieser syntax verwendet öfter, überlastung operator,() zu implementieren benannte Parameter? Ist es aufgrund der potenziellen Leistungseinbußen?
Eine andere Möglichkeit ist die Verwendung des namens idiom:
object.name("my name").ref(num); //every object method returns a reference to itself, allow object chaining.Aber, für mich, überlastung operator,() sieht viel "moderner" C++, so lange Sie nicht vergessen, doppelten Runden Klammern. Die performance leidet nicht viel, auch wenn es langsamer ist als eine normale Funktion, so ist es unwesentlich in den meisten Fällen.
Ich bin wohl nicht der erste zu kommen mit einer Lösung wie diese, aber warum ist es nicht mehr üblich? Ich habe nie etwas gesehen wie die oben beschriebene syntax (mein Beispiel), bevor Sie schrieb ich eine Klasse, die es akzeptiert, aber für mich sieht es perfekt aus.
- ...denn es erhöht die Komplexität und ist nicht nur nützlich?
- Was bedeutet das erreichen?
- Auch eine überlastung
operator,ist in der Regel eine schlechte Idee, weil es wird nicht verhält wie das normale,operator (ähnliche Logik erklärt auch, warum sollte nicht überladenoperator&&oderoperator||). - Ja, ich meine, ich sehe eine Menge von Komplexität und wenig oder gar nichts gewonnen. Denken Sie daran, die Komplexität kostet Geld. Es braucht Zeit für die Menschen zu verstehen, was Los ist ($$$) und es dauert, bis " Wartung/Behebung von Fehlern im Zusammenhang mit (wieder, $$$). Ganz ehrlich, wenn ich so etwas sah, in den code arbeite ich an ich hätte in einem Gespräch mit wem auch immer umgesetzt. Zu mir, riecht nach etwas, dass ein unerfahrener dev einfallen würde.
- Diese Funktionalität gibt es in der boost für die Jahre: boost.org/doc/libs/1_49_0/libs/parameter/doc/html/index.html weiß nicht, wie viel es in der Praxis verwendet wird, obwohl
- Nichts gewonnen? Ich kann hinzufügen, eine beliebige Anzahl von Parametern (in beliebiger Reihenfolge) mit minimalen code-änderungen, die ich erreichen große Flexibilität. Es gibt natürlich einige Regeln, aber die Umsetzung zwingt Sie auf den Benutzer, so viel es kann. Boost.parameter erhöht die compile-Zeit sehr stark, es sollte nicht meine Lösung. Es nutzt auch mehrere Makros, die meiner Meinung nach nicht so viel "modern C++"
- und wieder, wie sieht die Hilfe, die Sie in einer bemerkenswerten Art und Weise? Sicher, es klingt cool, aber sind die Leute wirklich mit Schwierigkeiten bei der Bereitstellung robuster code auf Zeit, weil Sie haben, um Argumente an eine Funktion in einer bestimmten Reihenfolge? Ich denke nicht so.
- erhöht die Kompilierzeit erheblich" vorkompilierte Header Verwenden, und Sie werden nicht sehen, ein Problem. Warum jemand nicht mit Ihnen an diesem Punkt ist mir ein vollkommenes Rätsel. Die Schuld einer Bibliothek, weil Sie mit Ihrem toolset unwirksam ist albern.
- Gut, es nicht passt für jede Lösung/Funktion, Klasse design sollte nur helfen, wenn Sie eine große Anzahl von Parametern. Jeder kann einfach passieren einige Arten in der falschen Reihenfolge. Aber ich verstehe deine Punkte, danke!
- Dieses Beispiel ist nicht Menschen-lesbar genug, um Durchschnittliche code-maintainer in Endlosschleife... Der Punkt der Verwendung von Vorlagen ist, um compiler erraten template-Argumente automatisch, wenn es möglich ist. Im Idealfall code fordert, dass template-Funktionen/Methoden, sollten Sie nicht enthalten jede
<oder>Klammern (die Klassen sind eine andere Geschichte, aber Sie sollten typedeffed). So etwas wieunsigned long & n = param<ref<unsigned long> >()ist unverständlich. Jedoch so etwas wieunsigned long n; getParam(n);wogetParamist Vorlagen<typename T> void getParam(T&)ist viel einfacher zu Lesen. - erhöht die Kompilierzeit erheblich" compile-Zeit weniger kostet als die Entwicklung der Zeit, IMO. Wie lange dauert es zu kompilieren? Stunde? Und wie lange dauert es, bis die Implementierung Ihrer Lösung oder erklären jemand?
- Ich weiß es, entschuldigen Sie mich, aber was ich wirklich meine, war, dass es viel zu groß, meiner Meinung nach. Ich möchte eine einzelne Datei, so einfach ist das. Meine Klasse ist 200-250 Zeilen code, wie groß ist der Auftrieb.parameter wenn Sie jedes Abhängigkeit (mit Ausnahme der STL). Ich glaube, es ist ziemlich viel, aber ich bin nicht eine boost-freak.
- es nicht passt für jede Lösung/Funktion, die " IMo, wenn Programmierer bekommt übermäßig aufgeregt über die Möglichkeiten Sprache bietet, wird er(oder Sie) beginnt verschwenden Entwicklung Zeit in die Entwicklung von übermäßig komplizierte Lösungen, die er nicht wirklich braucht. Ich würde vorschlagen, kleben mit dem KISS-Prinzip.
- Die Verwendung von Boost.Parameter, braucht man nur
#include <boost/parameter.hpp>- eine einzelne Datei. Wen kümmert es, was es enthält? - Klasse 200-250 Zeilen code", Was bedeutet, Sie verbrachte die Hälfte des Tages zu machen. boost-parameter bereits geschrieben, getestet, debugged, Fehler wurden gefunden und behoben, und es wird gepflegt durch andere Menschen. Das große problem mit Ihrem code, dass ich brauchen würde, um Ihre basic_parameter_class und ref zu verstehen, was genau hier vor sich geht. Da Sie gratitously vergessen haben, Ihre Implementierung, Ihr code wird gesetzt Betreuer in stupor für mindestens eine Stunde.
- Ich bin mir bewusst, der KUSS, das war genau der Grund, warum ich es schrieb. Ich finde in meinem code gibt es passt, aber natürlich ist es nur ein Ort für jetzt. Aber ich sehe deinen Punkt und alle anderen Fragen 🙂 @ildjarn : machst du Witze, die Datei öffnen und du findest massig mit beinhaltet...
- Daher das "who cares?". Warum ist es wichtig? (Hint: tut es nicht.)
- Ja das tut es wirklich, steigern.parameter ist eine große Abhängigkeit für mich, und für mich unnötig.
- Wie kann ein header-only-Bibliothek eine große Abhängigkeit? Das ist Unsinn.
- Ihre Klasse ist das Gegenteil von dem KUSS, weil Sie sich entschieden, das Rad neu zu erfinden und die Verwendung von nicht-intuitive syntax anstatt bestehende Lösung, die verwaltet wird von erfahrenen C++ - Entwickler für gratis (null-Kosten für Sie). Siehe meine Antwort für details.
- Wenn Sie "zeigen", dass die "header-only" ist immer "die kleinen" sind Sie falsch, Sie können Massiv mit code in header-Dateien, aber es tust, dass du das solltest. Mein Ziel ist es, nur STL-Abhängigkeit, mit einigen Ausnahme. Aber das ist off-topic. SigTerm : ich weiß, aber eigentlich habe ich es einmal probiert, aber es ging nicht sehr gut, nicht verstanden und ich habe "hard" - Fehler bei der Kompilierung, aber es war eine Zeit her. Ich bin wahrscheinlich ein besserer Programmierer heute.
- Ich habe nie gesagt, kleine, ich sagte, irrelevant. Es gibt keine Verknüpfung beteiligt, so gibt es keine Probleme (oder zumindest haben Sie nicht wirklich gesagt was es ist).
- Bitte bewegen Sie erweiterte Diskussionen zu Stack-Overflow-Chat.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Weil es ist counter-intuitive, nicht-menschlichen lesbaren und wohl ein schlechter Programmierstil. Es sei denn, Sie wollen die sabotage der codebase, vermeiden, dies zu tun.
Let ' s sagen, ich sehe in diesem code-fragment für die erste Zeit. Mein Gedankengang geht so:
().Testist eine Klasse, abertestist eine Funktion), und Sie müssen nichtCPräfixe).nameim Quellcode entdecke ich, dass es Klasse. Und dass es überlastungen der,Betreiber, so dass es tatsächlich nicht verwerfen Sie das erste argument nicht mehr.Sehen, wie viel Zeit verschwendet hier? Ehrlich gesagt, etwas zu schreiben wie, dass können Sie in Schwierigkeiten geraten, weil Sie die Sprache bietet, um Ihren code zu schauen, wie etwas, das Verschieden ist von dem, was Ihr code eigentlich macht (Sie machen einen Funktionsaufruf mit einem argument so Aussehen, wie es hat zwei Argumente, oder es ist eine Variable Funktion). Das ist ein schlechter Programmierstil, das ist etwa äquivalent zu überladen von operator+ durchführen substractions anstelle von Ergänzungen.
Nun, betrachten wir ein QString Beispiel.
Let ' s sagen, ich sehe es zum ersten mal in meinem Leben. So ist mein Gedankengang geht:
statusvom Typ QString.%1-style-Einträge und gibt QString&. Also die Kette der.arg()Anrufe sofort Sinn macht. Bitte beachten Sie, dass so etwas wie QString::arg werden kann und vorgefertigte, und Sie werden in der Lage, um es für verschiedene argument-Typen, ohne manuell die Angabe der Art der Argumentation in<>."Neu und glänzend" bedeutet manchmal "fehlerhaft und gebrochen" (slackware linux gebaut wurde, auf eine etwas ähnliche Idee). Es ist irrelevant, ob dein code sieht modern. Es sollten für Menschen lesbar, es sollte das tun, was es tun sollte, und Sie sollten Abfälle möglichst wenig Zeit in es zu schreiben. I. e. Sie sollten (persönliche Empfehlung) - Ziel "Implementierung einer maximalen Menge von Funktionen in kürzester Zeit zu minimalen Kosten (inklusive Wartung)", sondern erhalten die maximale Belohnung dafür. Auch macht es Sinn zu Folgen KISS-Prinzip.
Ihre "moderne" syntax nicht verringern Entwicklung Kosten, die nicht reduziert die Entwicklungszeit und erhöht die Kosten für die Wartung (Kontra-intuitiv). Als Ergebnis dieser syntax sollte vermieden werden.
returns QString&Sie können tun, dass auf xvalues ??Dort ist keine Notwendigkeit. Ihre dynamic dispatch (Verhalten sich anders, je nach logische Typ des Arguments) umgesetzt werden kann a) viel einfacher und b) sehr viel schneller mit template-Spezialisierung.
Und wenn Sie tatsächlich benötigen, eine Unterscheidung, die auf Informationen basieren, die nur auf Laufzeit, ich würde versuchen, bewegen Sie Ihre
test- Funktion, um eine virtuelle Methode derparamArt und nutzen Sie einfach dynamische Bindung (das ist, was es ist, und das ist, was man irgendwie immer wieder neu zu erfinden).Die einzigen Fälle, in denen dieser Ansatz wäre nützlicher, möglicherweise mehrere-Versand Szenarien, wo Sie wollen, um den code zu verkürzen und finden Sie einige ähnlichkeit Muster.
,ist ungewöhnlich und alles andere als einfach. Operator überladung ist sehr verlockend zu missbrauchen, und dies ist ein Missbrauch. In diesem Zusammenhang ist es das Gegenteil von einfachen, Gebrauch. Auch ich kann mir vorstellen, dass du etwas Magie in Ihrer parameter-Typen Los, der ist nicht trivial, also nicht einfach