Sind array's ueberfluessig?

Walli

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.

otze

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.

otze

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?

Shlo

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);
	}
};

otze

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

Shade Of Mine

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

Walli

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;

otze

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

b7f7

otze schrieb:

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

otze schrieb:

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

Shlo

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

Bashar

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

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

Shlo

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

b7f7

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?

Shlo

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.

otze

wenn 64bit kommt benutz ich eh erstmal sizeof bis mir die neuen werte ins blut übergegangen bin.
und bis dahin ist malloc(sizeof(int)*1000) vom wert her genau das gleiche wie malloc(4000).

@b7f7 na wo liegt denn der unterschied zwischen dem was ich gemacht hab, und dem was mastah gemacht hat? jetzt mit deinem neuen wissen musst du das ja sagen können.

Shade Of Mine

otze schrieb:

wenn 64bit kommt benutz ich eh erstmal sizeof bis mir die neuen werte ins blut übergegangen bin.
und bis dahin ist malloc(sizeof(int)*1000) vom wert her genau das gleiche wie malloc(4000).

Interessant, du entwickelst also jede software für jede plattform neu?

Ich bleib da lieber portabel und kompiliere einfach nur neu.

wenn du wirklich 4000 statt 1000*sizeof(int) schreibst, dann kann ich dich nicht mehr ernst nehmen.

otze

is sizeof() präprozessor?

Shade Of Mine

otze schrieb:

is sizeof() präprozessor?

nö, es ist ein operator