Entwickler-Ecke
Delphi Language (Object-Pascal) / CLX - Label für GoTo-Anweisung setzen
Crawfish - Fr 07.02.03 18:18
Titel: Label für GoTo-Anweisung setzen
Moin!
Wir arbeiten in Informatik mit Delphi und sollen als Hausaufgabe eine Ampel programmieren. Ich habe das jetzt so hinbekommen, dass die Ampel einmal richtig durchläuft. Nun muss sie aber öfter durchlaufen und dazu muss ich denk ich mal eine Schleife machen, und damit dies keine endlosschleife wird, soll sie erst wieder anfangen, wenn im letzten timer eine variable richtig gesetzt wurde. Soweit verstanden?
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
| label StartHere;
begin
fertig:='a';
while fertig='a' do
begin
fertig:='b';
timer1.enabled:=true;
timer2.enabled:=true;
timer3.enabled:=true;
timer4.enabled:=true;
timer5.enabled:=true;
end;
goto StartHere; |
In Timer 5 wurde die Variable fertig auf b gestellt. Nun meine Frage: Wie setze ich das Label richtig. So, wie es im Moment ist sagt er mir "Label wurde deklariert und referenziert, aber nicht gesetzt".
Vielen Dank im Voraus!
Crawfish
maximus - Fr 07.02.03 18:42
*lol* wer hat dir den den floh ins ohr gesetzt, dass mit labels machen zu wollen :arrow: BENUTZE NIEMALS LABELS :twisted: Sonst müssen wir noch'n exorzisten rufen :wink:
Der code sieht 'n bisschen merkwürdig aus, weil die schleife immer genau einmal durchlaufen wird. Dies ist genau das selbe:
Quelltext
1:
2:
3:
4:
5:
6:
| fertig:='b';
timer1.enabled:=true;
timer2.enabled:=true;
timer3.enabled:=true;
timer4.enabled:=true;
timer5.enabled:=true; |
Mach doch einfach im letzten timerEvent alle anderen timer wierder auf true. Ergo haste eine schleife
viel spass.
Crawfish - Fr 07.02.03 18:46
Also das mit den Labels war die Delphi-Hilfe (Delphi 5).
Ich versuchs mal und melde mich dann. Danke!
Crawfish
Crawfish - Fr 07.02.03 18:51
Ja es geht! Danke nochmal. Muss nur noch einen Stopp-Button proggen. Aber das krieg ich auch noch hin.
Crawfish
Delete - Fr 07.02.03 21:13
| maximus hat folgendes geschrieben: |
| BENUTZE NIEMALS LABELS |
Warum nicht?
Delete - Fr 07.02.03 21:21
Titel: PS!
Ach so, damit wir uns nicht falsch verstehen (und um evtl. Zensur vorzubeugen):
Ich habe z.B. ein Programm, dass im Hintergrund läuft und in einstellbarer Zeit auf mein POP3-Postfach zugreift und nach Mails checkt.
Du weißt, wie das läuft? Du meldest dich an, sendest Mailadresse, Passwort, usw. usw.
Im Fehlerfall (wenn eine Verbindung steht, aber nicht das gewünschte zurückliefert), sollte man die Verbindung nicht einfach bloß kappen sondern sich auch ordnungsgemäß am Server abmelden.
Nun müsste ich also für jedes evtl. auftretende Problem diese Abmelderoutine schreiben (sprich: "QUIT" senden) und dann die Prozedur verlassen.
Fazit: Ich habe ein Label definiert, dass ich kurz und ergreifend anspringe. Ich halte das -in diesem Fall, zugegeben!- für den besten Weg, denn das o.g. Kommando "QUIT" muss ich auch im Erfolgsfall senden, um die Verbindung zum Server zu schließen.
Der Code ist also vorhanden, steht nur etwas weiter hinten in der Prozedur. Darum das Label, und ich spare jede Menge Codezeilen.
Sag also bitte niemals NIEMALS. :)
btw: Das ist ein non-VCL-Programm. Ich muss also die Verbindung zum Server aufnehmen und die notwendigen Kommandos, da es ohne VCL keine Komponenten gibt, die mir diese Arbeit abnehmen würden. Schöner Nebeneffekt: das Programm ist 31k groß.
Also, dafür benutze ich gern mal ein oder zwei Labels. :wink:
Christian S. - Fr 07.02.03 21:27
Ausnahmen bestätigen die Regel. Und der Zweck heiligt die Mittel. Aber prinzipiell sollte wirklich gelten: YOU SHALL NOT USE LABELS!. Ist unschöner - und zugegeben manchmal trotzdem sinnvoller - Programmierstil.
@Mathias: nur, damit Du Dir nicht auf den Schlips getreten fühlst: es gibt vieles, was ich als unschönen Programmierstil empfinde, aber trotzdem selbst ab und zu benutze. Wenn ich also von schlechtem Programmierstil spreche, ist das kein Zeichen der Geringschätzung oder so.
Delete - Fr 07.02.03 23:00
Für ernsthafte Kritik bin ich immer zu haben, und da lasse ich mich auch gern eines Besseren belehren. Insofern fühle ich mich nicht auf den Schlips getreten. Im Gegenteil: ein offenes Wort ist mir lieber. :)
Christian S. - Fr 07.02.03 23:26
| Zitat: |
| Im Gegenteil: ein offenes Wort ist mir lieber. |
Das finde ich prima!
zurück zu den Labels:
Ich schätze Delphi gerade aufgrund seiner klaren und sehr gut strukturierten Quellcodes. Wenn man Labels und Goto in Maßen und mit dem richtigen Fingerspitzengefühl (im wahrsten Sinne des Wortes, wie ich gerade bemerke :wink: ) einsetzt, bleibt der auch erhalten.
Dieses Fingerspitzengefühl hat man jedoch noch nicht, wenn man Delphi gerade in der Schule lernt. Und gerade dann (also wenn man Delphi lernt) wird der Programmierstil am meisten geprägt. Und deshalb sollte man zu diesem Zeitpunkt unbedingt noch sagen: "Keine Labels".
Und zu einem späteren Zeitpunkt gibt es bestimmt ein paar Fälle, in denen ein Label wirklich sinnvoll ist. Man muss (meiner Meinung nach) nur darauf achten, dass eine klare Programmstruktur, bei der der Programmablauf so klar ist wie auch sonst in Delphi, erhalten bleibt. Ein Delphiprogramm sollte auf gar keinen Fall zu einer Spaghetti-Programmierung werden.
Ist natürlich eine sehr persönliche Einschätzung, aber wenn es um Programmierstil geht, ist das wie mit dem Geschmack: da hat jeder seinen Eigenen.
MfG,
Peter
Delete - Sa 08.02.03 09:23
| Peter Lustig hat folgendes geschrieben: |
| Wenn man Labels und Goto in Maßen und mit dem richtigen Fingerspitzengefühl (im wahrsten Sinne des Wortes, wie ich gerade bemerke :wink: ) einsetzt, bleibt der auch erhalten. |
Das denke ich auch; kleines Beispiel:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
| s := socket(AF_INET,SOCK_STREAM,0);
if(s <> INVALID_SOCKET) then
try
ZeroMemory(@saddr,sizeof(TSockAddr));
saddr.sin_addr.S_addr := dwIp;
saddr.sin_family := AF_INET;
saddr.sin_port := htons(pop3port);
// connect to server
res := connect(s,saddr,sizeof(saddr));
if(res = SOCKET_ERROR) then goto SocketCloseJump;
// check server status
ZeroMemory(@rbuf,sizeof(rbuf));
res := recv(s,rbuf[0],sizeof(rbuf),0);
if(res = SOCKET_ERROR) then goto SocketCloseJump;
if(rbuf[0] <> '+') then goto SendQuit;
// send user name
res := sendPop3Cmd(s,'USER ' + pop3user);
if(res = SOCKET_ERROR) then goto SocketCloseJump;
ZeroMemory(@rbuf,sizeof(rbuf));
res := recv(s,rbuf[0],sizeof(rbuf),0);
if(res = SOCKET_ERROR) then goto SocketCloseJump;
if(rbuf[0] <> '+') then goto SendQuit;
// send password
res := sendPop3Cmd(s,'PASS ' + pop3pwd);
if(res = SOCKET_ERROR) then goto SocketCloseJump;
ZeroMemory(@rbuf,sizeof(rbuf));
res := recv(s,rbuf[0],sizeof(rbuf),0);
if(res = SOCKET_ERROR) then goto SocketCloseJump;
if(rbuf[0] <> '+') then goto SendQuit;
// mehr POP3-Sachen, die ich aber nicht verrate
// :o)
{ ... }
SendQuit:
// close POP3 server
res := sendPop3Cmd(s,'QUIT');
if(res = SOCKET_ERROR) then goto SocketCloseJump;
ZeroMemory(@rbuf,sizeof(rbuf));
res := recv(s,rbuf[0],sizeof(rbuf),0);
SocketCloseJump:
finally
CloseSocket(s);
end; |
Ich glaube,
so furchtbar ist es trotz der zwei Labels nicht. Oder?
| Zitat: |
| Dieses Fingerspitzengefühl hat man jedoch noch nicht, wenn man Delphi gerade in der Schule lernt. Und gerade dann (also wenn man Delphi lernt) wird der Programmierstil am meisten geprägt. Und deshalb sollte man zu diesem Zeitpunkt unbedingt noch sagen: "Keine Labels". |
Das ist ein Argument, dem ich mich nicht verschließen kann!
:)
Gruß.
tommie-lie - Sa 08.02.03 12:52
Darf ich hier ein kleines Zitat aus meinem PowerBASIC-Buch ins Spiel bringen, Kapitel 7 "Kontrollstrukturen", Erscheinungsjahr 1993:
| Kirschbaum Software hat folgendes geschrieben: |
GOTO ist die einfachste Kontrollstruktur nach der Sequenz. Das GOTO ist ein Dinosaurier und ein fosiiler Vorgänger komplexer und elegenterer Kontrollstrukturen. [...]
Heute (und das war schon vor 10 Jahren!) lehnen viele Programmierer den Gebraauch von GOTOs ab. Damit haben sie Recht, trotzdem ist das GOTO nicht von sich aus schlecht. Ein zu lässiger Umgang mit GOTOs (wenn also von Punkt zu Punkt gesprungen wird, anstatt mit Prozeduren und Funktionen zu arbeiten) führt allerdings zu Verwirrungen beim Programmierer und zu Programmfehlern Außerdem verfügen die modernen BASIC-Dialekte, wie PowerBASIC, über weitaus elegantere Kontrollstrukutren. Von ihrer Funktion her unterscheiden sich GOTOs und alle mordernen Kontrollstrukturen natürlich nicht, sofern sie korrekt eingesetzt werden. Trotzdem gehören GOTOs heute eher zu einem schlechten Programmierstil, weil damit viel Unfug angerichtet wird. |
Dann kommt eine Beschreibung aller in PowerBASIC vorhandenen Alternativen, angefangen mit Schleifen über IF/THEN/ELSE-Konstrukte, SELECT CASE-Konstrukte bishin zu EXIT FAR-Konstrukten (eine spezielle Möglichkeit, unbedingte Sprünge zu verhindern, kennt vermutlich keiner hier...). Dannach kommt ein kleiner Abschnitt "Auch das letzte GOTO wird überflüssig". Darin wird beschrieben, daß ein letztes Argument für GOTOs die vereinfachte Verarbeitung ist. Als Beispiel wird ein Scchachspiel herangezogen, in dem das Spielende über GOTOs herbeigeführt wird. Durch ein paar WHILEs mit bestimmten Flags wird daraus ein (IMHO) viel übersichlicheres Programm, vollkommen ohne GOTOs.
Generell wird also schon seit über 10 Jahren davon abgeraten, GOTOs zu verwenden. Der Grund dafür ist, die verantwortungslose Programmierung, da GOTOs bei einigen Programmierern (vermutlich hauptsächlich Scriptkiddies und Anfängern) die Prozeduren und Funktionen und sogar Schleifen ersetzt haben.
Außerdem machen GOTOs in vielen Fällen das Programm unübersichtlicher und in einigen Fällen wäre man mit einer simplen Procedure (oder in BASIC auch mit einem SUB) wesentlich besser davongekommen, mit nur einer Zeile zusätzlichem Code (nämlich ein END SUB...).
MS' Code hätte ich zum Beispiel, als jemand der mit 12 Jahren gelernt hat, ohne GOTOs auszukommen, so gemacht:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
| procedure Quit;
procedure Close;
s := socket(AF_INET,SOCK_STREAM,0);
if(s <> INVALID_SOCKET) then
try
ZeroMemory(@saddr,sizeof(TSockAddr));
saddr.sin_addr.S_addr := dwIp;
saddr.sin_family := AF_INET;
saddr.sin_port := htons(pop3port);
// connect to server
res := connect(s,saddr,sizeof(saddr));
if(res = SOCKET_ERROR) then Close;
// check server status
ZeroMemory(@rbuf,sizeof(rbuf));
res := recv(s,rbuf[0],sizeof(rbuf),0);
if(res = SOCKET_ERROR) then Close;
if(rbuf[0] <> '+') then Quit;
// send user name
res := sendPop3Cmd(s,'USER ' + pop3user);
if(res = SOCKET_ERROR) then Close;
ZeroMemory(@rbuf,sizeof(rbuf));
res := recv(s,rbuf[0],sizeof(rbuf),0);
if(res = SOCKET_ERROR) then Close;
if(rbuf[0] <> '+') then Quit;
// send password
res := sendPop3Cmd(s,'PASS ' + pop3pwd);
if(res = SOCKET_ERROR) then Close;
ZeroMemory(@rbuf,sizeof(rbuf));
res := recv(s,rbuf[0],sizeof(rbuf),0);
if(res = SOCKET_ERROR) then Close;
if(rbuf[0] <> '+') then Quit;
procedure Quit;
begin
// close POP3 server
res := sendPop3Cmd(s,'QUIT');
if(res = SOCKET_ERROR) then goto SocketCloseJump;
ZeroMemory(@rbuf,sizeof(rbuf));
res := recv(s,rbuf[0],sizeof(rbuf),0);
end;
procedure Close;
begin
finally
CloseSocket(s);
end;
end; |
Meiner Meinung nach genauso einfach, man kann von überall den Socket schließen und QUIT senden, egal wo man im Programm gerade ist. Und an übersichtlichkeit hat es ja wohl auch nichts verloren, oder?
Delete - Sa 08.02.03 13:05
| tommie-lie hat folgendes geschrieben: |
| MS' Code hätte ich zum Beispiel, als jemand der mit 12 Jahren gelernt hat, ohne GOTOs auszukommen ... |
Der Satz gefällt mir. :wink: Die Wahrheit ist, seit ich 1991/92 mit TP angefangen habe und von GW-BASIC (MS-DOS 4.xx) weg bin, habe ich nie wieder mit "goto" gearbeitet.
Nur in besagtem Projekt (und im PortScanner) findet sich so ein Label, um mal eben fix ein paar Anweisungen zu "überspringen".
Mir gefällt z.B. nicht, dass du TRY/FINALLY/END aufgetrennt hast. Ob das noch korrekt funktioniert, ist eine andere Sache - ich weiß es nicht, glaube es aber auch irgendwie nicht.
Dann lieber darauf verzichten und vor dem Schließen des Sockets prüfen, ob dieser ungleich INVALID_SOCKET ist.
Nun, wie dem auch sei: bei objektiven Argumenten würde ich nie starrköpfig sein. In dem Fall bleibe ich es aber, :), denn geäußert wurden (auch von mir!) nur subjektive, persönliche Meinung über ein Für oder Wider.
| Zitat: |
| man kann von überall den Socket schließen und QUIT senden, egal wo man im Programm gerade ist. |
Hier mein einziger Einspruch: das mag in anderen Programm nützlich sein. In dem speziellen Fall aber nicht. Es gibt nur eine Prozedur, die den Server ansteuert, sich verbindet, nach Post guckt und wieder geht.
Wenn Prozeduren, dann lokale; damit man eben
nicht in die Versuchung kommt, den Server von jedem beliebigen Punkt des Programms schließen zu wollen.
Gruß.
Christian S. - Sa 08.02.03 13:19
@tommie-lie: irgendwie glaube ich nicht, dass Deine Version von Mathias' Programm überhaupt richtig funktioniert, denn es werden ja keine Anweisungen übersprungen, sondern nur welche dazwischen ausgeführt und dann am Ausgangspunkt weitergemacht.
@Mathias: In diesem Spezialfall muss ich sagen, dass die Gotos hier wirklich sinnvoll sind. Außerdem kann es zu keiner Verwirrung kommen, da immer nur genau einmal gesprungen wird, der Programmablauf vollkommen klar bleibt. Da ist wirklich nichts gegen einzuwenden. Sozusagen die Ausnahme, die die Regel bestätigt.
MfG,
Peter
maximus - Sa 08.02.03 13:49
*LOL* Da hab ich ja richtig was losgetreten :shock:
Ich werde niemehr NIEMALS sagen...oder darf ich auch nicht NIEMEHR sagen? aber meine intension war gut, da ich einen anfänger davor bewaren wollte einen grossen fehler zu begehen :D is ja auch alles geklärt!
| Zitat: |
| Die Wahrheit ist, seit ich 1991/92 mit TP angefangen habe und von GW-BASIC (MS-DOS 4.xx) weg bin, habe ich nie wieder mit "goto" gearbeitet. |
Geht mir auch so: Seit GW-BASIC hab ich nen hass auf GOTOs und diese schlimmen zeilen-nummerierungen. Was für eine freude ist da doch unser geliebtes PASCAL :)
grüsse. Maximus
PS: Ich kann GOTOs auch nur in extrem situationen gut heissen. Siehe oben 8) Scheint dort einigermassen angebracht zu sein.
tommie-lie - Sa 08.02.03 14:47
try? finally? überspringen?
Oooops.
Da hab ich nicht richtig aufgepast. Sorry, mein Fehler.
Dann geht meine Methode tatsächlich nicht. Aber vielleicht kann man's so umstrukturieren, daß man trotzdem noch ohne GOTOs auskommt...
Aber das wäre mir für den Augenblick zu viel Arbeit.
btw: Hat man bei GW-BASIC tatsächlich noch Zeilennummern gebraucht? PB hat extra darauf hingewiesen, daß man keine mehr braucht, und der Compiler sie ignoriert, es sei denn man will sie zu Label-Zwecken benutzen. Die Nummern hatten also keine Bedeutung mehr. Da bin ich ja richtig froh, daß ich mit dem Power-Dialekt aufgewachsen bin *g* (wer's übrigens heute noch haben will, kann auf
pb.com [
http://www.pb.com] noch die kostenlose DOS-Version runterladen. Die Windows-IDE kostet allerdings ein entsprechendes Entgeld... Mittlerweile gibt's sogar einen DLL-Compiler für PB!)
Delete - Sa 08.02.03 15:10
| tommie-lie hat folgendes geschrieben: |
| Aber das wäre mir für den Augenblick zu viel Arbeit. |
:D
| Zitat: |
| btw: Hat man bei GW-BASIC tatsächlich noch Zeilennummern gebraucht? |
Ja. Aber noch schöner war das alte KC-BASIC vom blinkenden Schuhkarton: dem KC-85 - "super" DDR-Computer. Auf dem Ding haben wir mal ein Programm für einen lokalen Betrieb geschrieben. Eine Präsentation, die -aus heutiger Sicht!- den Namen nicht verdient, aber dennoch funktionierte und den Weg von einem Stückchen ... äh, was war´s eigentlich: Stoff (?) ... zur fertigen Tischdecke zeigte. - Um´s mal zusammenzufassen
Aber meine Note weiß ich noch: eine Eins! 8)
tommie-lie - Sa 08.02.03 17:05
Und was war nun mit dem KC-BASIC? Was schlimmeres als 1000 Zeilen Code einzelnd zu nummerieren gibt's doch gar nicht, oder?
Delete - Sa 08.02.03 19:16
Nein, nicht schlimmer. Ich sagte doch: schöner! *seufz* ... Ach ja, die gute, alte Zeit ... :wink:
Aber mal ehrlich -
Wer selbst noch mit BASIC und Zeilennummern hantiert hat, wird doch wohl nicht sagen können, dass es Sch... war? Man war´s nicht anders gewohnt, und ehrlicherweise muss ich zugeben, dass ich beim Umstieg auf TP am Anfang Probleme wg. der fehlenden Nummerierung hatte.
Auf der anderen Seite, natürlich!, hattest du irgendwo eine Sprunganweisung drin und hast noch eine Zeile eingefügt, dann konntest du das ganze Listing durchwühlen und die Sprünge anpassen.
Da wir gerade dabei sind und -durch das Lesen- viele Leute wissen, woher ich komme und wie alt ich wohl sein dürfte ... noch ein Nachschlag. :twisted: Unser ESP-Lehrer (Ossis vor, wer weiß was es heißt? :wink:) gab den BASIC-Kurs nach der Schule. Ich nahm ... *hüstel* ... freiwillig daran teil.
So, nun wisst ihr´s. :roll:
tommie-lie - Sa 08.02.03 19:29
Ich habe nie mit Zeilennummern angefangen. Hab gleich mit PB angefangen. Ich fand das superklasse (als 12jähriger wohlgemerkt!), daß man da nicht jede Zeile einzeln nummerieren musste, weil ich gehört hatte, daß man das in anderen Programmiersprachen müsste. Später hat sich rausgestellt, daß es nur in den anderen BASIC-Dialekten so war, aber das war mir egal, ich fand's toll, daß ich immer alles mit Buchstaben ausdürcken konnte, und mir keine Tabelle mit Nummern machen musste, in der stand, welche Nummer welcher Ansprungpunkt war, damit ich nicht jedesmal den Quellcode durchsuchen musste.
AndyB - Sa 08.02.03 19:33
| tommie-lie hat folgendes geschrieben: |
| Hab gleich mit PB angefangen. |
Und PowerBasic (PB) stammt von TurboBasic ab, das wiederum von Borland entwickelt wurde. (Nachdem Borland TB aufgab, erwarb dir Firma Kirschbaum Software die Linzenz und entwickelte PowerBasic).
Man sieht: Borland Produkte waren damals schon die besseren.
tommie-lie - Sa 08.02.03 19:41
nanana, Laut Einleitung ist aber PowerBASIC "eine wesentliche Verbesserung gegenüber Turbo Basic 1.0/1.1 von Borland International".
Zum Beispiel die Huge-Arrays, die mehr als 65kB Daten fassen konnten, oder die Möglichkeit, TSR-Programme zu schreiben. Oder die Möglichkeit, unsigned Integers zu benutzen, womit der Gültigkeitsbereich in den positiven Bereich bei 32bit Verdoppelt wurde. Ganz zu schweigen von der Möglichkeit, 64 bit lange Integers zu benutzen.
Aber trotzdem ist Borland heute besser als beispielsweise MS. Obowohl Intel doch noch mehr Optimierungen für die Intel-CPUs bereithält (was aber auch nciht verwunderlich ist, hätte Borland einen eigenen Prozessor, wäre es genauso).
AndyB - Sa 08.02.03 19:54
Für die Zeit da TurboBASIC herauskam, war der Umfang dieser Compilers-IDE sehr gut. Das PowerBASIC (man beachte, dass es nie eine Einser-Version gab) natürlich an sehr nüztlichen Features zugelegt hat, habe ich auch nie bestritten.
tommie-lie - Sa 08.02.03 21:20
Ich dachte, du wolltest mit "Borland Produkte waren damals schon die besseren." aussagen, daß der TB der "große Bruder" von PB war, andersrum wird ein Schuh draus, PB ist eine Weiterentwicklung von TB.
Aber was ist daran zu bemängeln, daß es nie eine Version 1.0 gab?
AndyB - Sa 08.02.03 21:33
Ich benängle nichts. Das ist nur eine Feststellung, das TurboBASIC 1.x die Einser-Version von PowerBASIC ist.
| Zitat: |
| PB ist eine Weiterentwicklung von TB |
Und was habe ich geschrieben:
| Zitat: |
| Und PowerBasic (PB) stammt von TurboBasic ab, das wiederum von Borland entwickelt wurde |
Um es noch einmal klar und deutlich zu schreiben:
TurboBASIC wurde von Borland entwickelt und war zu seiner Zeit der beste BASIC Compiler. Da Borland die Weiterentwicklung einstellte, wurde von Kirschbaum Software PowerBASIC auf Basis von TurboBASIC geschaffen. Alle Features von TB sind also auch in PB vorhanden und verbessert worden.
tommie-lie - So 09.02.03 11:49
*rofl*
Da haben wir aber aneinander vorbei geredet!
Iss ja auch egal jetz'.
maximus - Mo 10.02.03 12:04
Na da geht ja einiges :D
Mit den zeilennummern war anscheinend 'n guter tipp. Ihr habt ja richtig nolstalgische gefühle dafür. Ich war dann schon über QBasic froh, um nochmal'ne basic abart ins spiel zu bringen. War zwar kein compiler, aber man hatte wenigstens SUBs und man konnte graphik befehle nutzen.
Mit Pascal fahren wir auf jeden besser!
mfg maximus
Tilman - Mo 26.04.04 21:07
| tommie-lie hat folgendes geschrieben: |
try? finally? überspringen?
Oooops.
Da hab ich nicht richtig aufgepast. Sorry, mein Fehler.
|
Also meiner meinung nach ist das überspringen kein problem wenn nach dem Aufruf exit benutzt wird.
AndyB - Di 27.04.04 01:56
Du bist ja früh dran. Der Thread ist schon über ein Jahr alt.
Christian S. - Di 27.04.04 07:37
Vor allem: seit dem 16.3.2003 dabei und jetzt das erste Posting! :lol: Das ist doch mal ein Argument dafür, die Nullposting-User nicht zu löschen! ;-)
Tilman - Di 27.04.04 11:27
Sorry, das mit dem Datum hatte ich nicht gesehen...
| Zitat: |
| Vor allem: seit dem 16.3.2003 dabei und jetzt das erste Posting! Das ist doch mal ein Argument dafür, die Nullposting-User nicht zu löschen! |
Stimmt, ist tatsächlich mein erster Beitrag. ich schreibe öfters im programmierforum.de - Forum. Aber hier lese ich auch regelmäßig zu verschiedenen Themen - die Auswahl ist einfach viel größer. Warum sollten User die nicht schreiben also gelöscht werden? Es kann doch jederziet passieren das man sich mal äussern möchte oder?
Delete - Di 27.04.04 13:48
Das ist sicher richtig. Allerdings musst du dich nicht registrieren um Beiträge lesen zu können. Und wenn man gelöscht wird (eben weil man nichts schreibt) und sich dann doch endlich zu Wort melden will, dann kann man sich IMHO auch ein zweites Mal registrieren.
Christian S. - Di 27.04.04 14:39
Hallo!
Ich bin ja auch dagegen, Leute, die lange nichts gepostet haben, zu löschen. Ich sehe da keinen großen Sinn drin. Aber die Diskussion gehört hier nicht hin. (Auch wenn ich sie angefangen habe :oops:)
MfG
Peter
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!