Makefiles son una forma sencilla de organizar la compilación de código. Este tutorial es un muy simple ejemplo de lo que se puede hacer con “make”, pero pretende ser una guía de principiantes para que pueda crear rápida y fácilmente sus propios archivos make para pequeños proyectos.

Vamos a tomar el código de ejemplo del articulo anterior. Lo que representaría un típico programa principal, algo de código funcional en un archivo separado, y un archivo de inclusión, respectivamente.

 

 

Normalmente, se compilará esta colección de código ejecutando el siguiente comando:

Este comando compila los dos códigos fuente involucrados en la creación del binario ejecutable “main” el parámetro -I. le dice al compilador que los archivos de inclusión .hpp los tiene que buscar en el directorio actual “.”

Por desgracia, este enfoque de la compilación tiene dos problemas. En primer lugar, si se pierde el comando de compilación o se cambia de computadora tiene que volver a escribir desde cero el comando. En segundo lugar, si sólo está haciendo cambios a un archivo .cpp, recompilar todos los archivos de código fuente cada vez que necesita recompilar demanda mucho tiempo y es poco eficiente. Ambos problemas se puede solucionar mediante el uso de un archivo “Makefile” con las instrucciones necesarias para la generación del ejecutable.

El makefile más simple que se podría crear sería algo como:

 

Si pones estas regla en un fichero llamado Makefile o makefile  y ejecutas “make” en la línea de comandos se ejecutará el comando de compilación como esta escrito en el makefile.

Se pone luego del nombre del ejecutable que se generara el símbolo : seguido de los archivos de codigo fuente que son necesarios para su creación y en la linea siguiente el comando de compilación necesario. Es importante destacar que antes de la llamada al compilador en la segunda linea hay un “Tab

Con el fin de ser un poco más eficiente, vamos crear un nuevo archivos Makefile:

 

Ahora hemos definido algunas constantes CC y CFLAGS. Resulta que estos son constantes especiales que se usan para decirle a make como queremos compilar. En particular  CC es el macro que especifica el compilador que vamos a usar usar, y CFLAGS es la lista de las banderas a pasar al comando de compilación. Al poner los archivos de objetos – main.o y suma.o – en la lista de dependencias y en la regla, make sabe que debe compilar primero las versiones .cpp individualmente, y luego construir el ejecutable.

El uso de esta forma de makefile es suficiente para la mayoría de proyectos de pequeña escala. Sin embargo, hay una cosa que falta: la dependencia de los archivos de inclusión. Si se va a realizar un cambio en suma.hpp, por ejemplo, que make no vuelva a compilar los archivos .cpp. Con el fin de solucionar este problema, tenemos que decirle make que todos los archivos .cpp dependen de ciertos archivos .hpp. Podemos hacer esto escribiendo una regla simple y agregarlo al archivo MAKE.

 

Esta adición creamo primero la macro DEPS, que es el conjunto de archivos .hpp de los que  los archivos .cpp dependen. Entonces definimos una regla que se aplica a todos los archivos que terminan en el sufijo .o. La regla dice que el archivo .o depende de la versión .cpp del archivo y los archivos .hpp incluidos en la macro DEPS. La regla luego dice que para generar el archivo .o, make necesita compilar el archivo .cpp usando el compilador definido en la macro CC. La bandera -c dice que genere el archivo de objeto, -o $@ dice para ponga la salida de la compilación en el archivo con el nombre en el lado izquierdo de los :,  $< es el primer elemento de la lista de dependencias, y  la macro CFLAGS se define como lo hicimos anteriormente.

Bueno este es un simple tutorial con ejemplos de como usar la herramienta Make. Aun así apenas nos asomamos a ver todo el potencial que nos ofrece.

 

En nuestro articulo anterior Cómo organizar tu código fuente en C++  definíamos algunas pautas para organizar nuestro código en varios archivos a fin de mejorar su tratamiento. En este articulo vamos a ver como hacer esto con un ejemplo simple, tomemos para ello el siguiente ejemplo que suma dos números a través de una función:

Vamos a retirar la función suma a un nuevo archivo, para ello necesitamos crear en realidad dos nuevos archivos y modificar el original. Por una parte tendremos la implementación de la función suma en un nuevo archivo llamado en este caso suma.cpp:

Que simplemente contiene la implementación de la función suma, para poder incorporar esta implementación en otros códigos fuentes es preciso que creemos un nuevo archivo con la definición de la función, para hacerlo, creamos ahora un archivo llamado suma.hpp donde podemos observar que la h hace referencia a header.

Acá tenemos unicamente la definición de la función y un par de directivas de preprocesador, veamos de que se trata.

La primera parte se llama un guardia de cabecera o header guard en ingles, estas lineas impiden que un archivo de cabecera sea cargado mas de una vez mediante #include. Sirve para proyectos de software muy extensos especialmente.

La segunda parte es el contenido real del archivo .hpp, que debe ser las declaraciones de todas las funciones que queremos otros archivos puedan ver. Todos nuestros archivos de cabecera deben tener una extensión .hpp.

Finalmente el archivo principal main.cpp queda de la siguiente manera:

Observe que la segunda linea incluye las funciones definidas en suma.hpp que se implementan en suma.cpp. Ahora ya las podemos usar libremente y a discreción a lo largo de este código fuente.

Julio Cesar tenía la premisa de “Divide y Triunfaras”, y muy mal no le fue en sus conquistas. Vamos a ver como organizar nuestro código fuente dividiéndolo en fragmentos de código más fáciles y cómodos de manejar, vamos a aprender cómo hacerlo y bajo qué criterios.

Muchos programas simples se pueden escribir en un solo archivo fuente en C++, pero, cualquier proyecto serio va a necesitar dividir en varios archivos con el fin de ser más manejable.

Sin embargo, muchos programadores que recién comienzan no se dan cuenta de cuál es la importancia de esto, sobre todo porque algunos ya lo intentaron y se encontraron con tantos problemas que decidieron que no valía la pena el esfuerzo.

Este artículo intenta explicar por qué hacerlo y en un próximo artículo cómo hacerlo correctamente.

Voy a llamar a los archivos estándar de C ++ (por lo general con extensión .cpp) “archivos de codigo fuente”. Esto será para distinguirlos de los “archivos de cabecera” (por lo general con extensión .h o .hpp).

¿Por qué dividir el código en varios archivos?

La primera pregunta que algunos programadores novatos se hacen cuando ven un directorio lleno de archivos de código fuente es, “¿por qué no está todo en un solo archivo?”

La división de cualquier proyecto de tamaño razonable nos provee de algunas ventajas, las más significativas de las cuales son las siguientes:

  • Acelerar la compilación – la mayoría de los compiladores trabajan en un archivo a la vez. Así que si todos sus 10000 líneas de código se encuentra en un archivo, y cambian una línea, entonces usted tiene que recompilar 10000 líneas de código. Por otro lado, si sus 10000 líneas de código se distribuyen uniformemente a través de 10 archivos, a continuación, cambiar una línea única requerirá compilar solo 1.000 líneas de código. Las 9000 líneas en los otros 9 archivos no necesitarán volver a compilarse.
  • Aumentar organización – La división de su código a lo largo de líneas lógicas, será más fácil para usted (y los otros programadores del proyecto) para encontrar funciones, variables, declaraciones, etc.
  • Facilitar la reutilización de código – Si el código está cuidadosamente dividido en secciones que operan en gran medida de forma independiente el uno del otro, esto le permite utilizar ese código en otro proyecto, que le ahorra un montón de tiempo y trabajo en volver a escribir el código.
  • Compartir código entre los proyectos – El principio aquí es el mismo que con el tema reutilización. Al separar cuidadosamente código en determinados archivos, se hace posible que los múltiples proyectos que utilizan algunos de los mismos archivos de código sin duplicarlos. El beneficio de compartir un archivo de código entre los proyectos y no sólo utilizando la copia y pega es que cualquier corrección de errores realizados en ese archivo o archivos de un proyecto afectará el otro proyecto, por lo que ambos proyectos pueden estar seguros de utilizar la versión más reciente del código.
  • Dividir las responsabilidades de codificación entre los programadores – Para grandes proyectos, esta es quizás la principal razón para la separación de código en varios archivos. Sistemas de gestión de configuración y los sistemas de control de versiones como CVS o Git ayudarle con esto.

Ahora que ya estás convencido de que hay beneficios para la división de tu proyecto en varios archivos más pequeños. Así que, ¿cómo hacerlo? Aunque algunas de las decisiones que tomes serán razonablemente arbitrarias, hay algunas reglas básicas que debes seguir.

En primer lugar, mira cómo dividir el código en secciones. A menudo esto es mediante su división en subsistemas separados, o “módulos”, como el sonido, la música, gráficos, manejo de archivos, base de datos, etc.

Crea nuevos archivos con nombres significativos para saber de un vistazo qué tipo de código es el que contienen.

A veces es necesario que un módulo se divida en dos o más archivos, ya que podría tener sentido hacerlo por razones lógicas.

Una vez que haya dividirlo según este criterio los archivos de código fuente, el siguiente paso es considerar lo que va a entrar en los archivos de cabecera. Básicamente consiste en poner el código que suele estar en la parte superior del archivo de código fuente en un archivo de cabecera separado.

EL código que se pone  en un encabezado por lo general incluye algunos o todos de los siguientes:

  • definiciones de clases y struct
  • typedefs
  • prototipos de funciones
  • variables globales
  • constantes
  • macros #defined
  • directivas #pragma

Peligros potenciales

Las reglas dadas arriba son bastante generales y sólo sirven como punto de partida para la organización de su código. En casos sencillos, se puede seguir esas directrices. Sin embargo, hay algunos detalles más que se tienen que considerar.

En mi experiencia, hay cuatro errores básicos que las personas enfrentan cuando entran en el oscuro mundo de los archivos de cabecera definidos por el usuario.

  • Los archivos de código fuente ya no se compilan ya que no pueden encontrar las funciones o variables que necesitan.
  • Definiciones duplicadas en una clase o identificador se incluye dos veces en un archivo de origen.
  • Duplicar instancias de objetos dentro del código que compila bien. Este es un error que une, a menudo difícil de entender

Conclusión

Si se realiza correctamente, la organización de los archivos de esta manera puede acelerar su desarrollo sin perjudicar en absoluto o introducir algún problema adicional. A pesar de que parece que hay mucho que considerar cuando se hace así, con el tiempo se convierte en una práctica habitual.

Sólo recuerde estos puntos clave:

  • Divida el código siguiendo el criterio de identificar los modulos logicos
  • Use los archivos de .cpp para la implementación y los archivos .hpp para la interfaz

En la empresa estábamos trabajando sobre nuestros servidores de VOIP y nos dimos cuenta de que surgía la necesidad de poder conectar los teléfonos de la flota dentro de nuestra red (configurar SIP) y así poder hacer llamadas desde el exterior o simple llamas a internos utilizando datos, ya sea wi-fi o red móvil, buscando en internet no encontramos una página que nos explique bien la operatoria es por eso que preparamos este post.

Fuente: Synergo

Boost es un conjunto de librerias de software libre y revisión por pares preparadas para extender las capacidades del lenguaje de programación C++. Su licencia, de tipo BSD, permite que sea utilizada en cualquier tipo de proyectos, ya sean comerciales o no.

Su diseño e implementación permiten que sea utilizada en un amplio espectro de aplicaciones y plataformas. Abarca desde bibliotecas de propósito general hasta abstracciones del sistema operativo. Con el objetivo de alcanzar el mayor rendimiento y flexibilidad se hace un uso intensivo de plantillas. Boost ha representado una fuente de trabajo e investigación en programación genérica y metaprogramación en C++.

Varios fundadores de Boost pertenecen al Comité ISO de Estándares C++. La próxima versión estándar de C++ incorporará varias de estas bibliotecas.

Charlando con un amigo en el IRC sobre la posibilidad del anonimato en la red no pudimos llegar a una conclusion aceptable, si recuerdan el año pasado  una charla de la universidad de  Carnegie Mellon sobre como descifrar el software de anonimato Tor fue abruptamente sacada de la agenda de la conferencia de “hackers” Black Hat el año pasado, la comunidad de seguridad se preguntaba en ese entonces  si la investigación fue  entregada en secreto a agencias de la ley de los Estados Unidos quienes como sabemos buscan anular la ocultación de la los usuarios anónimos de Internet.

Ahora la organización  Tor Proyect dice que cree que el FBI usó la tecnica de ataque de Carnegie Mellon  y les pagó generosamente por el privilegio.

El Proyecto Tor en la tarde del miércoles envió a WIRED una declaración de su director Roger Dingledine acusando directamente Carnegie Mellon de proporcionar secretamente  sus investigaciones de como vulnerar TOR a el FBI a cambio de un pago de “por lo menos $ 1 millón de dolares.”

 

El equipo de inteligencia artificial de Project Oxford de Microsoft hizo una demostración de la tecnología de reconocimiento de emociones el miércoles durante el evento Future Decoded de la empresa. Esta tecnología emplea expresiones faciales universales para identificar los sentimientos expresados en las fotos.

La herramienta, que se ha lanzado en versión beta para los desarrolladores, entrena a las computadoras a reconocer ocho fases emocionales: ira, desdén, miedo, asco, felicidad, neutralidad, tristeza y sorpresa.

Fuente: CNet

Microsoft ha anunciado la disponibilidad de una actualización de seguridad para Windows Hyper-V para protegerlo contra una condición de denegación de servicio que puede ser activado con ciertos (CPU) chipsets. Aunque la debilidad reside en el chipset, Microsoft publica esta actualización de seguridad para proteger a los clientes.

La actualización evita la vulnerabilidad de la  CPU  mediante la prevención de que un sistema operativo active la explotacion.

Fuente: Miscrosoft Security

Los Módems ADSL te obligan a cambiar la contraseña de administrador interfaz web. Aunque
usted puede cambiar la contraseña de administrador en la interfaz web, la nueva contraseña no se aplica a ssh de manera que la clave continua siendo la nunca bien ponderada “admin”
Se recomienda cambiar la clave desde el shell.10A

Microsoft y Red Hat han anunciado un acuerdo que ayudará a sus clientes a adoptar la cloud híbrida al proporcionar mayor capacidad de elección y flexibilidad en el despliegue de las soluciones de Red Hat sobre Microsoft Azure. En el marco de este acuerdo, Microsoft ofrecerá Red Hat Enterprise Linux como opción preferente para las cargas de trabajo empresariales de Linux sobre Microsoft Azure. Además, Microsoft y Red Hat trabajarán juntas para responder a las necesidades de las empresas, ISV y desarrolladores para construir, desplegar y gestionar aplicaciones sobre software de Red Hat en nubes públicas y privadas.

Fuente: Diario TI