Sind array's ueberfluessig?



  • in dem fall schon.
    dann gibts noch:

    int foo[1000];//4000 byte aufm stack reservieren
    int* bar=new int[1000];//4000 byte auf dem heap reservieren, delete nich vergessen
    int* bar2=static_cast<int*>(malloc(4000));//umständliche version von new, muss mit free wieder freigegeben werden.
    

    mehr fällt mir im moment nich ein...



  • otze schrieb:

    ok, ganz kurz: du musst dem compiler sagen, dass er dir erstmal die 4000bytes platz beschaffen soll, das macht er nämlich nicht automatisch.

    Seit wann können Compiler Speicher anfordern?

    otze schrieb:

    int* bar2=static_cast<int*>(malloc(4000));//umständliche version von new, muss mit free wieder freigegeben werden.
    

    Mal ganz abgesehen davon, dass man den Rückgabewert von malloc nicht casten soll, und dass malloc in C++ Code nichts zu suchen hat ist es keine "umständliche Version von new" 🙄 .



  • In C++ muss man casten und deshalb ist malloc umständlicher als new. Aber verboten ist es nicht.



  • man sollte doch besser sizeof(int)*arraysize schreiben



  • operator void schrieb:

    In C++ muss man casten und deshalb ist malloc umständlicher als new. Aber verboten ist es nicht.

    Nein, verboten ist es nicht. Aber es hat IMO trotzdem nichts in vernünftigem C++ Code zu suchen.



  • MaSTaH schrieb:

    otze schrieb:

    ok, ganz kurz: du musst dem compiler sagen, dass er dir erstmal die 4000bytes platz beschaffen soll, das macht er nämlich nicht automatisch.

    Seit wann können Compiler Speicher anfordern?

    dr compiler macht es nicht, aber er kann code erzeugen der dies tut

    otze schrieb:

    int* bar2=static_cast<int*>(malloc(4000));//umständliche version von new, muss mit free wieder freigegeben werden.
    

    Mal ganz abgesehen davon, dass man den Rückgabewert von malloc nicht casten soll, und dass malloc in C++ Code nichts zu suchen hat ist es keine "umständliche Version von new" 🙄 .

    es verhällt sich genauso wie new, der free Memory ist im gleichen speicherbereich wie der heap und er verhält sich genauso.
    wenn ich new char[4000] mache, erzeuge ich ein 4000 byte großes zusammenhängendes feld, genauso wie malloc(4000).
    der einzige vorteil von new ist, dass du direkt einen ctor benutzen kannst, im gegensatz zu malloc, und darum ist malloc umständlicher.
    ansonsten seh ich rein von den eigenschaften her keinen unterschied,es bleibt wie gesagt nur der fehlende ctor, was aber bei einem char array keinen unterschied macht.

    und nun verrat mir mal, wieso man den pointer den malloc übermittelt nicht umcasten soll, vorallem wenn man genau weis, dass man den void pointer nurnoch braucht, um den speicher wieder freizugeben.



  • otze schrieb:

    es verhällt sich genauso wie new, der free Memory ist im gleichen speicherbereich wie der heap und er verhält sich genauso.
    wenn ich new char[4000] mache, erzeuge ich ein 4000 byte großes zusammenhängendes feld, genauso wie malloc(4000).
    der einzige vorteil von new ist, dass du direkt einen ctor benutzen kannst, im gegensatz zu malloc, und darum ist malloc umständlicher.
    ansonsten seh ich rein von den eigenschaften her keinen unterschied,es bleibt wie gesagt nur der fehlende ctor, was aber bei einem char array keinen unterschied macht.

    nein siehe class(), ~class()
    und der vorteil das man new überschreiben kann.



  • dass will ich mal sehen, wie du den befehl new überschreibst 😃 (oh gott, ich hör mich ja schon so an wie mastah)

    class()=ctor ~class()=dtor

    class Klasse{
        //hier steht was
    };
    void test(){
        Klasse a;//ctor
    }//hier wird der dtor von Klasse aufgerufen
    

    ok, was hat das jetzt mit dem thema zu tun?



  • otze schrieb:

    dass will ich mal sehen, wie du den befehl new überschreibst 😃

    ist das so ungewöhnlich?

    struct A
    {
    	void* operator new(size_t size)
    	{
    		return ::operator new(size);
    	}
    
    	void* operator new[](size_t size)
    	{
    		return ::operator new[](size);
    	}
    
    	void operator delete(void* p, size_t size)
    	{
    		::operator delete(p);
    	}
    
    	void operator delete[](void* p)
    	{
    		::operator delete[](p);
    	}
    };
    


  • du hast die operatoren grade nicht überschrieben, sondenr überladen(darum mein kommentar wegen mastah^^)



  • Shlo schrieb:

    ist das so ungewöhnlich?

    Mal abgesehen dass es den Befehl new nicht gibt, hat er vermutlich den unterschied operator new und new operator gemeint. den new operator kann man naemlich tatsaechlich nicht ueberladen 😉



  • otze schrieb:

    und nun verrat mir mal, wieso man den pointer den malloc übermittelt nicht umcasten soll, vorallem wenn man genau weis, dass man den void pointer nurnoch braucht, um den speicher wieder freizugeben.

    int* p = (int*)malloc(3);
    *p = 42;



  • der programmierer der sowas schreibt muss sehr dumm sein(sowas mach nichmal ich 🙄 )



  • otze schrieb:

    der programmierer der sowas schreibt muss sehr dumm sein(sowas mach nichmal ich 🙄 )

    otze schrieb:

    int* bar2=static_cast<int*>(malloc(4000));



  • die Größe eines int's auf einem x86-System beträgt mindestens 4-Bytes und nicht 3 wie oben gepostet.



  • Ja klar, und das war schon immer und ewig so ...

    Unter DOS (16bit) ist ein int 2 Byte groß.



  • dann müssen die 3-Bytes auch stimmen...



  • Shlo schrieb:

    die Größe eines int's auf einem x86-System beträgt mindestens 4-Bytes und nicht 3 wie oben gepostet.

    d.h. kann ich auf nem x86 kein compiler benutzen der 16..64 oder 512 bit ints benutzt?



  • b7f7 schrieb:

    Shlo schrieb:

    die Größe eines int's auf einem x86-System beträgt mindestens 4-Bytes und nicht 3 wie oben gepostet.

    d.h. kann ich auf nem x86 kein compiler benutzen der 16..64 oder 512 bit ints benutzt?

    auf einem 32-bit System? glaube ich kaum.



  • Es gibt natürlich schon workarounds wie ints mit einer bestimmten Größe, dann wird der Wert halt auf mehrere Register aufgeteilt oder künstlich abgeschnitten (wie geht das eigentlich, mit shiften?).

    Ach übrigens, ich würde lieber sparsam mit Pointer-Casts und Pointer-Arithmetik umgehen, sonst kann man bei der nahenden Umstellung auf 64 Bit echt Ärger bekommen.


Anmelden zum Antworten