¿Importancia de compilar v. V. Multi-subprocesos (y convenciones de nombres lib)?

Question

Editar] ==>Para aclarar, en aquellos entornos donde se implementan múltiples objetivos en el mismo directorio, Planet Earth ha decidido una convención para agregar "d" o "_d" o "_debug" hacia "DEBUG"Versión (de una biblioteca o ejecutable). Tal convención puede considerarse" ubicua "y" entendida ", aunque (por supuesto) no todos hacen esto.

Del mismo modo, para resolver la ambigüedad entre las versiones "compartidas" y "estáticas" de una biblioteca, una convención común es agregar algo para distinguir entre los estáticos y el intercambio (como "myfile.lib"para compartir-importación-libra-on-windows y"myfile_s.lib"Para static-import-liber-on-windows). Si bien Posix no tiene esta ambigüedad basada en la extensión del archivo, recuerde que la extensión del archivo no se usa en la" línea de enlace ", por lo que es igualmente útil poder explícitamente Especifique la versión "estática" o "compartida" de una biblioteca.

Para el propósito de esta pregunta, ambos "debug/release" y "static/shared"son promovidos a "Convención ubicua para decorar la raíz del nombre del archivo".

PREGUNTA: ¿Cualquier otra configuración de implementación se "promociona" a este nivel de "convención ubicua" de modo que se volvería explícito en el nombre de la raíz de destino del archivo?

Mi suposición actual es "no". Para que la respuesta sea "sí", requeriría: más de una configuración para el objetivo dado está destinado a ser "utilizado" (y así implementado en un directorio común, que es la base asumida para la pregunta).

En el pasado, compilamos y sin la capacidad del "complemento web", que de manera similar requería esa decoración de nombres, pero ya no construimos esos objetivos (por lo que no lo afirmaré como ejemplo). Del mismo modo, a veces compilamos sin y sin soporte de personajes de múltiples bytes, pero lo odio, así que tampoco lo afirmaré.

Pregunta original

Fueron Establecer convenciones de nombres de la biblioteca/política, para ser aplicado en todos los idiomas y plataformas (Por ejemplo, admitimos productos híbridos que utilizan varios idiomas en diferentes plataformas, incluidas C/C ++, C#, Java). Un objetivo particular es garantizar que manejemos objetivos/recursos para el desarrollo móvil (que es nuevo para nosotros) además de nuestras aplicaciones tradicionales de escritorio (e integradas).

Por supuesto, una La opción es tener diferentes rutas para objetivos de diferentes configuraciones de compilación. Para el propósito de esta pregunta, se toma la decisión de tener todos los objetivos ubicados a un solo directorio y "decorar" el nombre de biblioteca/recurso/ejecutable para evitar colisiones basadas en la configuración de compilación (por ejemplo, "debug" v. "Libere", "estática lib" v. "Shared/dll", etc.)

La decisión actual es similar a otros en la web, donde agregamos tokens para evitar nombrar colisiones:

  MyName.lib           (release build, import for shared/dll)
  MyName_s.lib         (release build, static lib)

  MyName_d.lib         (debug build, import for shared/DLL)
  MyName_ud.lib        (Unicode/wide-char, debug, import for shared/DLL)
  MyName_usd.lib       (Unicode/wide-char, static lib, debug)

(Los anteriores son ejemplos de Windows, pero estas políticas se aplican de manera similar a nuestros sistemas POSIX).

Estos se basan en:

  d     (release or debug)
  u     (ASCII or Unicode/wide-char)
  s     (shared/DLL or static-lib)

PREGUNTA: No tenemos aplicaciones heredadas que deben compilarse de un solo hilo, y mi entendimiento es que (a diferencia de Microsoft) los sistemas POSIX pueden vincular objetivos de un solo y múltiples subprocesos en una sola aplicación sin problemas. Dado el impulso de hoy hacia múltiples núcleos y múltiples subprocesos, ¿Hay alguna necesidad en un gran empresa ¿Para establecer lo siguiente para identificar objetivos compilados "versus" multiproceso "?

  t       (single-threaded or multi-threaded)  *(??needed??)*

... ¿Y perdimos alguna otra colisión objetivo, como compilar y sin STL (en C ++)?

Como aparte, Microsoft tiene convenciones de nombres de biblioteca en:http://msdn.microsoft.com/en-us/library/aa270400(v=vs.60).aspx y sus convenciones de nombres de dll en: http://msdn.microsoft.com/en-us/library/aa270964(v=vs.60).aspx

Hace un año, una pregunta similar que no habló sobre los subprocesos y no hizo referencia a las convenciones de Microsoft en: ¿Cuál es la convención adecuada de nomenclatura para DLLS MSVC, bibliotecas estáticas y bibliotecas de importación?

Answer 1

Estás usando un compilador antiguo. No es necesario establecer tal estándar en una empresa, el proveedor ya lo ha hecho. Microsoft no ha enviado una versión única del CRT durante los últimos 13 años. Del mismo modo, Windows ha sido un sistema operativo Unicode durante los últimos 17 años. Tiene sentido cero escribir código agnóstico Unicode en estos días.

Pero sí, la convención común es agregar una "D" para la construcción de depuración de una biblioteca. Y para darle a una versión DLL de una biblioteca un nombre completamente diferente.