Si es gerente, su trabajo es adquirir recursos para su equipo, para superar las barreras en el camino del éxito de su equipo, y en general para intentar proporcionar el entorno más productivo y agradable de modo que sea más probable que su equipo realice esos milagros que se le piden siempre. Cambiar a C++ cae en tres de estas categorías, y puede ser maravilloso si no le costara nada. Aunque cambiar a C++ puede ser más económico - dependiendo de sus restricciones [31] - como las alternativas de la POO para un equipo de programadores de C (y probablemente para programadores en otros lenguajes procedurales), no es gratis, y hay obstáculos que debería conocer antes de intentar comunicar el cambio a C++ dentro de su compañía y embarcarse en el cambio usted mismo.
El coste del cambio a C++ es más que solamente la adquisición de compiladores C++ (el compilador GNU de C++, uno de los mejores, es libre y gratuito). Sus costes a medio y largo plazo se minimizarán si invierte en formación (y posiblemente un mentor para su primer proyecto) y también si identifica y compra librerías de clases que resuelvan su problema más que intentar construir las librerías usted mismo. Hay costes que se deben proponer en un proyecto realista. Además, están los costes ocultos en pérdidas de productividad mientras se aprende el nuevo lenguaje y posiblemente un nuevo entorno de programación. Formar y orientar puede minimizar ese efecto, pero los miembros del equipo deben superar sus propios problemas para entender la nueva tecnología. A lo largo del proceso ellos cometerán más errores (esto es una ventaja, porque los errores reconocidos son el modo más rápido para aprender) y ser menos productivos. Incluso entonces, con algunos tipos de problemas de programación, las clases correctas y el entorno de programación adecuado, es posible ser más productivo mientras se está aprendiendo C++ (incluso considerando que está cometiendo más errores y escribiendo menos líneas de código por día) que si estuviera usando C.
Una pregunta común es, «¿La POO no hace automáticamente mis programas mucho más grandes y lentos?» La respuesta es: «depende». Los lenguajes de POO más tradicionales se diseñaron con experimentación y prototipado rápido más que pensando en la eficiencia. De esta manera, prácticamente garantiza un incremento significativo en tamaño y una disminución en velocidad. C++ sin ambargo, está diseñado teniendo presente la producción de programación. Cuando su objetivo es un prototipado rápido, puede lanzar componentes juntos tan rápido como sea posible ignorando las cuestiones de eficiencia. Si está usando una librerías de otros, normalmente ya están optimizadas por sus vendedores; en cualquier caso no es un problema mientras está en un modo de desarrollo rápido. Cuando tenga el sistema que quiere, si es bastante pequeño y rápido, entonces ya está hecho. Si no, lo puede afinar con una herramienta de perfilado, mire primero las mejoras que puede conseguir aplicando las características que incorpora C++. Si esto no le ayuda, mire las modificaciones que se pueden hacer en la implementación subyacente de modo que no sea necesario cambiar ningún código que utilice una clase particular. Únicamente si ninguna otra cosa soluciona el problema necesitará cambiar el diseño. El hecho de que el rendimiento sea tan crítico en esta fase del diseño es un indicador de que debe ser parte del criterio del diseño principal. FIXME:Usar un desarrollo rápido tiene la ventaja de darse cuenta rápidamente.
Como se mencionó anteriormente, el número dado con más frecuencia para la diferencia en tamaño y velocidad entre C y C++ es 10%, y a menudo menor. Incluso podría conseguir una mejora significativa en tamaño y velocidad cuando usa C++ más que con C porque el diseño que hace para C++ puede ser bastante diferente respecto al que hizo para C.
La evidencia entre las comparaciones de tamaño y velocidad entre C y C++ tienden a ser anecdóticas y es probable que permanezcan así. A pesar de la cantidad de personas que sugiere que una compañía intenta el mismo proyecto usando C y C++, probablemente ninguna compañía quiere perder dinero en el camino a no ser que sea muy grande y esté interesada en tales proyectos de investigación. Incluso entonces, parece que el dinero se puede gastar mejor. Casi universalmente, los programadores que se han cambiado de C (o cualquier otro lenguaje procedural) a C++ (o cualquier otro lenguaje de POO) han tenido la experiencia personal de una gran mejora en su productividad de programación, y es el argumento más convincente que pueda encontrar.
Cuando su equipo empieza con la POO y C++, típicamente los programadores pasan por una serie de errores de diseño comunes. Esto ocurre a menudo porque hay poca realimentación de expertos durante el diseño e implementación de los proyectos iniciales, porque ningún experto ha sido desarrollador dentro de la compañía y puede haber resistencia a contratar consultores. Es fácil pensar que se entiende la POO demasiado pronto en el ciclo y se va por el mal camino. Algo que es obvio para alguien experimentado con el lenguaje puede ser un tema de gran debate interno para un novato. La mayor parte de este trauma se puede olvidar usando un experto externo para enseñar y tutorizar.
Por otro lado, el hecho de que estos errores de diseño son fáciles de cometer, apunta al principal inconveniente de C++: su compatibilidad con C (por supuesto, también es su principal fortaleza). Para llevar a cabo la hazaña de ser capaz de compilar código C, el lenguaje debe cumplir algunos compromisos, lo que ha dado lugar a algunos «rincones oscuros». Esto es una realidad, y comprende gran parte de la curva de aprendizaje del lenguaje. En este libro y en el volumen posterior (y en otros libros; ver el Apéndice C), intento mostrar la mayoría de los obstáculos que probablemente encontrará cuando trabaje con C++. Debería ser consciente siempre de que hay algunos agujeros en la red de seguridad.