x64 visual microsoft descargar c++ visual-studio microsoft-runtime-library

descargar - microsoft visual c++ 2015



Microsoft Visual Studio ~ C/C++ Runtime Library ~ Enlaces estáticos/dinámicos (2)

Soy un usuario de Microsoft Visual Studio. Mi pregunta es sobre "C / C ++ Runtime Library".

Creé un "Proyecto vacío" con un archivo fuente ".cpp" "main.cpp" que contiene el siguiente código:

#include <iostream> int main(void) { std::cout << "Hello World" << std::endl; return 0; }

"iostream es un archivo de cabecera que se utiliza para la entrada / salida en el lenguaje de programación C ++. Es parte de la biblioteca estándar de C ++".

  1. ¿Hay alguna diferencia entre "C / C ++ Runtime Library" y "C / C ++ Standard Library"?

  2. ¿Cómo puedo saber si la biblioteca "C / C ++ Runtime Library" está vinculada estática o dinámicamente al proyecto?

  3. ¿Cómo sé dónde se encuentra esta biblioteca en el sistema de archivos?

  4. En el caso, la "Biblioteca de tiempo de ejecución de C / C ++" está vinculada dinámicamente al proyecto, ¿cómo puedo saber qué ".dll" se usa y dónde se encuentra ".dll" en el sistema de archivos?

  5. Supongamos que enlace estáticamente la "Biblioteca de tiempo de ejecución de C / C ++" al proyecto, ¿puedo estar seguro de que el ejecutable generado a partir del código fuente funcionará en todas las plataformas de Windows (XP / Vista / Seven / ..., 32 bit / 64 poco)?

  6. ¿Cuáles son las ventajas / desventajas de vincular dinámicamente la "Biblioteca de tiempo de ejecución C / C ++" al proyecto?

  7. ¿Debería el enlace "C / C ++ Runtime Libray" estar vinculado estática o dinámicamente al proyecto?

Gracias por sus respuestas.

El término "biblioteca en tiempo de ejecución C / C ++" no significa nada, es más o menos el nombre de una configuración de proyecto en el IDE. Proyecto + Propiedades, C / C ++, Generación de código, Configuración de biblioteca en tiempo de ejecución. Allí puede elegir entre / MD y / MT.

Con / MD, la configuración predeterminada, su programa utilizará la versión DLL de las bibliotecas de tiempo de ejecución. En su máquina, fueron copiados en c: / windows / system32 y / o c: / windows / syswow64 por el instalador de Visual Studio. Y tiene copias de ellas en el subdirectorio vc / redist del directorio de instalación de VS, que puede usar cuando crea un instalador para su programa. Tres versiones de ellos, x86 para procesadores Intel de 32 bits, x64 para procesadores Intel de 64 bits y brazo para procesadores ARM. Elija el correcto según la Plataforma que seleccionó en su proyecto.

Los nombres de DLL relevantes son:

  • msvcr110.dll: la biblioteca de tiempo de ejecución de C (memcpy et al)
  • msvcp110.dll: la biblioteca estándar de C ++ (std :: string et al)
  • vccorlib110.dll: la biblioteca de tiempo de ejecución para aplicaciones de la Tienda Windows
  • vcomp110.dll: la biblioteca de tiempo de ejecución para OpenMP (ver #pragma omp)
  • atl110.dll: la biblioteca de tiempo de ejecución para proyectos ATL
  • mfc110 * .dll: bibliotecas de tiempo de ejecución y localización para proyectos MFC
  • vcamp110.dll: la biblioteca de tiempo de ejecución para proyectos de AMP

En su máquina, también tiene las compilaciones de depuración de esas DLL, copiadas al directorio de Windows por el instalador de VS. Tienen el mismo nombre con la letra "d" adjunta. Útil solo para depurar su código, no puede redistribuirlos. La configuración correspondiente de la Biblioteca de tiempo de ejecución es / MDd.

La mayoría de los proyectos de C ++ solo necesitan msvcr110.dll y msvcp110.dll, usted sabría cuando opta por utilizar las otras bibliotecas, ya que hay plantillas de proyectos y configuraciones específicas para ellas.

Una forma simple de obtener todas estas DLL instaladas en la máquina de su usuario es usar el instalador precompilado. Puede descargarlo desde aquí (nota: actual solo a partir de hoy, esto puede cambiar cuando esté disponible un service pack o una actualización). O simplemente puede copiarlos en el mismo directorio que su EXE principal.

Puede evitar tomar una dependencia en estos archivos DLL cambiando la configuración de la Biblioteca de tiempo de ejecución a / MT. En cuyo caso, el código de soporte de tiempo de ejecución está vinculado a su programa y solo tendrá que ejecutar un único EXE. Por supuesto, se hará más grande cuando lo haga, a veces de manera significativa, especialmente cuando usa MFC.

Usar / MT es arriesgado si crea DLL así como también un EXE. Terminará con múltiples copias del CRT en su programa. Esto fue especialmente un problema con versiones anteriores de VS donde cada CRT obtendría su propio montón, no tanto con VS2012. Pero aún puede tener problemas de tiempo de ejecución desagradables cuando tiene más de una variable "errno", por ejemplo. Se recomienda utilizar / MD para evitar dicha pérdida.

Su programa se ejecutará en Windows Vista, 7 y 8. El soporte para XP está disminuyendo, necesitará VS Update 1 y cambiará la configuración del conjunto de herramientas en el proyecto de "v110" a "v110_xp" para crear un programa que todavía se ejecute en XP . Algunas funciones se pierden cuando lo hace, asociado con la configuración regional y el almacenamiento local de subprocesos, es necesario realizar pruebas.

aquí no pasa nada ... por favor, repítelo si encuentra un error.

1. ¿Hay alguna diferencia entre "C / C ++ Runtime Library" y "C / C ++ Standard Library"?

si y no. a veces las personas usan la biblioteca de tiempo de ejecución para significar todo e ignoran por completo la biblioteca estándar (para las herramientas de Microsoft). sin embargo, técnicamente, la biblioteca de tiempo de ejecución se carga en tiempo de ejecución, por lo que incluye el par .lib (import lib) y .dll. mira aquí para más detalles: http://msdn.microsoft.com/en-us/library/vstudio/abx4dbyh(v=vs.100).aspx

técnicamente, libc * son bibliotecas estándar y * crt son bibliotecas de tiempo de ejecución.

2. ¿Cómo puedo saber si la biblioteca "C / C ++ Runtime Library" está vinculada de forma estática o dinámica al proyecto?

Si está utilizando el IDE (VS2010, otros son similares), esto está en las propiedades del proyecto:

- configuration properties - c/c++ - code generation [Runtime Library]

3. ¿Cómo sé dónde se encuentra esta biblioteca en el sistema de archivos?

Los archivos lib se encuentran en el directorio lib de su sdk (si instaló una versión posterior de Windows sdk) o en el directorio visual c ++.

4. En el caso, la "Biblioteca de tiempo de ejecución de C / C ++" está vinculada dinámicamente al proyecto, ¿cómo puedo saber qué ".dll" se usa y dónde se encuentra el ".dll" utilizado en el sistema de archivos?

Puede averiguar cuáles se usan al usar la herramienta de los dependientes. http://www.dependencywalker.com/

Los archivos DLL están en algún lugar del directorio de Windows. Los mueven y ahora están en lugares originales con manifiestos y cosas para hacer un seguimiento de la versión. No me preocuparía demasiado por esto. Si tienes que preocuparte por esto, es probable que algo esté mal. Para más detalles: http://msdn.microsoft.com/en-us/library/windows/desktop/aa375365(v=vs.85).aspx http://en.wikipedia.org/wiki/Side-by-side_assembly

Si esto es una preocupación, puede agrupar un paquete redistribuible con su instalador: diferencia entre Visual Studio Redistributable y Visual Studio SP1

5. Supongamos que enlace estáticamente la "Biblioteca de tiempo de ejecución de C / C ++" al proyecto, ¿puedo estar seguro de que el ejecutable generado a partir del código fuente funcionará en todas las plataformas de Windows (XP / Vista / Seven / ..., 32 bit / 64 bit)?

sí, si enlazas estáticamente, estás más seguro en términos de no poder encontrar el dll. sin embargo, esto hace que tu ejecutable sea más grande. hay otras consecuencias en términos de comportamiento ... es difícil de enumerar, pero la diferencia proviene del hecho de que la biblioteca está en un dll vs compilada en su exe.

6. ¿Cuáles son las ventajas / desventajas de vincular dinámicamente la "Biblioteca de tiempo de ejecución de C / C ++" al proyecto?

¿Por qué usar dll?

Un tamaño. tamaño de exe más pequeño porque todas las cosas de la biblioteca están en el archivo DLL que se supone que ya se han instalado en el sistema del usuario, aunque a veces esto no es cierto.

b - si hay errores en el tiempo de ejecución, Microsoft puede enviar una nueva versión al usuario. no tienes que lidiar con eso. si vincula estáticamente, debe enviar un nuevo exe al usuario.

¿Por qué no usar dll?

a - muchos problemas con lidiar con dll. Si se olvida de agrupar la redirección, pueden aparecer muchos problemas.

b - tener más dlls para cargar y descargar causa un arranque y una salida más lentos.

probablemente otras razones que no he pensado ...

7. ¿El "C / C ++ Runtime Libray" debería estar vinculado de forma estática o dinámica al proyecto?

Realmente depende. Yo personalmente prefiero estáticamente vinculado. Odio gatear buscando el redist / dll / etc correcto.