malloc in externer funktion?

ja aber da ist doch im grund das gleiche? das malloc/free wird in einer externen funktion aufgerufen.

CJosef

mallllllllloc schrieb:

ok, dein code ist ein bisschen abstrakt:
...
ist das so ungefähr richtig?

Ja, es ist allgemein gehalten, das kann ein beliebiger, selbstdefinierter Typ sein.
Wenn du dir überlegst, wie groß sizeof(char*) ist, dann wohl eher nicht.

mallllllllloc schrieb:

CJosef schrieb:

-Dein Speicher wird nicht freigegeben, obwohl du eine Funktion dafür vorgesehen hast

warum? ich rufe die funktion "closeThisFile" am ende auf.

Weil dein char* _malloc in der allokierenden Funktion ein anderes ist als in der main Funktion.

mallllllllloc schrieb:

CJosef schrieb:

-Filesize kann negativ werden

wann denn? ich glaube du meinst eher den rückgabewert von fseek()? im falle eines fehlers?

Edit: Ooops, ich hab da ein int gesehen. vergiss es

malllllllloc schrieb:

ja aber da ist doch im grund das gleiche? das malloc/free wird in einer externen funktion aufgerufen.

Das sind Minimalstbeispiele. Weil es aber oft, wie schon erwähnt, selbstdefinierte Datentypen sind für die Speicher reserviert und freigegeben wird, reicht oftmals ein einziges malloc/free nicht aus, wenn der Typ seinserseits Zeiger hat mit denen weiterer Speicher reserviert wird.

SeppJ

malllllllloc schrieb:

ja aber da ist doch im grund das gleiche? das malloc/free wird in einer externen funktion aufgerufen.

So ist das auch vollkommen ok. Was hier öfters vorgeschlagen wird und vor dem du gewarnt wurdest, ist das Schema, dass eine Funktion überraschend einen Zeiger zurück gibt, auf den man später free aufrufen muss, obwohl man selber gar kein malloc gemacht hat. Dass man das was ich oben "Handle" genannt habe wieder aufräumen muss ist hingegen für den Benutzer klar, er hat es schließlich vorher explizit mit der get_handle-Funktion erzeugt.

CJosef

mallllllllloc schrieb:

diese zeile verstehe ich nicht recht. du reservierst hier den inhalt von new_malloc, allerdings ist new_malloc noch nichts zugewießen, daher kannst du unmöglich die größe davon bestimmen

Kann man. Das ist im Prinzip das selbe in Grün:

typedef struct tagSomeType
{
	double dnumber;
	int inumber;
	char* pchar;	
}SomeType;

int main(void)
{
	SomeType* pst;
	printf("%d\n", sizeof(SomeType) == sizeof(*pst));
};

SeppJ schrieb:

So ist das auch vollkommen ok. Was hier öfters vorgeschlagen wird und vor dem du gewarnt wurdest, ist das Schema, dass eine Funktion überraschend einen Zeiger zurück gibt, auf den man später free aufrufen muss, obwohl man selber gar kein malloc gemacht hat. Dass man das was ich oben "Handle" genannt habe wieder aufräumen muss ist hingegen für den Benutzer klar, er hat es schließlich vorher explizit mit der get_handle-Funktion erzeugt.

ok, also im anderen thread wurde gesagt, dass das malloc, bzw. das free auf "gleicher ebene" aufgerufen werden sollte, das ist hier allerdings nicht der fall.

mallllllloc schrieb:

SeppJ schrieb:

So ist das auch vollkommen ok. Was hier öfters vorgeschlagen wird und vor dem du gewarnt wurdest, ist das Schema, dass eine Funktion überraschend einen Zeiger zurück gibt, auf den man später free aufrufen muss, obwohl man selber gar kein malloc gemacht hat. Dass man das was ich oben "Handle" genannt habe wieder aufräumen muss ist hingegen für den Benutzer klar, er hat es schließlich vorher explizit mit der get_handle-Funktion erzeugt.

ok, also im anderen thread wurde gesagt, dass das malloc, bzw. das free auf "gleicher ebene" aufgerufen werden sollte, das ist hier allerdings nicht der fall.

das ist käse.
free wird aufgerufen, wenn das objekt nicht mehr benötigt wird.
wann das der fall ist, das ist abhängig vom anwendungsfall und nicht von irgendwelchen ebenen. basta.

käselochaufspürer schrieb:

mallllllloc schrieb:

SeppJ schrieb:

So ist das auch vollkommen ok. Was hier öfters vorgeschlagen wird und vor dem du gewarnt wurdest, ist das Schema, dass eine Funktion überraschend einen Zeiger zurück gibt, auf den man später free aufrufen muss, obwohl man selber gar kein malloc gemacht hat. Dass man das was ich oben "Handle" genannt habe wieder aufräumen muss ist hingegen für den Benutzer klar, er hat es schließlich vorher explizit mit der get_handle-Funktion erzeugt.

ok, also im anderen thread wurde gesagt, dass das malloc, bzw. das free auf "gleicher ebene" aufgerufen werden sollte, das ist hier allerdings nicht der fall.

das ist käse.
free wird aufgerufen, wenn das objekt nicht mehr benötigt wird.
wann das der fall ist, das ist abhängig vom anwendungsfall und nicht von irgendwelchen ebenen. basta.

"man soll die verantwortung über malloc/free nicht an funktionen übergeben". das ist die hauptaussage des aderen threads.

seltsam, ich frage hier sachen, die in anderen threads schon beantwortet wurden, erhalte allerdings gänzlich andere antworten...

SeppJ

mallllllloc schrieb:

ok, also im anderen thread wurde gesagt, dass das malloc, bzw. das free auf "gleicher ebene" aufgerufen werden sollte, das ist hier allerdings nicht der fall.

Wo denn nicht?

seltsam, ich frage hier sachen, die in anderen threads schon beantwortet wurden, erhalte allerdings gänzlich andere antworten...

Du hast die Antworten und die Konzepte dahinter anscheinend nicht verstanden, daher deine Verwirrung.

nein. auf gleicher eben bedeutet für mich: in EINER funktion wird speicher alloziert und in der GLEICHEN funktion wieder freigegeben.

z.b.

int main()
{
    char *speicher=malloc(500);
    free(speicher);
}

und nicht:

int a(char *speicher)
{
     speicher=malloc(500);
     return 0;
}

int b(char *speicher)
{
    free(speicher);
    return 0;
}

int main()
{
     char *speicher;
     a(speicher);
     b(speicher);
}

laut dem anderen threads wird hier die verantwortung über malloc/free an die funktionen übergeben, und das soll man (lt. anderem thread) nicht machen.

Swordfish

malllllllllloc schrieb:

nein. auf gleicher eben bedeutet für mich: [...]

SeppJ schrieb:

Du hast die Antworten und die Konzepte dahinter anscheinend nicht verstanden, daher deine Verwirrung.

CJosef

malllllllllloc schrieb:

laut dem anderen threads wird hier die verantwortung über malloc/free an die funktionen übergeben, und das soll man (lt. anderem thread) nicht machen.

Ungläubiger!!!
Werf doch mal nen Blick in den Code größerer Projekte, das ist allgemein üblich eigene "Konstruktoren" und "Destruktoren" zu verwenden, a la

typedef struct tagAnyObject1
{
	int number;
	// Eventuel andere Objektmember, die dynamisch erzeugt werden ...
	...
}AnyObject1;

typedef struct tagAnyObject2
{
	double number;
	// Eventuel andere Objektmember, die dynamisch erzeugt werden ...
	...
}AnyObject2;

int create_any_object1( AnyObject1** p )
{
	AnyObject1* new_object = malloc ( sizeof ( *new_object ));
	if ( NULL != new_object )
	{
		// Eventuell andere Member dynamisch erzeugen ...
		...
	}
    return NULL == ( *p = new_object ); // 1: Fehler, 0: OK. 
}

int create_any_object2( AnyObject1** p )
{
	AnyObject2* new_object = malloc ( sizeof ( *new_object ));
	if ( NULL != new_object )
	{
		// Eventuell andere Member dynamisch erzeugen ...
		...
	}
    return NULL == ( *p = new_object ); // 1: Fehler, 0: OK. 
}

void free_object1 ( AnyObject1* p )
{
	if ( NULL == p ) 
		return;
	// Eventuell dynamisch erzeugte Objektmember freigeben ...
	...
	free ( p ); // Objekt freigeben.
}

void free_object2 ( AnyObject2* p )
{
	if ( NULL == p ) 
		return;
	// Eventuell dynamisch erzeugte Objektmember freigeben ...
	...
	free ( p ); // Objekt freigeben.
}

Was soll denn bitte daran schlecht sein?
Ganz im Gegenteil, das Auslagern der Erzeugung der Objekte und die Freigabe des
Speichers schafft Übersicht und verhindert Spaghetticode, denn sehr oft reicht ein einziges
malloc nicht aus, um ein Objekt zu erzeugen(hinter meinen ... in den Beispielen können viele viele weitere Zeilen stecken, die zur Erzeugung/Freigabe eines
Objekts nötig sind). Klar soweit?
Da gibts eigentlich auch nichts weiter zu diskutieren!

ok. dann hat man wohl im anderen thread mist erzählt oder was?!?

@Swordfish:
wirklich aussagekräftig....

Wutz

mallllllloc schrieb:

FILE *test=fopen(a,"rb");
	if(test==NULL)
	{
		return 1; // wenn datei nicht geöffnet werden kann
	}
	
	fseek(test,0,SEEK_END);

Die Kombination aus "rb" + fseek/SEEK_END liefert undefiniertes Verhalten.

mallllllloc schrieb:

unsigned int filesize=ftell(test);

datei > 4gb -> programm failure!
-> betriebssystem funktionen benutzen!