<< und <<

[Raptor]

Wie haengen der Operator << von

cout <<

und der Operator << von

int i=2;
i << 2; //i==8

zusammen?
Es ist ja irgendwie die selbe Syntax

[DrGreenthumb]

man kann in c++ operatoren überladen, also selbst bestimmen was passiert wenn der operator (in diesem fall <<) aufgerufen wird.

[Raptor]

Das habe ich mir gedacht.....
Das hiesse ja aber, das dem Operator<< ein neuer semantischer Sinn aufgedichtet wurde und ueberall steht geschrieben das man keine neuen Operatoren "erfinden" soll.

[leech]

die zahl 2 = 00000010
die zahl 8 = 00001000

<< schiebt also bitweise nach links...

[operator void]

Also, wenn du etwas so Weitreichendes wie die IOStreams schreibst darfst du es dir schon überlegen. Für jeden Kleinkram aus Schreibfaulheit oder Spieltrieb Operatoren zu überladen gilt als verpönt.

Davon abgesehen hat natürlich niemand gesagt, dass die IOStreams perfekt designt sind. Im Zweifelsfall geht eigenes Ermessen vor Mitläufertum

[Michael E.]

Ich weiß nicht, wo das Problem ist. operator* hat auch mehrere Bedeutungen:

- Pointer deklarieren
- Pointer dereferenzieren (aber nicht zum Adressennehmen, sonst wärs ja zu einfach :p )
- multiplizieren

[finix]

Michael E. schrieb:

(aber nicht zum Adressennehmen, sonst wärs ja zu einfach :p )

Genau. Lieber einfache Syntax statt an die Adressen von Pointern kommen zu können

[Bashar]

die iostream-Library wurde AFAIK 1985 geschrieben, da gabs Effective C++ noch nicht

[Power Off]

Michael E. schrieb:

- Pointer dereferenzieren (aber nicht zum Adressennehmen, sonst wärs ja zu einfach :p )

Die unterschiedliche Schreibweise stammt noch aus BCPL: "!" zum dereferenzieren, "@" zum Adressennehmen, da in BCPL alles ein Pointer sein konnte, ging es nicht anders.

Theoretisch haette man "*" auch zum Adressennehmen in C verwenden koennen, aber wie bereits gesagt wurde, wuerde sich dann die Frage stellen, wie man die Adresse eines Pointers nimmt. Dann haette man fuer die Pointerdereferenzierung eine andere Syntax nehmen muessen (z.B. "^" wie in Pascal).

Das haette dann so ausgesehen:

int b = 5;
int *a = *b;
^a = 7;

Ist nicht weniger verwirrend als die C-Syntax.

Mit einer Postfix-Notation des "*"-Operators haette man es allerdings loesen koennen:

int b = 5;
int* a = b*;  /* postfix notation: address-of */
*a = 7;       /* infix notation: dereference */

Dann waere "&" als Address-of-Operator weggefallen, und "*" haette eine zusaetzliche Bedeutung bekommen.

Fuer den Compiler ist es ja kein Problem, festzustellen, ob ein "*" nach einem Ausdruck geschrieben wird.

address-of-expr := addressable-expr "*" .

Den Vorschlag koennte man beim Design einer neuen Programmiersprache mit einbeziehen.

[Bashar]

Was heißt dann folgendes Fragment:

b*-1

[Power Off]

Bashar schrieb:

Was heißt dann folgendes Fragment:

b*-1

Gute Frage!!

Eventuell muesste man die Klammerung vorschreiben (aehnlich wie bei "a+++b" ):

(b)*(-1)
(b*)-1

[Bashar]

Power Off schrieb:

Eventuell muesste man die Klammerung vorschreiben (aehnlich wie bei "a+++b" ):

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.

[Power Off]

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!