Vereinfachung möglich und sinnvoll?
-
@SeppJ sagte in Vereinfachung möglich und sinnvoll?:
Nötig ist es nicht, aber es ermöglicht auch die Nutzung in verketteten Aufrufen, a la
cout << rtrim(my_string);
Wobei wir da tatsächlich so langsam in Gebiete kommen, wo die non-const Referenz zu gefährlichen Irrtümern führen kann. Beispielsweise wäre
result = ltrim(my_string)+ rtrim(my_string)
nicht so günstig.
Persönlich finde ich das besser entweder
std::string trim (const std::string& input);
oder
void trim (std::string& input_output);
zu wählen.
Ich vermisse mittlerweile in C++ ein Fortran Feature – die intent Deklaration von Parametern in Funktionen und Subroutinen. Funktionen können übrigens nur „in“ Parameter haben, Subroutinen „in“, „out“ und „in out“.
-
Ja, ich kann durchaus die Meldung des Linters da verstehen. Komplett neue Programmierer können sich da durchaus auf die Schnauze legen, und ein bösartiger Programmierer könnte absichtlich auch erfahrenen Programmierern ein Bein stellen. Aber ich finde es stark übertrieben. Die Hürde ist jetzt echt nicht hoch, das zu lernen. Und wenn du bösartige Feinde hast, werden die dich auf andere Weise kriegen. Ein bisschen Niveau muss man voraussetzen dürfen, sonst kommt man zu nix. Dieser Linter würde die gleiche Diagnose für einen großen Teil der Standardbibliothek liefern müssen.
-
Die boost-Stringbibliotheken bennenen ihre trim() Funktion explizit, da gibt es Sachen wie
trim( std::string& s )
undtrim_copy( std::string const& s )
, in allen Kombinationen (left
,right
mit und ohnecopy
im Namen). Sieht manchmal etwas sperrig aus, aber dafür sieht man beistd::string const cleaned = trim_copy( input ); oder std::string const cleaned2 = trim_left_copy( input );
aber auch sofort, was da passiert.
-
Dieses ganze
trim
,find
undsubstr
sieht mir so aus, als ginge es im Prinzip nur darum, den "richtigen" Substring in einem vorhandenen String zu finden. Da kann man eventuell auch überlegen, mitstd::string_view
zu arbeiten. So ließen sich einige Kopier- und Speicherallokations-Operationen einsparen... aber gut möglich, dass das bei diesem Code nur wenig ins Gewicht fällt und daher nicht so wichtig ist.Das sieht mir aber durchaus wie eine Rendering-Funktion aus, da lassen sich solche Optimierungen meistens schon rechtfertigen.
-
@DocShoe sagte in Vereinfachung möglich und sinnvoll?:
mit und ohne copy im Namen
Das gefällt mir. +1
Ich bin mittel-fortgeschrittener Anfänger, und für mich ist es eine Erleichterung, die Funktionsweise nicht über konstante bzw. nicht konstante Funktionsparameterdeklarationen "erahnen" zu müssen ... sondern sie direkt am Namen der Funktion ablesen zu können.
-
Ich habe das jetz so abgeändert, da ich das trim nur an den besagten Stellen brauche:
// Trim from left inline void ltrim(std::string &s, const char* t = " \t\n\r\f\v") { s.erase(0, s.find_first_not_of(t)); } // Trim from right inline void rtrim(std::string& s, const char* t = " \t\n\r\f\v") { s.erase(s.find_last_not_of(t) + 1); }
Es wäre auch ein Name im Stil von
inplace_rtrim()
denkbat
-
@MegaV0lt sagte in Vereinfachung möglich und sinnvoll?:
find_first_not_of
Heißt das nicht
not_in
anstattnot_of
? In SQL heißt's so... Odernot_one_of
?@MegaV0lt sagte in Vereinfachung möglich und sinnvoll?:
Es wäre auch ein Name im Stil von
inplace_rtrim()
-
Und ob die Antwort richtig ist, verrät dir jetzt das Licht: std::basic_string<CharT,Traits,Allocator>::find_first_not_of
-
@Th69 sagte in Vereinfachung möglich und sinnvoll?:
Und ob die Antwort richtig ist, verrät dir jetzt das Licht: std::basic_string<CharT,Traits,Allocator>::find_first_not_of
If all characters in the range can be found in the given character sequence, npos will be returned.
Ich würde sagen ... die Namensgebung ist an der Stelle einfach nicht folgerichtig.
-
Hab dazu etwas gefunden:
https://english.stackexchange.com/a/249450
of: wenn etwas zum Beispiel Teil oder nicht Teil von etwas ist
in: räumlich
Also ist "of" an der Stelle doch richtig...
Vermutlich wäre "in" umgangssprachlich.
-
Fängste wieder an Selbstgespräche zu führen?
Vielleicht vorher mal informieren, statt später mehrfach Korrekturen zu posten.
-
Selbstgespräche sind kein Zeichen von Dummheit... zumindest, wenn man nicht dadurch aufällt...
Da: https://www.bigfm.de/buzzhaltestelle/17062/studie-menschen-selbstgespraeche-fuehren-genies