Hi guys,

A few questions about constructors in c++. Given two classes, one called "UserInput" and the other "TextField"

the situation looks like this.

class UserInput{
public:
	UserInput(int len):
		str_len(len)
	{
		SDL_EnableUNICODE(SDL_ENABLE);
	}
	void handleInput(){
		//do stuff here
	}
private:
	int str_len;
};

class TextField(){
	public:
		TextField():
			  user_input(20){
	
		}
		void handleInput(){
			  user_input.handleInput();
		}
	private:
		UserInput user_input;
};

When later in the program, I instatiate an instance of TextField and call the function

text_field.handleInput();

the SDL_EnableUNICODE(SDL_ENABLE); is not active.

I suspect, if I make user_input a pointer, and allocate it onto the heap, this problem will go away but I don't understand the nuts and bolts.

Could someone explain to me why this is so?

Thanks,

Mike

To be extra clear, you have nothing to gain from making it a pointer in this case.

If your code is written as your example (ignoring syntax errors), the UserInput constructor should be called when the TextField is created, so there must be some other problem.

Could you write here where the TextField instance it's created, and his scope?

the SDL_EnableUNICODE(SDL_ENABLE); is not active.

This is EXACTLY the problem with globally shared mutable state.

SDL provides a flag, "enable unicode", that is global across the entire application. You turn on the global flag in your constructor. Chances are good that somewhere else in your code base, or in some library somewhere that your application uses, the flag is getting changed.

So what do you do about it?

You can track it down with breakpoints.

You will need both a breakpoint on SDL_EnableUNICODE() inside SDL to catch where people are calling the function, and also a memory breakpoint on the actual value in case it gets modified through alternative channels.

If the function is inlined in any of the libraries then the function-level breakpoint may not work and you'll need to rely more heavily on the memory breakpoint.

Also, let it serve as a reminder to you for the reason that global shared state should be avoided.

Where is your SDL_Init call?

When do you actually create a "TextField"? Is it before or after the keys on the keyboard are actually pressed? I think you have to enable Unicode before the events start rolling in, not right before you read them.

Why did you put this in a "TextField" class instead of wherever you initialize SDL?

Are you misjudging what's happening? Maybe it is enabled and something else is causing whatever problem you're seeing.

Thanks for all the help guys. I think that Pink Horror and frob hit the nail on the head. After I moved the

SDL_EnableUNICODE(SDL_ENABLE); from the UserInput class to my initSDL() function, it solved the problem

completely. All is working as it should. Upon exiting the program, a call will also be made to SDL_EnableUNICODE(SDL_DISABLE)

I see what you mean about globally shared mutable states frob, and yes, lesson learned.

Mike