2012-01-13 16 views
10

El código fuente de nuestra aplicación es cientos de miles de líneas, miles de archivos y en lugares muy antiguos: la aplicación se escribió por primera vez en 1995 o 1996. En los últimos años, mi equipo ha mejorado mucho la calidad de la fuente , pero hay un problema que particularmente me molesta: muchas clases tienen muchos métodos completamente definidos en su archivo de encabezado.¿Herramienta para analizar fuentes C++ y mover los métodos en línea del encabezado al archivo fuente .cpp?

no tengo ningún problema con los métodos declarados en línea en un encabezado en algunos casos - el constructor de una estructura, un método simple donde inlining mensurable hace que sea más rápido (tenemos algunas funciones matemáticas como éste), etc. Sin embargo, el uso liberal de métodos inline sin razón aparente es:

  • sucia
  • hace que sea difícil encontrar la puesta en práctica de un método (especialmente buscando a través de un árbol de clases para una función virtual, sólo para encontrar una clase tuvo su versión declarado en el encabezado ...)
  • Probablemente aumente el tamaño del código compilado
  • Probablemente cause problemas para nuestro enlazador, que es notoriously flaky for large codebases. Para ser justos, ha mejorado mucho en los últimos años, pero no es perfecto.

Este último motivo ahora puede estar causando problemas para nosotros y es una buena razón para ir a través de la base de código y mover la mayoría de las definiciones al archivo fuente.

Nuestra base de código es enorme. ¿Existe alguna herramienta automatizada que pueda hacer (la mayoría de) esto por nosotros?

Notas:

  • Utilizamos Embarcadero RAD Studio 2010. En otras palabras, el dialecto de C++ incluye VCL and other extensions, etc.
  • Unos cabeceras son independientes, pero la mayoría están emparejados con un correspondiente. archivo cpp, como lo haría normalmente. Además de la extensión, el nombre de archivo es el mismo, es decir, si hay métodos definidos en X.h, se pueden mover a X.cpp. Esto también significa que la herramienta no tiene que manejar el análisis del proyecto completo; probablemente podría simplemente analizar pares individuales de archivos .cpp/.h, ignorar los elementos incluidos, etc., siempre que pueda reconocer de manera confiable un método con un cuerpo definido en una declaración de clase y moverlo.
+0

http://stackoverflow.com/questions/6362995/c-refactoring-move-method-to-implementation-file duplicate? – Zuljin

+11

Obtenga un interno para hacerlo. –

+1

@Zuljin: hmm, posiblemente ... ¡Pero no hay respuestas aplicables! (VS complementos, sin indicación de cambios masivos en sus sitios web, y lo más votado de todos los comentarios y respuestas es algo que dice 'Oh, puedes crear fácilmente un guión ...' No creo 'fácil' y 'parse C++' normalmente van juntos!) –

Respuesta

6

Puede probar Lazy C++. No lo he usado, pero creo que es una herramienta de línea de comandos para hacer exactamente lo que quieres.

+0

+1: no conozco esta herramienta :) – neuro

+0

+1, nunca antes había escuchado eso. ¡Una búsqueda rápida hace que parezca una herramienta muy útil para este tipo de cosas! –

+0

Me puse en contacto con el autor después de leer las preguntas frecuentes. La herramienta requiere escribir código en un archivo .lzz, que Lazy C++ analiza y divide en archivos CPP y H. Creo que combinar nuestro código en archivos individuales solo para tener una herramienta dividirlos de nuevo podría ser tanto trabajo ... :) Gracias por la sugerencia, es una herramienta interesante. –

3

Si el código funciona, votaría en contra de cualquier reescritura automática importante.
Se podría necesitar mucho trabajo para arreglarlo.

Pequeñas mejoras iterativas en el tiempo es una mejor técnica, ya que podrá probar cada cambio en forma aislada (y agregar pruebas unitarias). De todos modos, su principal queja sobre no poder encontrar el código no es un problema real y ya está resuelto. Ya hay herramientas que indexarán su base de código para que su editor salte a la definición de función correcta sin tener que buscarla. Eche un vistazo a los ctags o el equivalente de su editor.

  • sucia

    Subjetiva

  • hace que sea difícil encontrar la implementación de un método (especialmente buscando a través de un árbol de clases para una función virtual, sólo para encontrar una clase tenía su versión declarada en el encabezado ...)

    Ya hay t ools disponibles para encontrar la función. ctags creará un archivo que le permite ir directamente a la función desde cualquier editor decente (vim/emacs). Estoy seguro de que su editor si alguno de estos tiene la herramienta equivalente.

  • aumenta Probablemente el tamaño del código compilado

    improbable. El compilador elegirá alinear o no en función de las métricas internas, no meteorológicas, ya que está marcado en línea en la fuente.

  • Probablemente causa problemas para nuestro enlazador, que es notoriamente escamoso para bases de código grandes. Para ser justos, ha mejorado mucho en los últimos años, pero no es perfecto.

    Unlikely. Si su enlazador es escamoso, entonces es escamoso, no va a hacer mucha diferencia dónde se definen las funciones, ya que esto no influye si están incluidas de todos modos.

+0

+1 por "Mucho trabajo podría estar involucrado en arreglarlo". Incluso diría que "Mucho trabajo ** estará ** involucrado en arreglarlo". – Sjoerd

+0

Gracias Loki. No quiero hacer una 'reescritura' - Quiero mantener el código lógico idéntico, simplemente mover su ubicación. Sé que no es tan simple como eso, pero ... :) Anticipo tal vez ejecutar una herramienta y revisar manualmente sus cambios, y conozco muy bien la base de código a pesar de su tamaño, por lo que me siento bastante seguro acerca de ese lado de eso. Algunos de los otros puntos, [esta pregunta SO] (http://stackoverflow.com/questions/6895408/to-inline-or-not-to-inline) pueden interesarte. –

1

usted tiene un número de problemas a resolver:

  • Cómo reagrupar a los archivos de origen y de cabecera idealmente
  • cómo automatizar las modificaciones de código para llevar esto a cabo

En ambos casos, necesita un analizador de C++ robusto con resolución de nombre completo para determinar las dependencias con precisión.

Luego necesita maquinaria que pueda modificar de manera confiable el código fuente de C++.

Nuestro DMS Software Reengineering Toolkit con su C++ Front End podría ser utilizado para esto. DMS se ha utilizado para la reestructuración de código C++ a gran escala; ver http://www.semdesigns.com/Company/Publications/ y rastrear el primer documento "Estudio de caso: Reingeniería de modelos de componentes en C++ a través de la transformación automática de programas". (Hay una versión anterior de este documento que puede descargar desde allí, pero la publicada es mejor). AFAIK, DMS es la única herramienta que se ha aplicado alguna vez para transformar C++ a gran escala.

Este SO discussion on reorganizing code soluciona el problema de agrupar directamente.

1

XE2 incluye un nuevo analizador estático. Podría valer la pena dar un giro a la nueva versión de la prueba de C++ Builer.

+0

Gracias David! De hecho, tengo una copia de C++ Builder XE2 Pro, así que lo intentaré con eso. (Aunque el trabajo se ha mantenido firme en 2010, estamos esperando que se actualice de 64 bits nuevamente, trato de mantenerme actualizado, por lo tanto, mi propia copia). Solo he intentado las refactorizaciones disponibles en 2010 antes, y no fueron muy confiable. –

Cuestiones relacionadas