Unterschied int *pi = new int(100) int *pi = new int[100];



  • siehe Titel.



  • int *pi = new int(100); // Du erzeugst einen int mit dem Wert 100.
    int *pi = new int[100]; // Du erzeugst 100 ints, die irgendwelche Werte haben.
    


  • Egal was der Unterschied ist, du solltest keinen von beiden benutzen (also so, wenn du smart-pointer genommen hättest wär es anders).

    @Gugelmoser: das hätte man fachlicher ausdrücken können. Du allokierst Speicher im Freispeicher für einen integralen Skalar der Größe eines Maschinenworts, und initialisierst ihn mit 0x64 (hälfte falsch) 🤡



  • Hacker schrieb:

    Egal was der Unterschied ist, du solltest keinen von beiden benutzen (also so, wenn du smart-pointer genommen hättest wär es anders).

    Nicht Smartpointer, sondern STL-Container sind die Alternative. Und für einzelne ints ist es eh fast immer sinnvoller, den automatischen Speicher zu benutzen.

    Hacker schrieb:

    @Gugelmoser: das hätte man fachlicher ausdrücken können.

    Findest du das besonders lustig oder musst du einfach erneut beweisen, dass du keine Ahnung hast?



  • Zerhacker schrieb:

    Hacker schrieb:

    Egal was der Unterschied ist, du solltest keinen von beiden benutzen (also so, wenn du smart-pointer genommen hättest wär es anders).

    Nicht Smartpointer, sondern STL-Container sind die Alternative. Und für einzelne ints ist es eh fast immer sinnvoller, den automatischen Speicher zu benutzen.

    Wie unoffensichtlich.
    Wenn er fragt, was der Unterschied ist, sieht man das er es benutzen will. Ich nehme an, er weiß, dass er Stackobjekte vorziehen soll, aber das hier mal ausprobiert; deswegen Smart-Pointer, wenn man allokieren muss.

    Das zweite war ein Witz.



  • Zerhacker schrieb:

    Hacker schrieb:

    Egal was der Unterschied ist, du solltest keinen von beiden benutzen (also so, wenn du smart-pointer genommen hättest wär es anders).

    Nicht Smartpointer, sondern STL-Container sind die Alternative. Und für einzelne ints ist es eh fast immer sinnvoller, den automatischen Speicher zu benutzen.

    Nicht zwingend, new[] kann Sinn machen.

    Wenn ich beispielsweise ein Bild in den Speicher laden möchte, muss ich die paar MB ja auch nicht zuerst alle auf 0 setzen um sie direkt zu überschreiben.



  • Hacker schrieb:

    Wenn er fragt, was der Unterschied ist, sieht man das er es benutzen will.

    Genau... Es gibt ja kaum Anfänger/Java-Umsteiger, die mit dem ein oder anderen Buch von $EVIL_AUTHOR gelernt haben und deshalb std::vector nicht kennen bzw. die Unnötigkeit von new in C++ noch nicht begriffen haben. Da darf man dann ruhig davon ausgehen, dass sie es auch tatsächlich so verwenden wollen.

    Sorry, Hacker: Aber wenn jemand so eine Frage wie die hier stellt, darfst du davon ausgehen, dass er eben NICHT weiß, was er tut, und Gugelmoser hat einfach den Unterschied herausgestellt. Ein Hinweis auf std::vector/Stack wäre sicher nett gewesen, smartpointer sind jedoch voll am Problem vorbei...

    Das zweite war ein Witz.

    Hohoho, ich kugel mich noch immer am Boden 🙄
    Von anderen deiner Beiträge weiß man, dass solche Statements durchaus ernst gemeint sind (außer du bist der immer lustige, ständig witzelnde Nerd)...



  • arghonaut schrieb:

    Sorry, Hacker: Aber wenn jemand so eine Frage wie die hier stellt, darfst du davon ausgehen, dass er eben NICHT weiß, was er tut, und Gugelmoser hat einfach den Unterschied herausgestellt. Ein Hinweis auf std::vector/Stack wäre sicher nett gewesen, smartpointer sind jedoch voll am Problem vorbei...

    Gut. -.-

    Verwende brav

    std::vector<int> a(100);
    

    Und sieh dir die anderen schönen STL-Container hier:

    http://www.cplusplus.com/reference/stl/

    an. Allokiere niemals selbst Speicher, wenn du es vermeiden kannst. Das führt manchmal zu schwer zu entdeckbaren Bugs, die du dann lange suchen darfst.



  • Ethon schrieb:

    Wenn ich beispielsweise ein Bild in den Speicher laden möchte, muss ich die paar MB ja auch nicht zuerst alle auf 0 setzen um sie direkt zu überschreiben.

    Da kannste den vector auch gleich beim Konstruieren befüllen.



  • Tachyon schrieb:

    Ethon schrieb:

    Wenn ich beispielsweise ein Bild in den Speicher laden möchte, muss ich die paar MB ja auch nicht zuerst alle auf 0 setzen um sie direkt zu überschreiben.

    Da kannste den vector auch gleich beim Konstruieren befüllen.

    Wie würdest du das machen? istream_iteratoren um byteweise zu lesen/schreiben sind signifikant langsamer als wenn das OS dir direkt einem Rutsch den ganzen Dateiinhalt in den Speicher schreibt.



  • Ethon schrieb:

    Wenn ich beispielsweise ein Bild in den Speicher laden möchte, muss ich die paar MB ja auch nicht zuerst alle auf 0 setzen um sie direkt zu überschreiben.

    Ein unique_ptr<T[]> hat einen nicht messbaren Geschwindigkeitsvorteil gegenüber vector<T> , aber drei Nachteile:
    - er kennt sein Ende nicht ( end() , size() )
    - keine richtigen Iteratoren ( begin() , end() )
    - der "Iterator" ist bloß ein Zeiger



  • TyRoXx schrieb:

    - der "Iterator" ist bloß ein Zeiger

    Wo ist da das Problem?
    Theoretisch könnte man auch in vector

    typedef T* iterator;
    

    schreiben.
    Übrigens sind Punkt 1 und 2 praktisch identisch. Wenn man die Größe hat, kann man sich ein start-end Iteratorenpaar durch einfache Addition basteln.



  • Hacker schrieb:

    TyRoXx schrieb:

    - der "Iterator" ist bloß ein Zeiger

    Wo ist da das Problem?
    Theoretisch könnte man auch in vector

    typedef T* iterator;
    

    schreiben.

    Kann man, tut man aber nicht.
    - Ein eigener Iterator kann Debugging-Zeugs haben.

    - Zeigeriteratoren sind eben Zeiger, was ungewollte Effekte haben kann:

    typedef T *iterator;
    iterator i;
    cout << *i << "\n";
    cout << i << "\n"; //Ausgabe als void *
    


  • Hacker schrieb:

    Allokiere niemals selbst Speicher, wenn du es vermeiden kannst. Das führt manchmal zu schwer zu entdeckbaren Bugs, die du dann lange suchen darfst.

    Ich komme immer wieder darauf zurück:

    Back in the good old days-- the "Golden Era" of computers-- it was easy to separate the men from the boys (sometimes called "Real Men" and "Quiche Eaters" in the literature).

    Some programming tools NOT used by Real Programmers:
    Source language debuggers. Real Programmers can read core dumps.

    Compilers with array bounds checking. They stifle creativity, destroy most of the interesting uses for EQUIVALENCE, and make it impossible to modify the operating system code with negative subscripts. Worst of all, bounds checking is inefficient.

    http://www.pbm.com/~lindahl/real.programmers.html

    Dann rate mal wo ich dich einordne. :p



  • EOP schrieb:

    Dann rate mal wo ich dich einordne. :p

    Was genau war an meiner Aussage jetzt falsch? ➡ 😕
    Und wieso ist Kursiv-Schrift im BBCode tiefgestellt?



  • Hacker schrieb:

    Was genau war an meiner Aussage jetzt falsch? ➡ 😕

    Nichts. Sie kommt halt von einem Müslifresser 😉



  • Swordfish schrieb:

    Hacker schrieb:

    Was genau war an meiner Aussage jetzt falsch? ➡ 😕

    Nichts. Sie kommt halt von einem Müslifresser 😉

    Ich esse überhaupt kein Müsli 🕶
    Wenigstens habe ich keine Wahnvorstellungen und halte mich für einen Schwertfisch.

    Denn ich habe Wahnvorstellungen und halte mich für einen Hacker! 🤡



  • Hacker schrieb:

    Denn ich habe Wahnvorstellungen und halte mich für einen Hacker! 🤡

    Wieviele shells hast du auf irgendwelchen servern, du Hacker du?



  • EOP schrieb:

    Hacker schrieb:

    Denn ich habe Wahnvorstellungen und halte mich für einen Hacker! 🤡

    Wieviele shells hast du auf irgendwelchen servern, du Hacker du?

    Keinen.



  • Hacker schrieb:

    Keinen.

    Tausche gerne gegen Nominativ feminin.


Log in to reply