Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / dbInKey()

Author
Message
Ghthor
16
Years of Service
User Offline
Joined: 5th Apr 2008
Location:
Posted: 14th Apr 2008 04:11
Does anyone have any idea what dbInKey() returns if no key is being pressed? so far I've testing 0, '\0', "\0" none of these being what is returned.

Taco Justice
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Apr 2008 04:48
dbInKey() returns a pointer to a character string and a quickie debug session shows that it's an empty string if nothing is pressed. So either



or, the quicker way



Without seeing your code I'd have to assume that you were testing the returned value rather than what the returned pointer was pointing to.

Strange that it returns a pointer to a character rather than a character

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Ghthor
16
Years of Service
User Offline
Joined: 5th Apr 2008
Location:
Posted: 14th Apr 2008 05:06
I love you

Taco Justice
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Apr 2008 05:32
I have that effect on people.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Ghthor
16
Years of Service
User Offline
Joined: 5th Apr 2008
Location:
Posted: 14th Apr 2008 08:10
OK Another question, is the returned char* a ptr to a new operation memblock that I have to garbage collect perse. Or is it collected by the internal GDK runtime functions

Taco Justice
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Apr 2008 09:00
Very likely the latter. In C++ if you're not doing a new call to reserve memory then the pointer is merely being assigned to point to an area defined by the function that assigned it. Since this is a pointer to a single character then I can't imagine why it would reserve space for anything more.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Ghthor
16
Years of Service
User Offline
Joined: 5th Apr 2008
Location:
Posted: 14th Apr 2008 15:50
Ok So you have to garbage collect it. Every call of dbInKey() is returning a new piece of memory that you have to delete.

Taco Justice
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Apr 2008 16:47
No. Certainly not. I'd almost bet a day's pay that there's a single character slot somewhere in there whose address is returned to you. If you were to check the value of the pointer itself on each call to dbInKey() I bet you'd find it points to the same memory location. In fact, I wouldn't even try the

if (strlen(c_ptr) == 0){}

approach now that I think about it. I'd just check the character at that location being equal to '\0' or simply zero.

When you use a new command to allocate memory the system has to not only allocate the memory, it also as to prepend some data regarding the location and amount of space reserved. This is so it knows what to recover. That's a bit of wasted resources to consume just to point to a single character. I think it results in something like 16 bytes of data just to do the housekeeping even for allocation of a single character using new.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Ghthor
16
Years of Service
User Offline
Joined: 5th Apr 2008
Location:
Posted: 14th Apr 2008 20:08 Edited at: 14th Apr 2008 20:13
Nope heres the code, remove the if(dbUpKey()) branch that encapsulates the assign commands and watch it slowly eat up your ram.



sucks but you gots to delete everytime before the dbInKey() or its a memleak. I wonder what Other kinda stuff I can find ^_^ .

Taco Justice
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 14th Apr 2008 20:52
"sucks" is the word. I made some assumptions, sure, but logic says to reserve a character in static space, put the character from the keyboard in that spot and return the address of that character. The next time a character is asked for just reuse the space. Of course, someone would probably run a delete on it anyway.

Do you have a figure on the amount of memory lost? It makes a difference if you code


vs.



Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Ghthor
16
Years of Service
User Offline
Joined: 5th Apr 2008
Location:
Posted: 15th Apr 2008 00:20
I don't know how long the char string is, this code isn't giving me any errors; I guess this is becuase I'm not using the Debug dll for linking?



Its at the very least 2 chars, one for the key that is input and one that is a '\0' terminator. My output supports that it is 2 chars in size except that I have no errors. I'm Using delete [] argument; and I don't have anymore leaks atm, that are noticable. I'm not running any programs to detect leaks. I noticed this just by eyeballing the amount of memory that was being used by my program.

Taco Justice
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 15th Apr 2008 00:38
I just ran your code through a debug session and sure enough, each call to dbInKey() set your respective pointers to a different address. The difference in the address was 32 bytes. I then stuck a

delete [] testing1;

right after your

testing1 = dbInKey();

and sure enough testing2 was set to the same address that testing1 had been set to. So, you do need to clean up that space. Wow!

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Ghthor
16
Years of Service
User Offline
Joined: 5th Apr 2008
Location:
Posted: 15th Apr 2008 01:14 Edited at: 15th Apr 2008 01:16
I just found another leak, its the char* returned by dbStr(); I'm now assuming that all char* returns I have to clean up now. which smells beacuse now instead of this


I have to write this



=[ I'm glad I found this though, would have proved rather annoying later of down the road. Implementing all these delete's has stablized my Memory usage though. It is no longer moving constantly upward during runtime, hurray! ^_^

Taco Justice
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 15th Apr 2008 02:53
That's good to know. It might be worth it putting a wrapper around the function and store the output in std::string before doing a delete [].

There's got to be a better way to handle this but I'm not sure what. It may be a workaround for the way that c/c++ functions handle local data. If you declare a buffer inside a function it only exists as long as the function exists. When the function ends, any data that was created inside the function has its storage space returned to the stack. So a char xxx [128] buffer inside of a function call gets removed and returning a pointer to that buffer just leaves you pointing to garbage. However, the buffer can be declared as a static variable and it gets created in the heap and remains throughout the scope of the program. You still have to make sure that you reserve enough space to compensate for the maximum amount of string length you'll need. That's probably why so many functions that create strings have the programmer provide the space and pass the function the destination address.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 15th Apr 2008 07:55
...which is why the allocation looks more like:
char* xxx = new char[128];

The function will return the pointer xxx on the stack (provided that is the function's return type, that is.), and the memory is to be freed by the caller.

That's nothing new, however. CRT uses a static buffer for time strings, for example.

You have literally asked for a string, why is it surprising that you need to dispose of it when you are done?

Here is an example of another thing you must delete/free yourself, or risk leaking memory if you do not. C++ cannot automatically delete all memory allocated with new.
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 15th Apr 2008 08:18
I'm talking about functions like atoi where the user is required to pass the address of the receiving buffer to the function and the function writes the characters to the buffer and, in that particular case, returns the address of the same buffer. The programmer has the responsibility of providing enough space but he knows that.

It's not so surprising but usually the recovery is done within the same functionality in which it's assigned. There's been nothing in the documentation mentioning the need to free the memory and when the possibility of a static buffer is an option this is the kind of thing one needs to know.

The dbInKey() function only needs to return a pointer to a single character. Why allocate 32 bytes in order to point to a single character that could be in static memory? In fact, why not just return a character rather than a pointer? With dbStr () there's a definite limit on the number of characters necessary to express a value. Why not have a static buffer with a sufficient number of bytes to hold that string and re-use it?

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
jinzai
18
Years of Service
User Offline
Joined: 19th Aug 2006
Location: USA
Posted: 15th Apr 2008 09:58
Well, a character might not be 8-bits, although a keystroke is. 32 bytes is probably just the minimum allocation unit the library is compiled with. (Alignment affects this, among other factors.)

Login to post a reply

Server time is: 2024-09-29 17:33:36
Your offset time is: 2024-09-29 17:33:36