Sorry your browser is not supported!

alright. its about time someone asked what the hell is wrong with the file functions of dark gdk. in the past, some people have said that this commands lead to a memory leak, including the built in tokenizer. is this true? i have made some research, done some example programs that use this functions, use char pointers, and when i run the test program, it starts with, lets say, 10.000 mb of ram. when the program enters the loading file part, it is 11.000 mb in ram,then , it tokenizes the whole file, converts from char to int, float, etc, a lot of dbReadString, a lot of dbFirstToken, dbNextToken and lots of declared and initialized char * inside some fors and ifs and lots of comparing etc, you get the point. when it closes the file it used to read, the memory usage drops back to 10.000 mb... is there any real memory leak in this commands??? a detailed and explained answer would be nice not only for me, but for many people who are just getting used to pointers and functions returning char*. and all those sort of things. thank you (please dont be rude)

All (or many) of the functions in DarkGDK that return a char* allocate new memory on each call.

That includes:
dbStr
dbInput
dbEntry
dbGetEntry
dbLeft
etc...

Usage is as follows:


If you don't assign the returned pointer to a variable, you lose the address, and the newly allocated memory gets thrown onto and forgotten on the heap. It may seem harmless that a few bytes of memory get left behind, but if you call one of these functions wrong in every loop, the garbage can accumulate, and eventually crash the program or the computer.

As for the file input commands, they are only in the gdk since the gdk is almost a direct port of dbc, which included the original functions. That's why people just say to use fstream. It just gives more control over files, and why not use native C++ functions when using C++?

so if i use them adecuately (dont know if that word is written correctly XD) there will be no memory leak at all?

I doubt it.