Hallo,
ich habe eine kurze Frage zur switch-case Funktion in C.
Zum Beispiel nehme ich folgendes:
char a = 100;
switch (a)
{
case 1:
case 2:
a += 17;
case 10:
case 11:
a -= 36;
default:
a += 14;
}
printf("%d", a);
}
Was ist der Endwert von a ? Springt die Funktion nicht sofort zu
default, weil case 100 nicht vorhanden ist?
peter schrieb:> Was ist der Endwert von a ? Springt die Funktion nicht sofort zu> default, weil case 100 nicht vorhanden ist?
Ja natürlich.
Wenn a den Wert 100 hat, dann ist der erwartete Wert 114.
Das ist in dem Fall sogar unabhängig davon, wie der Compiler die ihm
überlassene Entscheidung ob ein simpler char ein Vorzeichen haben soll
oder nicht bewertet.
peter schrieb:> Danke Karl-Heinz,>> der Meinung war ich auch, allerdings wird mir angezeigt, 114 sei eine> falsche Antwort.
Dann zeig dein komplettes Programm.
Es soll auch schon vorgekommen sein, dass man in diversen Auswertungen
und Ausgaben einen Fehler hat.
Was kommt denn beim printf raus?
Hallo Karl-Heinz,
ein komplettes Programm gibt es nicht, das ist das einzige was ich habe.
Die Aufgabe besteht darin, zu bestimmen, welcher Wert ausgegeben werden
soll.
Ich war mir ziemlich sicher, dass es 114 sein muss ( der Meinung bist du
ja auch), im Bewertungsbogen steht allerdings, dies sei falsch, es steht
aber auch nicht die angeblich richtige Antwort dabei.
Ich wollte nur sehen, ob der Fehler bei mir oder evtl im Bewertungsbogen
liegt.
genau wie bei dieser Aufgabe:
Welcher Wert wird ausgegeben?
int x = -2;
void main(){
schleife:
if (++x % 2)
goto schleife;
printf("%i", harry);
}
Ist der Endwert nicht -1 ?
In der Schleifenbedingung wird dieser ja um 1 erhöht, also -1,
somit ist er nicht mehr durch 2 teilbar und das goto wird nicht mehr
berücksichtigt, folglich müsste das ergebnis doch -1 sein?
peter schrieb:> Hallo Karl-Heinz,>> ein komplettes Programm gibt es nicht, das ist das einzige was ich habe.
Das ergibt allerdings keinen Sinn. Sieht man daran, dass der von Dir
gepostete Code nur eine öffnende geschweifte Klammer enthält, aber zwei
schließende.
peter schrieb:> Danke Karl-Heinz,>> der Meinung war ich auch, allerdings wird mir angezeigt, 114 sei eine> falsche Antwort.
Wer sagt das?
Ein minimal lauffähiges Programm:
1
#include<stdio.h>
2
3
intmain()
4
{
5
chara=100;
6
switch(a)
7
{
8
case1:
9
case2:
10
a+=17;
11
case10:
12
case11:
13
a-=36;
14
default:
15
a+=14;
16
}
17
printf("%d",a);
18
19
return0;
20
}
ergibt genau das Ergebnis wie von Karl Heinz genannt:
Daniel A. schrieb:> Ich denke x ist 0, ++x ist kein postincrement, (-2+1)%2 ergibt -1, -1> ist wahr,die schleife wird erneut durchlaufen und (-1+1)%2 ist 0,> ausgabe ist 0.
Exakt.
Daniel A. schrieb:> Ich denke x ist 0, ++x ist kein postincrement, (-2+1)%2 ergibt -1, -1> ist wahr,die schleife wird erneut durchlaufen und (-1+1)%2 ist 0,> ausgabe ist 0.
Sehe ich auch so.
Das switch case in der ersten Aufgabe ist mit Vorsicht zu geniessen,
weil es keine breaks enthält. Da aber der erste Wert (100) in keinem
case ist, sollte er direkt zu default gehen und 114 reauskommen.
Steht die Aufgabe so wirklich in einer (Prüfungs)Aufgabe?
Mit den nicht passenden geschweiften Klammern?
Dann sollte man den Author der Frage in einen C Anfängerkurs schicken.
Justus S. schrieb:> Mark B. schrieb:>> Wer sagt das?>> peter schrieb:>> im Bewertungsbogen steht allerdings, dies sei falsch,
Dann irrt sich der Bewertungsbogen. Oder aber der Themenersteller postet
nicht den ganzen Code, oder hat beim Abtippen Fehler eingebaut.
Loog schrieb:> Für solche "Probleme" kann man schnell den Quelltext online testen
Mich würde es gar nicht wundern, wenn die Leute diesen Quelltext in
verschiedene Kompiler einfügen und vollkommen unterschiedliche
Ergebnisse bekommen. Darüber hinaus ist es auch möglich, daß die Antwort
auf dem Lösungsbogen falsch ist. Ich habe das bei
Facharbeiter-Prüfungsbögen zum Energieelektroniker erlebt und die IHK
hat 2 Jahre gebraucht, um das zu berichtigen.
:-(
MfG Paul
Paul B. schrieb:> Darüber hinaus ist es auch möglich, daß die Antwort> auf dem Lösungsbogen falsch ist.
selbst in gedruckten und verkauften, verteilten Berufsschulbücher zur
RFS Ausbildung waren Fehler eingebaut die zur mehrdeutigen Lösung
führten.
xXx schrieb:> peter schrieb:>>> if (++x % 2)>> Ich programmiere seit ueber 20 Jahren in C & C++ und ich bin stolz> darauf, dass ich diese Frage nicht beantworten kann.
Ist auch kein guter Programmierstil, so wie es dasteht.
xXx schrieb:>> if (++x % 2)>> Ich programmiere seit ueber 20 Jahren in C & C++ und ich bin stolz> darauf, dass ich diese Frage nicht beantworten kann.
Ich sehe ein preincrement, das hat Precedence Klasse 2 und ein %, das
hat Precedence Klasse 3
Quelle: http://en.cppreference.com/w/c/language/operator_precedence
Vieleicht erklärst du uns mir warum das deiner Meinung nach nicht
eindeutig ist, für mein begrenztes Wissen sieht das recht eindeutig aus.
> Vieleicht erklärst du uns mir warum das deiner Meinung nach nicht> eindeutig ist, ...
Nicht eindeutig? Davon schreibt er nichts.
> xXx schrieb:>>> if (++x % 2)>>>> Ich programmiere seit ueber 20 Jahren in C & C++ und ich bin stolz>> darauf, dass ich diese Frage nicht beantworten kann.
Der Andere schrieb:> Vieleicht erklärst du uns mir warum das deiner Meinung nach nicht> eindeutig ist, für mein begrenztes Wissen sieht das recht eindeutig aus.
Wo habe ich geschrieben, es waere nicht eindeutig? Ich habe mich nur vor
vielen Jahren von elitaerem Code ab- und leicht lesbarem Code
zugewandt. Damit beeindruckt man seine durchschnittlichen Kollegen zwar
kurzfristig weniger, aber langfristig ist es besser fuer Produktivitaet
und fuer's Klima, wenn man sich und seinen Kollegen die Arbeit einfacher
macht.
Vorteile von solchen Konstrukten sehe ich praktisch keine, Nachteile
dagegen viele.
xXx schrieb:> Wo habe ich geschrieben, es waere nicht eindeutig? Ich habe mich nur vor> vielen Jahren von elitaerem Code ab- und leicht lesbarem Code> zugewandt.
Wobei 'leicht lesbar' immer im Auge des Betrachters liegt.
> Damit beeindruckt man seine durchschnittlichen Kollegen zwar> kurzfristig weniger, aber langfristig ist es besser fuer Produktivitaet> und fuer's Klima, wenn man sich und seinen Kollegen die Arbeit einfacher> macht.
Und genau das ist auch der Weg vom Amateur zum Profi. Amateure glauben
immer, man müsse in C möglichst kryptisch programmieren; möglichst viel
in eine Zeile quetschen; möglichst undurchschaubare Sonderzeichenorgien
kreieren um bei den Profis anerkannt zu werden. Ein Profi hat längst
gelernt, dass genau das der sichere Weg ins Desaster ist. Wer ein und
denselben Source Code 5 Jahre oder noch länger in der Wartung hat, der
ist darauf angewiesen die Dinge schnell wieder neu erfassen zu können.
Was natürlich nicht heisst, dass man hilflos daneben stehen darf, wenn
einem solche Dinge unterkommen. Klar kann man das alles auflösen. Und
dann so umschreiben, dass man beim nächsten mal nicht wieder in dieselbe
Verlegenheit kommt :-) Denn das nächste mal kommt bestimmt.
xXx schrieb:> Ich habe mich nur vor vielen Jahren von elitaerem Code ab- und leicht> lesbarem Code zugewandt.
Was ist daran "elitär"? Spricht hier der Anti-C-Troll?
Rufus Τ. F. schrieb:> xXx schrieb:>> Ich habe mich nur vor vielen Jahren von elitaerem Code ab- und leicht>> lesbarem Code zugewandt.>> Was ist daran "elitär"? Spricht hier der Anti-C-Troll?
Niemand wird ernsthaft behaupten wollen, dass das Inkrementieren einer
Variablen innerhalb einer if-clause sinnvollen und guten Code darstellt.
Rufus Τ. F. schrieb:> xXx schrieb:>> Ich habe mich nur vor vielen Jahren von elitaerem Code ab- und leicht>> lesbarem Code zugewandt.> Was ist daran "elitär"? Spricht hier der Anti-C-Troll?
So eine Antwort halte ich eigentlich fuer Trolling, aber weil's von
einem Moderator kommt, nehme ich es mal ernst.
Wie kommst du auf Anti-C? Aehnliche Konstrukte kann man in vielen
Sprachen produzieren. Dass es hier um C geht, ist nur Zufall und bisher
wurde das nicht zum Thema gemacht. Java 8 bietet da zum Beispiel auch
viele Moeglichkeiten, seinen Kollegen zu zeigen, wo der Hammer haengt.
Und Perl erst...
Elitaer: Wenn ich Code schreibe, der von 80% meiner Kollegen nicht auf
Anhieb verstanden werden kann, dann ist das elitaer. Ich bin toll, die
anderen nicht, sie sollen halt ihre Hausaufgaben machen. Der
Projektleiter sieht es etwas anders: Er sieht einen Querulanten, der
sein Koennen nicht fuer das Projekt einsetzt, sondern gegen seine
Kollegen. Und da der Nachschub an Superentwicklern begrenzt ist, geht
Teamplay vor Talent.
Uebrigens werden auch Superentwickler aelter, oder muessen sich mal
abseits ihrer ausgetretenen Pfade umschauen...
Mark B. schrieb:> Niemand wird ernsthaft behaupten wollen, dass das Inkrementieren einer> Variablen innerhalb einer if-clause sinnvollen und guten Code darstellt.
wie macht man das sinnvoller und gut?
wenn ich schon vor der if ein inc brauche nutze ich das, klar kann ich
vorher inc machen oder sogar eine neue Zeile einsetzen.
Das inc davorzusetzen oder eine neue Zeile davor zu schreiben, macht es
das besser?
Mir wir dann immer der Moni zu kurz, sei es in Spaltenbreite oder in
Zeilenlänge was ist daran nun besser?
xXx schrieb:> Wo habe ich geschrieben, es waere nicht eindeutig? Ich habe mich nur vor> vielen Jahren von elitaerem Code ab- und leicht lesbarem Code> zugewandt.
Das hatte ich anders interpretiert, weil ich nicht stolz darauf wäre
einen Code der gerade mal aus 2 Operatoren und einer Variablen besteht
nicht zumindest mit etwas genauer hinschauen zu analysieren zu können.
Karl H. schrieb:> Wer ein und> denselben Source Code 5 Jahre oder noch länger in der Wartung hat, der> ist darauf angewiesen die Dinge schnell wieder neu erfassen zu können.> Was natürlich nicht heisst, dass man hilflos daneben stehen darf, wenn> einem solche Dinge unterkommen. Klar kann man das alles auflösen.
Das ist der Punkt. 70% des Codes mit dem ich zu tun habe ist nicht von
mir, also muss ich in der Lage sein auch solchen Code zu verstehen.
Das man den dann mit dem Prinzip KISS ggf. vereinfacht ist auch klar.
Peter D. schrieb:> xXx schrieb:>>> if (++x % 2)>> Das Increment muß man nicht notwendig im Vergleich machen.> Ganz anders sieht es schon hier aus:>
1
>if(x&&(++x%2))
2
>
> Da ist die Lesbarkeit besser als mit ner Kette von ifs.
Da bin ich anderer Meinung.
In eine if-Anweisung gehört ein Vergleich bzw. mehrere Vergleiche.
Vergleiche sind boolscher Natur bezüglich des Ergebnisses, das sie
produzieren. Also solche Operationen wie:
größer als
kleiner als
gleich
ungleich
etc.
sowie zur Verknüpfung mehrerer Vergleiche Operatoren wie logisches UND
und ODER. Arithmetische Operationen gehören dort nicht hin. Also auch
kein Inkrement, keine Division oder dergleichen.
Der Vorteil davon ist bessere Lesbarkeit und bessere Testbarkeit des
Codes.
Joachim B. schrieb:> wie macht man das sinnvoller und gut?>> wenn ich schon vor der if ein inc brauche nutze ich das, klar kann ich> vorher inc machen oder sogar eine neue Zeile einsetzen.>> Das inc davorzusetzen oder eine neue Zeile davor zu schreiben, macht es> das besser?> Mir wir dann immer der Moni zu kurz, sei es in Spaltenbreite oder in> Zeilenlänge was ist daran nun besser?
Code richtet sich immer nach der Anforderung, die er erfüllen soll.
Was genau wollte man hier implementieren?
Der Andere schrieb:> Wann wird das x incrementiert?
&& ist ein sequence point.
Die linke Seite muß zuerst ausgerechnet werden und hat keine
Seiteneffekte auf die rechte Seite.
Ergibt die linke Seite 0, darf die rechte Seite nicht mehr ausgeführt
werden.
Das && wird deshalb gerne genommen als Guard gegen ungültige Startwerte.
xXx schrieb:> Wenn ich Code schreibe, der von 80% meiner Kollegen nicht auf Anhieb> verstanden werden kann, dann ist das elitaer.
Wenn Deine Kollegen nicht in C programmieren können, ist das nicht
"elitär". Und wenn sie in C programmieren können, aber solche
Codestellen nicht auf Anhieb verstehen -- wer um alles in der Welt hat
die eingestellt? Und wofür?
Rufus Τ. F. schrieb:> xXx schrieb:>> Wenn ich Code schreibe, der von 80% meiner Kollegen nicht auf Anhieb>> verstanden werden kann, dann ist das elitaer.>> Wenn Deine Kollegen nicht in C programmieren können, ist das nicht> "elitär". Und wenn sie in C programmieren können, aber solche> Codestellen nicht auf Anhieb verstehen -- wer um alles in der Welt hat> die eingestellt? Und wofür?
In einer Firma kann nicht jeder so entwickeln, wie es ihm persönlich
gerade in den Kram passt. Das kann man zuhause privat gerne machen, aber
nicht wenn man dafür bezahlt wird.
Wenn man Softwareentwicklung ernsthaft betreibt, dann gibt es
Programmierrichtlinien an die man sich zu halten hat. Wer das nicht
will, der kann sich gerne beim IOCCC austoben, dafür ist er da.
Und selbst der hat manche Regeln. ;-)
Was ist wahrscheinlicher:
1.) Dass einer genial ist und supertollen Code schreibt und alle anderen
zu doof sind um ihm zu verstehen?
2.) Dass jemand die eigenen Fähigkeiten im Programmieren überschätzt und
in Wahrheit Code verzapft, der unnötig schwer zu lesen und zu warten
ist?
Im realen Berufsleben habe ich 2.) viel öfter erlebt als 1.). Sehr,
sehr, sehr, sehr, sehr viel öfter.
Das ist ja alles schön und gut, und sicherlich auch richtig.
Aber bei einem so banalen Konstrukt?
Nein. Wer daran scheitert, dem helfen auch keine Programmierrichtlinien.
Ich meine damit nicht, daß man derartige Konstrukte nutzen muss oder
auch nur sollte, aber man muss sie verstehen können. Und zwar ohne
länger darüber nachzudenken.
Paul B. schrieb:> Darüber hinaus ist es auch möglich, daß die Antwort auf dem Lösungsbogen> falsch ist.
Ja. Ich kann mich aus meinem Studium auch noch daran erinnern, daß der
Professor das ANSI-C, das er gelehrt hat, offenbar schlechter kannte als
ich. In den Prüfungen waren da gerne mal Fragen nach dem Ergebnis eines
bestimmten Stücks Code enthalten, das eigentlich undefiniertes Verhalten
und damit kein eindeutiges Ergebnis hat. Und nein, "undefiniert" wurde
nicht als korrekt gewertet, sondern nur das Ergebnis, das der Compiler,
den der Prof normalerweise benutzt, produziert.
Mark B. schrieb:> Code richtet sich immer nach der Anforderung, die er erfüllen soll.
Richtig. Deshalb verwehre ich mich auch gegen so pauschale Sachen wie:
Mark B. schrieb:> In eine if-Anweisung gehört ein Vergleich bzw. mehrere Vergleiche.> Vergleiche sind boolscher Natur bezüglich des Ergebnisses, das sie> produzieren.
[...]
> Der Vorteil davon ist bessere Lesbarkeit und bessere Testbarkeit des> Codes.
Was besser lesbar ist, hängt nicht nur von dieser einen Zeile ab. Solche
pauschalen Regeln sind für den Anfänger sicher als Orientierung gut, und
in den meisten Fällen passen sie ja auch. Aber der Profi erkennt die
(wenigen) Stellen, an denen er die Lesbarkeit verbessern kann, wenn er
mal davon abweicht, ohne dass der Code dadurch "elitär" wird (ja, auch
goto kann sinnvoll sein und die Lesbarkeit verbessern).
Man muss ja nicht gleich hochkomplexe Ausdrücke hinschreiben, bei denen
man sämtliche Regeln der integer promotion, operator precedence und wer
weiß was noch alles auswenig kennen muss. Auf der anderen Seite erwarte
ich von einem professionellen Programmierer aber auch, dass er nicht
gleich verzweifelt, nur weil ein Konstrukt mal eine Stufe komplizierter
ist als der Trivialfall. Schließlich kriegt auch der Geld dafür.
> Was ist wahrscheinlicher:> 1.) Dass einer genial ist und supertollen Code schreibt und alle anderen> zu doof sind um ihm zu verstehen?
Einstein galt als schlechter Professor, weil seine Studenten seine
Vorlesungen nicht verstanden haben. ;-)
> 2.) Dass jemand die eigenen Fähigkeiten im Programmieren überschätzt und> in Wahrheit Code verzapft, der unnötig schwer zu lesen und zu warten> ist?
Kann auch eine Mischung aus beidem sein. Er ist ein genialer
Programmierer, der aber leider seinen Code trotzdem für andere schwer
verständlich schreibt, ohne dass diese deshalb zu doof sein müssen. Er
merkt vielleicht nicht mal, dass der Code zu kompliziert ist.
Karl H. schrieb:> Amateure glauben> immer, man müsse in C möglichst kryptisch programmieren; möglichst viel> in eine Zeile quetschen; möglichst undurchschaubare Sonderzeichenorgien> kreieren um bei den Profis anerkannt zu werden.
Dafür ist aber Perl viel besser geeignet ;-)
Jay schrieb:> Wer Seite 21 dieser Präsentation gesehen hat> http://www.vaxman.de/publications/apl_slides.pdf findet plötzlich, dass> C oder Perl extrem langweilige und lesbare Programmiersprachen sind.
Ja ja:
* Being able to write APL programs does not normally imply
that you are able to read APL programs – not even your own!
* This has APL earned the notation of being a write only
language
> Ich erinnere mich auch noch an REC. Ein Beispielprogramm aus> http://delta.cs.cinvestav.mx/~mcintosh/cellularautomata/REC_files/rec25.pdf> sieht so aus>>
1
> ([-2]J,([-2]K,
2
> (VV*UU*+PPPP****VV*UU*[-1]*+V*U*[8]*P*[-1]*+
3
> (N".W;" W;),V[.054]+K,!74!:;)
4
> "←-W"↓WU[.08]+J,!50!:;);)
5
>
>> Nein, das ist kein Modem-Rauschen.
Mja, Brainfuck und Whitespace sind da auch nicht viel besser ;-)
Rolf M. schrieb:> Auf der anderen Seite erwarte> ich von einem professionellen Programmierer aber auch, dass er nicht> gleich verzweifelt, nur weil ein Konstrukt mal eine Stufe komplizierter> ist als der Trivialfall. Schließlich kriegt auch der Geld dafür.
Kein wirklicher Profi wird an einer solchen Zeile
1
if(x&&(++x%2))
verzweifeln oder gar dran scheitern ... aber darüber den Kopf schütteln
- und gerade deshalb ist er sein Geld wert ;)
Jay schrieb:> Ich erinnere mich auch noch an REC.
Ich höre heute zum erstan Mal davon.
Hast du dich tatsächlich einmal damit beschäftigt? Wenn ja, in welchem
Zusammenhang?
> Ein Beispielprogramm aus> http://delta.cs.cinvestav.mx/~mcintosh/cellularautomata/REC_files/rec25.pdf> sieht so aus>> ([-2]J,([-2]K,> (VV*UU*+PPPP****VV*UU*[-1]*+V*U*[8]*P*[-1]*+> (N".W;" W;),V[.054]+K,!74!:;)> "←-W"↓WU[.08]+J,!50!:;);)>> Nein, das ist kein Modem-Rauschen.
Natürlich nicht. Das Programm ist absolut selbsterklärend, auch für
einen wie mich, der von der Sprache noch nie etwas gehört hat.
Naja, fast selbsterklärend ;-)
Ich habe es spaßeshalber mal in C umgeschrieben:
REC (Regular Expression Compiler) is a concise programming language
2
development in mayor Mexican Universities at end of 60's which allows
3
students to write programs without knowledge of the complicated syntax
4
of languages like FORTRAN and ALGOL.
1
... the interpreter REC Fortran was writing for Gerardo Cisneros at the
2
beginning of computing in Mexico, which marks a milestone in software
3
development in Mexico, ...
REC ist also sozusagen eine Programmiersprache für Dummies und stellt
einen Meilenstein der Softwareentwicklung in Mexiko dar. Das Zeug, das
die damals rauchten, muss schon heftig gewesen sein ;-)
Eric B. schrieb:> Jay schrieb:>> Wer Seite 21 dieser Präsentation gesehen hat>> http://www.vaxman.de/publications/apl_slides.pdf findet plötzlich, dass>> C oder Perl extrem langweilige und lesbare Programmiersprachen sind.>> Ja ja:> * Being able to write APL programs does not normally imply> that you are able to read APL programs – not even your own!> * This has APL earned the notation of being a write only> language
Da kommen Erinnerungen hoch.
Mit APL bin ich nie warm geworden. Und ja, ich hatte 1 Semester lang
APL. Aber ehrlich, es war eine Qual. Und das sag ich als einer, der auf
der Uni keine einzige angebotene Programmiersprache ausgelassen hat.
Eric B. schrieb:> Mja, Brainfuck und Whitespace sind da auch nicht viel besser ;-)
Ich denke schon, da diese nur einen sehr begrenzten Zeichenvorrat haben
und meiner Erinnerung nach jedes Zeichen genau eine Bedeutung hat,
unabhängig vom Kontext.
Eric B. schrieb:> Mja, Brainfuck und Whitespace sind da auch nicht viel besser ;-)
Die sind aber als Spaß-Sprachen entstanden. Bei APL und z.B. REC meinen
es die Entwickler ernst.
Yalu X. schrieb:> Jay schrieb:>> Ich erinnere mich auch noch an REC.>> Ich höre heute zum erstan Mal davon.>> Hast du dich tatsächlich einmal damit beschäftigt?
Ja, aber ...
> Wenn ja, in welchem Zusammenhang?
Ich habe es in den, ich glaube Anfang der 80ern, als eine
Programmiersprache auf CP/M kennengelernt. Ich war auf der Suche nach
was Kleinem, Feinen für CP/M um Steuerungsprogramme und Simulationen zu
schreiben. Die C-Compiler für CM/M waren nicht prickelnd, Microsoft
FORTRAN schon gar nicht, die BASICs (auch das von Microsoft) waren eher
mau.
Ich habe von REC in Rekordgeschwindigkeit die Finger gelassen, und bin
bei Z80 Assembler, FORTH, und Prospero FORTRAN 77 gelandet, je nach
Anwendung. Es gab danach für mich noch eine kurze Zeit mit Turbo Pascal
auf CP/M, aber das war's dann für mich auf CP/M.
>> Nein, das ist kein Modem-Rauschen.>> Natürlich nicht. Das Programm ist absolut selbsterklärend, auch für> einen wie mich, der von der Sprache noch nie etwas gehört hat.>> Naja, fast selbsterklärend ;-)>> Ich habe es spaßeshalber mal in C umgeschrieben:
Applaus!
Wenn du es mal auf CP/M ausprobieren möchtest, die folgenden vier
Disketten enthalten REC für CP/M:
http://www.retroarchive.org/cpm/cdrom/SIMTEL/SIGM/VOLS100/VOL164/http://www.retroarchive.org/cpm/cdrom/SIMTEL/SIGM/VOLS100/VOL165/http://www.retroarchive.org/cpm/cdrom/SIMTEL/SIGM/VOLS100/VOL166/http://www.retroarchive.org/cpm/cdrom/SIMTEL/SIGM/VOLS100/VOL167/
Disk 166 enthält etwas "Dokumentation"
(http://www.retroarchive.org/cpm/cdrom/SIMTEL/SIGM/VOLS100/VOL166/HOWTOUSE.DOC)
Disk 167 enthält sogar so eine Programm für ein PCB Layout einer
Steckkarte.
> REC ist also sozusagen eine Programmiersprache für Dummies und stellt> einen Meilenstein der Softwareentwicklung in Mexiko dar. Das Zeug, das> die damals rauchten, muss schon heftig gewesen sein ;-)
Oder tranken. Tequila ¡Ay, caramba!
Thread beobachten
Seitenaufteilung abschalten