Somos seres realmente destinados a la adaptación, incluso a las que quizá no deberíamos adaptarnos. El estilo de la librería CStash ha sido un modelo a seguir para los programadores en C durante mucho tiempo. Sin embargo, si nos ponemos a examinarla por un momento, nos daremos cuenta de que utilizar esta librería puede resultar incómodo. Cuando la usamos debemos, por ejemplo, pasar la dirección de la estructura a cada función de la librería. Por eso, cuando leemos el código, los mecanismos de la librería se mezclan con el significado de las llamadas a las funciones, lo cual dificulta la comprecsión del programa.

Sin embargo, uno de los mayores obstáculos al trabajar con librerías en C es el problema llamado conflicto de nombres (name clashes). C trabaja con un único espacio de nombres de funciones. Esto significa que, cuando el enlazador busca por el nombre de una función, lo hace en una única lista de nombres maestra. Además, cuando el compilador trabaja sobre una unidad de traducción, un nombre de función sólo puede hacer referencia a una única función con ese nombre.

Supongamos que compramos dos librerías de diferentes proveedores y que cada librería consta de una estructura que debe inicializar y destruir. Supongamos que cada proveedor ha decidido nombrar a dichas operaciones initialize() y cleanup(). ¿Cómo se comportaría el compilador si incluyéramos los archivos de cabecera de ambas librerías en la misma unidad de traducción? Afortunadamente, el compilador C dará un mensaje de error diciéndonos que hay una incoherencia de tipos en las listas de argumentos de ambas declaraciones. No obstante, aunque no incluyamos los archivos de cabecera en la unidad de traducción igual tendremos problemas con el enlazador. Un buen enlazador detectará y avisará cuando se produzca uno de estos conflictos de nombres. Sin embargo, hay otros que simplemente tomarán el primer nombre de la función que encuentren, buscando en los archivos objeto en el orden en el que fueron pasados en la lista de enlazado. (Este comportamiento se puede considerar como una ventaja ya que permite reemplazar las funciones de las librerías ajenas con funciones propias.)

En cualquiera de los dos casos, llegamos a la conclusión de que en C es imposible usar dos bibliotecas en las cuales existan funciones con nombres idénticos. Para solucionar este problema, los proveedores de librerías en C ponen un prefijo único a todas las funciones de la librería. En nuestro ejemplo, las funciones initialize() y cleanup() habría que renombrarlas como CStash_initialize() y CStash_cleanup(). Esta es una técnica lógica: decoramos los nombres de las funciones con el nombre de la estructura sobre la cual trabajan.

Este es el momento de dirigir nuestros pasos a las primeras nociones de construcción de clases en C++. Como el lector ha de saber, las variables declaradas dentro de una estructura no tienen conflictos de nombres con las variables globales. ¿Por qué, entonces, no aprovechar esta característica de las variables para evitar los conflictos de nombres de funciones declarándolas dentro de la estructura sobre la cual operan? O sea, ¿por qué no hacer que las funciones sean también miembros de las estructuras?