Deutsch
Befehlssatz und Hilfe

§ 7 - Operatoren

 
- Seite 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:  [...] 
 
01.12.2014  
 



 
- Seite 1 -



Michael
W.
...und bei Potenzen wird oft der doppelte Stern benutzt, wie oben schon geschrieben. Dann wären ja alle "eingetütet".
 
XProfan X3
System: Windows 8/10, XProfan X4
Programmieren, das spannendste Detektivspiel der Welt.
02.12.2014  
 



Ich glaube Roland nimmt ^, was findest Du besser?
 
02.12.2014  
 




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 X3
System: Windows 8/10, XProfan X4
Programmieren, das spannendste Detektivspiel der Welt.
02.12.2014  
 



Finde ich auch, machen wir so.
 
02.12.2014  
 



Ok, hab ^ eingebaut.
 
04.12.2014  
 



Nun ist sogar folgendes möglich:
c=0
d=1
print d+ ++c
//gibt 2 aus und c hat hier den Wert 1
 
24.01.2015  
 



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 könnte man natürlich 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?
 
30.01.2015  
 



@Michael:

Habe mal obigsten Beitrag Tabelle auf die einfachere Beitragssytax
umgestellt weg von HTML.
 
30.01.2015  
 



 
- Seite 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 möglich sein wenn man die erlaubten Sonderzeichen bei Variablenbezeichnern entsprechend vorgibt.
 
31.01.2015  
 




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 für die Variablen,
eine Variable 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 über 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 große 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 für assoziative Datenfelder. Aber doppelt genommen, was sich auch gut schreibt und "Abstand" zur Übersicht 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:
msg msg.box  txt1 .. txt2 .. txt3 null "OK" null xpypeingabe1// mit extra Leerzeichen
msg msg.box  txt1..txt2..txt3 null "OK" null xpypeingabe1// kompackt
msg msg.box "Bitte notieren: "..plmod..":  "..xpmax.." | "..ypmax null "OK"
trstr=trstr..tr[l][4]..";"..tr[l][1]..";"..tr[l][2]..";"..tr[l][3]..";"..tr[l][0].."\n"

Hoffe, dass ich nicht gleich beziehe.
 
14.12.2015  
 



Es wäre für mich kein Problem aus:

..

einfach:

+str(parse1Argument)

zu machen.
 
14.12.2015  
 




HofK
Als alternatives Kokatenationszeichen lohnt es sich vielleicht nicht, obwohl es recht übersichtlich erscheint und man für 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 ?
 
14.12.2015  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

14.205 Betrachtungen

Unbenanntvor 0 min.
Ernst15.12.2017
maroro25.07.2016
Nico Madysa28.03.2016
HofK23.02.2016
Mehr...

Themeninformationen

Dieses Thema hat 3 Teilnehmer:

iF (10x)
HofK (3x)
Michael W. (3x)


Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie