C++ Codeoptimierung Tastatureingabe

[Titusthefox (Gast)]

Guten morgen.

Ich habe in C++ eine Aufgabenstellung zu lösen: Es sollen Beliebige 
Zeichen von der Tastatur eingelesen werden, dann sollen bestimmte 
Zeichen aus der Eingabe herausgefiltert werden und bei Eingabe eines 
bestimmten Zeichens soll das Einlesen abbrechen und das Programm mit 
einer Meldung beenden.

Realisiert habe ich das auf diese Weise, nun würde mich interessieren ob 
man das eleganter lösen kann:

#include <iostream>
#include <string>
using namespace std;

const string punctuation {".,;-_!?"};
const char EXIT {'~'};
const char NEWLINE {'\n'};

void is_punctuation(string& s) {
  for(char& ch : s)
    for(char w : punctuation)
      if(ch==w)
        ch = ' ';
}

int main() {
  char ch;
  string s {};

  while(cin.get(ch)) {
    s+=ch;
    if(ch==NEWLINE) {
      is_punctuation(s);
      cout << s << '\n';
      s = "";
    }
    else if(ch==EXIT) {
      is_punctuation(s);
      cout << s << '\n';
      cout << "Programm wurde mit " << EXIT << " beendet." << '\n';
      break;
    }
  }
}

Eingabe: hello world ohne . und , te~st
Ergebnis: hello world ohne   und   te~
Programm wurde mit ~ beendet.

Funktionieren tut es.

[PittyJ (Gast)]

Cool, eine Programm ohne jeglichen Kommentar.
Schon lange her, dass ich das mal erleben durfte.


Das winchtigste ist nicht die Eleganz, sondern dass du das nach 5 Jahren 
auch noch verstehst.

[rµ (Gast)]

Stilistisch: Funktionen mit Namen is_irgendwas sollten normalerweise ein 
"Prädikat" sein, also ein bool liefern, und keinen Zustand haben bzw. 
verändern (pure Funktion).

ansonsten wird man das nicht substanziell anders machen können.

[Titusthefox (Gast)]

PittyJ schrieb:
> Cool, eine Programm ohne jeglichen Kommentar.
> Schon lange her, dass ich das mal erleben durfte.

Ok Optimierung Nr.1 :)

[rµ (Gast)]

natürlich sollte man wenn man schon "int main()" deklariert dem body 
auch ein "return 0" spendieren.

[Titusthefox (Gast)]

rµ schrieb:
> Stilistisch: Funktionen mit Namen is_irgendwas sollten normalerweise ein
> "Prädikat" sein, also ein bool liefern, und keinen Zustand haben bzw.
> verändern (pure Funktion).

Ok ich benenne sie um in delete_punctuation()
Nr.2

[MaWin (Gast)]

Titusthefox schrieb:
> würde mich interessieren ob man das eleganter lösen kann:

Natürlich.
Man kann die doppelten Programmteile im EXIT und NEWLINE Zweig 
einsparen, und die quadratische O(n2) Laufzeit je nach punctuation 
Zeichenanzahl auf lineare Zeit O(n) reduzieren.

Das puffern einer ganzen Zeile vor Ausgabe wird wohl Absicht sein, den 
Puffer s könnte man sonst auch einsparen.

[Titusthefox (Gast)]

MaWin schrieb:
> Man kann die doppelten Programmteile im EXIT und NEWLINE Zweig
> einsparen, und die quadratische O(n2) Laufzeit je nach punctuation
> Zeichenanzahl auf lineare Zeit O(n) reduzieren

Code Vorschlag?

[rµ (Gast)]

Titusthefox schrieb:
> quadratische O(n2) Laufzeit je nach punctuation
>> Zeichenanzahl auf lineare Zeit O(n) reduzieren
>
> Code Vorschlag?

bool is_punctiation(char const ch)
{
  // return true iff ch in punctuation
  ...
}

while(cin.get(ch)) {
  if (is_punctuation(ch))
    ch = ' ';
  ...
}

und den std::string könnte man durch ein constexpr std::array ersetzen.

[Marten Morten (Gast)]

PittyJ schrieb:
> Cool, eine Programm ohne jeglichen Kommentar.
> Schon lange her, dass ich das mal erleben durfte.

Da kann ich dir eimerweise Openssource Programme zeigen. Da wird immer 
noch die alte Einstellung "It was hard to write, it should be hard to 
read" gepflegt.

[Wilhelm M. (wimalopaan)]

Marten Morten schrieb:
> PittyJ schrieb:
>> Cool, eine Programm ohne jeglichen Kommentar.
>> Schon lange her, dass ich das mal erleben durfte.
>
> Da kann ich dir eimerweise Openssource Programme zeigen. Da wird immer
> noch die alte Einstellung "It was hard to write, it should be hard to
> read" gepflegt.

Code und Comment altern unterschiedlich.
Deswegen sollte man Kommentare auf das absolute Minimum beschränken und 
folgendes beachten:

"Kommentiere nur das, was der Code nicht sagen kann, und nicht das, was 
der Code nicht sagt!".

Daraus erwächst natürlich eine Handlungsanweisung ... die leider oft 
missachtet wird.

[Vincent H. (vinci)]

Prinzipiell finde ich den Code eigentlich recht gut. Er ist halt noch 
recht imperativ was einige Nachteile mitbringt. Umso vertrauter man mit 
der Standardbibliothek und modernem C++ ist umso deklarativer und 
kompakter ließe sich die Aufgabenstellung lösen.

Die Frage nach "eleganter" ist immer etwas gemein weil ich dich jetzt 
nicht mit dir eventuell unbekannten Dingen erschlagen will. Hier mal 
eine Version die auf moderne Features von C++20 setzt (ranges: 
https://en.cppreference.com/w/cpp/ranges)

Code:
https://godbolt.org/z/MgGMGw

Da Standard-Input mim Online-Compiler etwas schwierig ist ;) gibt es 
oben ein #define zum Ein- und Ausschalten.


rµ schrieb:
> natürlich sollte man wenn man schon "int main()" deklariert dem body
> auch ein "return 0" spendieren.

Es gibt keine Alternative zu int main(), zumindest keine gültige.

[leo (Gast)]

Vincent H. schrieb:
> Es gibt keine Alternative zu int main(), zumindest keine gültige.

Nein. Gerade fuer uC gilt oft:

5.1.2.1 Freestanding environment

In a freestanding environment (in which C program execution may take 
place without any benefit of an operating system), the name and type of 
the function called at program startup are implementation-defined. / .. 
/ The effect of program termination in a freestanding environment is 
implementation-defined.

leo

[rµ (Gast)]

Vincent H. schrieb:
> rµ schrieb:
>> natürlich sollte man wenn man schon "int main()" deklariert dem body
>> auch ein "return 0" spendieren.
>
> Es gibt keine Alternative zu int main(), zumindest keine gültige.

naja, mit gespaltener Zunge gesprochen gäbs da natürlich noch die 
Variante mit argc/argv ;-)

Das ändert natürlich nichts am return-wert. Eine Funktion die nicht void 
deklariert ist sollte auch was zurückgeben.

wens interessiert:
https://stackoverflow.com/questions/2108192/what-are-the-valid-signatures-for-cs-main-function/

[Wilhelm M. (wimalopaan)]

rµ schrieb:
> Eine Funktion die nicht void
> deklariert ist sollte auch was zurückgeben.

Bei main() ist das anders: impizites return 0;

[Vincent H. (vinci)]

void main()

gcc
error: '::main' must return 'int'

clang
error: 'main' must return 'int'

ellcc
error: 'main' must return 'int'

power64
error: '::main' must return 'int'

zappcc
error: 'main' must return 'int'


Einzig und allein msvc und icc schlucken void...


/edit
Achja, und wir sprechen von C++, nicht von C

[Wilhelm M. (wimalopaan)]

rµ schrieb:
> naja, mit gespaltener Zunge gesprochen gäbs da natürlich noch die
> Variante mit argc/argv ;-)

Und die mit den Env-Variablen gibt es ggf. auch noch (impl-defined)

[Wilhelm M. (wimalopaan)]

Und eine etwas "oldschool" Variante:

#include <iostream>
#include <string>
#include <algorithm>
#include <iterator>
#include <set>

#define USE_FAKE_STDIN

int main() {
    const std::set<char> punctuation{'.', ',', ';', '-', '_', '!', '?'};
#ifdef USE_FAKE_STDIN
  std::string in{"hello world ohne . und , te~st"};
#else
  std::string in;
  std::getline(std::cin, in);
#endif

  const auto end = std::find(std::begin(in), std::end(in), '~');
  std::transform(std::begin(in), end, std::begin(in), [&](const char c){
      if (punctuation.contains(c)) {
          return ' ';
      }
      return c;
  });
  
  std::copy(std::begin(in), end, std::ostream_iterator<char>(std::cout));
}

[Rolf M. (rmagnus)]

Wilhelm M. schrieb:
> rµ schrieb:
>> Eine Funktion die nicht void
>> deklariert ist sollte auch was zurückgeben.
>
> Bei main() ist das anders: impizites return 0;

Sollte man der Vollständigkeit halber trotzdem hinschreiben. Ich würde 
auch mal gerne wissen, was die Standard-Macher da geritten hat, extra 
für main() einen Sonderfall in die Sprachdefinition einzubauen, nur 
damit man dort das sonst nötige return weglassen kann. Das erscheint mir 
wenig sinnvoll.

leo schrieb:
> Gerade fuer uC gilt oft:
>
> 5.1.2.1 Freestanding environment

Allerdings nicht so oft wie man denkt. Einige µC-Implementationen sind 
Hosted Environments.

[Wilhelm M. (wimalopaan)]

Rolf M. schrieb:
> Sollte man der Vollständigkeit halber trotzdem hinschreiben.

Nein, denn ohne das return 0; ist es ja nicht unvollständig.

[MaWin (Gast)]

Titusthefox schrieb:
> Code Vorschlag

State machine, dispatch nach Zeichen '\n', '~', '.', ',', ';', '-', '_', 
'!' und anderen.

[Rolf M. (rmagnus)]

Wilhelm M. schrieb:
> Rolf M. schrieb:
>> Sollte man der Vollständigkeit halber trotzdem hinschreiben.
>
> Nein, denn ohne das return 0; ist es ja nicht unvollständig.

Bezogen auf Standardkonformität nicht. Allerdings wäre Code nicht 
sonderlich lesbar, wenn immer man nur das technisch allernötigste 
hinschreiben würde.

[zitter_ned_aso (Gast)]

Titusthefox schrieb:
> if(ch==NEWLINE) {
>       is_punctuation(s);
>       cout << s << '\n';
>       s = "";
>     }
>     else if(ch==EXIT) {
>       is_punctuation(s);
>       cout << s << '\n';

mag ich nicht.  Die gleichen Zeilen stehen mehrmals untereinander.  Von 
Dr. Sommer habe ich hier gelernt, dass man sowas vermeiden sollte 
(DRY-Prinzip: Don't Repeat Yourself).

while(cin.get(ch)) {                                                  
    s+=ch;                                                              
                                                                        
    switch(ch){                                                         
        case NEWLINE:                                                   
        case EXIT:   remove_punctuation(s);                             
                cout<<s<<'\n';                                          
                s="";                                                   
    }                                                                   
                                                                        
    if(ch==EXIT)                                                        
        break;     
}

[leo (Gast)]

zitter_ned_aso schrieb:
> while(cin.get(ch)) {
>     s+=ch;

Jetzt sehe ich's erst: das ist ja voellig verkehrt - zuerst alles 
anfuegen, dann die Sonderzeichen wieder entfernen bzw ersetzen.

leo

[zitter_ned_aso (Gast)]

dann kann man im Prinzip gleich alle Zeichen einzeln ausgeben (ohne sie 
in einem String zu speichern)

[M.K. B. (mkbit)]

Wilhelm M. schrieb:
> Und eine etwas "oldschool" Variante:

Warum oldschool?

Ich würde das Transform durch ein replace_if ersetzen. Ist zwar im 
Prinzip das gleiche, aber die Funktion sagt gleich aus, was man damit 
tut.

Das set ist eine elegante Lösung, aber evtl. nicht die performanteste. 
Bei wenigen zu suchenden Zeichen könnte eine lineare Suche auf einem 
String schneller sein. (Indirection beim Zugriff und fehlende Cache 
locality) std::string::contains gibt es leider erst ab C++20, aber man 
kann ja auch einen bestehenden stl Algorithmus nehmen.

[Wilhelm M. (wimalopaan)]

M.K. B. schrieb:
> Warum oldschool?

Das meinte ich im Vergleich zu der ranges-Variante.

M.K. B. schrieb:
> Ich würde das Transform durch ein replace_if ersetzen. Ist zwar im
> Prinzip das gleiche, aber die Funktion sagt gleich aus, was man damit
> tut.

Das stimmt:

#include <iostream>
#include <string>
#include <algorithm>
#include <iterator>
#include <array>

#define USE_FAKE_STDIN

int main() {
    constexpr std::array punctuation{'.', ',', ';', '-', '_', '!', '?'};
#ifdef USE_FAKE_STDIN
    std::string in{"hello world ohne . und , te~st"};
#else
    std::string in;
    std::getline(std::cin, in);
#endif
    
    const auto end = std::find(std::begin(in), std::end(in), '~');
    std::replace_if(std::begin(in), end, [&](const char c){ 
        return std::find(std::begin(punctuation), std::end(punctuation), c) != std::end(punctuation);
    }, ' ');
    
    std::copy(std::begin(in), end, std::ostream_iterator<char>(std::cout));
}

M.K. B. schrieb:
> Das set ist eine elegante Lösung, aber evtl. nicht die performanteste.

Auch das stimmt: hier war mir die Expressivität des Codes wichtig: 
doppelete Ersetzungszeichen machen keinen Sinn. Im Endergebnis aber auch 
egal.

Der größte Nachteil des std::set ist der non-constexpr ctor.

M.K. B. schrieb:
> std::string::contains gibt es leider erst ab C++20

Dann machen wir es ganz traditionell und können dann auch ein constexpr 
std::array benutzen.

Oder man fügt einen entsprechenden Algorithmus hinzu:

#include <iostream>
#include <string>
#include <algorithm>
#include <iterator>
#include <array>

#define USE_FAKE_STDIN

namespace {
    template<typename T>
    auto contains(const T& container, typename T::value_type e) {
        return std::find(std::cbegin(container), std::cend(container), e) != std::cend(container);
    }
}

int main() {
    constexpr std::array punctuation{'.', ',', ';', '-', '_', '!', '?'};
#ifdef USE_FAKE_STDIN
    std::string in{"hello world ohne . und , te~st"};
#else
    std::string in;
    std::getline(std::cin, in);
#endif
    
    const auto end = std::find(std::begin(in), std::end(in), '~');
    std::replace_if(std::begin(in), end, [&](const char c){ 
        return contains(punctuation, c);
    }, ' ');
    
    std::copy(std::begin(in), end, std::ostream_iterator<char>(std::cout));
}

[Titusthefox (Gast)]

Welchen Vorteil bietet ein std::array gegenüber einem std::string?

[M.K. B. (mkbit)]

Das Array liegt auf dem Stack und die Größe steht zur Compilezeit fest.
Der String könnte auch auf dem Heap liegen, wenn nicht die small string 
optimization greift.

Ob der String schlechter ist hängt vermutlich vom Optimizer ab.

[Wilhelm M. (wimalopaan)]

Titusthefox schrieb:
> Welchen Vorteil bietet ein std::array gegenüber einem std::string?

In diesem Fall wird der generierte Code - auch wegen der Deklaration als 
constexpr - wohl ziemlich identisch sein.

Auch ohne constexpr wird bei diesen kleinen Stringlängen SSO greifen, 
und damit ist der Unterschied wieder marginal.

Grundsätzlich bringt man mit std::array eine Intention zum Ausdruck: 
dies ist eine Sammlung fester Länge von logisch zusammengehörigen 
Elementen.

(Die Länge von std::array ist ja im Gegensatz zu std::string oder 
std::vector zur Compilezeit fest und damit unveränderbar)

Ich sehe eher einen semantischen Unterschied: in meinen Augen bringt das 
std::array (neben den Anmerkungen von oben) klar zum Ausdruck, dass 
diese einzelnen Zeichen nicht als zusammenhängende Zeichenkette (wie 
etwa der Text) anzusehen ist, sondern einfach nur als eine Menge von 
Trennzeichen. Genau aus diesem Grund halte ich eben std::set für die 
beste Wahl (das mit dem non-constexpr ctor wird sich ja bald lösen). 
Eine Menge bringt diesen Sachverhalt zusammen mit der Mengensementik am 
besten zum Ausdruck.

[sid (Gast)]

Titusthefox schrieb:
> Ich habe in C++ eine Aufgabenstellung zu lösen: Es sollen Beliebige
> Zeichen von der Tastatur eingelesen werden, dann sollen bestimmte
> Zeichen aus der Eingabe herausgefiltert werden und bei Eingabe eines
> bestimmten Zeichens soll das Einlesen abbrechen und das Programm mit
> einer Meldung beenden.

das nennt sich Keylogger;
und die eigentliche Aufgabe wird sein das Antiviren programm davon zu 
überzeugen dass Du harmlos bist.

ich bin raus keylogger mag ich nicht
die klauen eh nur Logins und passworte
und sind genau zu garnichts anderem gut.

Alles andere kann ein Eingabefeld haben

[Peter D. (peda)]

Titusthefox schrieb:
> nun würde mich interessieren ob
> man das eleganter lösen kann:

Ich würde erstmal Standardfunktionen nehmen, ehe ich was selber zu Fuß 
mache, z.B. strtok.

[Oliver S. (oliverso)]

Vincent H. schrieb:
> Hier mal
> eine Version die auf moderne Features von C++20 setzt (ranges:
> https://en.cppreference.com/w/cpp/ranges)

Wilhelm M. schrieb:
> Und eine etwas "oldschool" Variante:

Modernes, supermodernes, und hypermodernes C++ nutzt nichts, wenn es die 
Aufgabenstellung nicht erfüllt.

Titusthefox schrieb:
> und bei Eingabe eines
> bestimmten Zeichens soll das Einlesen abbrechen und das Programm mit
> einer Meldung beenden.

Oliver

[Titusthefox (Gast)]

Eine Frage zwischendurch, ist der Wert eines solchen Konstrukts 
definiert oder kann es auch undefiniert sein? Bitte mal von der 
Sinnhaftigkeit absehen.

if(QUOTEMARK==false) {
   QUOTEMARK = !QUOTEMARK;
}

[Titusthefox (Gast)]

Wie könnte man den Code erweitern wenn alle Punktuationszeichen entfernt 
werden sollen, nicht aber die Punktuationszeichen zwischen 
Anführungszeichen, zB.

Eingabe: Hallo, Test! "Hallo, Test!"
Ausgabe: Hallo  Test  "Hallo, Test!"

[MaWin (Gast)]

Wilhelm M. schrieb:
> Oder man fügt einen entsprechenden Algorithmus hinzu:

Was für ein irrwitziger Aufwand von durch hyperkomplizierte Konstrukte 
verblendete Programmieranfänger die im ersten Semester nicht aufgepasst 
haben.

Insgesamt wird 4 mal durch den String n iteriert, und davon ein Mal für 
jedes Stringzeichen m durch die punctuation Zeichen, also n*m+3n.

Das ist quadratische Laufzeit und Overhead ohne Ende, typisch für die 
modernen gigabytefressenden Programme die nichtmal einen Mäusefurz 
hinbekommen.

while(cin.get(c))
{
  switch(c)
  {
  case '~':
  case '.':
  case ',':
  case ';':
  case '-':
  case '_':
  case '!':
    c=' ';
    break;
  case EXIT:
    cout << EXIT << '\n' << "Programm wurde mit " << EXIT << " beendet." << '\n'; 
    return;
  }
  cout << c;
}

Speicherbedarf: 1 byte. Laufzeit 1 * n. Denses switch wird normalerweise 
(optimize speed) in Sprungtabelle nach Bereichsvergleich kompiliert, es 
ergibt sich also auch im Maschinencode keine Vergleichskette

  if(c=='.'||c==','||c==';'||c=='-'||c=='_'||c=='!'||c=='?')

die ja i.A. zu 7 nicht-zutreffenden Vergleichen führt.

Aber all das lernt man in heutigen Programmiervorlesungen wohl nicht 
mehr, man schreibt lieber mit mehr Tipparbeit grössere Programme die 
mehr Speicher brauchen und langsamer laufen, irgendwer muss ja dafür 
sorgen dass man sich ständig neue Computer kaufen muss weil die 
Programmierhansel nicht mehr so fähig sind wie früher.

[Titusthefox (Gast)]

Und was ist daran schlechter?

while(cin.get(ch)) {
    s+=ch;
    if(ch==NEWLINE || ch==EXIT) {
      delete_punctuation(s);
      cout << s << '\n';
      s = "";
      if(ch==EXIT) break;
    }
}

void delete_punctuation(string& s) {
  bool convert {true};
  for(char& ch : s) {
    if(ch==QUOTE)
      convert = false;
    for(char w : punctuation)
      if(ch==w && convert==true)
        ch = ' ';
  }
}

[Heiko L. (zer0)]

MaWin schrieb:
> switch(...)
> Speicherbedarf: 1 byte. Laufzeit 1 * n.

Richtig. Was der Compiler daraus macht interessiert für solche 
Betrachtungen nicht...

[MaWin (Gast)]

Titusthefox schrieb:
> Und was ist daran schlechter

Wurde doch gesagt:

Mehrmaliges durchlaufen jeden Zeichens, dann einmal bei jedem Zeichen 
noch komplettes Durchlaufen aller punctuation Zeichen.

Könnt ihr noch nichtmal Programme durchschauen ?

Protokolliert doch einfach mal, welche Instruktionen die CPU für eine 
Beispieleingabe durchführen  muss, um verstehen zu lernen, warum C++ zu 
dermassen schlechten (hier im Beispiel schlimmer als Faktor 3 langsamer) 
Programmen führt, die weder weniger Tipparbeit noch übersichtlicher 
sind.

Was soll QUOTE in deinem Programm ? Nachträgliche Problemänderung ?

[Titusthefox (Gast)]

MaWin schrieb:
> Was soll QUOTE in deinem Programm ? Nachträgliche Problemänderung ?

Habe weiter dran gearbeitet, das gehört eigentlich nicht hier rein.

MaWin schrieb:
> Protokolliert doch einfach mal, welche Instruktionen die CPU für eine
> Beispieleingabe durchführen  muss, um verstehen zu lernen, warum C++ zu
> dermassen schlechten (hier im Beispiel schlimmer als Faktor 3 langsamer)
> Programmen führt, die weder weniger Tipparbeit noch übersichtlicher
> sind.

Bin ehrlich gesagt schockiert, habe den Code aus einem bekannten C++ 
Buch. Ich nehme mir mal mit, dass man immer so einfach wie möglich beim 
Programmieren denken sollte, danke.

[Titusthefox (Gast)]

MaWin schrieb:
> Protokolliert doch einfach mal, welche Instruktionen die CPU für eine
> Beispieleingabe durchführen  muss, um verstehen zu lernen, warum C++ zu
> dermassen schlechten (hier im Beispiel schlimmer als Faktor 3 langsamer)
> Programmen führt, die weder weniger Tipparbeit noch übersichtlicher
> sind.

Ich habe diesen Code genommen ohne darüber nachzudenken, eigentlich 
verwendet man ihn nur wenn man ganze Zeilen mit getline() einliest und 
den string dann analysieren/manipulieren muss.

[Titusthefox (Gast)]

Habe den Code nochmal überarbeitet, jetzt liest es ganze Zeilen als 
string ein und entfernt alle Punktuationen bzw. nicht wenn etwas in 
Anführungszeichen steht. Ich denke nur so macht der Code auch Sinn.

Wäre super wenn ihr euch das nochmal anschaut und eure kritik loswerdet:

#include <iostream>
#include <string>
using namespace std;
const string punct {".,;?!_-'"};

bool is_punct(char ch) {
    for(char w : punct)     // macht wirklich nur Sinn wenn man mit strings arbeitet
        if(ch==w) return true;
    return false;
}

void
 convert_punct(string& s) {
    bool convert {true};
    for(char& ch : s) {     // macht wirklich nur Sinn wenn man mit strings arbeitet
        if(ch=='"') {
            convert = !convert;
        }
        else if(is_punct(ch)&&convert)
            ch = ' ';
    }
}

int main()
{
    cout << "Beliebige Eingabe machen\n";
    cout << "Zum beenden Strg+Z eingeben\n";
    for(string line; getline(cin,line);) {
        convert_punct(line);
        cout << line << '\n';
    }
}

[foobar (Gast)]

> Das ist quadratische Laufzeit

Auch wenn du es noch zig mal wiederholst, wird es nicht wahrer.  Die 
Laufzeit ist O(n*m) mit m=konstant, also O(n).

[MaWin (Gast)]

foobar schrieb:
> Auch wenn du es noch zig mal wiederholst, wird es nicht wahrer.  Die
> Laufzeit ist O(n*m) mit m=konstant, also O(n).

Stimmt.

Also: die Laufzeit steigt soeohl wenn man den Eingabestring als auch 
wenn man den punctuation String erweitert.

[Wilhelm M. (wimalopaan)]

Titusthefox schrieb:
> Wäre super wenn ihr euch das nochmal anschaut und eure kritik loswerdet:

Die expliziten Schleifen fördern nicht das Verständnis des Codes. Besser 
ist es, Algorithmen zu verwenden. Und lass Dich nicht von solchen Leuten 
verwirren, die so etwas behaupten :

MaWin schrieb:
> Was für ein irrwitziger Aufwand von durch hyperkomplizierte Konstrukte
> verblendete Programmieranfänger die im ersten Semester nicht aufgepasst
> haben.

Oder:

MaWin schrieb:
> Das ist quadratische Laufzeit

Du solltest die freie Funktion nicht unbedingt is_punct(...) nennen, 
sondern contains(...) daraus machen, dann ist sie universeller 
verwendbar.

Auch sollte man Output-Parameter vermeiden. Kann man so machen, aber es 
ist die Frage, welche Probleme man sich damit später einhandelt. Kopien 
sind oft besser.

Solchen Code kann man zwar schreiben, allerdings musst Du Dir im klaren 
sein, dass dieser Code natürlich völlig unflexibel ist.

MaWin schrieb:
> while(cin.get(c))
> {
>   switch(c)
>   {
>   case '~':
>   case '.':
>   case ',':
>   case ';':
>   case '-':
>   case '_':
>   case '!':
>     c=' ';
>     break;
>   case EXIT:
>     cout << EXIT << '\n' << "Programm wurde mit " << EXIT << " beendet."
> << '\n';
>     return;
>   }
>   cout << c;
> }

Die Kunst beim Programmieren ist nicht, ein lauffähiges und für seinen 
begrenzten Einsatzzweck korrekt funktionierendes Programm zu schreiben. 
Das kann man auch mit einer solchen "Erstsemesterlösung (O-Ton MaWin) 
irgendwie hinkriegen. Aber ich glaube, dass Du über dieses Stadium schon 
hinaus bist.

Zudem Reden wir hier von PC-Programmierung:  Speicherbedarf ist nicht 
notwendigerweise ein Gütekriterium und selbst auf µC gibt es für nicht 
benutzten Speicher kein Geld zurück.

Also mach Dir Gedanken über Abstraktionen, und versuche jeweils dir 
höchste Abstraktion zu wählen.
Und mache Dir Gedanken über Namen: naming is hard, es ist vielleicht 
sogar das Schwierigste beim Programmieren.

[Wilhelm M. (wimalopaan)]

Als Verallgemeinerung von

MaWin schrieb:
> while(cin.get(c))
> {
>   switch(c)
>   {
>   case '~':
>   case '.':
>   case ',':
>   case ';':
>   case '-':
>   case '_':
>   case '!':
>     c=' ';
>     break;
>   case EXIT:
>     cout << EXIT << '\n' << "Programm wurde mit " << EXIT << " beendet."
> << '\n';
>     return;
>   }
>   cout << c;
> }

kannst Du ja dies hier verwenden:

#include <iostream>
#include <string>

using namespace std;

template<typename T, T... CC>
struct Replace {
    inline static constexpr Replace with(const T& w) {
        return Replace(w);
    }
    T operator()(const T& in) const {
        if (((in == CC) || ...)) {
            return w;
        }
        return in;
    }
private:
    constexpr explicit Replace(const T& i) : w{i} {}
    const T w;
};

int main() {
    constexpr auto exitChar{'~'};
    constexpr auto replace = Replace<char, '.', ',', ';', '-', '_', '!', '?'>::with(' ');
    
    char c{};
    while(cin.get(c)) {
        c = replace(c);
        if (c == exitChar) {
            cout << exitChar << '\n' << "Programm wurde mit " << exitChar << " beendet." << '\n';             
            return 0;
        }
        cout << c;
    }   
}

Dies liefert etwas kürzeren Maschinencode als die switch-Variante.

[Oliver S. (oliverso)]

Wilhelm M. schrieb:
> Dies liefert etwas kürzeren Maschinencode als die switch-Variante.

Mit -O3 ist der Maschinencode (in erster Näherung) identisch.

Oliver

[MaWin (Gast)]

Wilhelm M. schrieb:
> Dies liefert etwas kürzeren Maschinencode als die switch-Variante

Zeigen, denn das halte ich für unwahrscheinlich, denn
a) if(c==exitchar) ist ein zusätzlicher Vergleich, der beim switch 
gleich miterledigt wurde.

b) Und dein Template if (((in == CC) || ...)) sieht doch in erster 
Näherung nach if(c=='.'||c==','||c==';'||c=='-'||c=='_'||c=='!'||c=='?') 
aus mit seinem immensen Laufzeitaufwand.

Wenn replace(c) vom Compiler als char replace[256]={'\0', '/1', ... '+', 
' ', ' ', ' ', '/, '0', ... '{', ' ', '}', ... '\x7F'} umgesetzt wird, 
dann könnte es effizienter sein, aber das trau ich dem Compiler nicht 
zu.

[Oliver S. (oliverso)]

Oliver S. schrieb:
> Mit -O3 ist der Maschinencode (in erster Näherung) identisch.

Mit in erster Näherung meine ich vertauschte Anordnung der Blöcke. Die 
eigentliche Funktionalität wird tatsächlich in völlig identischen Code 
übersetzt.

Oliver

[Wilhelm M. (wimalopaan)]

MaWin schrieb:
> Zeigen, denn das halte ich für unwahrscheinlich,

Mach selbst (godbolt).

MaWin schrieb:
> Und dein Template if (((in == CC) || ...)) sieht doch in erster
> Näherung nach if(c=='.'||c==','||c==';'||c=='-'||c=='_'||c=='!'||c=='?')
> aus mit seinem immensen Laufzeitaufwand.

Du scheinst eine schlechte Meinung von Compilern zu haben.

MaWin schrieb:
> Wenn replace(c) vom Compiler als char replace[256]={'\0', '/1', ... '+',
> ' ', ' ', ' ', '/, '0', ... '{', ' ', '}', ... '\x7F'} umgesetzt wird,

Mir ist es ehrlich gesagt egal: ich instrumentiere den Compiler mit 
möglichst viel Information, und er macht seinen Job gut. Meine Erfahrung 
ist: fold-expressions werden sehr effizient umgesetzt.
Ich verstehe nicht, warum Du schlauer als der Compiler sein willst. 
Schreibe vernünftige Abstraktionen, und Compiler tut seine Arbeit.

[Wilhelm M. (wimalopaan)]

Oliver S. schrieb:
> Mit in erster Näherung meine ich vertauschte Anordnung der Blöcke. Die
> eigentliche Funktionalität wird tatsächlich in völlig identischen Code
> übersetzt.

Beim mir ist er mit gcc-trunk wenige Instruktionen kürzer. Aber das ist 
auch völlig egal.
Dieses Gequatsche, man müsste als Programmierer die Optimierungen des 
Compilers erledigen, ist doch einfach nur Blödsinn. Die Compilerbauer 
sind ja nicht blöd. Man muss seinen eigenen Code nur mit genügend 
Informationen für den Compiler ausstatten, und dann tut der seinen Job 
ganz hervorragend.

[MaWin (Gast)]

Wilhelm M. schrieb:
> Meine Erfahrung ist:

Meine Erfahrung ist: selbst simpelste Dinge werden von Compilern extrem 
mies umgesetzt.

Das war sogar meine Studienarbeit, Vergleich von 8 C Compilern für 8088. 
Und heute schau ich bei AVR und STM32 hin und wieder nach dem 
Assembleroutput und bin ähnlich erschrocken.

[Wilhelm M. (wimalopaan)]

MaWin schrieb:
> Meine Erfahrung ist: selbst simpelste Dinge werden von Compilern extrem
> mies umgesetzt.

Willkommen im 21-ten Jahrhundert!

MaWin schrieb:
> Das war sogar meine Studienarbeit, Vergleich von 8 C Compilern für 8088.

Da hast Du in 30 Jahren nichts dazugelernt, und schreibst Code, der die 
Optimierungstrategieen der Compiler zunichte macht. Das ist schon hohe 
Kunst.

[MaWin (Gast)]

Wilhelm M. schrieb:
> Mach selbst (godbolt)

Sprich: du hast gelogen und bist gar nicht in der Lage mal eben die 
Zeilen aus deinem schon generierten Output hierher zu kopieren, weil du 
den nicht hast, sondern ihn dir nur im Koof zusammenphantasiert hast. 
q.e.d.

Mein VS2015 kann den von dir verwendeten neuesten C++ noch gar nicht, 
ich werd mir jetzt aucb keinen neueren Compiler installieren.

[MaWin (Gast)]

Wilhelm M. schrieb:
> Da hast Du in 30 Jahren nichts dazugelernt

Falsch, die AVR und STM32 sind aktuelle gcc, so strohdoof wie vor, 30 
kommt hin. Compilerbauer haben nichts hinzugelernt.

[Wilhelm M. (wimalopaan)]

MaWin schrieb:
> Mein VS2015 kann den von dir verwendeten neuesten C++ noch gar nicht,

Tja, Pech für Dich.

Solltest mal über eine aktuelle Entwicklungsumgebung nachdenken.

Kleiner Tipp: in ein paar Wochen haben wir 2020 und C++2a wird zu C++20 
und danach geht es in riesen Schritten zu C++23.

[Wilhelm M. (wimalopaan)]

MaWin schrieb:
> Sprich: du hast gelogen und bist gar nicht in der Lage mal eben die
> Zeilen aus deinem schon generierten Output hierher zu kopieren, weil du
> den nicht hast, sondern ihn dir nur im Koof zusammenphantasiert hast.

Das Du nicht in der Lage bist den Code zu compilieren oder zu verstehen, 
beweist erstmal gar nichts.

[Wilhelm M. (wimalopaan)]

MaWin schrieb:
> Falsch, die AVR und STM32 sind aktuelle gcc,

MaWin schrieb:
> Mein VS2015 kann den von dir verwendeten neuesten C++ noch gar nicht,

Ich hatte Dir einen Tipp gegeben, und der heißt Matt Godbolt. Bis Du 
auch dazu nicht in der Lage?