NULL

audacia

Nein; = delete legt fest, daß die entsprechende Methode nicht benutzt werden darf. Das ist ein Workaround für den Designfehler, daß für Klassen standardmäßig ein Defaultkonstruktor, ein Kopierkonstruktor und ein Zuweisungsoperator generiert wird.

Entsprechend soll es = default; geben, das explizit die Default-Version anfordert.

Edit: Typographie.

audacia schrieb:

Nein; = delete legt fest, daß die entsprechende Methode nicht benutzt werden darf. Das ist ein Workaround für den Designfehler, daß für Klasse standardmäßig ein Defaultkonstruktor, ein Kopierkonstruktor und ein Zuweisungsoperator generiert wird.
Entsprechend soll es = default; geben, das explizit die Default-Version anfordert.

aha, ich hab's auch grad selbst gelesen: http://en.wikipedia.org/wiki/C%2B%2B0x
ich persönlich hätte ja ein paar #pragmas für sowas definiert, aber egal. C++ soll wohl das chinesich unter den programmiersprachen werden. bestimmt läuft's APL bald den rang ab.

Tachyon

+fricky schrieb:

[ich persönlich hätte ja ein paar #pragmas für sowas definiert, aber egal. C++ soll wohl das chinesich unter den programmiersprachen werden. bestimmt läuft's APL bald den rang ab.

Aber #pragmas sind allgemein für irgendwelche compilerspezifischen Dinge gedacht. Das Gedöhns mit dem delete und default Hokus-Pokus soll aber standardisiert sein.

Tachyon schrieb:

+fricky schrieb:

[ich persönlich hätte ja ein paar #pragmas für sowas definiert, aber egal. C++ soll wohl das chinesich unter den programmiersprachen werden. bestimmt läuft's APL bald den rang ab.

Aber #pragmas sind allgemein für irgendwelche compilerspezifischen Dinge gedacht. Das Gedöhns mit dem delete und default Hokus-Pokus soll aber standardisiert sein.

ok, aber ein paar spezielle #pragmas könnte man ja standardisieren. spricht doch nichts dagegen, wie so'ne metasprache, um gewisse features ein- und auszuschalten. es hätte z.b. den vorteil, dass der code noch von älteren compilern verstanden würde. die würden unbekannte pragmas einfach ignorieren (und hätten eben diese features nicht zur verfügung).

ja ich weiss auch nicht was das hersoll. ich komme schon mit den ganzen cast dingen in c++ nicht klar! ich brauch doch nicht den compiler der mir sagt was ich darf und was nicht. ich bin der programmierer ich weiss es selbst!!das stört mich in c++ im vgl zu c so. ständig motzt der compiler wegen irgendwelchen illegal cast static_cast reinterpret_cast etc der ganze schwachsinn!

c++hater schrieb:

ich komme schon mit den ganzen cast dingen in c++ nicht klar!

Es gibt auch nix zu casten.

c++möger schrieb:

c++hater schrieb:

ich komme schon mit den ganzen cast dingen in c++ nicht klar!

Es gibt auch nix zu casten.

wozu gibts des dann alles? das ist alles unnötig. ich weiss als programmierer ja selbst was ich darf und was nicht...bzw wenn ich es ned weiss muss ich wohl c++ benutzen. naja jedem das seine.

die Typisierung ist dazu da, mehr Fehler schon zur Compilezeit zu erkennen, damit zur Laufzeit weniger schief geht - also letztendlich, den Programmierer vor seiner eigenen Schusseligkeit zu schützen. Dem selben Zweck dient letztendlich auch OOP. Ein Programmierer mit IQ 160+ und ausgeprägtem Kurzzeitgedächtnis könnte wohl auch ohne Typprüfung und ohne OOP fehlerfrei laufende, riesige Softwaresysteme mit 1e6+ Zeilen schreiben. Dem Durchschnittsprogrammierer mit IQ < 160 muß der Compiler aber nunmal etwas mehr auf die Finger schauen.

u_ser-l schrieb:

die Typisierung ist dazu da, mehr Fehler schon zur Compilezeit zu erkennen, damit zur Laufzeit weniger schief geht

Allerdings führen Compilezeitfehler niemals zu Laufzeitfehlern.

naja hab ich ned nötig. aber wers braucht..

c++magic schrieb:

Allerdings führen Compilezeitfehler niemals zu Laufzeitfehlern.

natürlich nicht - wird ja kein exe erzeugt.

*john 0

c++hater schrieb:

ständig motzt der compiler wegen irgendwelchen illegal cast static_cast reinterpret_cast etc der ganze schwachsinn!

Das zeigt doch eindeutig, daß Du Schrott zusammenschreibst. In C++ gibt es kaum Gründe überhaupt einen Cast zu nutzen, in seltenen Fällen braucht man mal dynamic_cast. Die restlichen Casts braucht man nur im Zusammenspiel mit der Altlast C, oder wenn man Designfehler ausbügeln muß.

~john schrieb:

In C++ gibt es kaum Gründe überhaupt einen Cast zu nutzen, in seltenen Fällen braucht man mal dynamic_cast. Die restlichen Casts braucht man nur im Zusammenspiel mit der Altlast C...

in einem gut gemachten C-programm wird auch selten bis nie gecastet. das muss an was anderem liegen. übrigens ist diese 'altlast' ein grosser bestandteil von C++. oder glaubst du etwa, irgendwelche saboteure waren am werk, die C++ mit C-syntax vergiftet haben?

~john schrieb:

...oder wenn man Designfehler ausbügeln muß.

den begriff 'designfehler' hört man sehr oft im zusammenhang mit C++. woran liegt das eigentlich?

volkard

+fricky schrieb:

den begriff 'designfehler' hört man sehr oft im zusammenhang mit C++. woran liegt das eigentlich?

woanders bemerkst du es nicht, weil z.B. java die fehler als feature verkauft.

volkard schrieb:

...weil z.B. java die fehler als feature verkauft.

hast du ein beispiel?

volkard

+fricky schrieb:

volkard schrieb:

...weil z.B. java die fehler als feature verkauft.

hast du ein beispiel?

klar. sehr laut waren immer die schreier, die schien, daß java niemals operator overloading haben dürfe, weil es den code total unlesbar macht.

DEvent

volkard schrieb:

+fricky schrieb:

volkard schrieb:

...weil z.B. java die fehler als feature verkauft.

hast du ein beispiel?

klar. sehr laut waren immer die schreier, die schien, daß java niemals operator overloading haben dürfe, weil es den code total unlesbar macht.

Wieso ist es ein Fehler keine op. overloading zu haben? Nun wird zwar deine nachste mathematische API eben ein wenig komplizierter zu benutzen sein, ich kann aber gut ohne op. overloading leben.

*john 0

+fricky schrieb:

in einem gut gemachten C-programm wird auch selten bis nie gecastet.

Kein Wunder C kennt keine strenge Typisierung.

+fricky schrieb:

das muss an was anderem liegen. übrigens ist diese 'altlast' ein grosser bestandteil von C++.

Leider - es verkompliziert die Sprache und die Compiler nur, und bringt nur etwas, wenn man C-Header für das Linken von C-Objektmodule braucht. In normalen C++ Code braucht man die Altlasten nun wirklich nicht mehr.

volkard schrieb:

sehr laut waren immer die schreier, die schien, daß java niemals operator overloading haben dürfe, weil es den code total unlesbar macht.

ja, ist schon ein echter schwachpunkt, dass diese starke source code encryption technologie allen java codern verwehrt ist. dann könnte java eindlich so'nen stream-input shiftoperator einführen, wie z.b. C++'s <<, der seine operanden nach belieben verwurschteln kann. noch irgendwas? pointer und mehrfachvererbung vielleicht?

Kein Wunder C kennt keine strenge Typisierung.

C++ aber auch nicht, hat's alles von C übernommen, bis auf die kleine ausnahme mit dem void*

+fricky schrieb:

noch irgendwas? pointer und mehrfachvererbung vielleicht?

Java hat doch Pointer, nur keine Pointerarithmetik. Oder lässt du dich von Sun's Naming-Convention irre leiten, welche diese Pointer als References bezeichnet?

Kein Wunder C kennt keine strenge Typisierung.

C++ aber auch nicht, hat's alles von C übernommen, bis auf die kleine ausnahme mit dem void*
:)[/quote]
Haha, der war gut