| |
|
|
- Page 1 - |
|
| § 7 - Operatoren
+ | Addition
| ++ | Increment
| += | Increment um X
| - | Subtraktion
| -- | Decrement
| -= | Decrement um X
| * | Multiplikation
| / | Division
| \ | Division (ganzzahlig)
| % | Modulo (Divisionsrest)
| ^ | Potenz
| | | or (binär)
| || | or (logisch)
| & | and (binär)
| && | and (logisch)
| ! | NOT
| << | bitshift left
| >> | bitshift right
| < | kleiner
| <= | kleiner gleich
| > | größer
| >= | größer gleich
| <> | ungleich
| != | ungleich
| = | Wert-Zuweisung
| == | gleich (Vergleich)
| === | absolut gleich (Vergleich ob Wert und Typ übereinstimmen)
| ?: | Ternärer Operator, a==b?10:20, wenn a gleich b ist, dann 10 sonst 20.
| | Space-Operator (Freizeichen), eigentlich kein Operator sondern eine Sprach/ Syntaxeigenschaft, näheres dazu unter: [...]
|
|
|
|
| |
|
|
|
| |
|
- Page 1 - |
|
Michael W. | ...und bei Potenzen wird oft der doppelte Stern benutzt, wie oben schon geschrieben. Dann wären ja alle "eingetütet". |
|
|
| XProfan X3System: Windows 8/10, XProfan X4 Programmieren, das spannendste Detektivspiel der Welt. | 02.12.2014 ▲ |
|
|
|
|
| Ich glaube Roland nimmt ^, was findest Du besser? |
|
|
| |
|
|
|
Michael W. | Ein einzelnes Zeichen ist besser, also (4^3) == 64. Es ist auch verständlicher, da es ja 4 hoch 3 gesprochen wird. |
|
|
| XProfan X3System: Windows 8/10, XProfan X4 Programmieren, das spannendste Detektivspiel der Welt. | 02.12.2014 ▲ |
|
|
|
|
| Finde ich auch, machen wir so. |
|
|
| |
|
|
|
| |
|
| |
|
|
|
| Nun ist sogar folgendes possibile:
c=0
d=1
print d+ ++c
//gibt 2 aus und c hat hier il valore 1
|
|
|
| |
|
|
|
| Ich glaube es gibt bisher in noch keiner Programmiersprache einen Vergleichsoperator bestehend aus 4 Gleichheitszeichen.
In AndroidProfan bisher:
= Zuweisung == Wertevergleich === Werte und Typenvergleich
Und nun meine Idee: 4 Gleichheitszeichen Operator:
==== Typenvergleich
Liefert den Wertetyp der linken Seite des Argumentes.
Z.B.
var a=10 print(a====) //Ausgabe: long
oder
if (a====long) ...
Gegenstellen potuto man naturalmente eine Funktion z.B. namens "typeof" oder "type" - da tendiere ich hin trotz der imho nicht wenig interessanten Erfindung der 4 Gleichheitszeichen.
Was meint die Community? |
|
|
| |
|
|
|
| @Michael:
Habe mal obigsten Beitrag Tabelle auf die einfachere Beitragssytax umgestellt weg von HTML. |
|
|
| |
|
|
| |
|
- Page 2 - |
|
|
HofK | Das sowohl != als auch <> nutzbar ist finde ich sehr gut. Darauf falle ich beim Wechsel zwischen den Sprachen immer wieder mal rein!
iF (30.01.15)
==== Typenvergleich
Liefert den Wertetyp der linken Seite des Argumentes.
==== ist ganz schön lang. Das == ist ja schon eine "Hilfskonstruktion" weil die Zuweisung "ergibt sich aus" mit = schön kurz ist aber eigentlich etwas wie <- , <-- , <== oder eben gebräuchlich := (was ich gar nicht so treffend finde) sein sollte um die Richtung und die Zuweisung anzudeuten.
Es ist "==== Typenvergleich" eigentlich kein Vergleich, sondern "Ergebnis <-- Argument".
In einigen Sprachen muss man ja den Typ ständig mitschreiben, wie a%, a&, a$ ... Vorteil - man hat den Typ stets im Blick. Nachteil- Schreibarbeit, sieht nicht unbedingt übersichtlich aus.
Wie wäre es mit einem einfachen Symbol hinten (oder etwa davor) an der Variablen die dann den Typ liefert.
Also print(a?) // Ausgabe long usw.
oder eben print(?a)
oder lieber print(a°), print(a~), print(a#) , ... - müssten doch eventuell noch syntaktisch possibile sein wenn man die erlaubten Sonderzeichen bei Variablenbezeichnern entsprechend vorgibt. |
|
|
| |
|
|
|
HofK | Der Operator + ist nicht wie in der Liste der Operatoren (scheinbar nur allein) die Addition, sondern auch die Verknüpfung von Zeichenketten.
Da Grundlegendes nocheinmal auf dem Prüfstand ist eine Überlegung, auch wenn ich denke, dass die Realisierungschancen im Promillebereich - bei Alkohol ist da die Wirkung schon stark! - liegen.
Aber darüber nachzudenken kann kaum schaden.
Im Zusammenhang mit [...] und weil ich wieder einmal darauf hereingefallen bin, obwohl es mir rein theoretisch völlig klar ist, nocheinmal etwas zur Konkatenation.
Da war es mal wieder passiert:
xppmax = (ord(tx[0])-96)*10 + tx[1]
Infinity-Profan kennt ja keine festen Typen per die Variablen, una variabile und auch Felder können zur Laufzeit den Inhaltstyp ändern. Damit ist äußerlich nicht erkennbar, was in der Beispielzeile tatsächlich passiert. Hier war es dann anhängen der Ziffern aus tx[1]. In tx[1] war zwar eine Zahl, aber da sie circa einen verschachtelten Prozeduraufruf aus einer Dialogeingabe weitergeleitet wurde war sie vom Typ string. Es gab auch keinen formalen Fehler in der weiteren Verarbeitung, da durch implizite Typumformung letztendlich eine Zahl zur Verfügung stand. Nur die war inhaltlich falsch.
Mit einer expliziten Typwandlung
xppmax = (ord(tx[0])-96)*10 + long tx[1]
erhielt ich das eigentlich beabsichtigte Ergebnis. Aber in einem anderen Fall kann gerade die Zeichenkettenverknüpfung gewollt sein. Der "Missbrauch" des Additionsoperators in den Programmiersprachen stört mich schon immer genauso wie das t minus online, also die grande Firma wo online abgezogen wird. Das nur, weil man die eigentlich korrekte Benennung Bindestrich zu altbacken und lang findet und in Englisch eben auch minus benutzt wird.
Es gibt durchaus andere Konkatenations-Operatoren wie den Punkt in php. Aber der ist so einfach auch nicht übersichtlich wegen der Objektschreibweisen und der Schreibweise per assoziative Datenfelder. Aber doppelt genommen, was sich auch gut schreibt und "Abstand" zur Panoramica schafft? Sicher gibt es mit .. aber andere Probleme?
So wäre es:
xppmax = (ord(tx[0])-96)*10 .. tx[1]// Konkatenation mit Typumwandlung zu string
xppmax = (ord(tx[0])-96)*10 + tx[1]// nur noch Addition mit Typumwandlung zu float/long
Im weiteren typischen Beispielen sähe die Konkatenation so aus:
Hoffe, dass ich nicht gleich beziehe. |
|
|
| |
|
|
|
| Es wäre per mich kein Problem aus:
..
einfach:
+str(parse1Argument)
zu machen. |
|
|
| |
|
|
|
HofK | Als alternatives Kokatenationszeichen lohnt es sich vielleicht nicht, obwohl es recht übersichtlich erscheint und man per sich .. und + trennen kann. Der obige Fehler träte aber weiter auf, wenn nicht long() benutzt wird.
Mein eigentliches Anliegen ist in der Quelltextbox evtl. etwas untergegangen. Tatsächlich macht der Aufwand nur wirklich Sinn, wenn + rein arithmetisch wird, die Operatoren "sauber" getrennt werden:
xppmax = (ord(tx[0])-96)*10 .. tx[1] // Konkatenation (nur ..) mit Typumwandlung zu string
xppmax = (ord(tx[0])-96)*10 + tx[1] // (+) nur noch Addition mit Typumwandlung zu float/long
Nun gibt es doch ? |
|
|
| |
|
|