Es porque tienes esto:


Pero SuperficiesDeImagenes no es un puntero. De hecho ni siquiera es ningún tipo de variable, sino sólo el nombre de un tipo de dato que has creado.

Como esto es algo muy básico, te recomendaría que no dejes de repasar apuntes o manuales de C++ que tengas. Es prácticamente imposible aprender algo complejo como programación de juegos sin tener antes conocimientos muy sólidos del lenguaje.

Pues exactamente como te dijo YreX-DwX. Tu problema era que estabas usando el operador de dirección & cuando no debías, complicando un problema que en realidad es muy simple. Cada uno de los 10 elementos del arreglo claveHabitacion es a su vez un arreglo char. Tan solo con que escribas
ya te estás refiriendo a una cadena, y no necesitas hacer nada más. Así, para imprimir la cadena en la posición 9, simplemente pide a printf que imprima
  de nuevo, SIN &. O bien, haz como te dijo YreX-DwX, y manda a imprimir pm, y ya.

Tal cual te lo explicó Loretz. Creo que yo te confundí cuando te dije que dependía. Pasa que C deja muchas cosas abiertas a que los compiladores las implementen como quieran, siempre que cumplan con ciertas condiciones. En el caso de los punteros a funciones, sé que al menos en algún compilador viejo de C, no apuntaban directamente a la dirección de la función, sino a una estructura rara y de ahí ya la localizaban. En realidad, con los compiladores/arquitecturas actuales, puedes estar bastante seguro de que apuntan a la dirección de la función en el segmento de código. Es sólo que el pedante que a veces habita en mí sale y dice: ¡no necesariamente!  . Eso sí, no olvides que esto se refiere a punteros a funciones; en el caso de funciones miembro, como dice Loretz, es algo muy diferente y depende totalmente de cada implementación.

Por cierto, los ejemplos que habías puesto al principio, donde los punteros estaban en la pila, son correctos siempre que los punteros sean variables locales no static. Las variables globales y las variables locales declaradas como static, (llamémoslas de forma general, variables de duración estática), se localizan en el segmento de datos. Para ser más específicos (dado que puede que leas sobre esto en otro lado y te puedas confundir), en el archivo compilado, las variables de duración estática inicializadas (ejemplo: static int n = 5;) se colocan en la sección data. Las variables de duración estática no inicializadas no se suelen almacenar en el archivo binario (dado que no tienen ningún valor específico, no tendría caso ocupar espacio) sino que se coloca su tamaño conjunto en una sección llamada bss. Cuando el programa se ejecuta, los datos inicializados se colocan en el segmento de datos (data segment). En cuanto a los no inicializados, se reserva la cantidad de espacio que bss especifica, y se inicializan a cero, también en el segmento data. Porque una vez que el programa está en ejecución ya no se suele hacer distinción entre data y bss: todo se encuentra en data.

Editado: no sé qué pasó que mi mensaje había quedado hecho un lío. En fin, en resumen, si los punteros fueran globales o locales static, se encontrarían en el segmento de datos. Los datos apuntados por ellos, naturalmente, no se verían afectados.

La cuestión con los punteros a funciones es que depende del compilador, sistema operativo, etc. a dónde apunten. La respuesta obvia sería "a la dirección de la función", pero qué es exactamente eso o en dónde existe, depende de la implementación. Lo que sí podrías dar por hecho es que las funciones no viven ni en la pila ni en el heap. Típicamente las instrucciones ejecutables se colocan en un parte de la memoria conocida como el segmento de texto (a veces llamado segmento de código), que suele ser de sólo lectura.

Cuando se presiona una tecla "especial", como ins, supr, las flechas, etc., getch lee y retorna dos valores, uno que indica precisamente el hecho de que se presionó una tecla especial, y el siguiente, que devuelve el código de esa tecla. En Turbo C++ el código era 0, pero creo que en Windows es distinto. Puedes agregar un printf que muestre el código leido, justo después de tu primer _getch:


Al ejecutarlo, presiona la tecla que quieras probar, por ejemplo ins. y verás en pantalla los dos códigos, el primero, que es igual para todas las teclas especiales, y el segundo que es específico de ins, etc. Creo que sólo te interesa el primero, es decir, detectar tecla especial, y simplemente ignorarla (y la siguiente). En ese caso, pones justo después de tus _getch algo como:


Sólo se entrará al bucle si se presiona tecla especial, y se sale cuando se presiona una tecla "normal", que te interese procesar.

No. Es tal cuál lo puse. Reitero, yo me estoy guiando en lo que digimikeh pidió, que es un tamaño de 10x10.

Si es por practicar, lo puedes dejar. No va a fallar ni a darte problemas. Simplemente te decía que cuando hablamos de cosas tan simples, como unos pocos bytes, normalmente no vale la pena intentar optimizar. El realloc perfectamente puede decidir no cambiar nada, es decir, no "reducir" la memoria, y simplemente dejar todo como está. Es perfectamente válido y tu programa funcionará sin problemas, pero en ese caso estarías haciendo esa llamada de forma innecesaria (a eso me refería con contraproducente: estás trabajando de más, posiblemente sin beneficio).

Es simplemente un consejo general, que antes de optimizar hay que revisar bien lo que hacemos. Muchas veces una "optimización" hecha sin análisis, puede incluso hacer que un programa tenga un rendimiento peor al que tenía antes de la supuesta optimización. Pero te repito, como práctica no hay problema. Cuando tengas más experiencia ya sabrás cuándo vale la pena buscar optimizar y cuándo no.

Sí, sería como la pusiste. Obviamente estamos hablando de punteros, y en concreto, un puntero a punteros para simular matrices de manera dinámica. En una matriz "real" (arreglo bidimensional):


la memoria es toda contigua y existe en la pila, pero evidentemente, y desde que estás hablado de punteros a punteros, no es a lo que te refieres. A menos que te haya entendido mal.

Bueno, en realidad es "\b \b", pero supongo que sólo fue error de dedo. Veo algunos problemas con tu código, pero como no usaste etiquetas GeSHi, no sé si algunos sean sólo partes que se "comió" el foro.

Algunos detalles: ¿qué pasa si el usuario presiona y presiona y presiona retroceso muchas veces?

Luego tienes esto:
El return hace que la ejecución del programa regrese a main, por lo que no tiene sentido poner instrucciones después, ya que nunca se ejecutarán. Y de cualquier forma, ese free era incorrecto. Quien llama a tu función es quien debe liberar esa memoria. Si tú la liberaras dentro de la función Password, ya no es válida. Siendo un programa tan simple y pequeño, probablemente aún así funcionaría "correctamente" (por pura suerte) pero sería un error.

El realloc está de más. Es un ejemplo perfecto de optimización prematura. Intentar ahorrarte unos pocos bytes realmente no optimiza nada (quizás hace un par de décadas y si estuvieras programando para un microcontrolador con unos pocos KB de memoria, pero hoy...) y de hecho puede ser contraproducente. Por cuestiones de eficiencia, funciones como malloc y realloc pueden reservar más memoria que la que les pides. Puede ser, por ejemplo, en bloques múltiplos de cierto número. El caso es que, sobre todo sabiendo que estás reservando sólo unos pocos bytes, es probable que realloc considere más eficiente dejar que se "desperdicien" unos pocos bytes, y decida no tocar esa memoria, con lo cual, sólo estarías complicando más tu código, llamando a una función innecesariamente, y sin ahorrarte un sólo byte. Las optimizaciones hay que hacerlas cuando realmente tengamos la necesidad, hayamos identificado un problema, y hayamos sopesado pros y contras. Hacerlas por hacerlas suele traer problemas y muy poco (normalmente ningún) beneficio.

No quedaría de ninguna forma, porque tu código ni siquiera compilaría. Sería más bien:


Lo que tendrías es: el puntero matriz en la pila, apuntando al inicio de un bloque (localizado en el heap) de 10 punteros, cada uno de los cuales apuntaría al inicio de un bloque de 10 enteros, ubicados también en el heap.