Funktion für nur Zahlen und nur Buchstaben
-
volkard schrieb:
seit 99 sind 6 jahre her.
Sag das mal jemand, der auf einem alten Betriebssystem mit alten Entwicklungswerkzeugen arbeiten muss. Der freut sich bestimmt!
volkard schrieb:
das char dient vor allem der kommentierung, was da reingeht. genauso das bool beim ausgang.
Dabei vernachlaessigst Du das Problem, dass z.B. getchar() Integers zurueckliefert. D.h. beim Aufruf muss man nach char casten. Toll!
volkard schrieb:
#define RANGE(min,x,max) ((min)<=(x))&&((x)<=(max)) bool isDigit( char ch ){ return RANGE('0',x,'9'); }Prinzipiell sehr schoen, aber die Parameterreihenfolge ist sehr bizarr (von dem Fehler in isDigit() mal abgesehen -- es muss "ch" statt "x" heissen).
Besser und logischer waere:
#define RANGE(x,min,max) ((min)<=(x))&&((x)<=(max)) bool isDigit( int ch ){ return RANGE( ch, '0', '9' ); }
-
volkard schrieb:
mit dem ?: behebst du nir ein problem, das entstanden ist, weil du ist statt bool lieferst.
Ich verstehe ungefaehr, durch die Tippfehler, was Du damit sagen willst.
Leider ein weiterer Irrtum von Dir: Der Ergebnistyp eines ? : Operatorpaars ist gleich dem Ergebnistyp des eingetretenen Falles.
Also liefert bei "bool" der Ausdruck "x ? true : false" auf jeden Fall ein Ergebnis vom Typ bool.
Siehe auch Kapitel 6.5.15 im C Standard (ISO 9899:1999).
Die Regel "int always wins" gilt schon seit dem ersten C Standard (1990) nicht mehr.
-
Power Off schrieb:
Prinzipiell sehr schoen, aber die Parameterreihenfolge ist sehr bizarr
ja, das "subjekt" sollte an erster stelle in der parameterliste stehen. aber hier gewinnt die konvetion, denn borland liefert seit urzeiten eine range aus mit dem subjekt in der mitte und jeder kennt und mag sie. gleiche geschichte wie random().
-
Power Off schrieb:
volkard schrieb:
mit dem ?: behebst du nir ein problem, das entstanden ist, weil du ist statt bool lieferst.
Ich verstehe ungefaehr, durch die Tippfehler, was Du damit sagen willst.
Leider ein weiterer Irrtum von Dir: Der Ergebnistyp eines ? : Operatorpaars ist gleich dem Ergebnistyp des eingetretenen Falles.warum sagte das?
oder so:
int isDigit( int ch ){ return '0' <= ch && ch <= '9' ? 1 : 0; }erstmal danke für die ganzen aufklärungen, wie C geht. liege ich noch richtig, daß hier das ?1:0 gar nichts für den compiler bringt? es muß also was sein, was für den menschen da ist. soll das ?1:0 deutlich machen, daß der ausdruck "sozuagen" einen bool liefert, nur im kleidchen eines int? und hierzu sagte ich, daß der bedarf nur entsanden ist, weil du int statt bool lieferst.
-
volkard schrieb:
erstmal danke für die ganzen aufklärungen, wie C geht. liege ich noch richtig, daß hier das ?1:0 gar nichts für den compiler bringt? es muß also was sein, was für den menschen da ist. soll das ?1:0 deutlich machen, daß der ausdruck "sozuagen" einen bool liefert, nur im kleidchen eines int? und hierzu sagte ich, daß der bedarf nur entsanden ist, weil du int statt bool lieferst.
Es waren 2 Versionen, eine mit "bool" und eine ohne.
Und ja, ich finde das mit "? :" lesbarer, vor allem wenn man den Code nur ueberfliegen will, dann seh ich sofort: Aha, da kommt das zurueck.
Das ist halt Geschmackssache.
Genauso wie ich "for ( ; ; ) ... continue ... break" auf die Schnelle lesbarer finde als "while () ..." an der Stelle jedenfalls, wo ich es verwendet habe. Beim Programmieren spart das auch einige Zeit beim Denken, z.B. wie ich das jetzt in eine while-Schleife verpacke. Natuerlich in dem Fall vielleicht nicht angebracht, aus den Gruenden, die ihr genannt habt, aber es spart tatsaechlich Zeit, wenn man haufenweise solchen Code schreiben muss. Wenn man nicht viel Zeit hat, kann's um jeden Sekundenbruchteil gehen, den man spart -- deswegen benutze ich auch GVIM als Editor.
-
Power Off schrieb:
Besser und logischer waere:
#define RANGE(x,min,max) ((min)<=(x))&&((x)<=(max)) bool isDigit( int ch ){ return RANGE( ch, '0', '9' ); }logischer garantiert nicht, da volkards vorschlag viel näher an der mathematik ist mit 1<=x<=9.
Sag das mal jemand, der auf einem alten Betriebssystem mit alten Entwicklungswerkzeugen arbeiten muss. Der freut sich bestimmt!
irgendwo muss man einen Schlussstrich ziehen.
Leider ein weiterer Irrtum von Dir: Der Ergebnistyp eines ? : Operatorpaars ist gleich dem Ergebnistyp des eingetretenen Falles.
Also liefert bei "bool" der Ausdruck "x ? true : false" auf jeden Fall ein Ergebnis vom Typ bool.
ich glaub, was volkard meint ist: wenn der vergleich bool zurückgibt, hat dein operator absolut keinen sinn, vergleichbar mit folgender Zeile:
!!true;er bringt keine lesbarkeit mehr, sondern nur mehr code-bloat. Dein Code hat wirklich nur an der Stelle sinn, wo du als "kompabilitätsgründen" int zurückgibst, da er dort etwas _macht_
Und ja, ich finde das mit "? :" lesbarer, vor allem wenn man den Code nur ueberfliegen will, dann seh ich sofort: Aha, da kommt das zurueck.
wenn die funktion bool zurückgibt weis ich: entweder, es kommt true, oder false zurück. "Sachertorte" kann ich als rückgabewert also schon ausschließen
-
Power Off schrieb:
Genauso wie ich "for ( ; ; ) ... continue ... break" auf die Schnelle lesbarer finde als "while () ..." an der Stelle jedenfalls, wo ich es verwendet habe. Beim Programmieren spart das auch einige Zeit beim Denken, z.B. wie ich das jetzt in eine while-Schleife verpacke. Natuerlich in dem Fall vielleicht nicht angebracht, aus den Gruenden, die ihr genannt habt, aber es spart tatsaechlich Zeit, wenn man haufenweise solchen Code schreiben muss. Wenn man nicht viel Zeit hat, kann's um jeden Sekundenbruchteil gehen, den man spart -- deswegen benutze ich auch GVIM als Editor.
Du sagst ja selbst, dass du schon einige Zeit dabei bist. Scheinbar bist du damals sofort in die Zeitdruck-Programmierung eingestiegen während andere hier auch ab und an mal ein paar Momente zum rumbasteln hatten. Anders kann ich mir nämlich nicht erklären wieso dir bei einem Problem nicht intuitiv die passende Schleife einfällt. Ich mache es immer in der Reihenfolge "denken -> tippen", was sich bisher immer als relativ praktisch erwiesen hat. Bei komplexeren Sachen kritzelt man sich dann halt kurz ein Diagramm und denkt mal ein paar Sekunden nach wie man das Problem geeignet strukturieren kann. Das ist vorher ein kleiner Mehraufwand der meiner Erfahrung nach im Endeffekt unheimlich viel Zeit spart.
-
Walli schrieb:
Du sagst ja selbst, dass du schon einige Zeit dabei bist. Scheinbar bist du damals sofort in die Zeitdruck-Programmierung eingestiegen während andere hier auch ab und an mal ein paar Momente zum rumbasteln hatten. Anders kann ich mir nämlich nicht erklären wieso dir bei einem Problem nicht intuitiv die passende Schleife einfällt. Ich mache es immer in der Reihenfolge "denken -> tippen", was sich bisher immer als relativ praktisch erwiesen hat. Bei komplexeren Sachen kritzelt man sich dann halt kurz ein Diagramm und denkt mal ein paar Sekunden nach wie man das Problem geeignet strukturieren kann. Das ist vorher ein kleiner Mehraufwand der meiner Erfahrung nach im Endeffekt unheimlich viel Zeit spart.
Ist ja schoen, dass Du while-Schleifen so cool findest, aber mir gefallen halt for-Schleifen besser.
Was der "richtige Schleifentyp" ist, liegt im Ermessensspielraum des Programmierers, wuerde ich sagen.
Und: Es gibt beim Programmieren durchaus Situationen, in denen man gar keine Zeit zum Denken hat. Toll, wenn Du das Problem noch nicht hattest.
Ich denke beim Programmieren schon lange nicht mehr bewusst nach. Geht alles vollautomatisch.
Diagramme! Du bist echt lustig, Mann!
-
Power Off schrieb:
Ich denke beim Programmieren schon lange nicht mehr bewusst nach.
*kich*
-
Ich denke beim Programmieren schon lange nicht mehr bewusst nach.
Unmöglich.
-
Power Off schrieb:
Ist ja schoen, dass Du while-Schleifen so cool findest, aber mir gefallen halt for-Schleifen besser.
Schön! Warum benutzt du eigentlich eine Hochsprache wenn die so viele unnütze Konstukte bietet?
Power Off schrieb:
Und: Es gibt beim Programmieren durchaus Situationen, in denen man gar keine Zeit zum Denken hat.
Ich möchte nicht deine Software benutzen müssen.
Power Off schrieb:
Diagramme! Du bist echt lustig, Mann!
Ich meine nicht so einen "UML-von-vorne-bis-hinten-Quatsch" wie er einem an der Uni immer als gängige Praxis eingeredet wird sondern simple Skizzen auf Papier. Wenn du die nicht brauchst... schön. Aber du denkst ja sowieso nicht beim programmieren, warum also Gedankenstützen auf Papier? Und sowieso: Du hast ja so wenig Zeit, dass du zu jeder Tages- und Nachtzeit innerhalb von wenigen Minuten auf neue Beiträge reagieren kannst
. Langsam wird es echt lächerlich mit dir.
-
Walli schrieb:
Ich meine nicht so einen "UML-von-vorne-bis-hinten-Quatsch" wie er einem an der Uni immer als gängige Praxis eingeredet wird sondern simple Skizzen auf Papier. Wenn du die nicht brauchst... schön. Aber du denkst ja sowieso nicht beim programmieren, warum also Gedankenstützen auf Papier? Und sowieso: Du hast ja so wenig Zeit, dass du zu jeder Tages- und Nachtzeit innerhalb von wenigen Minuten auf neue Beiträge reagieren kannst
. Langsam wird es echt lächerlich mit dir.Wenn ich zur Zeit einen Job haette, wuerde ich mit Sicherheit kaum hier posten ... dann haette ich keine Zeit mehr.
Kommst Du Dir nicht megatoll vor, mit Deinen Vorurteilen?
-
impossible schrieb:
Ich denke beim Programmieren schon lange nicht mehr bewusst nach.
Unmöglich.
Alles ist unmoeglich, solange wie man nicht damit konfrontiert wird.
Ich hatte zwei megastressige Arbeitsverhaeltnisse in den letzten 9 Jahren.
Mit der Zeit geht einem alles in Fleisch und Blut ueber -- wie Autofahren.
Aber sei echt froh, wenn's bei Dir noch nicht so schlimm ist.
-
Power Off schrieb:
Ist ja schoen, dass Du while-Schleifen so cool findest, aber mir gefallen halt for-Schleifen besser.
Er findet while-Schleifen nicht "cool". Der einzige, der Sprachmittel unabhängig von Sinn und Zweck betrachtet, bist du.
Power Off schrieb:
Ich denke beim Programmieren schon lange nicht mehr bewusst nach. Geht alles vollautomatisch.
Man kann deinem Code ansehen, dass er ohne bewusste Hirntätigkeit entstanden ist.
Power Off schrieb:
Mit der Zeit geht einem alles in Fleisch und Blut ueber -- wie Autofahren.
Jetzt will ich nicht nur mit deinem Code nichts zu tun haben, ich will dir auch nicht auf der Straße begegnen.
Wenigestens bist du konsequent. Dein Code passt zu deinem Auftreten.
-
MFK schrieb:
Man kann deinem Code ansehen, dass er ohne bewusste Hirntätigkeit entstanden ist.
Ich fasse das Kompliment auf! Danke!
Nee, im Ernst, es hat Vor- und Nachteile. Nachteil ist: Wenn mir nix einfaellt, hab ich ein Problem. Vorteil ist: Nahezu fehlerfreie Software ohne nachzudenken hinzubekommen kann nicht jeder.
Meine ehem. Arbeitgeber haben sich regelmaessig darauf verlassen, dass ich immer sofort eine Loesung fuer auch noch so komplexe Probleme gefunden habe. Einmal hab ich z.B. ein Projekt realisiert, bei dem vorher ein Gutachten gemacht worden war, dass es technisch unmoeglich sei. Mein Chef sagte mir das, und fragte mich, ob ich es machen wolle. Und ich sagte ja, und dann machte ich es. Der Kunde war sehr zufrieden mit dem Endprodukt.
In der betreffenden Firma machte ich immer die Sachen, die niemand anders machen wollte oder konnte.
Ich bin sozusagen einer der Muellmaenner der Softwareindustrie! Ich mach alles!
-
Power Off schrieb:
Nee, im Ernst, es hat Vor- und Nachteile. Nachteil ist: Wenn mir nix einfaellt, hab ich ein Problem. Vorteil ist: Nahezu fehlerfreie Software ohne nachzudenken hinzubekommen kann nicht jeder.
Wenn das für dich so passt, ist das in Ordnung. Aber dann würde ich dich bitten, darauf zu verzichten, den Anfängern hier solchen Code als Lösung oder Beispiel anzubieten. Ich finde, dass du damit eine Menge Schaden anrichtest. Geh einfach mal davon aus, dass der überwiegende Teil der Leute, die hier Fragen stellen, nicht so begnadet ist wie du (nicht ironisch), und deshalb mit solchem Code nicht klarkommt.
-
Power Off schrieb:
Nee, im Ernst, es hat Vor- und Nachteile. Nachteil ist: Wenn mir nix einfaellt, hab ich ein Problem. Vorteil ist: Nahezu fehlerfreie Software ohne nachzudenken hinzubekommen kann nicht jeder.
programmieren ohne nachzudenken hat nachteile: dein code ist kacke. außerdem geht das natürlich nur in domänen, wo du zu hause bist.
vorteile: keine.
natürlich kann ich auch in etlichen domänen code einfach so runterschreiben und bis auf ein paar tippfehler, die der compiler schnell sieht (vor allem retrun statt return), ist der code clean. nur ich schaue immer danach nochmal drüber, ob es was zu verbessern gibt. und meistens ist da nix mehr, weil ich auch auf anheb den weg einschalge, wo es nix mehr zu verbessern gibt.
zeitersparnis sehe ich bei deinem code nicht, denn ich lese code mindestens 20-mal häufiger, als ich ihn schreibe. also muß nur das lesen optimiert werden. selbst wenn ich vor so einer funktion eine sekunde pausieren würde, um nachzudenken, welche schleife paßt und danach nochmal 2 sekunden, um zu schauen, ob es sich hübsch anfühlt, hab ich die 3 sekunden doch schon ganz bald wieder drin, sobald ich den ersten fehler suche und anläßlich dessen den code mehrmals lese.
gerade bei arbeitgebern wie du sie beschreibst, die ganz mächtig zeitdruck machen und auch nicht gestatten, daß man nachher noch ein wenig pflegt, ist die große kathastrophe doch immer dann, wenn der kunde nach 2 jahren noch ein feature dazu will. dreht man hier was, reißt woanders ein bug auf und die sucherei geht los.
-
volkardus schrieb:
natürlich kann ich auch in etlichen domänen code einfach so runterschreiben und bis auf ein paar tippfehler, die der compiler schnell sieht (vor allem retrun statt return), ist der code clean. nur ich schaue immer danach nochmal drüber, ob es was zu verbessern gibt. und meistens ist da nix mehr, weil ich auch auf anheb den weg einschalge, wo es nix mehr zu verbessern gibt.
Das ist bei mir genauso.
(bleibende Tippfehler mach allerdings auch sehr wenige, da ich beim Schreiben den Blick immer auf dem Cursor habe und meist sofort korrigiere, wenn ich es sehe; allerdings mach ich als weniger offensichtliche Tippfehler, z.B. "==" statt "!=" usw., oder falsche Bezeichner, aber die find ich immer beim nochmal durchlesen, compilieren oder testen)
Die Methode, den Code solange zu durchzulesen, bis man davon ueberzeugt ist, ist gut. Meist werfe ich den Compiler nicht eher an, bis ein Modul testbereit ist.
volkardus schrieb:
gerade bei arbeitgebern wie du sie beschreibst, die ganz mächtig zeitdruck machen und auch nicht gestatten, daß man nachher noch ein wenig pflegt, ist die große kathastrophe doch immer dann, wenn der kunde nach 2 jahren noch ein feature dazu will. dreht man hier was, reißt woanders ein bug auf und die sucherei geht los.
Ich schreibe die Programme meist von vornherein so, dass man sie erweitern kann, und dass durch eine Aenderung nirgendwo "bugs aufreissen" koennen.
Es gibt ein paar einfache Techniken, z.B. Black-Boxing (aber auch White-Boxing), mit denen man solche Probleme vermeiden kann.
Jede Funktion hat eine klare Aufgabe und eine klare Schnittstelle. Klassen z.B. duerfen keine nicht-hierarchischen Abhaengigkeiten haben.
Code muss geordnet sein wie eine Julia-Menge, z.B.: man kann rein- und rauszoomen, aber die Zusammenhaenge sind stets klar.
-
Power Off schrieb:
Wenn ich zur Zeit einen Job haette
kann das mit deinem kacke code zusammenhaengen?
-
MFK schrieb:
Aber dann würde ich dich bitten, darauf zu verzichten, den Anfängern hier solchen Code als Lösung oder Beispiel anzubieten. Ich finde, dass du damit eine Menge Schaden anrichtest.
Meinst Du nicht, dass Du ein wenig uebertreibst?
Mit "solcher Code" bezieht Du Dich auf folgende gueltige C Konstruktion:
for(;;) { if ( /* Wiederholbedingung */ ) continue; if ( /* Abbruchbedingung */ ) break; }Dies ist ein gaengiges Konstrukt. Ich nehme es immer, wenn die Abbruchbedingung zu Beginn unklar ist. Dann kann ich spaeter nach Belieben Abbruch- oder Wiederholbedingungen eingeben.
Man kann auch "goto" dafuer verwenden, aber ich finde "for" dafuer bequemer.
Jeder Anfaenger wird frueher oder spaeter sowas lesen muessen, da wird er nicht drum rum kommen.
Und meine readnum() Funktion is auch sehr leicht zu lesen.
Als ich C Anfaenger war, vor 19 Jahren, hab ich ja schon sowas lesen koennen (aber da konnte ich schon BASIC und Assembler).
Irgendwie hab ich das Gefuehl, ihr wollt mich bloss verscheissern.