P
Bashar schrieb:
Das wär dann glaub ich einzigartig in der C++-Syntax. Bei a+++b gibt es übrigens keine Mehrdeutigkeit, da der lexikalische Scanner "greedy" arbeitet, d.h. er würde a ++ + b erkennen.
Stimmt, bei C++ findet die Zerlegung in Tokens vor der syntaktischen Analyse statt.
"*" als Postfix-Address-Of-Operator wuerde halt in einigen Faellen eine Klammerung erfordern.
Aber wir sprachen ja von neuen Programmiersprachen, nicht C++, C++ ist ja bereits festgelegt.
"@" als Address-Of-Operator waere auch nicht schlecht, besser als "&", da "@" im Englischen als "at" gelesen wird und "&" als "and".
Vor allem besitzt "@" in C-aehnlichen Sprachen keinerlei Verwendung. Wahrscheinlich gab's auf den Tastaturen der C-Entwickler kein "@", so dass sie diese Syntax aus BCPL nicht uebernehmen konnten.
Ein Problem haben C-aehnliche Sprachen allerdings durch die Unterscheidung der Gross-/Kleinschreibung, da es dies schwierig macht, C Programme auf Rechnern zu verwenden, die keine Kleinbuchstaben haben. Der Zeichensatz von BCPL ging nur von Grossbuchstaben aus, erlaubte aber auch Kleinbuchstaben fuer Schluesselwoerter und Bezeichner, so dass die Gross/Klein-Schreibung egal war.
Digraph-, Trigraph-Sequenzen und alternative Tokens zeugen aber von Bemuehungen des Standard-Konsortiums, eingeschraenkte Zeichensaetze zu unterstuetzen.
C-aehnliche Sprachen (und auch BCPL) sind sehr kurz notierbar, was in anderen Sprachen lange nicht so einfach ist.
Mann koennte ja
DEFINE a AS POINTER TO integer;
a DEREFERENCED := 7;
schreiben, aber das wuerde Ex-C-Programmierer in den sicheren Wahnsinn treiben!
