|
Anzeige
|
with.do bei C/c++?
Gast
#7923104
In Pascal/Freepascal/Delphi/Lazaurs gibt es with...do gibt es vergleichbares in C/C++?
Gast
#7923107
und sowas?
std:vectorstd::string list = {"Montag", "Dienstag", "Mittwoch"}; for (const auto& day: list) { std::cout << day << std::endl; }
Gast
#7923160
hmm, nicht ganz – dein C++-Beispiel und das Pascal-Snippet tun vom Prinzip her etwas anderes. Dein C++-Code geht einfach die Liste durch und gibt jeden Eintrag aus. Keine Bedingung, keine Fallunterscheidung – nur Iteration. Der Pascal Code prüft nur einen Wert (today) gegen eine Menge von Werten und entscheidet dann zwischen zwei Ausgaben. Oder sehe ich das falsch? Ich habe con C++ so absolut keine Ahnung, bin da eher auf Krabbelkind Niveau, bewege mich da eher bei Pascal oder sogar Basic als C/C++ Müsste es nicht eher so sein
Wird aber auch in der Pascal-Welt aus verschiedenen Gründen oft als schlechter Stil gesehen, z.B. da man bei längeren Blöcken nichtmehr auf Anhieb sieht, zu welcher Struktur ein Member gehört usw.
Nö. Aber
Oliver
Gast
#7923176
hm, aber in Pascal ist [monday..friday] ist eine echte Bereichsprüfung. Der Compiler versteht automatisch: monday <= today <= friday. Switch in C kennt nur einzelne Werte in case, keine Bereiche. In C++ müsste man sich dann doch so behelfen [code] switch (today) { case monday: case tuesday: case wednesday: case thursday: case friday: std::cout << "Oh great—work" << std::endl; break; default: std::cout << "Happy weekend!" << std::endl; break; } {/code] with ist evil: https://ideasawakened.com/post/why-you-should-not-use-WITH-in-your-Delphi-code ... macht mehr potenziellen Ärger als es nutzt. Wirth hat es in seinen Nachfolgesprachen nicht mehr drinn. In den meisten Codingstyles steht drinn dass man es nicht nutzen soll.
Wohl eher was mit set::find. if x in [ a .. b ] in Pascal nutzt hier Mengen, das ist kein Array oder Liste auch wenn es so aussieht, afaik.
Gast
#7923186
Doch, das geht inzwischen. Wobei die Pascal Syntax einfach und lesbar ist im Vergleich zu C++. Ohne Autocompletion kann heute keiner mehr C++ schreiben, und ohne Syntax Highlighting ist C++ unlesbar.
Gast
#7923189
ah ok., Jepp, in C bekomme ich Augenkrebs:-( und brauche immer etliche Versuche bis es mal so klappt, wie ich er versuche, programmiere dafür aber auch viel zu selten
Wenn du zum Augekkrebs auch nocht einen Konten im Kopf haben willst, probier es mal mit python. SCNR
ließ sich unter https://www.onlinegdb.com/online_c_compiler testen.
Nö, gibt's nicht. Und ich halte das für eher gut. Dieses with-Konstrukt ist zwar manchmal scheinbar eine Erleichterung (wie etwa in gezeigtem Beispiel), aber kann auch sehr schnell in die Hölle führen. Die Crux ist nämlich: with-Blöcke können sowohl geschachtelt werden als auch für mehrere Bezeichner gleichzeitig gelten. Und dann noch ein paar Zeilen Code und kein Schwein kann mehr auf die Schnelle nachvollziehen, zu welchem der with-Bezeichner nun der im Block verwendete Feld-, Methoden oder Eingenschaftsname gehört. Inbesondere dann nicht, wenn es den in mehreren der in with-Klausel aufgeführten Bezeichner gibt. Die Sprachdefinition regelt zwar klar, was dann passiert, aber es ist trotzdem große Scheiße. Sprich: with ist vor allem dazu geeignet, den Code maximal unlesbar zu machen. Eine der wenigen Sachen, die ich an Pascal Scheiße finde. Das nutzen vor allem Leute, die ihren Code obfuskieren wollen, was in Pascal ja viel schwieriger ist als in C/C++.
eine der ganz wenigen "reinen" Funktionen in unseren Sourcen ist "inrange(int, int, int), die praktisch überall genau solche Konstrukte ersetzt durch
egal ob der größere Wert als 2.ter oder 3.ter Parameter kommt oder ob überhaupt einer größer ist. Damit offenbart sich auch die Schwäche der ganzen Konstruktion: Sunday...Monday überrascht die Hälfte der Nutzer.
Sorry, das hat man in C++ auf jeden Schritt und Tritt, also wenn DAS ein Argument ist, dann müsste man C++ komplett verbieten. Da weisst du nicht mal ob + addiert, ob ein 'Variablenname' nicht doch ein getter-Funktionsaufruf ist, und welche Kaskade von Funktionen dabei durchlaufen wird dank Klassenhierarchie.
Wo der größere oder kleinere Wert wo steht, ist nur eine Abfrage und ein Swap mehr. Was deine "Funktion" wohl im Hintergrund macht? Mir sind offensichtliche Lösungen lieber.
Welche Schwäche? Würdest du mir bitte erklären, wo du da eine siehst? Ich hätte auch die Fernsehzeitschrift-Reihenfolge (Samstag -> Freitag) verwenden können. Selbst mit Montag als erstem und Sonntag als letztem Tag der Woche funktioniert die Abfrage. Wie sind die Wochentage denn in Pascal definiert?
Es funktioniert damit so nicht:
Du müsstet dann darauf achten, in allen Fällen (und nur denen), in denen der Bereich die Grenze Sonntag -> Montag überschreitet, das && durch ein || zu ersetzen. Falls hier nicht direkte Werte sondern z.B. Variablen stehen, muss diese Unterscheidung zur Laufzeit über ein zweites if erfolgen. Solche Dinge verstecke ich dann auch lieber hinter einer Funktion. Und um das ganze dann wieder zu Pascal zurückzubringen: Was passiert eignetlich, wenn man
schreibt?
Sagen wir es so: Mein Beispiel erfüllt die Frage, ob das so geht. Deswegen definiere ich ja auch die enum mit den Wochentagsnamen. Es ist kein Ersatz für die "in"-Funktion, sondern nur eine Lösung für das angefragte Beispiel.
Was soll dabei rauskommen? Meine Abfrage bezieht sich auf die von mir genannte enum. Will man was anderes haben, muss man auch die enum anpassen. Man sollte schon wissen, was man tut (sonst klemmt man sich die Finger).
Meistens sucht man aber nicht eine Lösung, die speziell für ein ganz konkretes Beispiel funktioniert, sondern eine allgemeingültige.
Na true, wenn heute Sonntag oder Montag ist, sonst false. Eben ein Test auf einen Bereich von Wochentagen.
Und genau das ist der Punkt: Es funktioniert nur, wenn die Definition des Enums und die Abfrage genau auf einander abgestimmt sind und nicht allgemein. Und ich denke, das ist, was Bruno mit
meinte. Du hattest ja gefragt, wo da die Schwäche ist.
Das heißt für die Abfrage, die ich gezeigt habe, würdest du dann die Tage im Enum verschieben, damit sie funktioniert? Das wird spannend, wenn du hier nicht mehr zwei feste Werte hast, sondern Variablen, in denen die Grenzen stehen.
Bei einem [Y..X] wo Y > X gilt, entspricht [Y..X] der leeren Menge [].
Für DIESES Problem funktioniert die Lösung. Wenn man was allgemeingültiges haben will, sollte man die Randbedingungen definieren. Auch die Pascal-Funktion wird irgendwo ihre Grenzen haben.
Nö. Ich würde die Abfrage so schreiben, dass sie das Ergebnis produziert, was ich haben will, und nicht irgendwas, was sich jemand aus den Fingern gesogen hat.
Ich nenne das jetzt mal "Philosophisches Geplapper", da es nichts mit der eigentlich Fragestellung (ob es das folgende Konstrukt auch in C/C++ gibt) zutun hat:
Antwort: Ja, kann man ähnlich realiseren. Wie sind denn monday, friday und die anderen Wochentage definiert?
Üblicherweise als Aufzählungstyp (enum): type Wochentage = (monday, tuesday, usw ); Davon kann man dann Bereiche angeben eben wie in dem if [monday .. friday] oder auch über Bereiche neue Typen ableiten: type Wochenendtage = [saturday..sunday]; Intern haben die einen Wert den man mit ord() ermitteln kann. inc(), decr() gibts auch noch zum hoch/runterzaehlen.
Also wie in C. "Meine" enum könnte man auch problemlos von Montag bis Sonntag definieren. Und "meine" Abfrage würde immer noch funktioneren. Wozu was "allgemeingültiges" schreiben, wenn man das Problem mit einer "popeligen" Abfrage lösen kann?
Das muss Wochenendtage = saturday..sunday; heissen.
Oben hast du es noch ein Beispiel genannt, und mehr als das ist es auch nicht.
Hab ich ja geschrieben. Ich habe mit meinen Ausführungen diese Frage beantwortet:
und das bezieht sich nicht ausdrücklich auf C oder C++, sondern auf den Konstrukt an sich, da er in Pascal offenbar genau die gleiche Schwäche hat.
Es hat mit der Frage zu tun, die du gestellt hast:
Ich kann jetzt nicht für Bruno sprechen, aber das ist die Schwäche, die ich sehe.
Klar kann man das. Es ist aber finde ich kein Fehler, darauf hinzuweisen, dass so ein Konstrukt generell gewisse Fallstricke mit sich bringen kann. Du hast gefragt, welche das sind, ich hab dir diese Frage beantwortet.
Gut, wenn du dir absoulut sicher bist, dass du in deinem Programm so einen Test nicht mit einem Bereich über die Grenze Sonntag->Montag brauchst und auch nie brauchen wirst, dann kannst du es natürlich so machen. Es kann aber (vor allem bei der Pascal-Variante, weil da die Vergleiche nicht explizit ausgeschrieben sind) durchaus überraschen, dass es evtl. nicht mehr funktioniert, wenn man eine andere Kombination an Wochentagen nimmt. Was ist jetzt so schlimm daran, darauf hinzuweisen?
Nope. Mein Programm ist eine Beispiellösung für das von Mairian genannte "Problem". Man kann es auch auf andere Art und Weise lösen. Es ist eine erste, einfache, nachvollziehbare Lösung als Beispiel. Die muss nicht perfekt auf alle möglichen Worstcases reagieren.
Die selben Fallstricke wird es auch bei anderen Programmiersprachen geben. Deswegen nannte ich deinen Post "philosophisches Geplapper" - es trägt nicht zur Lösung der Frage bei. Es könnte sein, dass ein Fehler auftritt; muss aber nicht unter den vorgegeben Bedingungen. Dein Verhalten würden einige "übergriffig" nennen.
Also ist das hier nur der Mimimi-Trollthread eines Dilletanten. Deine Beschwerden sind leicht zu heilen: benutz kein C. :-)
Nochmal: Es bezog sich nicht auf die Programmiersprache, sondern darauf, dass der Konstrukt an sich zu Problemen führen kann.
Nun, wenn mich jemand fragt, wie er sich am besten in den Fuß schießen kann, aber mit einem Gewehr statt einer Pistole, dann werde ich zumindest dazuschreiben, dass es generell keine gute Idee ist, sich in den Fuß zu schießen. Ob er diesen Hinweis zu Herzen nimmt oder nicht, ist kann er ja dann immer noch selbst entscheiden. Wenn mich dann noch jemand fragt, warum das keine gute Idee ist, erkläre ich es ihm eben.
Warum? Ich habe lediglich eine Frage beantwortet, die DU gestellt hast. Da würde ich dein Verhalten eher so beschreiben. Bruno hat nebenbei erwähnt, dass der Konstrukt problematisch sein kann, du hast gefragt, warum, und ich hab dir das beantwortet. Damit hätte es eigentlich zu Ende sein können, aber du hast da inzwischen eine riesen Diskussion draus gemacht.
Wie du schon scheibst: Ich hatte Bruno gefragt. Dass Du dann deinen Senf datzugeben musstest, war mMn überflüssig.
Wenn Du jetzt "Pandas" gesagt hättest... aber Python ist ziemlich geradeaus, damit sollte ein Entwickler leicht zurecht kommen.
Nein. Diese Dinger in Pascal sind keine Aufzählungstypen, sondern Mengentypen. Der Unterschied ist: Es ist von vorherein sichergestellt, dass die Elemente sich als Flags verwenden lassen, denn intern sind diese Dinger eher sowas wie Bitfields in C. Bloß halt mit wesentlich besserer Unterstützung durch die Sprache, die viele Operatoren und Funktionen bereitstellt, um mit diesen Mengentypen sinnvoll zu arbeiten.
Ich zitiere mal den ersten Satz von: https://learnxbyexample.com/pascal/enums/ "Our enum type ServerState has an underlying int type. Enumerated types (enums) are data structures that allow us to define a set of named values for a variable. While some languages have built-in support for enums, many can simulate them using other features." Die gleiche Definition wie in C... Laut Wikipedia (https://de.wikipedia.org/wiki/Aufz%C3%A4hlungstyp) unterscheiden sich die enum von Pascal, Java etc von denen von C durch die Typsicherheit. Ich bin mir nicht ganz sicher, aber arm-gcc (Keil) spuckt AFAIR eine Warning aus, wenn man zwei unterschiedliche enum-Typen mischen will - gehen tut es, aber es wird gemeckert. Laut Delphisprachspec lassen sich mit Aufzaehlungstypen (das sind keine Mengen wie oben jemand behauptete, die spielen da auch rein aber sind nicht das selbe, "set" ist ein eigener Typ und kann auch andere typen aufnehmen, aufzaehlungstypen können nur ordinaltypen aufnehmen) alle Ordinaltypen möglich. Ordinaltypen sind einfach alle ganzzahligen Typen. Mann kann aufzaehlungswerten auch vordefinierte Werte zuweise wie in C bei den enums. Also der erste Wert 100 und nicht wie default eben 0,...
Beitrag #7923779 wurde von einem Moderator gelöscht.
Im Prinzip gibt es viele gute alternativen, wieso muss es ausgerechnet eine ähnliche Lösung sein? Das gleich ist ja name.first,name.middle und name.last .. wieso ist das schwerer als es wegzulassen? Man könnte den Struct erweitern (Nur eine Idee): struct MyStruct { String first; String middle; String last;
};
Sorry, da habe ich Dich auf dem falschen Fuß erwischt. Ich fand Deine Zeile genau richtig, habe unsre "inrange" angebracht und wollte unabhängig davon darauf hinweisen, dass Wochentage für Ranges ungeeignet sind. Wenn inrange als "ist in range [von ... bis]" verstanden wird, dann sollte [3 ... 5] das gleiche bedeuten wie [5 ... 3]. Bei Wochentagen ist Montag-Freitag offensichtlich was anderes wie Freitag-Montag. Und da der erste Tag unterschiedlich festgelegt ist, ist Deine Lösung für diese Aufgabe perfekt, die Aufgabe aber dumm. Für Wochentage führt es zwangsläufig früher oder später in Missverständnisse.
Danke für die Rückmeldung. Meine Fuinktion arbeitet halt nach dem Motto: "Keep it simple!" ;) Die Aufgabe ist erfüllt. Es geht ja nicht um die "in"-Funktion, sondern um das, was bei der Funktion rauskommen soll. Wenn ich ein anderes Ergebnis haben will, muss ich die Abfrage halt ändern / erweitern - ist hier aber nicht gefragt. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
