Dialogue class code for RPG

The following code draws a dialogue box on the screen with an image for the character you are talking to. It has no errors and compiles fine using allegro and MSVC++ .net. Feel free to use it or mod it some and if you mod it much toss me a copy so I can see what yea did. Feedback is welcome as well.

Special notes for this class:
It will hold the game up ex. a fireball is about to incinerate the player the player runs to a NPC and talks - he is safe untill he is done talking.

Two initial suggestions:
Use std::string instead of char*. Saves you a lot of trouble.
Move Initialize into the constructor. Saves you checks to see if the object is initialized or face the consequences.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

Two initial suggestions:
Use std::string instead of char*. Saves you a lot of trouble.
Move Initialize into the constructor. Saves you checks to see if the object is initialized or face the consequences.

char * or string really has no impact both work in very similar ways. In my code I like char* I have used it for years and haven't had issues yes it is depreciated, that does not mean it will not work. Another point would be found here http://www.allegro.cc/manual/api/text-output/textout_ex it calls for a char * not string.

Class was made implementaion specifc. Also this post was more for a refferance so people can use the code at will and was not ment to be asking how to improve it more of a I wonder how people will use it.

If you are writing code and know specificly to use an initalize funtion there is no reason that you should ever have an uninitalized class. My structure is _GENERALLY_

Code:

//define vars
//code

not something like the following that makes you look in two or possibly more spots to see the declaration of the variable.

Code:

//define some local vars
//code some load stuff
//make some more vars and use loaded info to populate the new vars
//code more stuff

The impact is that with std::string, or other string classes, you no longer need to do manual memory management. This can be of tremendous benefit, especially in the face of the possible throwing or propagating of exceptions in C++.

Originally Posted by ~Kyo~

Another point would be found here textout_ex it calls for a char * not string.

The parameter that you have in mind is of type const char*, which you can obtain by calling the c_str() member function of std::string.

Originally Posted by ~Kyo~

If you are writing code and know specificly to use an initalize funtion there is no reason that you should ever have an uninitalized class.

If you can eliminate the possibility of using an uninitialised object, or attempting to initialise the same object twice, then you might as well do so instead of using two phase construction.

Originally Posted by ~Kyo~

My structure is _GENERALLY_

Code:

//define vars
//code

That does explain your preference for two phase construction. However, if you make full use of your constructors to perform initialisation (as you should), you can then declare (and define) variables near first use. This helps in maintenance by keeping variables in as small a scope as feasible, while potentially improving performance by avoiding unnecessary work. Of course, there is also the benefit of correctness as has been mentioned, i.e., an object is always in a valid, initialised state.

Originally Posted by Bjarne Stroustrup (2000-10-14)

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

The impact is that with std::string, or other string classes, you no longer need to do manual memory management. This can be of tremendous benefit, especially in the face of the possible throwing or propagating of exceptions in C++.

The parameter that you have in mind is of type const char*, which you can obtain by calling the c_str() member function of std::string.

If you can eliminate the possibility of using an uninitialised object, or attempting to initialise the same object twice, then you might as well do so instead of using two phase construction.

That does explain your preference for two phase construction. However, if you make full use of your constructors to perform initialisation (as you should), you can then declare (and define) variables near first use. This helps in maintenance by keeping variables in as small a scope as feasible, while potentially improving performance by avoiding unnecessary work. Of course, there is also the benefit of correctness as has been mentioned, i.e., an object is always in a valid, initialised state.

You mention scope of variable which lies with implementation and the method of implementation.

This is the main block that uses this class the dialogue class is more for doing the draw routine than it is for a long term storage type class. While yes I could use it as a global function the class works better in terms of portability. Perhaps everyone thought it was used as a long term storage and rendoring situation which is not the case. I would think another option would be to overload the constructor, but as it stands with my current implementation it would be wasted code. The only difference I see is it would be in existance a split second less if I implement it the way that was offered - maybe in other situations it would help with memory management, but in this situation we are talking about <1k of memory that exists for the amount of time it takes for the person to read the text and hit enter which is still in an endless loop.

You say string would be a safer way to store data compared to a char * or even a char []. It also limits the data manipulation without calling your other class funtions. If you know you will NEED to do data manipulation on a structure why not leave it in a form that provides you with the access you need to begin with? The most common arguement is so that things don't "accidentally" get changed how do you have an accident in code you type do x then y then z the computer then performs x then y then z if it does something wrong your code is illogical you should not be manipulating data structures if you are reading them and if you really want to make it so people can not break it - assuming portability which is relevant in this case let us use const so no one screws the data up - which could also be placed into the class, but the class is tested and known to work which would mean it is not a requirement because we know the data doesn't get changed.

Note how you don't have to bother with freeing the memory, which you don't anyway. Less code, as well. Less clutter. Easier to read. Exception safe.

For the first statement, I have no idea what you mean. All we suggested is that instead of creating the object and then call Initialize, you simply call the constructor with the same arguments as Initialize, and then the object is ready to use.

And for the second... look at the code above. Much easier to understand and maintain. It is also exception safe. You don't have to free. Etc, etc.
You seem to have a C background. Not to tell you what to do, but you really should embrace what is already there for you. Why roll out your own solution? Using facilities brings down bugs and decreases security risks, so you can spend more time on implementing features rather than hunting down bugs. What is not to like?

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

You say string would be a safer way to store data compared to a char * or even a char []. It also limits the data manipulation without calling your other class funtions.

It does not limit the data manipulation that you can do.

I do not think that Elysia's code accurately copies what your code does. Assuming that temp is changed to a std::string, that Dialogue has a constructor that appropriately performs initialisation (i.e., it does the work that the Initialize member function currently does, with const std::string& parameters), and that an appropriate using declaration or using directive is in scope:

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

Though I did translate the code 1-to-1, as best I could. I did find some problems, though, such as uninitialized pointers and overwritten pointers. It was used to serve an example, not a working piece of code.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.