Diskussion:C++-Programmierung: Operatoren

Aus Wikibooks
Zur Navigation springen Zur Suche springen

Die Absätze zu new und delete waren falsch. Die Syntax

Object o = new Object

ist Java, aber kein C++. In C++ arbeiten beide Operatoren mit Zeigern auf das Objekt. Die Namensgebung ist hier auch fraglich, denn prinzipiell sieht die Syntax so aus:

Klassenname* objektname = new Konstruktorname(Parameterliste);

Denn: 1) new liefert als Datentyp die Adresse einer Klasse also Klasse*, 2) Objektname hat den Datentyp Adresse und hinter new steht der Konstruktor, der auch mal einen oder mehrere Parameter haben kann. Viele verwechseln das mit dem Klassennamen, weil man bei leerer Pameterliste die () Klammern weglassen kann.

--Micael Hallmann --Nikolai Pretzell

dynamic_cast[Bearbeiten]

Bei einem dynamic_cast muss in den spitzen Klammern der Zieltyp stehen. Folgender Text war also falsch:

Derived *dptr1 = dynamic_cast<Base*>(bptr1);
Derived *dptr2 = dynamic_cast<Base*>(bptr2);

Außerdem habe ich noch ein Beispiel für dynamic_cast mit Referenzen geschrieben und dementsprechend den Text geändert.

--Cg909 13:57, 11. Jul 2006 (UTC)

Unäres Plus[Bearbeiten]

Aus dem Artikel:

Dient zur expliziten Angabe des Vorzeichen. Da aber Zahlen ohne explizites Vorzeichen positiv sind, kann dieser Operator immer weggelassen werden.

Das ist nicht ganz richtig. Zwar ändert das unäre Plus nicht den Wert, allerdings zuweilen den Typ:

#include <iostream>
#include <ostream>

enum foo { zero, one, two };

void f(int) { std::cout << "int\n"; }
void f(short) { std::cout << "short\n"; }
void f(foo) { std::cout << "foo\n"; }

int main()
{
  short a = 0;
  f(a);
  f(+a);
  foo b = zero;
  f(b);
  f(+b);
}

ergibt

short
int
foo
int

Leider ist nicht klar, an welche Stelle dieser Artikel soll (also vor oder nach der Behandlung von Typen; momentan ist er von nirgendwo verlinkt), insofern ist nicht klar, ob es sinnvoll ist, das an dieser Stelle zu erwähnen. Jedenfalls ist die Aussage, dass man es immer weglassen könne, nicht richtig; unter bestimmten Umständen kann das entfernen des unären + aus einem korrekten Programm ein fehlerhaftes machen. Beispiel:

enum Wochentag { Montag, Dienstag, Mittwoch, Donnerstag, Freitag, Samstag, Sonntag };
Wochentag operator+(Wochentag t, unsigned diff)
{
  return Wochentag((+t + diff)%7);
}

Entfernt man hier das unäre Plus vor dem t, ergibt sich eine unendliche Rekursion. --Ce 20:14, 3. Sep. 2007 (CEST)Beantworten[Beantworten]

Außerdem kann ein unäres Plus auch für eigene Datentypen überladen werden und kann dort Aktionen auslösen, so dass es nicht mehr weggelassen werden kann. Ein Beispiel ist die Parser-Bibliothek boost::spirit.

&& und ||[Bearbeiten]

Die so genannte "short circuit evaluation" gilt nur, wenn beide Operanden fundamentale Datentypen sind. Denn sonst könnten benutzerdefinierten Operatoren im Spiel sein, für die diese abgekürzte Auswertung nicht gilt. --RokerHRO 03:49, 23. Feb. 2008 (CET)Beantworten[Beantworten]

Das Token :: ist kein Operator im eigentlichen Sinne, es hat hier daher nichts zu suchen. Wäre :: ein Operator, würde man ihn klammern können. So kann man zwar A::B::C schreiben, aber (A::B)::C ist etwas anderes, nämlich eine (C-Style-)Typumwandlung von ::C in den Typen (A::B), und A::(B::C) ist ein Syntaxfehler. --RokerHRO 03:52, 23. Feb. 2008 (CET)Beantworten[Beantworten]

Plattformabhängigkeiten bei Shift-Operationen[Bearbeiten]

Es sollte erwähnt werden, dass bei den Bitshift-Operationen überaschende/unerwartete Plattformabhängikeiten auftreten:

  • unsigned u = 1 << 32; // ist 1 auf Intel-CPUs. Die 1 wird also nicht aus dem Register "rausgeschoben"
  • unsigned u = 1 << 33; // na, wer kommt drauf, ohne es auszuprobieren?
  • int i = -1 >> 3; // plattformabhängig!
  • int i = 1 << 31; // plattformabhängig!
  • int i = 1234 >> -1; // plattformabhängig!

Es gibt da noch ein paar mehr garstige Fälle. --RokerHRO 03:57, 23. Feb. 2008 (CET)Beantworten[Beantworten]