Unterschiede zu C++ für Umsteiger von Java

net 0

Artchi schrieb:

Hier habe ich eine Wissenslücke: Was ist der '>>>" Operator? (ernste Frage!)

right-shift unter missachtung des vorzeichens (schiebt auch bei negativen zahlen nullen rein).

net 0

Artchi schrieb:

net schrieb:

ich hab noch'n paar nachteile von C++: :xmas2:
* einfache datentypen sind in C++ variabel (länge, byte order usw.).

Hat aber auch seine Vorteile: wenn ich auf einem 256 bit System entwickel, unterstützt mein Compiler höchstwahrscheinlich mit einem long die volle 256 bit Breite.

das kann man nicht unbedingt als vorteil sehen, wenn ein programm plötzlich 80% mehr speicher braucht der einfach nur brach liegt

QarateKid

@Artchi&simon2
Hallo nochmal ich, habe mich jetz ausgiebig mit dem verzicht auf zeiger beschäftigt,
und noch ne frage, wollte nich gleich nochmal nen thread aufmachen:

Kann es sein, daß ein Fall, bei dem man nicht darauf verzichten kann(auf zeiger), ist, wenn man rein abstrakte klassen verwendet?
Oder gibts da auch noch tricks?
Ansonsten nochmal danke für die hinweise, man kommt echt fast vollkommen ohne aus, so ist das viel schöner.
Dummerweise hatte ich halt anfangs meine eigenen container geschrieben und da gabs mit referenzen bissel probs(is mir noch nich ganz klar was genau), aber mit den stl containern läuft das super.
cu

CStoll

QarateKid schrieb:

Kann es sein, daß ein Fall, bei dem man nicht darauf verzichten kann(auf zeiger), ist, wenn man rein abstrakte klassen verwendet?
Oder gibts da auch noch tricks?

Ja, für abstrakte Klassen benötigst du Zeiger (weil sie abstrakt sind, können sie schließlich nicht direkt erzeugt werden). Möglicherweise kann man da auch über Referenzen vorgehen, aber ob das praktikabel ist, ist die andere Frage.

(und generell im Zusammenhang mit Polymorphie sind Zeiger recht hilfreich)

Simon2

QarateKid schrieb:

@Artchi&simon2
...Kann es sein, daß ein Fall, bei dem man nicht darauf verzichten kann(auf zeiger), ist, wenn man rein abstrakte klassen verwendet?...

Wieso ?
Es gibt doch Referenzen:

class A {
   public:
      virtual void f() const  = 0;
      virtual ~A() {}
};

class B : public A {
   int i;
   public:
      B(int li) : i(li) {}
      void f() const { cout << "B::f: " << i << "\n"; }
};

class C : public A {
   string s;
   public:
      C(string ls) : s(ls) {}
      void f() const { cout << "C::f: " << s << "\n"; }
};

void f(A const & a) {
   cout << "f():";
   a.f();
}

int main() {
   B b(1);
   C c("Simon2");

   A& refB = b;
   A& refC = c;

   refB.f();
   refC.f();

   f(refB);
   f(refC);
   return 0;
}

Aber natürlich kannst Du NICHT

A a = B(i); // Fehler: A ist nicht instantiierbar

o.ä. machen.
Beim CallByValue und ReturnByValue wird's natürlich "kribbelig" ... da musst Du evtl. doch manchmal auf Heap-Objekte ausweichen - aber Vieles kann man mit Referenzen (auf Stackobjekte) machen.

Gruß,

Simon2.

Artchi

Also Zeiger brauchst du dann, wenn du sowas machen willst (wenn ich mal Simon2s Klassen benutze):

A *a = new B();

Weil das geht ja nicht:

A a;  // A kann man nicht erzeugen

Ansonsten nochmal danke für die hinweise, man kommt echt fast vollkommen ohne aus, so ist das viel schöner.
Dummerweise hatte ich halt anfangs meine eigenen container geschrieben und da gabs mit referenzen bissel probs(is mir noch nich ganz klar was genau), aber mit den stl containern läuft das super.
cu

Aber du machst doch nicht sowas:

std::vector<A&> a_vec;

Referenzen im Container ist ganz schlecht.

net 0

Artchi schrieb:

Also Zeiger brauchst du dann, wenn du sowas machen willst (wenn ich mal Simon2s Klassen benutze):
A *a = new B();
Weil das geht ja nicht:
A a;  // A kann man nicht erzeugen

so gibt's 'nen pointer nur temporär

A& a = *(new B(1));
   ...
   a.f(); // c++ ist lustig: zugriff ohne pointer

Simon2

Artchi schrieb:

Also Zeiger brauchst du dann, wenn du sowas machen willst (wenn ich mal Simon2s Klassen benutze):
A *a = new B();
Weil das geht ja nicht:
A a;  // A kann man nicht erzeugen

Achja .... und für (die meisten ?) STL-Container auch, weil die ihre Inhalte "rumkopieren" und das geht mit Referenzen nicht, mit Zeigern aber schon.

Gruß,

Simon2.

Simon2

net schrieb:

...
// c++ ist lustig: zugriff ohne pointer
...

...dafür mit Speicherleaks :p

Gruß,

Simon2.

net 0

Simon2 schrieb:

net schrieb:

...
// c++ ist lustig: zugriff ohne pointer
...

...dafür mit Speicherleaks :p

muss nicht. kannt ja 'delete &a' machen...
edit: hab's gerade ausprobiert.
...aber wenn c++ schlau gemacht wär, würde es automatisch nach verlassen des scopes den destruktor aufrufen. macht es aber nicht

LordJaxom

net schrieb:

...aber wenn c++ schlau gemacht wär, würde es automatisch nach verlassen des scopes den destruktor aufrufen. macht es aber nicht

Dann müsste C++ so schlau sein zu ermitteln, ob die Referenz auf ein Heap-Objekt oder auf ein Stack-Objekt zeigt und wenn ersteres, ob noch andere Referenzen drauf zeigen. Dann jedoch sind wir eh wieder bei Java :p

Also ich würde mich beschweren wenn C++ meine Objekte eigenmächtig killt, nur weil irgendwo eine Referenz ihr Leben aushaucht...

Simon2

Naja, spätestens mit const-Refs dürfte damit aber Schluß sein .

net schrieb:

..aber wenn c++ schlau gemacht wär, würde es automatisch nach verlassen des scopes den destruktor aufrufen. macht es aber nicht

Entweder Garbage-Collection oder nicht. So eine Mischform geht eben nicht...

Gruß,

Simon2.

net 0

Simon2 schrieb:

Entweder Garbage-Collection oder nicht. So eine Mischform geht eben nicht...

warum nicht? könnte man doch in C++ einbauen - einen garbage collector nur für 'heap-referenzen' wie: Class &Object=*(new Class()); das wär doch nicht schlecht, der user hätte freie wahl ob er die eingebaute müllverbrennungsanlage benutzen will, oder C++ wie er's bisher kennt... :xmas2:

Artchi

Dann nimm C++/CLI. Oder warte auf C++0x, da wird noch diskutiert, ob es nicht einen optionalen GC geben soll.

net 0

Artchi schrieb:

...warte auf C++0x, da wird noch diskutiert, ob es nicht einen optionalen GC geben soll.

ach, das ist schon im gespräch?
und ich dachte ich muss jetzt 'ne mail an diese standardisierungs-heinis schreiben

CStoll

net schrieb:

warum nicht? könnte man doch in C++ einbauen - einen garbage collector nur für 'heap-referenzen' wie: Class &Object=*(new Class());

Randfrage: Woher weiß das System, ob ich gerade eine Heap-Referenz oder eine Stack-Referenz habe? (wenn ich das direkt aufrufe, kann man das ja noch unterscheiden - aber bei einer Anweisung ala Class& ob = func(); siehst du schon nicht mehr, woher die Referenz kommt)

net 0

CStoll schrieb:

net schrieb:

warum nicht? könnte man doch in C++ einbauen - einen garbage collector nur für 'heap-referenzen' wie: Class &Object=*(new Class());

Randfrage: Woher weiß das System, ob ich gerade eine Heap-Referenz oder eine Stack-Referenz habe? (wenn ich das direkt aufrufe, kann man das ja noch unterscheiden - aber bei einer Anweisung ala Class& ob = func(); siehst du schon nicht mehr, woher die Referenz kommt)

klar, solche 'gc-aware' referenzen müssten schon eindeutig für's system sein (man könnte ein neues schlüsselwort dafür erfinden z.b. create statt new).
auch müsste man sicherstellen, dass ein versehentliches 'delete' keine negativen auswirkungen hat... :xmas2:

Artchi

In C++/CLI gibts gcnew als Schlüsselwort, damit in einer Compile-Einheit zwischen verwalteten und nicht verwalteten Code unterscheiden kann:

Class^ o = gcnew Class(); // GC räumt es nachher weg.
Class* o2 = new Class(); // Auf dem Heap.

Wenn ein GC in C++ rein kommt, wird man sich bestimmt an C++/CLI orientieren. Da Herb Sutter der Designer von C++/CLI ist und reinzufällig den C++ Komitee Vorsitz inne hat.

auch müsste man sicherstellen, dass ein versehentliches 'delete' keine negativen auswirkungen hat...

Wieso? In C++/CLI ist z.B. gerade der Clou das ich auch verwaltete Objekte explizit selbst mit delete zerstören darf. Ist ja alles nur einer Frage des Designs. Dann gibts auch keine Probleme.

net 0

Artchi schrieb:

auch müsste man sicherstellen, dass ein versehentliches 'delete' keine negativen auswirkungen hat...

Wieso? In C++/CLI ist z.B. gerade der Clou das ich auch verwaltete Objekte explizit selbst mit delete zerstören darf. Ist ja alles nur einer Frage des Designs. Dann gibts auch keine Probleme.

das finde ich schlecht. wenn man die objektlebensdauer selber bestimmen will, dann sollte man die herkömmliche new/delete-logik anwenden. manuelles löschen von GC-verwalteten objekten provoziert doch nur übelste bugs. ich würde beides getrennt halten.

net schrieb:

wenn man die objektlebensdauer selber bestimmen will, dann sollte man die herkömmliche new/delete-logik anwenden. manuelles löschen von GC-verwalteten objekten provoziert doch nur übelste bugs. ich würde beides getrennt halten.

Richtig. In C++/CLI ruft der delete-Operator bei GC-verwalteten Objekten einfach nur die Dispose Methode auf; die Freigabe des Speichers solcher Objekte bleibt Aufgabe des Garbage-Collectors.

<a href= schrieb:

msdn">There is no equivalent function to the C++ delete operator for the CLR.
...
It is, however, illegal to use the delete operator with such a managed, or garbage collected, pointer.
...
In C# you can call the Dispose method directly, or use a using statement just as if the type were defined in C#; but what about C++? How do you normally call the destructor of a heap based object? By using the delete operator, of course! Applying the delete operator to a handle will call the object's Dispose method. Recall that the object's memory is managed by the garbage collector. We are not concerned about freeing that memory, but only about freeing the resources the object contains.