Uli schrieb:> Kann mir jemand sagen wie ich die Fehlermeldungen beheben kann.
ja möglichst schnell den code löschen, ein Buch kaufen, C lernen und
noch mal neu einfangen.
Zum Glück hast du einen Fehler, wenn nicht würde dein Programm nach ein
paar Sprüngen den Stack überschreiben und du würdest ewig nach dem
Fehler suchen.
goto aus einer ISR darf man nicht machen !!!!!!!!
// *** ENDE LIFT INITALISIERUNG *** //
} Ich denke nicht, dass die Klammer hier hingehört...
//** ENDE Lift Initialisierung ** //
--> C Buch und lernen!
Uli schrieb:> Kann mir jemand sagen wie ich die Fehlermeldungen beheben kann.
Kann mir jemand sagen, warum derart langer Code nicht als Anhang
hochgeladen werden kann?
Peter II schrieb:> goto aus einer ISR darf man nicht machen !!!!!!!!
Darf man nicht nur machen sondern ist auch gegen den C-Standard. Goto
funktioniert nur innerhalb der gleichen Funktion und selbst da ist es
schlechter Programmierstil.
Ich hab den Code nicht komplett gelesen aber es scheint als willst du
aus der ISR heraus festlegen was als nächstes in der main Funktion
passiert. Dazu nutzt man normalerweise Statusvariablen, die man dann
auch als volatile deklariert. Auch wenn es hart klingt, nehm die
Hinweise der anderen ein C Buch zu lesen bitte ernst. Muss man natürlich
nicht gleich von vorne bis hinten lesen aber ein paar Grundlagen schaden
dir sicherlich nicht.
Ein Lift ist eine Zustandsmaschine zum Vorzeigen und Lernen.
Jeder, der bei uns goto verwendete (versuchte) hat sich einen
ordentlichen Lacher eingefangen.
Wegen des katastrophalen Codes aber nur ein unterdrücktes: "Hi".
Oder wie die zwei Peter's schrieben...
Bitte schmeiß den 'code' überboard und frage einen der sich damit aus
kennt.
Wir wollen dir hier nichts böses, aber du steuerst da ohne Ahnung auf
einen großen Eisberg zu.
Fang doch erst mal klein an und mach eine Steuerung für ein Lauflicht
und das OHNE 'goto' und '_delay_ms'!
Als Schlagwort (Tip) wurde ich dir hier raten:
- Flag gesteuerter Ablauf
- kleine (sehr kleine) Statemaschiene
Lese dir bitte nochmal die Grundlagen durch, dann baue den Code für das
Lauflicht zusammen, danach steuerst du das LF mit einem Taster (LF links
rum), danach steuerst du das LF mit 2 Taster.(LF links + rechst rum)
Zeig das nochmal her und wir helfen dir bei den Problemen.
Wenn du das dann hast, ist der Code für die Liftsteuerung schon fast
fertig.
(der größte Teil kann wieder verwendet werden)
viel Glück
@ Uli (Gast)
Naja, keiner is unnütze. Er kann auch als schlechtes Beispiel dienen ;-)
Siehe
Statemachine,
Interrupt und
Strukturierte Programmierung auf Mikrocontrollern
Und vorher schreibst du 100 mal mit Papier und Füllfederhalter in
Schönschrift.
"Ich soll keine Gotos benutzen."
weiters schreibst du 100 mal:
Ich soll meinen Code konsequent und richtig einrücken.
Nach ausnahmslos jeder öffnenden { wird alles, was in diesem Block bis
zur schliessenden } um 2 Leerzeichen eingerückt. Und zwar solange, bis
der Block zu Ende ist. Die schliessende } wird dann wieder um 2
Leerzeichen weniger eingerückt, so dass öffnende { und schliessende }
untereinander stehen.
Wenn ich also schreibe
1
intmain()
2
{
3
....
4
}
dann muss die funktions-schliessende } wieder ganz links stehen und in
diesem Block darf es keine Anweisung geben, die am linken Rand anfängt.
Auch der Umkehrschluss ist zulässig: Wenn ich der Meinung bin, dass
meine Funktion zu Ende ist, dann muss es sich automatisch so ergeben,
dass die schliessende } wieder am linksn Zeilenrand zu stehen kommt.
Ist irgendetwas davon nicht erfüllt, dann habe ich mich irgendwo in der
{-} Hierarchie vertan und ich muss dieses Problem suchen.
<Ende des zu Schreibenden>
Sauber eingerückter und sorgfältig geschriebener Code ist nicht einfach
nur Luxus, sondern ein vitales Element der Fehlervermeidung beim
Code-Schreiben.
Sebastian V. O. schrieb:> Goto ... ist schlechter Programmierstil.Amateur schrieb:> Jeder, der bei uns goto verwendete (versuchte) hat sich einen> ordentlichen Lacher eingefangen.> Wegen des katastrophalen Codes aber nur ein unterdrücktes: "Hi".
Ahja... also ist der Linux-Kernel und Treiber katastrophaler Code in
schlechtem Programmierstil?
Interessante Auffassung...
Statemachine wurde ja schon genannt.
Der SChlüssel zu deinem Programm besteht darin, dass du dir ein paar
Variablen einführst, in denen das Programm darüber Buch führt, in
welchem Stock der Lift gerade steht und in welchen Stock der Lift fahren
soll.
UNgefährt so
1
volatile uint8_t ZielStock; // wo soll der Lift hinfahren
2
volatile uint8_t AktuellerStock; // wo ist er gerade
3
4
int main()
5
{
6
....
7
8
while( 1 ) {
9
10
if( ZielStock != AktuellerStock )
11
{
12
Logik um die Liftkabine vom Stockwerk 'AktuellerStock'
13
zum Stockwerk 'ZielStock' fahren zu lassen.
14
}
15
16
}
17
}
18
19
ISR(INT0_vect) // Taster_1
20
{
21
ZielStock = 1;
22
}
23
24
ISR(INT1_vect) // Taster_2
25
{
26
ZielStock = 2;
27
}
28
29
ISR(INT2_vect) // Taster_3
30
{
31
ZielStock = 3;
32
}
Hier
1
if( ZielStock != AktuellerStock )
2
{
3
Logik um die Liftkabine vom Stockwerk 'AktuellerStock'
4
zum Stockwerk 'ZielStock' fahren zu lassen.
5
}
in diesem Bereich kannst du dich austoben. Wenn das Zielstockwer größer
als das aktuelle Stockwerk ist, muss der Lift also nach oben fahren und
umgekehrt. Der Vergleich der beiden Stockwerknummern sagt dem Programm
was zu tun ist.
Aber Vorsicht! Es soll auch schon vorgekommen sein, dass in anderen
Stockwerken die Knöpfe gedrückt werden, während der Lift gerade fährt.
Allerdings: Bring erst mal die einfachen Fälle zum Laufen und kümmere
dich später um die komplizierteren Dinge.
Kaj schrieb:>> Jeder, der bei uns goto verwendete (versuchte) hat sich einen>> ordentlichen Lacher eingefangen.>> Wegen des katastrophalen Codes aber nur ein unterdrücktes: "Hi".>> Ahja... also ist der Linux-Kernel und Treiber katastrophaler Code in> schlechtem Programmierstil?
Wer im Linux Kernel bzw. in einem Treiber rumstochert, ist kein Anfänger
mehr.
Dort mögen gotos schon ihren Grund haben. Aber in den nächsten 5 Jahren
gibt es für den TO keinen Grund einen goto einzusetzen. So wie in 99.9%
aller Programme, nachdem man den Linux Kernel und Treiber ausgenommen
hat.
Und ja. In Fehlerbehandlung haben gotos in C auch ihren Sinn. Aber
soweit ist der TO auch noch lange nicht, dass das für ihn relevant wäre.
> Interessante Auffassung...
Interessant ist eher, dass jedesmal wenn man einem Neuling ein bischen
was beibrignen will, wie man ordentliche Programme schreibt, es immer
einen Schlaukopf gibt, der das Schlagwort 'Linux-Kernel' in den Raum
stellt.
oh man was ein Wirrwarr ... da krieg ich ja Angst, je wieder einen
Aufzug zu benutzen :-)
Tipps:
- keine goto's !
- Bau ein RTOS (Scheduler) drunter und entwirre den ganzen Unsinn in
sinnvolle Tasks! Dann wirds auch lesbar.
- Arbeite mit einem Event-basierten System.
@ Random ... (thorstendb) Benutzerseite
>- keine goto's !
Ja
>- Bau ein RTOS (Scheduler) drunter und entwirre den ganzen Unsinn in>sinnvolle Tasks! Dann wirds auch lesbar.>- Arbeite mit einem Event-basierten System.
Käse^3. Der OP soll erstmal die elementaren Grundlagen der
Programmierung lernen. Dieses Problem kann man ganz solide und sauber
mit EINER Statemachine ohne RTOS, Events uns sonstigen Kram lösen.
Oliver S. schrieb:> Random ... schrieb:>> - Bau ein RTOS (Scheduler) drunter und entwirre den ganzen Unsinn in>> sinnvolle Tasks! Dann wirds auch lesbar.>> YMMD ;)>> Oliver
Wenn ich so viele delays sehe wird mir schlecht :-)
Das geht besser mit einem RTOS, und plötzlich hat man wieder viel
Rechenzeit frei ^^
Random ... schrieb:> Wenn ich so viele delays sehe wird mir schlecht :-)> Das geht besser mit einem RTOS, und plötzlich hat man wieder viel> Rechenzeit frei ^^
jetzt braucht man schon für eine Fahrstuhl ein OS. Kein Wunder das heute
die Leute schon eine CPU mit 1Ghz in ihre Armbanduhren einbauen.
Nein ein RTOS ist hier fehl am Platz, es versteckt dinge die man erst
einmal verstehen sollte bevor man so etwas einsetzt.
Letztenendes musst du bei diesen Delays von 1sec selbst ne Art Scheduler
schreiben... sonst setzt du ja nur Cycles in Wärme um. Selbst @8MHz AVR
Speed...
> Kein Wunder das heute die Leute schon eine CPU mit 1Ghz in> ihre Armbanduhren einbauen.
Setzt man ein RTOS _*sinnvoll*_ ein, kann dadurch ne Menge Rechenzeit
mehr rausgeholt werden, und komplexe, Flag-gesteuerte Abläufe
vereinfacht werden.
Random ... schrieb:> Letztenendes musst du bei diesen Delays von 1sec selbst ne Art Scheduler> schreiben... sonst setzt du ja nur Cycles in Wärme um. Selbst @8MHz AVR> Speed...
Die einzige Alternative wären die Sleep-Modes. Aber was bringt das bei
einer Liftsteuerung. Da macht der Stromverbrauch des Controllers wohl
nichts mehr aus.
Random ... schrieb:> Letztenendes musst du bei diesen Delays von 1sec selbst ne Art Scheduler> schreiben... sonst setzt du ja nur Cycles in Wärme um. Selbst @8MHz AVR> Speed...
nein, ich wüsste gar nicht wozu ich überhaupt ein Delay braucht sollte
bei diesem Projekt.
> Setzt man ein RTOS _*sinnvoll*_ ein, kann dadurch ne Menge Rechenzeit> mehr rausgeholt werden
wie soll man durch einen Overhead eines RTOS Rechenzeit sparen? Er
verbraucht sogar mehr weil es regelmäßig eine Taskwechsel macht und
dafür haufenweise Register umkopiert.
Es ist ein zusätzlicher Layer, dieser braucht mehr Ressourcen. Es kann
durchaus sein, das damit die Programmierung einfacher ist, aber auf
kosten der Ressourcen.
Random ... schrieb:> Letztenendes musst du bei diesen Delays von 1sec selbst ne Art Scheduler> schreiben... sonst setzt du ja nur Cycles in Wärme um. Selbst @8MHz AVR> Speed...
Der springende Punkt ist doch, dass es diese ganzen delays überhaupt
nicht braucht.
Und wenn ein Mega8 nicht in den Sleep Mode geht, dann spielen die 15mA
verglichen mit dem was der Motor braucht, auch schon keine Rolle mehr.
> Setzt man ein RTOS _*sinnvoll*_ ein, kann dadurch ne Menge Rechenzeit> mehr rausgeholt werden, und komplexe, Flag-gesteuerte Abläufe> vereinfacht werden.
Ja. kann.
Wenn man es kann und wenn die Aufgabenstellung entsprechend ist. Seine
Aufgabe ist trivial. Sogar die zugehörige State Machine ist trivial. Sie
besteht in der Erstversion aus ganzen 5 Zuständen mit überschaubaren
Zustandsänderungen.
Und so schnell wird seine Kabine schon nicht dahinrasen, dass sich der
µC nicht zwischendurch mal ein Nickerchen gönnen könnte.
Nana
so ein Lift macht bis zu 12000 m/min = 20m/sek gleichzeitig wird
erwartet, dass er millimetergenau stoppt, ohne die freistehenden
Passagiere
allzu arg zu belasten. Dafür werden hochpräzise Positionsgeber (AWG)
verwandt mit einer Auflösung kleiner 1mm und je schneller die Aufzüge
fahren, um so mehr werden die Systeme auf Redundanz ausgelegt. Da ist
die Rufabarbeitung und das Türbedienen die Kür. Die Pflicht besteht in
der positionsgenauen Fahrtsteurung mit wechselnden Lasten (bis +/- 60%
der statischen Nennlast) die dabei auflaufenden temporären Datenmengen
sind nicht
unerheblic.
Dazu ist es erforderlich keine µs ohne genaue position zu sein. Allein
das Log des Canbusses moderner Lifte nur einer Fahrt ist manuell kaum zu
lesen geschweige ohne Hilfsmittel zu analysieren. ;)
Und ich habe bereits erfahren, dass dies zum auffinden sporadischer
Fehler von Nöten sein kann und da geht es selten um nur eine Fahrt. Da
hatte ich Glück das der Fehler just auftrat als ich das Logging begann.
Namaste
Also wenn ich die Aufzüge auf unserem Firmengelände sehe, da kommt mir
das Grausen. Ich bin ja schon froh, wenn ich den Rollwagen mit Ankippen
über die Kante kriege.
Und die Störempfindichkeit der Elektronik ist extrem. Wenn ich über die
Auslegeware zum Aufzug gehe, muß ich mich erst an der Tür erden, sonst
leuchten beide Tasten gleichzeitig auf. Man muß nichtmal die Taste
drücken, annähern reicht.
Und die Etagenanzeige zeigt auch gerne mal wirre Pixelmuster.
Einmal ist mir was lustiges passiert, ich drücke auf Taste 5, die geht
kurz an, dann wieder aus, dafür aber alle anderen an.
Wer diese Steuerung entwickelt hat, für den war Entprellen und sichere
Datenübertragung bestimmt ein Fremdwort.
Ich verstehe auch nicht, warum da immer noch Glühbirnchen in den Tasten
sind, die gehen so oft kaputt.
Im Winter gabs oft Probleme, wenn der Aufzug im Erdgeschoß hielt, da
wurde ihm zu kalt. Er fährt jetzt immer in die 3. Etage.
Die Anzeige im Erdgeschoß ist schon lange kaputt und kann nicht
repariert werden. Vermutlich sind alle Produktionsunterlagen
geschreddert worden, obwohl der Aufzug nur etwas über 10 Jahre alt ist.
Auch wenn es jetzt weit off topic wird:
Karl Heinz schrieb:> weiters schreibst du 100 mal:>> Ich soll meinen Code konsequent und richtig einrücken.> Nach ausnahmslos jeder öffnenden { wird alles, was in diesem Block bis> zur schliessenden } um 2 Leerzeichen eingerückt. Und zwar solange, bis> der Block zu Ende ist. Die schliessende } wird dann wieder um 2> Leerzeichen weniger eingerückt, so dass öffnende { und schliessende }> untereinander stehen.> Wenn ich also schreibe>
1
>intmain()
2
>{
3
>....
4
>}
5
>
> dann muss die funktions-schliessende } wieder ganz links stehen und in> diesem Block darf es keine Anweisung geben, die am linken Rand anfängt.> Auch der Umkehrschluss ist zulässig: Wenn ich der Meinung bin, dass> meine Funktion zu Ende ist, dann muss es sich automatisch so ergeben,> dass die schliessende } wieder am linksn Zeilenrand zu stehen kommt.> Ist irgendetwas davon nicht erfüllt, dann habe ich mich irgendwo in der> {-} Hierarchie vertan und ich muss dieses Problem suchen.>> <Ende des zu Schreibenden>>> Sauber eingerückter und sorgfältig geschriebener Code ist nicht einfach> nur Luxus, sondern ein vitales Element der Fehlervermeidung beim> Code-Schreiben.
Lieber Karl Heinz, für diese Worte möchte ich dir einmal danken. Dabei
ist es doch so unglaublich altmodisch (oder -more fashionable and state
of the art- 'old school'..) so einzurücken und vor allem die Klammern so
zu setzen.
Moderne Menschen machen machen das so:
int main(){
....
}
Allein daran erkennt man schon, daß sie zu einer jungen, dynamischen
Generation gehören!
Übereinanderstehende geschweifte Klammern? Wie voriges Jahrtausend ist
das denn??? Und dann nur 2 Leerzeichen eingerückt? BAAH! 4, man muß 4
oder 8 Leerzeichen einrücken! Das sind doch viel mehr, und du bist
gleich viel wichtiger!
Aber Scherz beiseite, ich war schon erbaut, daß ein junger Mann, der
selber kein Softwareentwickler ist und aus reinen Qualitätsgründen auf
meinen Code schauen musste meinte: Wie Geil ist das denn? Das kann man
ja alles LESEN!
Seitdem schreibe ich auch in Java, Python, Javascript, PHP, Perl und
selbst bash in diesem Stil, und alle finden es cool, weil es lesbar ist.
Und ich persönlich finde es gut, daß es in C (und C++)ein goto gibt. Und
sollte es das irgendwann mal nicht mehr geben, kann man es immer noch in
Inline-Assembler nachbauen. Ich bekenne an dieser Stelle, seit 1992
bestimmt 5 mal goto in C benutzt zu haben!
Äh, was wollte ich eigentlich sagen?
Jawoll, insbesondere mit deinem letzten Satz gebe ich dir absolut Recht.
IdS,
Baku
Stefan Lagger schrieb:> Uli schrieb:>> Kann mir jemand sagen wie ich die Fehlermeldungen beheben kann.>> Uli ist das dein ernst?>> ~Stefan Lagger
Uli wenn du Probleme hast kannst du mich jeder Zeit anrufen egal wo ich
bin, egal um welche Zeit. Du hast ja meine Nummer.
Ich helfe dir zwar nicht gerne aber ich helfe dir.
~Stefan Lagger
Uli schrieb:> #define F_CPU 100000UL
Auch das macht mich stutzig. Bist du sicher, das dein MC nur mit 100kHz
läuft? Bedenke, das man in dieser Zeile die CPU Frequenz in Hertz
angibt, für einen MC, der mit z.B. 10MHz getaktet wird, sollte da
Matthias Sch. schrieb:> Uli schrieb:>> #define F_CPU 100000UL>> Auch das macht mich stutzig. Bist du sicher, das dein MC nur mit 100kHz> läuft? Bedenke, das man in dieser Zeile die CPU Frequenz in Hertz> angibt, für einen MC, der mit z.B. 10MHz getaktet wird, sollte da#define> F_CPU 10000000UL> stehen.
Wenn du meinst.
Stefan Lagger schrieb:>> Auch das macht mich stutzig. Bist du sicher, das dein MC nur mit 100kHz>> läuft? Bedenke, das man in dieser Zeile die CPU Frequenz in Hertz>> angibt, für einen MC, der mit z.B. 10MHz getaktet wird, sollte da#define>> F_CPU 10000000UL>> stehen.>> Wenn du meinst.
Ich habe keine Ahnung, was du damit zu tun hast, aber das ist keine
Meinung von mir, sondern ein Tipp an den TE. Eine Meinung habe ich hier
nicht geäussert.
Matthias Sch. schrieb:> Stefan Lagger schrieb:>>> Auch das macht mich stutzig. Bist du sicher, das dein MC nur mit 100kHz>>> läuft? Bedenke, das man in dieser Zeile die CPU Frequenz in Hertz>>> angibt, für einen MC, der mit z.B. 10MHz getaktet wird, sollte da#define>>> F_CPU 10000000UL>>> stehen.>>>> Wenn du meinst.>> Ich habe keine Ahnung, was du damit zu tun hast, aber das ist keine> Meinung von mir, sondern ein Tipp an den TE. Eine Meinung habe ich hier> nicht geäussert.
Keine Angst Uli die sind nicht nur neidisch auf dich, die wollen dir
sogar helfen.
~Stefan Lagger
Matthias Sch. schrieb:
> Uli schrieb:>> #define F_CPU 100000UL>> Auch das macht mich stutzig. Bist du sicher, das dein MC nur mit 100kHz> läuft? Bedenke, das man in dieser Zeile die CPU Frequenz in Hertz> angibt, für einen MC, der mit z.B. 10MHz getaktet wird, sollte da#define> F_CPU 10000000UL> stehen.
Ich glaube du hast keine Ahnung, wie machtvoll so ein MC sein kann. Die
dunkle Seite des MC hat leider schon so manchen Programmjedi zu sich
gezogen. Möge die Macht mit euch sein.
Amateur schrieb:> Jeder, der bei uns goto verwendete (versuchte) hat sich einen> ordentlichen Lacher eingefangen.
Ein "goto" ist primär ein Kündigungsgrund!
Nur mit einer extrem guten Ausrede darf man weiterarbeiten.
@Barack Obama, Stefan Lagger, Uli
Da könntet ihr euch doch eigentlich einfach kurz mal treffen und
miteinander diskutieren? Ihr seid ja nicht weit voneinander weg...
@ Winfried J. (Firma: Nisch-Aufzüge) (winne)
> so ein Lift macht bis zu 12000 m/min = 20m/sek gleichzeitig wird>erwartet, dass er millimetergenau stoppt, ohne die freistehenden>Passagiere>das Log des Canbusses moderner Lifte nur einer Fahrt ist manuell kaum zu>lesen geschweige ohne Hilfsmittel zu analysieren. ;)
Jaja. Es gibt auch Formel 1 Autos, die die 350 km/h fahren und aus dem
Stand diese Geschwindigkeit in vielleicht 20s erreichen. Mag sein.
Die große Masse bäckt aber deutlich kleinere Brötchen und bewegt sich
deutlich gemächlicher. So auch die meisten Lifte.
Und bevor der OP auch nur ansatzweise daran denken kann, einen Formel 1
Lift zu programmieren, muss er erstmal einen Kurbellift SAUBER in den
Griff kriegen.
Winfried J. schrieb:> so ein Lift macht bis zu 12000 m/min = 20m/sek gleichzeitig wird> erwartet, dass er millimetergenau stoppt, ohne die freistehenden> Passagiere allzu arg zu belasten.
20m/s kann ich mir vorstellen,
12km/min (720km/h) ist aber ambitioniert ;-)
Das Hauptproblem ist, daß Anfänger denken, man könne einfach so drauflos
schreiben und den grausligsten Spaghetticode abliefern.
Ein erfahrenen Programmierer fängt so an:
- PC ausschalten
- Bleistift und Papier nehmen und Ablaufdiagramm erstellen
- Ablaufdiagramm durchspielen
- und erst wenn das funktioniert, kann man den PC wieder anschalten
- Ablaufdiagramm in Code umsetzen.
Selbst Egon Olsen brauchte immer erstmal einen Plan.
Karl Heinz schrieb:> Ist irgendetwas davon nicht erfüllt, dann habe ich mich irgendwo in der> {-} Hierarchie vertan und ich muss dieses Problem suchen.
Warum zeigt einem eine moderne IDE nicht einfach die Stelle, wo etwas
nicht stimmt. Das Verfolgen von Klammerhierarchien und das Zählen von
Leerzeichen am Zeilenanfang sollte ein moderner Computer doch
hinkriegen. Das würde einem wesentlich weiter helfen, als am Ende des
Quelltextes ein Aufschrei des Compilers "Missing '}' expected" o.ä.)
oder sonstige abstruse Fehlermeldungen.
<ot>
Wenn man mal ein paar der hochwohlgelobten Freiheiten beim Schreiben des
Quellcodes über Bord schmeißen und in der IDE festlegen würde, dass zu
einer bestimmten Hierarchieebene genau eine bestimmte Einrückung gehört
(auch kein wildes Misch-Masch aus Tab und Space usw.) hätte man eine
prächtige Möglichkeit, die Formatierung gegen die vom Compiler gelesene
Struktur abzugleich und Abweichung gezielt anzumeckern. Aber echte
Programmierer, sind sich wohl zu eigen, um sich solchen Konventionen
fremdbestimmt zu unterwerfen. Warum sollen die oben genannten
Formatierungskonventionen nicht in der IDE einstellbar sein und
Änderungen sogar über automatische, in die IDE integrierte
Reformatierungsfunktion für den Quelltext in einem Rutsch übernehmbar
sein?
Manchmal kommt man sich bei C vor, wie am Ende der 70er Jahren.
</ot>
Wolfgang schrieb:> Warum zeigt einem eine moderne IDE nicht einfach die Stelle, wo etwas> nicht stimmt. Das Verfolgen von Klammerhierarchien und das Zählen von> Leerzeichen am Zeilenanfang sollte ein moderner Computer doch> hinkriegen. Das würde einem wesentlich weiter helfen, als am Ende des> Quelltextes ein Aufschrei des Compilers "Missing '}' expected" o.ä.)> oder sonstige abstruse Fehlermeldungen.
Der Compiler macht es! Man muß es nur nutzen.
1
intmain(void){
2
inta;
3
4
a=1;
5
6
a+="Stuss";
7
}
$ gcc -Wall -Wextra x.c
x.c: In function ‘main’:
x.c:6:7: warning: assignment makes integer from pointer without a cast
[enabled by default]
x.c:7:1: warning: control reaches end of non-void function
[-Wreturn-type]
Baku M. schrieb:> Moderne Menschen machen machen das so:> int main(){> ....> }>> Allein daran erkennt man schon, daß sie zu einer jungen, dynamischen> Generation gehören!
Du hast keine Ahnung.
Das ist der K&R bzw. 1TBS ("the one true brace style"). Kommt, man
glaubt es kaum aus der Zeit von Kernighan and Ritchie. Der Unterschied
zwischen K&R-Style und 1TBS ist die Behandlung von
Kontrollkonstruktionen mit nur einer Anweisung.
Der original Unix-Kernel ist mit K&R, bzw. 1TBS geschrieben. Der
Linux-Kernel ist in 1TBS geschrieben. Der ANSI-C Standard benutzt
ebenfalls 1TBS und C++ Meister Stroustrup benutzt auch eine Variante von
1TBS.
An 1TBS erkennst du nicht die bekifften modernen Hippster,
Web"programmierer" und andere Jutebeutelträger, sondern die alten Schule
der Meister.
Wolfgang schrieb:> ...über automatische, in die IDE integrierte> Reformatierungsfunktion für den Quelltext in einem Rutsch übernehmbar> sein?> Manchmal kommt man sich bei C vor, wie am Ende der 70er Jahren.> </ot>
Ich glaub eher, du lebst noch in den 70ern.
Meine IDE (Eclipse) kann das, ich vermute sehr viele andere können das
auch.
Wenn jeder im Projekt das selbe Style-Template verwendet gibt es am
Schluß nur noch einheitlichen Code. Das ist es ja, was du willst,
richtig?
Schau dich um, das wurde schon längst erfunden und ist auch für C
nutzbar, nicht nur für Java oder .NET.
(Ich vermute, dein Kommentar soll C als alt und überholt darstellen.
Puh, böses Eigentor ;-))
Wolfgang schrieb:> Warum zeigt einem eine moderne IDE ...> Manchmal kommt man sich bei C vor, wie am Ende der 70er Jahren.>
Was hat die IDE eigentlich mit der Programmiersprache zu tun?
Max H. schrieb:> Was hat die IDE eigentlich mit der Programmiersprache zu tun?
sehr viel, denn sie bietet Syntax Unterstützung und
Autovervollständigung. Das geht recht schlecht ohne Kenntnisse der
Sprache.
Was du meinst ist ein Editor, den kann man für jede Sprache nutzten.
Paul Baumann schrieb:> Peter Dannegger schrieb:>> Selbst Egon Olsen brauchte immer erstmal einen Plan.>> Mächtig Gewaltig!> ;-)
Und John Hannibal Smith sagte immer:" Ich liebe es wenn ein Plan
funktioniert"
Wolfgang schrieb:> Wenn man mal ein paar der hochwohlgelobten Freiheiten beim Schreiben des> Quellcodes über Bord schmeißen und in der IDE festlegen würde, dass zu> einer bestimmten Hierarchieebene genau eine bestimmte Einrückung gehört> (auch kein wildes Misch-Masch aus Tab und Space usw.) hätte man eine> prächtige Möglichkeit, die Formatierung gegen die vom Compiler gelesene> Struktur abzugleich und Abweichung gezielt anzumeckern.
Das wurde z.B. bei Python gleich in der Sprache verankert. Da hat man
die Klammern einfach ganz weggelassen und markiert die Blocke nicht nur
optisch, sondern auch für den Compiler (bzw. Interpreter) direkt durch
die Einrückung. Das ganze wird oft kontrovers diskutiert. Es hat seine
Vor- aber auch Nachteile.
Rolf Magnus schrieb:> Das wurde z.B. bei Python gleich in der Sprache verankert. Da hat man> die Klammern einfach ganz weggelassen und markiert die Blocke nicht nur> optisch, sondern auch für den Compiler (bzw. Interpreter) direkt durch> die Einrückung. Das ganze wird oft kontrovers diskutiert. Es hat seine> Vor- aber auch Nachteile.
Ich habe das am Anfang gehasst. ;-)
Jetzt nutze ich Python recht gerne, schnell kann man mal ein paar
hundert Zeilen runterhacken um kurz etwas zu testen.
Und Python code liest sich auch recht angenehm.
Mark 99 schrieb:> An 1TBS erkennst du nicht die bekifften modernen Hippster,> Web"programmierer" und andere Jutebeutelträger, sondern die alten Schule> der Meister.
Sicher?
1
intf(intx,inty,intz){
2
if(x<foo(y,z)){
3
qux=bar[4]+5;
4
}else{
5
while(z){
6
qux+=foo(z,z);
7
z--;
8
}
9
return++x+bar();
10
}
11
}
Also irgendwas muss man ja rauchen, damit man solch einen Spaghetti-Code
produziert. Die wollen sich doch nur von der Masse abheben oder deren
Arbeitsplatz sichern. Man spart sich ein paar Zeilen auf Kosten der
Lesbarkeit, macht heute ja auch wirklich Sinn. Finde meinen 23"
Bildschirm immer noch zu klein.
Das hier sieht sehr viel besser aus (Allman-Stil):
1
intf(intx,inty,intz)
2
{
3
if(x<foo(y,z))
4
{
5
qux=bar[4]+5;
6
}
7
else
8
{
9
while(z)
10
{
11
qux+=foo(z,z);
12
z--;
13
}
14
return++x+bar();
15
}
16
}
Jetzt lässt sich das Konstrukt auch leicht überblicken.
Schöne Diskussion.
Aber sie geht am Kern des 'Problems' vorbei.
Natürlich gibts unterschiedliche Einrück und Klammersetz Systeme. Aber
die helfen alle nichts, wenn man sie nicht konsequent anwendet.
Ob man die Klammer am Ende der Zeile macht, oder in der nächsten Zeile
ist nicht so wichtig. Ich selbst mach sie auch am Ende der Zeile, ausser
wenn ich hier im Forum poste, da benutze ich manchmal auch die nächste
Zeilen Variante. Und ja, ich bin da auch nicht ganz konsequent. Die
öffnende Klammer einer Funktion kommt immer in die nächste Zeile.
Der springende Punkt ist nicht, wo man jetzt genau seine Klammer
hinsetzt, sondern das man das immer gleich macht und vor allen Dingen,
dass man die Einrückung konsequent anwendet. Nur dann bringt ein
derartiges System was (egal welches).
und ja. Viele Editoren übernehmen den Einrückteil von alleine. SChalte
ich meistens ab. Mir geht das nämlich auf den Keks, wenn ich mehr Zeit
damit verbringe, die wohlgemeinte Autoformatierung des Editors wieder so
zu korrigieren, wie ich das will, als mich auf meinen Code zu
konzentrieren. Wenn mir der Editor den Cursor bei einem Zeilenumruch in
die Spalte setzt, in der in der Zeile zuvor die Anweisung begonnen hat,
dann genügt mir das vollauf. Und ansonsten soll er sich raushalten. Ich
formatiere meine Tabellen so, wie ich das will, und nicht wie sich das
irgendeine Automatik so vorstellt.
> Warum zeigt einem eine moderne IDE nicht einfach die Stelle, wo etwas nicht
stimmt.
Wo ist denn in
1
voidfoo()
2
{
3
inti,j;
4
5
for(i=0;i<20;i++){
6
k=5*i;
7
8
{
9
j=8*i;
10
for(k=9;k<15;k++)
11
{
12
a[k]=k;
13
}
14
}
der erste Fehler? Woran hast du das erkannt? Wo soll also die IDE den
Cursor hinstellen? Und vor allen Dingen: wann soll sie denn den Cursor
dort hin stellen? Wer sagt denn, dass ich mit editieren bereits fertig
bin und nicht den Code noch ein paar mal umbreche?
Das Problem ist: sobald die Klammerung nicht mehr stimmt (was nur ein
Mensch sagen kann, weil er die beabsichtigte Logik erkennen kann), ist
die Zuordnung aller weiteren schliessenden Klammern zu den öffnenden
Klammern nicht mehr eindeutig möglich.
Ob die öffnende Klammer am Ende der Zeile oder in einer extra Zeile
steht, ist wirklich Geschmackssache. Als ich C als Student Mitte der
80er auf Unix System V lernte, habe ich die Klammer auch am Ende der
Zeile gemacht - einfach um Zeilen zu sparen. Denn bei einem
VT100-Terminal mit "nur" 80x24 Zeilen ist jede Zeile, die man gewinnt,
wichtig.
Heute, wo die Terminals nur noch als Emulation laufen und man die Größe
des Fensters auf viel mehr Zeilen und Spalten aufziehen kann,
positioniere ich die öffnende Klammer immer auf einer extra-Zeile. Das
hat zwei Gründe: Erstens gewinnt man Platz für Kommentare, um den
nachfolgenden Block zu kommentieren. Zweitens fällt es mir viel
schneller auf, wenn ich eine Klammer mal vergessen oder eine zuviel drin
habe.
Aber wie gesagt: das ist reine Geschmackssache. Und über Geschmack lässt
sich vortrefflich streiten. :-)
Sebastian V. O. schrieb:> Goto> funktioniert nur innerhalb der gleichen Funktion und selbst da ist es> schlechter Programmierstil.
GoTo ist nicht perse schlechter Programmierstil. Kann mal also nicht so
verallgemeinern.
@TO
Ich bin überhaupt kein Freund dieser Sprache, deshalb kann ich auch
Nichts
zur Fehlersuche beitragen, aber das hat ja bis jetzt auch kein Anderer
getan.
Was Du tun könntest, wäre, Zeilennummern zu erzwingen, um dann mit der
Maus
auf die untenstehenden Fehlermeldungen zu klicken. Oft (nicht immer)
landet
man dann in der Zeile, die den Fehler enthält, bzw. wo er zuerst
auftritt.
Dann gilt es, "weiter oben" im Quelltext zu suchen, ob man nicht eine
Deklaration falsch oder auch gar nicht gemacht hat.
Ich nehme mal an, daß das Programm schon einmal gelaufen ist, denn so
einen großen Brocken wämmert man ja normalerweise nicht im Ganzen
hinein.
Ich vermute, daß das Programm von jemand Anderem stammt und Du sollst
es nun in Gang bringen. Solche Fahrstuhlübungen werden gerne in
sog. Bildungseinrichtungen gemacht und dort gibt es dann niemanden, der
beim Schreiben und/oder der Fehlersuche behilflich sein kann....
Utschastnik schrieb:> Ich vermute, daß das Programm von jemand Anderem stammt und Du sollst> es nun in Gang bringen. Solche Fahrstuhlübungen werden gerne in> sog. Bildungseinrichtungen gemacht und dort gibt es dann niemanden, der> beim Schreiben und/oder der Fehlersuche behilflich sein kann....
Oder die "Lehrkräfte" strotzen selbst vor Inkompetenz. Selber schon
erlebt an der FH, nach einem Professor, der mal an der
Videospiel-Branche tätig war, soll "i++" schneller sein als "i+=1". Vor
30 Jahren hätte er ja recht gehabt aber heute?
TriHexagon schrieb:> soll "i++" schneller sein als "i+=1". Vor> 30 Jahren hätte er ja recht gehabt aber heute?
Ich denke, ich lehne mich da nicht zu weit aus dem Fenster, wenn ich
behaupte: noch nicht mal vor 30 Jahren war i++ schneller als i+=1.
Die entsprechende 'Optimierung' im Expression Tree ist so trivial, das
geht beim 'Constant Folding' im Compiler mehr oder weniger automatisch
mit.
Ein Compiler, der das nicht beherrscht verdiente auch damals die
Bezeichnung 'Compiler' nicht wirklich.
Vielleicht wollte er nur auf den Unterschied zwischen Read-Modify-Write
und direktem Inkrementieren hinweisen und nutzte das nur als Beispiel
ohne hier wirklich eine Aussage bezüglich Compiler und Optimierung
machen zu wollen.
Utschastnik schrieb:> Was Du tun könntest, wäre, Zeilennummern zu erzwingen, um dann mit der> Maus> auf die untenstehenden Fehlermeldungen zu klicken. Oft (nicht immer)> landet> man dann in der Zeile, die den Fehler enthält, bzw. wo er zuerst> auftritt.> Dann gilt es, "weiter oben" im Quelltext zu suchen, ob man nicht eine> Deklaration falsch oder auch gar nicht gemacht hat.>
Ich nehme an, du beziehst dich auf das Original-Posting:
Nicht in diesem Fall.
Der Code im Eröffnungsposting ist prinzipiell so verkorkst, denn kannst
du nur wegwerfen und neu machen. Das ist so, wie wenn eine Autobahn mit
Stroh gebaut werden würde. Egal an welchen Stellen du mit Stroh
nachbesserst, das wird nichts. Das kann prinzipiell schon nichts werden.
Da gibts nur eines: abreissen und neu machen. (Was er dann ja getan hat.
Die FOrmatierung ist immer noch grausam, das ganze ist noch ein wenig
ungelenk, aber zumindest könnte das was werden)
> Ich nehme mal an, daß das Programm schon einmal gelaufen ist,
Nope. Den hat er ziemlich sicher selbst verbrochen.
> denn so> einen großen Brocken wämmert man ja normalerweise nicht im Ganzen> hinein.
Du hast noch nicht vielen Neulingen geholfen, stimmts? (soll kein
Vorwurf sein).
Sonst wüsstest du, dass mehr als 80% aller Neulinge, wenn sie keinen
vernünftigen Lehrer haben, den immer gleichen Fehler machen: Sie
überschätzen sich, bzw. sie unterschätzen die Schwierigkeit, die mit
steigender Komplexität exponentiell auf sie zukommt. In a nutshell: Sie
schreiben zu viel ungetesteten Code auf einmal und das dann auch noch
ohne sich vorher einen realistischen Plan zurecht zu legen.
Das was man im Eröffnungsposting sieht ist also gar nicht so exotisch
sondern eigentlich recht häufig.
Aber das macht nichts: Compiler und Computer sind stur. Die haben noch
jedem beigebracht, wo seine Grenzen zur Zeit liegen und das es sich
rächt, wenn man in Relation zum Können zu große Sprünge machen will.
cyblord ---- schrieb:> Vielleicht wollte er nur auf den Unterschied zwischen Read-Modify-Write> und direktem Inkrementieren hinweisen und nutzte das nur als Beispiel> ohne hier wirklich eine Aussage bezüglich Compiler und Optimierung> machen zu wollen.
Leider nicht wirklich, er meint der Compiler übersetzt i++ zu INC und
i+=1 zur Instruktion ADD (jedenfalls meinte er das produziert
schnelleren Maschinencode). Aber welcher Compiler macht so etwas? Auf
x86 soll man INC sowieso nicht mehr benutzen (laut dem Intel
Optimization Guide), weil INC im Falle eines Überlaufes kein Carry-Flag
setzt. Schneller dürfte INC heutzutage auch nicht mehr sein.
Karl Heinz schrieb:> Ich denke, ich lehne mich da nicht zu weit aus dem Fenster, wenn ich> behaupte: noch nicht mal vor 30 Jahren war i++ schneller als i+=1.
Naja, was vor knapp 40 Jahren wirklich schneller war und zumindest
begünstigend gewesen sein dürfte, dass die Herren K&R diese Operatoren
eingeführt haben, sind Zeigerausdrücke der Art
1
c=*cp++;
2
3
*--p=x;
und zwar nur in dieser Anordnung. Der Grund ist, das das die
elementaren Stack-Operationen sind (Auskellern/Einkellern), und da
die PDP-11 einen streng orthogonalen Befehlssatz hatte (alle
Operationen, die es für den Stackpointer R6 gab, gab es genauso auch
für alle anderen Register), konnte der Compiler das direkt auf Befehle
abbilden. Damit hatte man die Möglichkeit, in einer Hochsprache
trotzdem die Effektivität eines Assemblerprogrammierers zu haben.
Jörg Wunsch schrieb:> Naja, was vor knapp 40 Jahren wirklich schneller war und zumindest> begünstigend gewesen sein dürfte, dass die Herren K&R diese Operatoren> eingeführt haben, [...]
Nur zur Info: Hinter K&R verbergen sich die Herren Kernighan & Ritchie.
Die Increment/Decrement-Operatoren (++/--) sind aber schon älter. Diese
gab es bereits in der Vorgängersprache B. Diese wurde von Ken Tompson
(und nicht von Kernighan) und Dennis Ritchie entworfen.
Siehe auch Tompson's B-Manual:
http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html
bzw. das B-Tutorial aus den Bell Labs:
http://www.cs.bell-labs.com/cm/cs/who/dmr/btut.html
P.S.
Auch Tompson benutzte damals schon die geschweifte Klammer-Auf am Ende
der Zeile. Hat also wirklich nichts mit "heute hipp" zu tun ;-)
Thread beobachten
Seitenaufteilung abschalten