Your member declaration is wrong.
You have declared mName as a
char, that is a single character (which will be easiest to compare to DBP's BYTE datatype).
C-style strings are
arrays of chars. That is also what DarkGDK (1) uses and they are usually defined as char* or through the typedef LPSTRING.
The string class offers much more convenience over the old c-strings (of course they are essentially wrapper classes over char arrays still so, but they present the strings in a more easily accessible way with appropriate operators and mutatability - while you can change the contents of a C-string, it cannot be resized so a native c-string can never grow larger than the char buffer you declared for it in the first place).
Anyway, your code fails with an ambiguity warning because there is no overload of the dbPrint() function that accepts a single
char as input. The char, being a numeric datatype at its core, can be implicitly cast to int however and there is a dbPrint(int) overload. But there is also a dbPrint(long) and a char can be implicitly cast to a long as well. Thus it is ambigous - the compiler cannot figure it out by itself. You can solve this by explicitly casting your char variable when passing it to dbPrint().
That would look like this:
dbPrint((int)character.mName) and would print the numeric value of 'character.mName'.
However, as you stated, you cannot write 'character.mName = "Fred"'; this is because "Fred" is a shortcut for writing the c-string, or char-array ['F', 'r', 'e', 'd', '\0']. But character.mName is a
single char.
If you insist on using c-strings you would solve this by changing its declaration to read
It now is a pointer to one or more characters (ie an array of them). Writing it as you have the constant string "Fred" will be allocated on the stack and thus be freed whenever it goes out of scope. With dynamically allocated c-strings you have to be wary to create and release their used memory yourself or you'll end up with memory leaks though. But you'll get to that later in your adventures I'm sure.
About my example, that is correct, I have mostly been using DarkGDK 2 lately which doesn't have that nuisance.
The thing is that dbPrint() expects a normal char*, while the std::string::c_str() member function returns a const char*.
As such you will have to do a const cast on it like so for it to work:
// Dark GDK - The Game Creators - www.thegamecreators.com
// the wizard has created a very simple project that uses Dark GDK
// it contains the basic code for a GDK application
// whenever using Dark GDK you must ensure you include the header file
#include "DarkGDK.h"
#include <sstream>
#include <string>
// the main entry point for the application is this function
void DarkGDK ( void ) {
// While you can put this in a loop that wasn't the idea. You can try that if it doesn't render anything though.
int a = 4;
float b = 9.21f;
char c = 'C';
std::string d = "This should print ";
std::stringstream ss;
ss << d << a << ", " << b << ", " << c;
dbPrint(const_cast<char*>(ss.str().c_str())); // Added a const cast so that the given and expected ypes match
dbSync();
dbSync();
dbWaitKey();
// return back to windows
return;
}
"Why do programmers get Halloween and Christmas mixed up?" Because Oct(31) = Dec(25)
