PureBoard

Man muss es nicht aber ich gebe den Typ trotzdem immer an.
Das erspart mir ständiges nachgucken (bei langen Codes) welchen Typ die ein oder andere Variable hat.
Sowas kann man leicht vergessen wenn der Code mal Wochen oder Monate rumgelegen hat.

EnableExplicit ist ein wahrer Segen für PB. Nur so nebenbei.

Hier werden schon wieder Äpfel mit Birnen verglichen.

Fakt ist doch wohl:
- Menschen haben verschiedene Geschmäcker, deshalb auch verschiedene Sprachenvorlieben.
- PB ist einsteigerfreundlicher
- PB macht nen akzeptablen ASM Code im Vergleich mit allen existierenden Sprachen.
- PB macht nen schrecklichen ASM Code im Vergleich zu optimierenden Compilern
- PB untersützt zur Zeit kein SSE/SSE2/SSE3, etc...
- PB hat nur einen Compiler.
- C(++) hat viele Compiler. Deshalb kann der Output sacklangsam oder megaschnell sein, groß oder klein, je nachdem, welchen Compiler ich mit welchen Einstellungen nutze.
- C(++) hat ne sehr viel größere Community als PB, weshalb es auch alles für C(++) gibt und im Gegensatz dazu fast nichts für PB.
- C(++) ist aus den oben genannten Gründen mächtig.
- In C(++) kann ein gelernter Programmierer ebenso schnell Applikationen erstellen, wie in PB.
- Größere Projekte (50000 Zeilen+) sind ein Graus in PB, weil man schnell rudimentäre Dinge wie OOP, Templates und mächtige Libs vermisst.
- Kleinere Projekte (-1000 Zeilen) sind in C++ manchmal umständlich (und darauf reiten Basicer immer rum), weil man viel machen muss, um sich erstmal ne Plattform zu schaffen.
- C(++) ist was für Profis (und deswegen progge ich PB, weil ich kein Profi bin), die sich nicht mit intuitivem, aber umständlichen Syntax plagen wollen, die wie Neo hinter den code blicken können.

EnableExplicit ist ein wahrer Segen für PB. Nur so nebenbei.

Ist ja schön und gut. Aber hat nichts mit meiner Aussage im letzten Post zu tun.

Aktiviert (EnableExplicit) oder deaktiviert (DisableExplicit) den Explizit-Modus. Wenn aktiviert, werden alle nicht ausdrücklich mittels Define, Global, Protected, Static oder Shared deklarierten Variablen nicht akzeptiert und der Compiler wird eine Fehlermeldung ausgeben. Dies kann helfen, Schreibfehler bei der Verwendung von Variablen auszumerzen.

Man muss trotzdem Nachschauen welchen Typ eine Variable hat wenn man es nicht mehr auf anhieb weis.

Ist ja schön und gut. Aber hat nichts mit meiner Aussage im letzten Post zu tun.

Darf man denn jetzt nur noch auf den jeweils vorherigen Post antworten?!

> Sowas kann man leicht vergessen wenn der Code mal Wochen oder Monate rumgelegen hat.

nö.

alles is Long. Nur wo es wirklich benötigt wird, isses Float.
ok, mittlerweile hat man auch quad und double,
aber die benutzt man eh nur, wenn man sich wirklich was bei gedacht hat.
und die mit nem $ am ende sind strings.

...wieso soll ich irgendwie typen nachschaun müssen?

PS:
wenn du da son problem mit hast, dann nimm halt eigene Prä- oder Suffixe.

Recht hat er!

Datentypen wie Byte oder Word sind meist eh nur sinnvoll wenn Dateien ausgelesen oder geschrieben werden, und da sind die Variablen so oder so nur in der entsprechenden Procedure gültig. Alles andere, was innerhalb des Programms benutzt wird, ist meist Long, und Float nur in bestimmten Fällen. Und das $ am Ende eines Stringnamens ist eh fast Pflicht, vor allem wenn man an der "guten Basic-Syntax" so festhält

das mit dem = und dem == stimmt schon. vergleich und zuweisung sind doch zwei völlig verschiedene sachen, wieso das gleiche zeichen? mir macht es zwar absolut keine umstände, würde aber gerne mal wissen warum das so geregelt wurde. hat das irgendwelche gründe im compilerbau?
in mathe schreibt sich die zuweisung ja := glaub ich. find' ich auch unschön, aber = ..ist doch quark. dann lieber a<13 oder a:13, ach was weiß ich

> hat das irgendwelche gründe im compilerbau?

nein. ursprünglich waren Zuweisung und Prüfung schon durch den Kontext eindeutig definiert.
in den ersten Basic-Varianten musste ein "Set" vor jeglicher zuweisung stehen. auch heute ist es in Basic noch so, dass eigentlich eine Zuweisung
nicht im Kontext einer Prüfung stehen kann und umgekehrt.

aber in C geht das, und deshalb wurde es nötig, zwei unterschiedliche Zeichen zubenutzen.
mal etwas herausgerissen aus dem zusammenhang: nur wenn die erste bedingung TRUE ist, wird die Zweite bearbeitet.
bei nem OR nur dann, wenn die erste False ist, der Ausdruck wird solange ausgewertet,
bis ein eindeutiges ergebnis vorliegt, dann bleibt der Rest unbearbeitet.
die Zweite ist aber eine Zuweisung, und ist damit immer True,
verändert also den Boolwert nicht, wird aber nur dann ausgeführt,
wenn die erste bedingung zutrifft.
klar, das hier ist unnütz, aber man kann damit wirklich abenteuerliche konstrukte bauen,
dass eine routine unter verschiedensten bedingungen ausgeführt wird,
aber ettliche Flags komplett andere werte haben, je nachdem, welche der verschachtelten Bedingungen zur ausführung führte.

PS:
und DAS ist eines der dinge, die C ausmachen.
wer das nicht kann, kann auch BASIC nehmen.

Hier das versprochene Beispiel für unleserlichen C-Code:
Das Programm berechnet Pi mit einer doch ganz guten Genauigkeit.

Kaeru Gaman hat geschrieben:> hat das irgendwelche gründe im compilerbau?

nein. ursprünglich waren Zuweisung und Prüfung schon durch den Kontext eindeutig definiert.
in den ersten Basic-Varianten musste ein "Set" vor jeglicher zuweisung stehen.

Code: Alles auswählen

Set A = 10
Set B = B+1

Ursprünglich war es ein LET