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 / DGK C++; Getting Display Types

Author
Message
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 22nd Jun 2014 06:16
Link
Alright got some time to work on my Dark Engine Gui this week. I am needing to add a Display Mode config. Where are some examples of selecting multiple Display Types (Short of hard coding popular modes that work on my machine...

There are many answers but just one question" ~ Jerilith the Mad
Back to top
Profile PM Email
Rudolpho
18
Years of Service
User Offline
Joined: 28th Dec 2005
Location: Sweden
Posted: 22nd Jun 2014 11:57
Link
dbPerformChecklistForDisplayModes (or some such name).
Then dbCheckklistQuantity() returns the number of unique available display modes, dbChecklistValueA() returns the width, B the height and C the depth.


"Why do programmers get Halloween and Christmas mixed up?"
Back to top
Profile PM Email Website
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 23rd Jun 2014 03:31
Link
I will poke at that, I think thats exactly what I am after. Thanks, btw I like your sig by the way... "Because we blow"...

There are many answers but just one question" ~ Jerilith the Mad
Back to top
Profile PM Email
s_i
14
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 23rd Jun 2014 22:56 Edited at: 28th Jun 2014 22:06
Link
Way #1:


Way #2:


But be careful, because if the resolution for full-screen game differs from that established by the user on his Windows desktop, antialiasing does not work.

Example #1:
My monitor original resolution: 1680x1050
I set Windows desktop resolution: 1440x900
In game I use:

Result: OK. See picture 1.

Example #2:
My monitor original resolution: 1680x1050
I set Windows desktop resolution: 1680x1050

Result: no antialias. See picture 2.



So I use only GetSystemMetrics(SM_CXSCREEN) & GetSystemMetrics(SM_CYSCREEN) for fullscreen.

Attachments

Login to view attachments
Back to top
Profile PM
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 24th Jun 2014 04:50
Link
Thanks even more than I hoped for. Thanks great example will have to work it into the gui.

Though I am curious?



in the above example, "delete[] string1", string1 is still in use in the loop. deos this not cause problems or is this just remove tany data stored in string1 but retianing the varible?...

There are many answers but just one question" ~ Jerilith the Mad
Back to top
Profile PM Email
s_i
14
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 24th Jun 2014 19:32 Edited at: 28th Jun 2014 22:07
Link
Read carefully my code in Way#1: "char* string1;" is before the cycle "for (i=...) {...}". So all will be OK with string1.
The reason for "delete[] string1" is bug in DarkGDK source code: all string commands of DarkGDK gives "memory leak". You can read about this here:
http://forum.thegamecreators.com/?m=forum_view&t=211255&b=22
http://forum.thegamecreators.com/?m=forum_view&t=67322&b=15
and many other threads for last years.
So use this:
Back to top
Profile PM
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 28th Jun 2014 18:23 Edited at: 28th Jun 2014 18:24
Link
Quote: "The reason for "delete[] string1" is bug in DarkGDK source code: all string commands of DarkGDK gives "memory leak". You can read about this here:"

This is wrong.

Your code deletes a char* returned by dbChecklistString() - YOU SHOULD NOT BE DOING THIS. When the next "PerformChecklistForWhatever" function is called, all checklist strings from the previous checklist are freed automatically by this function on line 913:


I glanced over the other issues with dbStr(), here are the relevant functions: the source code here






g_pCreateDeleteStringFunction is a function pointer to this core function:
https://code.google.com/p/darkbasicpro/source/browse/trunk/%20darkbasicpro%20--username%20LeeBamberTGC/Dark%20Basic%20Pro%20SDK/Shared/Core/DBDLLCore.cpp


There are a lot of WTFs going on in this code, and I'm not entirely sure what the policy of deleting strings is. From what I can gather, it doesn't seem like the strings are deallocated until DarkGDK is shut down.

hands are ruined by repetitive stroking... - Mr. V, 2014
Back to top
Profile PM Email Website
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 28th Jun 2014 20:08
Link
Ok, correct me if I’m wrong. The function ChecklistString() in CSystemC.cpp looks to be allocating a character array and copying the checklist string. FreeChecklistStrings() does nothing to free the memory allocated by ChecklistString().
Back to top
Profile PM Email
s_i
14
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 28th Jun 2014 22:35 Edited at: 28th Jun 2014 22:54
Link
@ TheComet
No, you are wrong with dbChecklistString(). Please, test this code:


And you are wrong in all other cases. Example #2:

Result: memory leak.

Example #2 in "Resourse Monitor" in Windows7:

Attachments

Login to view attachments
Back to top
Profile PM
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 28th Jun 2014 23:52 Edited at: 29th Jun 2014 00:05
Link
Looks like Will have to change out how the strings are handled. This is more than likely why Minstrel in DGK 2.0 decided to let us handle string allocation. With that in mind I figure it would be a good idea to create some function that can handle that type of work. One of my biggest gripes was that he stripped those functions out (I liked them, dbMid, dbStr dbVal), they made it much easier for me just to work on my coding. There are some examples that have been posted, going to have to dig\'m up and consolidate them.

There is a good chance that my little Dark Engine GUI is full of memory holes then, though many of them localized in the class functionws, where it shows the text (dbStr, dbVal, dbMid are used allot) if those are leaving a memory leak it will eventually blow up)..

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 29th Jun 2014 00:20 Edited at: 29th Jun 2014 00:22
Link
Just ran a test on my Dark Engine Gui, the programs memory foot print is slowly growing in size... Then ran my engine without the text and (just mostly the gui elements) and the memory foot print does not grow. Outstanding!.. I have been coding with library for years and this is the first time I ran across this thread... That could of been a big headache .. later on. Still fixable. So looks like this turned into a string thread (again).. And thanks.

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 29th Jun 2014 01:20
Link
Yup just trimmed a bit of code involving my text. Looks like these functions are going to have to be redone. Any good examples of similar functions like dbMid, dbLeft, dbStr and dbVal?

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 29th Jun 2014 01:33
Link
I don't know even dbText, seams to increase the size of the memory foot print..... just looking at some my code...

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 29th Jun 2014 02:27 Edited at: 29th Jun 2014 02:31
Link
dbText() should be fine if using a string constant. If using a string function, it's probably that function causing the memory leak. Here is a memory safe alternative to the dbStr() function. The other string functions shouldn’t be too complicated.

Back to top
Profile PM Email
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 29th Jun 2014 08:30 Edited at: 29th Jun 2014 08:46
Link
Amazing this also create a memory leak :
strcpy_s (cFont,dbTextFont());

changed it out to this...



took me a while to find this after I got out of work. It was in the same function with the dbText. Just means that I will have to work on cleaning up another section with the files, there is allot of dbStr functions there.... now the program is not growing in Kb per second.

Well thanks again for all of your folks input. This will make my program that much more stable in the long run. I did not know about that memory error, this means that my previous version of the gui have memory leaks that you can drive truck through.

Another quick question:

With the delete[] my_ptr, if I am correct this just clears the data on the point and sets it back to it's 0 position?

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
s_i
14
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 29th Jun 2014 13:05 Edited at: 29th Jun 2014 13:14
Link
delete[] my_ptr; //this frees allocated memory...
my_ptr = 0; //...then you can do this for safety reasons. //some people write "my_ptr = NULL;"
Back to top
Profile PM
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 29th Jun 2014 17:43
Link
You don’t really need to nullify the pointer if you take care not to use it after the memory has been freed.

If you include the header - globstruct.h. You can use the internal macro - SAFE_DELETE_ARRAY(). This macro's definition is -
#define SAFE_DELETE_ARRAY( p ) { if ( p ) { delete [ ] ( p ); ( p ) = NULL; } }
Back to top
Profile PM Email
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 30th Jun 2014 04:46 Edited at: 30th Jun 2014 04:49
Link
Soo if I did this


Is this safe or just bad practice. Am I deleting the pointer or just the memory it was using?

Quote: "You don’t really need to nullify the pointer if you take care not to use it after the memory has been freed. "


Am I using the pointer after I have freed the memory up..... not for sure (though I think I am, this may cause problems later.)

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 30th Jun 2014 06:23 Edited at: 30th Jun 2014 06:30
Link
What this is doing is setting your character pointer equal to that returned by the function. Since you cannot access the actual character pointer used by DarkGDK, this pointer is used to free the memory. Each time you call the function DarkGDK is allocating memory. So, yes you want to delete the memory after each use. When the function goes out of scope the pointer will be nullified. Looks good to me.

File I/O is one area where I prefer to use the fstream: Stream class.
Back to top
Profile PM Email
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 30th Jun 2014 07:46 Edited at: 30th Jun 2014 07:55
Link
I will look at that as well thanks. Rewriting the file/load and save routines this evening. Already dropping in memory size (changing the dbStr() calls with the pointers. My program should not grow into a Memory Blackhole (and collapsing into on itself and crashing the program) any time soon now. I can only imagine after a few menu loads what this could become... , There is soo much I don't know about this, But thanks. I like the the streaming approach, more uniform in idea. you can stream out to the screen, or into a string, or into a file with out much change to the format = useful. I can see using this as a log format at this time. The dg file routines don't append anything. The fstream functions can.

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 30th Jun 2014 09:09
Link
To really make DarkGDK what it can and should be, we really need to break existing functionality. The 3DMath and File modules, in my opinion should totally be scrubbed.
Back to top
Profile PM Email
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 30th Jun 2014 11:44 Edited at: 30th Jun 2014 11:47
Link
I'm curious, why do I not see anyone using C++ code around here?

Because this kind of stuff makes me cringe:


Why not use some of the STL to solve this elegantly?


std::to_string requires C++11, if you don't have a C++11 compliant compiler then this function can be used as a replacement:



@s_i

Does this cause memory leaks?


hands are ruined by repetitive stroking... - Mr. V, 2014
Back to top
Profile PM Email Website
s_i
14
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 30th Jun 2014 20:49 Edited at: 30th Jun 2014 20:51
Link
@ TheComet
Yes. And very fast. After 21 seconds program ("Release" config.) crashes, because 2Gb limit was reached.



P.S. VS2008 does not use C++11.

Attachments

Login to view attachments
Back to top
Profile PM
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 30th Jun 2014 22:05 Edited at: 30th Jun 2014 22:07
Link
@TheComet

I can't speak for everyone else, but personally, I can't stand that kind of code. I don't trust the integrity of Microsoft-code any further than I can throw it. It tends to be buggy, full of memory leaks, and the compiler is always trying to tie my hands with - yuck! Plus it's mangled, messy, and ugly. There are other ways to make the code pretty that doesn't involve mangling it with modifiers.

Also, I much prefer char* to "strings", especially Microsoft Strings. They're simply, concise, and logical. And I know exactly what's going on under the hood.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 30th Jun 2014 22:54
Link
Quote: " Also, I much prefer char* to "strings", especially Microsoft Strings. They're simply, concise, and logical. And I know exactly what's going on under the hood."

You're dealing with Microsoft code anyways as DGDK code is compiled as C++ rather than C. The Visual C++ standard library is required to match performance characteristics described in the ISO C++ standard. The C library is also entirely Microsoft code, as Microsoft has written its own version of the standard C library that is used system-wide with few alternatives(if any). How else did all those "*_s" functions get into the C headers?

So not using C++ because of Microsoft is laughable. I am curious how the compiler is "always trying to tie [your] hands". I also am curious what version of Visual Studio you're using that it's so full of memory leaks. I rarely go above ~150 MB.

@TheComet
Using const_cast<> is considered bad C++. Unfortunately using std::string with DGDK is more work than it's worth if you want to use idiomatic C++.

Back to top
Profile PM Email
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 30th Jun 2014 23:23 Edited at: 30th Jun 2014 23:30
Link
Yeah I know most of that stuff is implemented by Microsoft (but I would hardly say that Microsoft created C++; they didn't create anything (of value)). It's that all that stuff adds an additional heavy layer of extreme crappiness that gets in the way and absolutely need not be there. As for the rest, I have no wish to argue over it - lol!

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 1st Jul 2014 01:39 Edited at: 1st Jul 2014 02:03
Link
Quote: "I can't speak for everyone else, but personally, I can't stand that kind of code. I don't trust the integrity of Microsoft-code any further than I can throw it. It tends to be buggy, full of memory leaks, and the compiler is always trying to tie my hands with - yuck! Plus it's mangled, messy, and ugly. There are other ways to make the code pretty that doesn't involve mangling it with modifiers.

Also, I much prefer char* to "strings", especially Microsoft Strings. They're simply, concise, and logical. And I know exactly what's going on under the hood."


lol, and the C library you're using right now wasn't created by Microsoft?

I don't know where you've been to think it's note safe - it is.

char* is less safe than std::string, because you always need to make sure its null-terminated, you need to make sure the buffer is large enough when using sprintf, you can't concatenate strings easily at all, etc.

Quote: "Using const_cast<> is considered bad C++. Unfortunately using std::string with DGDK is more work than it's worth if you want to use idiomatic C++."


I know, but DGDK's functions aren't const correct (lee dun goofed), so there's not really any choice.

hands are ruined by repetitive stroking... - Mr. V, 2014
Back to top
Profile PM Email Website
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 1st Jul 2014 02:30 Edited at: 1st Jul 2014 02:31
Link
Hey you asked. Obviously we program from different paradigms. What you look for and what I look for are not the same, that's all.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 1st Jul 2014 19:50
Link
Me, most of what I know I got from 3 or 4 books and some online tutorials (and you folks here on the forums). But it is cool to see different ways of doing code. Take the what works for you. I myself and using visual studio 8. I have a hard time installing the libraries without the install wizards. So kinda regulated to the older set ups. Going to have to ask mike from mike net how to re-install his multiplayer library once I get the gui done enough to work on my game again.

Quote: ""Using const_cast<> is considered bad C++"


What is "const_cast<>"?

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 1st Jul 2014 22:06 Edited at: 1st Jul 2014 22:08
Link
Quote: "What is "const_cast<>"?"

const_cast<> is a specific type of casting in C++ that can remove or add const-ness (that is, the ability to be changed) to any variable. It is one of the more dangerous casts as it can cause undefined behavior if used improperly. Casting a const char* to a char* is probably one of the safer uses, but don't use it on a literal string.

Just in case you're wondering, here's the other C++-specific casts:
static_cast<> - Primarily used to convert between numeric types such as from float to double or char to int.
reinterpret_cast<> - Used to change a pointer from one type to another, such as casting a void* into a int* or a BaseClass* to a DerivedClass*.
dynamic_cast<> - The most dangerous of the C++ casts, used runtime type introspection to change types if possible. Rarely used, I'm not even sure if I described it right.
const_cast<> - The cast described above.

There may be one or two more, but I think those are the main casts. You can also use C-style casts such as (void*)your_pointer but these(the C++ casts) tell the programmer more specifically what's happening.

Back to top
Profile PM Email
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 2nd Jul 2014 11:54 Edited at: 2nd Jul 2014 14:57
Link
Quote: "What is "const_cast<>?"


Just adding to what Dar13 said with some code examples.

const is used to tell the compiler that something is read-only:


Similarly, a function that accepts a char* will reject a const char*


The function print() should be const because it's only reading from the variable. Inexperienced programmers will not make it const, and unfortunately the entire DarkGDK library has done this.

const_cast is the workaround solution for this, and should only be used if you are absolutely certain the data won't be manipulated. Such is the case with print(), and such is the case with dbText().



In my example above, std::string::c_str() returns a const char*, but dbText() requires a char*, so I had to use const_cast.

Why use const in the first place?

It's good practice to make as many things as possible const. It allows the compiler to optimise your code more than when things aren't const. For example:



This code produces the following machine code:


Making max const:


Produces this:


It already pre-computed value because the expression is now constant.

The other thing it does is it helps catch horrible errors. If your variable is changing when it shouldn't, any function that is const can instantly be ignored, narrowing down all of the possibilities.

Most of the time when being const correct you won't even be able to compile the software if you have read/write logic errors. That's a good thing and saves a lot of development time.

hands are ruined by repetitive stroking... - Mr. V, 2014
Back to top
Profile PM Email Website
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 2nd Jul 2014 12:51
Link
Think I have learned my about pointers and char• in this thread, thanks a lot.

I use allot of storage in text in the format of :

Char sText(32);

And copy and add strcpy_s and strcat_s, it was my work around without using pointers. Just made sure I kept the text under the amount I was using in the character array, things ran fine. Though been applying what you folks have shown has helped out.

Kinda excited about the sprintf function, nifty way of creating a formated string, and the file method for streaming as well. Well off to bed. Night

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 2nd Jul 2014 16:14
Link
sprintf() is a good tool for quick formatted strings, but runs a risk of buffer overflow if you're not careful. The way TheComet converted using std::stringstream is a much safer way than using sprintf().

I also hazard you against relying on any function with a "_s" at the end, as that means it's an extension to the C library that is not available on other platforms such as Linux or Mac OSX. By all means, use it with DGDK as otherwise you have to jump through some serious hoops to things "the right way"(tm). Just remember that it's not guaranteed to be there always.

Back to top
Profile PM Email
s_i
14
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 2nd Jul 2014 18:01 Edited at: 2nd Jul 2014 18:04
Link
In my GUI code I use "strncpy_s" -- easy and safe. It works in VS2005...VS2013. Example:



http://msdn.microsoft.com/en-us/library/5dae5d43(v=vs.90)
.
Back to top
Profile PM
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 2nd Jul 2014 18:59
Link


should be const:



Yeah its safe, but it's not optimal memory wise, it's not dynamic (max 40 characters in your example), and it's not cross platform.

This here looks way more appealing to the eye:



Or, if you "don't trust" std::string but still want it to be dynamic :


But that's essentially exactly what std::string does anyway.

hands are ruined by repetitive stroking... - Mr. V, 2014
Back to top
Profile PM Email Website
s_i
14
Years of Service
User Offline
Joined: 23rd May 2009
Location: Russia
Posted: 2nd Jul 2014 19:23
Link
"should be const" or "may be const"? Is it necessarily?
Back to top
Profile PM
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 2nd Jul 2014 19:51
Link
Quote: ""should be const" or "may be const"? Is it necessarily? "


It's good practice

Rule of thumb is: If the variable doesn't change, make it const.

hands are ruined by repetitive stroking... - Mr. V, 2014
Back to top
Profile PM Email Website
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 2nd Jul 2014 19:58
Link
Quote: " In my GUI code I use "strncpy_s" -- easy and safe. It works in VS2005...VS2013."

My point is that if you go to use another platform, you won't have those functions anymore. They're Windows exclusive and as such are not covered in the ISO C standard.

But, it's your code, do what you want.

Back to top
Profile PM Email
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 2nd Jul 2014 22:22
Link
That's another thing about strings - is that they're Microsoft-specific. Borland's string class (and everything else) was better. Char* (or whatever the platform calls it) is universal. If the convenience of string functionality is important, just design your own string class that uses char*, then you have it in your own library, which you can port anywhere.

If you use Microsoft's char* functions, one caution with strcat() is exposed by a major blunder made by TGC team in their interpretation of .3ds files. The strcat() function takes that char*, and scans forward for the NULL terminator, then copies the addition onto it there. TGC had a large char* array that took exponentially longer each time it added text to the end of it, because it always scanned from the beginning - to keep adding to the end, and it took longer and longer as the char* text size grew. This is why their importing of models is extremely slow in the release versions (this was crudely/quickly corrected in the latest source code version). So if you write your own class that uses char*'s, to have efficient implementation of an equivalent to strcat(), it would be a good idea to store the index of the NULL terminator as a private variable. That same variable can, of course, be checked against the allocated memory size to protect against overflow as well.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 2nd Jul 2014 23:02
Link
Quote: "That's another thing about strings - is that they're Microsoft-specific"


Not they're not?

Your entire post basically described exactly what std::string is.

hands are ruined by repetitive stroking... - Mr. V, 2014
Back to top
Profile PM Email Website
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 2nd Jul 2014 23:26
Link
Quote: "That's another thing about strings - is that they're Microsoft-specific."

No they're not. C++ strings(std::string) are part of the standard C++ library like std::cout, std::ofstream, etc are. And I guarantee that std::string would be faster or just as fast as anything implementation you could cook up with a fraction of the effort on your part.

You seem to have a lot of misconceptions about C++, especially about the standard library.

Back to top
Profile PM Email
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 2nd Jul 2014 23:41 Edited at: 2nd Jul 2014 23:46
Link
Wow! I just looked it up and I see you're right, about it not being Microsoft-specific. Thanks for pointing that out. Gives me a new toolset to check out. But still, I prefer to know/determine ~exactly~ what's going on in my software (from the lowest levels) - as I've observed most software and various popular implementations to be of extreme poor quality. So I'm not sure I'll use it, but it's worth checking into.

What I was thinking of when I said it was Microsoft-specific... Microsoft did have their own string class (at least that was my understanding). I know Borland did. I didn't realize this was a different string class than the Microsoft one. "Standard" can mean lots of things in different contexts.

Being a self-taught programmer, learning what I need to as I need it, has its advantages and its disadvantages. But I wouldn't trade it for the alternative

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 3rd Jul 2014 01:22
Link
I am also a self-taught programmer, so I can sympathize.

Quote: "But still, I prefer to know/determine ~exactly~ what's going on in my software (from the lowest levels) - as I've observed most software and various popular implementations to be of extreme poor quality"

How low are you talking? Dark GDK is an abstraction on top of an abstraction so you're already pretty far from hardware, no further than the C++ standard library is. And you can know exactly what each function does by going to a site such as cppreference.com or cplusplus.com and looking up what each function/class/etc does. In order to be called an implementation of the C++ standard, it has to adhere to those standards.

Back to top
Profile PM Email
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 3rd Jul 2014 01:49 Edited at: 3rd Jul 2014 02:04
Link
Well I got into DarkGDK for the sake of time. Ultimately, I'll be creating my own engine, assembly-optimized. And ultimately it won't have anything to do with OpenGL and certainly not DirectX. From what I know of OpenGL, it uses the same paradigm/ mindset as DirectX, which is quite primitive (no pun intended). DarkGDK was just something I could get into right away for a couple of time-sensitive projects.

When I say I want to know exactly what the software does, I don't mean the interface-functionality, I mean the underlying implementation of it. I want to know what the CPU is doing. I've seen some implementations that are very well-optimized (and not prone to bugging), and others that are atrocious. I like to have clean software.

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
Dar13
15
Years of Service
User Offline
Joined: 12th May 2008
Location: Microsoft VisualStudio 2010 Professional
Posted: 3rd Jul 2014 03:04
Link
I realize that, but that can be as simple as choosing a good library. Good libraries are known for having clean, optimized code. And anyways, compilers nowadays are much much better optimizers than hand-written assembly except in extremely rare cases.

Quote: "OpenGL and certainly not DirectX"

I honestly don't see how you can get around using those two and expecting any type of reasonable 3D performance. Those two are the primary interfaces for using a graphics card for 3D graphics and are quite optimized for most workloads.

After all that, at the end of the day, it's your life. Have fun!

Back to top
Profile PM Email
The Tall Man
10
Years of Service
User Offline
Joined: 16th Nov 2013
Location: Earth
Posted: 3rd Jul 2014 04:46 Edited at: 3rd Jul 2014 05:27
Link
Yeah I'm aware of that, aside from better hardware that is

When the mainstream keeps insisting on impeding the way forward, go ahead and leave it behind

Judging what we see is the greatest blinder and self-limiter in the universe.

What we perceive is never reality. It is only a story we tell ourselves based on our current perspective, which has far more to do with our beliefs about ourselves than with anything else.
Back to top
Profile PM
Timidon
18
Years of Service
User Offline
Joined: 26th Jun 2005
Location: Bakersfield, Ca. USA.
Posted: 3rd Jul 2014 08:36
Link
Well now to start the gui Rewrite, it collapsed into a memory black hole... started revamping the strings, and something kept over writing my information... so scrapped it and started over. trying a different approach to it...

Watch "StarCrash" a 1979 epic film, make sure your not to sober..
Back to top
Profile PM Email
Randomness 128
17
Years of Service
User Offline
Joined: 13th Feb 2007
Location:
Posted: 3rd Jul 2014 17:40
Link
Quote: "Well I got into DarkGDK for the sake of time. Ultimately, I'll be creating my own engine, assembly-optimized. And ultimately it won't have anything to do with OpenGL and certainly not DirectX. From what I know of OpenGL, it uses the same paradigm/ mindset as DirectX, which is quite primitive (no pun intended). DarkGDK was just something I could get into right away for a couple of time-sensitive projects.

When I say I want to know exactly what the software does, I don't mean the interface-functionality, I mean the underlying implementation of it. I want to know what the CPU is doing. I've seen some implementations that are very well-optimized (and not prone to bugging), and others that are atrocious. I like to have clean software."


If you make software for a modern PC, you're not going to know exactly what's going on at every level. There's just too much variety in PC hardware for that to be doable. With no abstraction at all, you'd end up having to program for every possible piece of hardware available. You'd need to make your own drivers for every graphics card, every sound card, etc. Every time new hardware is released, you'd have to update your engine with drivers for it.

If you want to make software for PCs, you need to get used to the fact that you'll be working at a higher level than that. There will be drivers and APIs. You won't know exactly what the hardware is doing at all times.

If you want to make something that low level just for fun, I'd suggest going with an older platform. You could make a game for DOS, perhaps. I've been working on a Sega Genesis game. It's written entirely in assembly. There are no APIs, drivers, or even an operating system. It's just the hardware and whatever I put on the cartridge.

320x224
Back to top
Profile PM Email
WickedX
15
Years of Service
User Offline
Joined: 8th Feb 2009
Location: A Mile High
Posted: 5th Jul 2014 10:50
Link
I can fully appreciate everybody’s input here and I guess, I should get with the times. So, I have been going over my stack of C++ reference material. From what I’m reading what is safe or not, boils down to proper usage. The way I have been using delete to free the memory returned from DarkGDK’s string functions should crash the program if there is nothing on the heap to delete. Am I wrong?

Let's run through the code TheComet posted for the dbStr() function. This time using the proper corresponding overloaded functions.

char* dbStr(int iValue)


This function simply returns the value returned from calling the function Str(NULL, iValue).

DWORD Str(DWORD pDestStr, int iValue)


This function converts the value to a string and stores it in the internal - static LPSTR variable m_pWorkString. Since NULL is passed for pDestStr we can skip to GetReturnStringFromWorkingString().

LPSTR GetReturnStringFromWorkString(void)


This function defines the variable LPSTR pReturnString. As TheComet point out, g_pCreateDeleteStringFunction is a function pointer to the core function: CreateSingleString(). Lastly the function copies the working string to the LPSTR pReturnString variable.

void CreateSingleString(DWORD* dwVariableSpaceAddress, DWORD dwSize)


Since this function is called with dwSize>0, the function is using new to allocate memory. So, really how is it unsafe to use delete?
Back to top
Profile PM Email
TheComet
16
Years of Service
User Offline
Joined: 18th Oct 2007
Location: I`m under ur bridge eating ur goatz.
Posted: 5th Jul 2014 11:43 Edited at: 5th Jul 2014 11:45
Link
@WickedX - Thank you for analysing the source code.

It seems I was wrong. Can someone confirm that the following two code snippets do not cause memory leaks? (I don't have DarkGDK installed):

#1


#2


hands are ruined by repetitive stroking... - Mr. V, 2014
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-04-19 14:53:37
Your offset time is: 2024-04-19 14:53:37