Was passiert genau, wenn ich einen Point mit NULL initialisiere?

zeusosc

Decimad schrieb:

zeusosc schrieb:

Tachyon schrieb:

Du bist bestimmt auch einer von den Kandidaten die meinen, rohe Arrays sind schneller als ein vector, was?

War zwar nicht an mich gerichtet, aber ich werde trozdem mal darauf antworten.
Ja.

Iterator in/decrement ist prinzipiell ein paar cyclen langsamer, da eine addy inc/dec (in form eines pointers) meistens inline sind.

Hrmmm?

Was ist daran unverständlich?

Decimad schrieb:

zeusosc schrieb:

Gerade da kann man sehen was die Ctor/Dtor calls eigentlich an performance kosten.

Woran? Ich sehe es daran nicht.

Ich wiederhole: Wegen der Initialisierung der member und sicherheitsmechanismen. Guckt dir mall den Callstack an. Da wirst du die benötigten aufrufe, sprünge etc sehen.

Decimad schrieb:

zeusosc schrieb:

Verzichtet man zusätzlich auf einen vector und allociert , nicht reallociert, und befreit einen Speicherbereich innerhalb der Schleife, so bekommt man noch einen zusätzlichen performance schub. (<-- realloc ist langsamer, da bei vergrößerung des speicherbereiches erst geguckt wird ob genügen "zusätzlicher" speicher vorhanden ist, oder ein weiter block frei ist mit genügen speicher, dann den speicher vom alten in den neuen block kopiert.)

Realloc ist vor allem deshalb langsamer, weil der alte Speicherbereich in den neuen kopiert werden muss.

Ich habe den verdacht das Du meinen Text nur überfliegst. Das habe ich doch geschrieben oder nicht?

Decimad schrieb:

zeusosc schrieb:

std::vector aus der stl ist kein schlechtes object und zahlreich handoptimiert sowie für viele einsatzgebiete anwendbar, vlt. sogar empfehlenswert. Aber in vielen Fällen fehlverwendet, was zu Performance einbussen von mehreren 100 000-en cyclen bedeutet.

Weil man halt alles nur dafür verwenden sollte, wofür es designed wurde? Es sei denn, es geht darum fix was zusammenzuflicken...

Ich sehe du verstehst was ich meine...

grüße

Tachyon

Ich weiß ja nicht, was Du da mit dem vector so treibst, aber bei mir bleibt im Realeasemode nichts mehr von dem Sicherheitsmechanismen übrig. Und die Iteratoren werden zu normalen Zeigern.

Ecke schrieb:

So'n Quatsch.

Ja quatsch hast du hier tatsächlich eine Menge zusammen getragen.

Ecke schrieb:

Die Größe eines Vektors ist ein Integraler Bestandteil seines Interfaces. Wie sonst sollst du über alle Elemente eine Vektors iterieren, wenn du seine Größe nicht kennst?

Ich sehe du hast keine Ahnung worum es geht, aber erlaubst es dir dich ziemlich weit aus dem Fenster zu lehnen.

Ecke schrieb:

Das ist bei Arrays auch nicht anders. Du musst irgendwie die Anzahl der Elemente im Array kennen, sonst kannst du nicht darüber iterieren. Bei mit new angelegten Arrays musst du die Größe explizit speichern, bei Arrays auf dem Stack geht es evtl. noch über sizeof(), solange das Array noch nicht zu einem Pointer zerfallen ist.

Also wieder: Dieses "zusätzliche" Attribut ist gar nicht zusätzlich, da du in jedem Fall bräuchtest.

Spätestens als ich realloc geschrieben habe, hättest du hellhörig werden sollen.

Btw. Was soll das sein, ein Array zu einem Pointer zerfallen? Du kannst maximal ein Zeiger auf ein Array haben, aber ein Array ist kein Zeiger und wird auch keiner.

-Shelling-

Darf ich mir hier kurz die Frage erlauben, warum hier ein dynamisches Array in Form von std::vector mit einem statischem Array verglichen wird? Sollte man da zum Ausgleich nicht lieber std::tr1::array als Vergleich nehmen?

Btw. Was soll das sein, ein Array zu einem Pointer zerfallen? Du kannst maximal ein Zeiger auf ein Array haben, aber ein Array ist kein Zeiger und wird auch keiner.

Ich glaube, genau dass meint er. Also das ein Pointer auf ein Array gerichtet wird.

Zeus

Paul Müller schrieb:

Zeus schrieb:

Hast du eh kein Einfluß mehr, darüber entscheidet der Compiler für sich alleine. Höchstens als Hinweis.

Ich weiß. Und dein Hinweis bekräftigt nur meine Aussage, ich hoffe das ist dir aufgefallen.

Langsam weiß ich nicht, ob ich mit ein Troll oder mit einen der schwer vom Begriff ist.
Ich versuchs trotzdem noch einmal.
Wie kann dein Argument ein Gegenargument wegen den Abstraktionkosten sein, wenn die Fähigkeit zu Inline ausschließlich bei der Implementierung des Kompiler und der Runtime liegt. Die Abstraktion hast du im Code, nicht in der Übersetzung.

Sehen wir uns im konrekten Fall vom MS Visual C++ Kompiler an:

Even with __forceinline, the compiler cannot inline code in all circumstances. The compiler cannot inline a function if:

* The function or its caller is compiled with /Ob0 (the default option for debug builds).
* The function and the caller use different types of exception handling (C++ exception handling in one, structured exception handling in the other).
* The function has a variable argument list.
* The function uses inline assembly, unless compiled with /Og, /Ox, /O1, or /O2.
* The function is recursive and not accompanied by #pragma inline_recursion(on). With the pragma, recursive functions are inlined to a default depth of 16 calls. To reduce the inlining depth, use inline_depth pragma.
* The function is virtual and is called virtually. Direct calls to virtual functions can be inlined.
* The program takes the address of the function and the call is made via the pointer to the function. Direct calls to functions that have had their address taken can be inlined.
* The function is also marked with the naked __declspec modifier.

Zeus schrieb:

Langsam weiß ich nicht, ob ich mit ein Troll oder mit einen der schwer vom Begriff ist.

Ich würde eher behaupten, dass du nur die Hälfte liest und dir deswegen völlig unnötig die ganze Arbeit machst. Ich weiß was inline macht, wann es angewendet wird und wann nicht. Aber du scheinst einen wichtigen Punkt immer wieder zu überlesen, obwohl ich ihn schon mehrmals hervorgehoben habe.

SeppJ schrieb:

du brauchst bloß ein Gegenbeispiel zu zeigen, bei dem eine (natürlich nicht absichtlich schlecht programmierte) Klasse auch nur einen Maschinenbefehl mehr benötigt als ein vergleichbarer Code ohne Klasse.

Ich extrahiere mal die wichtigen Informationen für dich:
[] auch nur einen Maschinenbefehl mehr
[] als ein vergleichbarer Code ohne Klasse

Den ersten Punkt können wir gerne aufweichen. Fakt ist aber, wenn der Compiler nicht inlinen kann, dann muss er die Argumente auf den Stack pushen und die Funktion anspringen, ausführen, zurück springen und irgendwann noch den Stack wieder aufräumen. Ich denke du kannst mir folgen. Die Idee ist aber die Lösung ohne Abstraktion definitiv zu "inlinen". Wir müssen also kein Stack pushen und popen und wir müssen nicht zur Funktion springen und wieder zurück springen. Es sollte klar sein, dass weniger Aufwand, weniger Zeit bedeutet.

SeppJ

Ich mach hier mal zu. Die Argumente wurden alle genannt, jetzt dreht sich die Diskussion im Kreis. Deshalb kommen in diesem Beitrag auch keine Fachargumente mehr, sondern ich verweise auf alles was bisher geschrieben wurde.

@Paul Müller: Du denkst jetzt sicherlich, dass ich dies mache um eine unangenehme Wahrheit zu unterdrücken. Ich schreibe kurz noch einen kurzen Text, warum ich zumache, den du nicht einsehen wirst, aber in ein paar Jahren wirst du es vielleicht verstehen:

Dies ist ein Hilfeforum in dem Fragen beantwortet werden. Falsche Aussagen kann man natürlich auch nicht stehen lassen und deine Behauptung wurde korrigiert und sogar tatkräftig widerlegt. Damit sollte sich das Thema eigentlich erledigt haben. Ob du es einsiehst oder nicht ist deine Sache. Man argumentiert nur noch mit dir, weil man dich nicht dumm sterben lassen will. Ich habe den Eindruck du hängst dich nur rein, weil du irgendwie den Thread gewinnen willst. Hier ist eine große Weisheit: Entgegen anders lautender Gerüchte kann man das Internet nicht gewinnen!
Jetzt da "Gewinnen" in diesem Thread aufgrund der Schließung unmöglich ist, kannst du ihn dir ja noch einmal in Ruhe durchlesen, ohne krampfhaft Recht haben zu müssen. Dies ist ein doppelter Gefallen für dich: 1. Lernst du vielleicht etwas wichtiges, 2. machst du dich nicht weiter lächerlich. Ich sehe du bist auch in anderen Threads aktiv und versuchst zu helfen, aber wenn du hier so weiter machst, nimmt dich bald niemand mehr ernst. Das Wort Troll ist schon gefallen.
Du argumentierst in diesem Thread allein gegen das gesamte Forum, gegen viele Jahrzehnte gesammelte C++ Erfahrung. Hier haben Leute gepostet die vermutlich länger programmieren als du lebst. Glaubst du, die haben alle unrecht und du allein auf der Welt hast eine spektakuläre Wahrheit gefunden? Ich weiß, es ist gut, Autoritäten in Frage zu stellen. Aber in Frage stellen heißt auch, kritisch darüber nachzudenken, ob der Rest der Menschheit nicht vielleicht doch Recht haben könnte, wenn man alleine dagegen steht.