Algunas ventajas del uso de c++11.

C++ es un lengueaje de propósito general, el nuevo estándar centra sus esfuersos en dos aspectos fundamentales:

1. Hacer a c++ un mejor lenguaje para la programación de sistemas y creación de biliotecas.
2. Hacer a c++ más fácil de enseñar y aprender.

Hay muchas aplicaciones en las que podemos encontrar a c++ unas veces como lenguaje principal y otras veces usado en partes críticas de las mismas ej:

• Google, el motor de búsqueda.
• Amadeus, para venta de voletos de vuelo.
• Facebook, la red social.
• JVM (Oracle).
• Interpretes javascrip (google V8).
• Qt, framework para el desarrollo multiplataforma.
• POCO, para el desarrollo orientado a la web.
• OpenCV, para el tratamiento en tiempo real de imágenes.
• Navegadores Web (Internet Explorer, Mozilla, Google-Chrome, Safari).
• En general se pueden encontrar muchas aplicaciones en finansa, telecomunicaciones, drivers, el ejército, aplicaciones embebidas, videojuegos, matemática computacional(para lo que no fue originalmente creado, sin embargo está siendo ampliamente utilizado), robótica, entre muchas otras.

Como lo dice el título del post, acá les comparto algo de lo nuevo de c++11 antiguamente conocido como c++0x (si quieres una referencia más completa deberás leer un libro, yo recomiendo “The C++ Programming Language . Fourth Edition. Bjarne Stroustrup (el creador original de C++... que más se puede decir...)”, autores como estos además te recomiendan para ver material técnico específico la especificación de la iso(ISO C++ standard (ISO/IEC 14882-2011) [C++,2011] )).

Bueno las novedades de c++ abarcan la forma de escribir(sintácsis), el rendiemiento, facilidades de la biblioteca estandar, entre otras, de manera general son bastantes los cambios(a mi concideración para bien). C++11 salió ya hace algún tiempo: en 2009 se realiza una primera revisión del estándar a modo de borrador, en agosto de 2011 fue aprobado por la iso, en 2012 sale la primera implementación completa y hoy estamos aquí, algunos sin usarlo todavía a pesar de que actualmente es soportado por gcc(g++), clang, visualc++, por solo mencionar los compiladores más populares. Resulta que la “inercia” por lo que conocemos en ocaciones es muy fuerte y hace que nos estanquemos mientras la tecnología avanza. Yo concidero que un ingeniero no se debe medir tanto por lo que sabe como por lo que está dispuesto a aprender, una empresa que contrate un desarrollador o ingeniero en general que no esté dispusto a seguir los avances estaría adquiriendo un recurso humano que rapidamente quedaría sin soporte, es mejor tener un desarrollador LTS(Longer Time Support, :-P que se adapta a los cambios tecnológicos al pasar el tiempo).

Para ver un ejemplo de comparación del rendimiento(performace) del nuevo c++(c++11) en comparación con el antiguo(2003 que fue una revisión/corrección del c++ iso 1998) consideremos el siguiente ejemplo.

std::vector<int> getInts()

{

std::vector<int> ints;

for(int i =0; I <=10000000; i++) ints.push_back(i);

return ints;

}

Como podemos ver aquí se está creando un vector de enteros en un ámbito más reducido al que probablemente usará el valor de retorno, en este caso una vez que se tenga en memoria este vector al retornarlo se llama al constructor de copia para copiar uno por uno los elementos del vector para retornar esta copia y eliminar(de forma automática) de la memoria el creado originalmente, como te podrás dar cuenta tiene poco sentido esto de que teniendo los datos en meoria se cree una copia, se elimine el original y el copiado sea el que se use por el simple hecho de salirse del ámbito(el ámbito es la definición del espacio de vida de un objeto que puede ser global, de espacio de nombre, de clase, de función, de bloque, etc). Pués bien c++11 provee algunas soluciones a esto, una de ellas es la utilización de el contructor move que en vez de hacer una copia lo que hace es mover la dirección de memoria del dato en cuestión y entregarsela al ámbito que hizo el pedido.

Otra forma de resolver este problema hubiese sido usando un puntero reservando memoria para él de forma dinámica y retornando su dirección de memoria, esto en realidad es una solución implementable pero a la vez es un antipatrón ya que va en contra del principio de RAII (‘‘Resource Acquisition Is Initialization’’), o sea si la memoria se crea en este ámbito quién debería ser el responsable de eliminarla para mantener este esquema... pués c++11 también provee una solución elegante desde esta perpectiva y es con el uso de shared_ptr lo que crea un objeto de propiedad compartida que devolverá la memoria reclamada en cuanto el último de sus propietarios lo haga sin tener que llamar de forma explícita a delete.

Otro ejemplo es al usar regex(nuevo), si quieres representar una expresión que incluya algún slash invertido o comilla doble este debe ser precedido por un backslash(es a lo que se le llama escapar la cadena). Por ejemplo al representar lo siguiente:

string s = "\\w\\\\w"; // I hope I got that right

podemos darnos cuenta que esto es propenso a errore, para ello el nuevo c++(c++11) provee raw string literals en el cual un backslash es un backslash!!!, ej:

string s = R"(\w\\w)"; // I’m pretty sure I got that right

Otro ejemplo que me gustaría comentar, auto y range-for:

La palabra auto ha cambiado el significado de las antiguas versiones donde la había heredado de C, antes significaba que la variable era autodestruible, o sea escribir auto int era equivalente a int esto indicaba que el objeto llamaba a su destructor de forma automática al salirse del ámbito, ahora indica detecció de tipo desde el inicializador con lo cual podriamos por ejemplo escribir:

template<class T> void f1(vector<T>& arg)

{

for (vector<T>::iterator p = arg.begin(); p!=arg.end(); ++p) *p = 7;

for (auto p = arg.begin(); p!=arg.end(); ++p) ∗p = 7;

}

los cuales serían equivalentes y por su puesto el segundo más elegante que el primero.

El range-for te permite recorrer un contenedor de forma muy sencilla, tal como sigue:

void print_book(const vector<Entry>& book)

{

for (const auto& x : book) cout << x << '\n';

}

esto no se explica, solo se mira y el código habla por si solo, además comentar que para tener un contenedor propio capaz de usar esta cualidad solo hay que implemntar el begin y el end del contenedor.

Como último ejemplo las expresiones lambda o funciones lambda (simplemente lambda como también se les suele llamar). Lambda es una notación simplificada para definir y utilizar objetos o instancias de funciones anónimas. Esto es particularmente útil cuando pasas una operación como argumento a un algorimo, aquí puedes ver un ejemplo:

template<class C>

void print_modulo(const C& v, ostream& os, int m)

// output v[i] to os if v[i]%m==0

{

breadth_first(begin(v),end(v),

[&os,m](int x) { if (x%m==0) os << x << '\n'; }

);

}

Un ejemplo de la utilidad de esto lo puedes ver al usar signal/slog(un concepto de Qt framework).

Como podrás saber es imposible tratar en un simple post sobre todas estas nuevas características por lo que te dejo en manos de Stroustrup:

Here are what I consider the most widely useful new ‘‘building bricks’’ affecting the style of

C++11 code with references to the text and their primary authors:

• Control of defaults: =delete and =default: §3.3.4, §17.6.1, §17.6.4; Lawrence Crowl and

Bjarne Stroustrup.

• Deducing the type of an object from its initializer, auto: §2.2.2, §6.3.6.1; Bjarne Stroustrup.

I first designed and implemented auto in 1983 but had to remove it because of C compatibil-

ity problems.

• Generalized constant expression evaluation (including literal types), constexpr: §2.2.3,

§10.4, §12.1.6; Gabriel Dos Reis and Bjarne Stroustrup [DosReis,2010].

• In-class member initializers: §17.4.4; Michael Spertus and Bill Seymour.

• Inheriting constructors: §20.3.5.1; Bjarne Stroustrup, Michael Wong, and Michel Michaud.

• Lambda expressions, a way of implicitly defining function objects at the point of their use in

an expression: §3.4.3, §11.4; Jaakko Jarvi.

• Move semantics, a way of transmitting information without copying: §3.3.2, §17.5.2;

Howard Hinnant.

• A way of stating that a function may not throw exceptions noexcept: §13.5.1.1; David Abra-

hams, Rani Sharoni, and Doug Gregor.

• A proper name for the null pointer, §7.2.2; Herb Sutter and Bjarne Stroustrup.

• The range-for statement: §2.2.5, §9.5.1; Thorsten Ottosen and Bjarne Stroustrup.

• Override controls: final and override: §20.3.4. Alisdair Meredith, Chris Uzdavinis, and Ville

Voutilainen.

• Type aliases, a mechanism for providing an alias for a type or a template. In particular, a

way of defining a template by binding some arguments of another template: §3.4.5, §23.6;

Bjarne Stroustrup and Gabriel Dos Reis.

• Typed and scoped enumerations: enum class: §8.4.1; David E. Miller, Herb Sutter, and

Bjarne Stroustrup.

• Universal and uniform initialization (including arbitrary-length initializer lists and protec-

tion against narrowing): §2.2.2, §3.2.1.3, §6.3.5, §17.3.1, §17.3.4; Bjarne Stroustrup and

Gabriel Dos Reis.

• Variadic templates, a mechanism for passing an arbitrary number of arguments of arbitrary

types to a template: §3.4.4, §28.6; Doug Gregor and Jaakko Jarvi.

Para ver un pequeño ejemplo de c++11 en acción revisa:

Altadisponibilidad de servidores y balanceo de carga.

¿Por qué deberiamos migrar nuestro código a Qt5?

Con un tiempo ya de liberada la versión 5 del framework Qt existen proyectos y personas que aún no actualizan su código a la nueva versión(para garantisar soporte prolongado de las dependencias). Cuando salió Qt4 trajo con sigo grandes cambios en la API con respecto a Qt3 haciendo que la actualización a Qt4 del software escrito en Qt3 fuese una tarea relmente difícil, era casi como reescribir el programa. Por el contrario de lo que occurrió con Qt5 que ha mantenido armonía con la API de Qt4, la mayor parte de esta permanece idéntica, lo que hace que la transición de las aplicaciones basadas en Qt4 a Qt5 sea con menores dolores de cabeza de lo que fue alguna vez entre otras versiones.

En Qt5, QML se ha puesto en el punto de mira del proyecto, es uno de los módulos más importantes que por supuesto usa al resto, pero esta es casi la presentación, la portada, lo que ve el usuario. A su vez el cambiar a Qt/C++ por Qt/Quick no es del todo positivo, mejor dicho no es que no sea positivo, es que si alquien escoje C++ teniendo como primer medidor el performace realmente no creo que Qt/Quick se le pueda comparar, en este sentido lo que se suele hacer es crear interfaces modernas y vistosas (look-and-feel) usando QML que pueden tener un potente lógica por detrás escrita en C++ y vinculada al código javascrip sin una mayor cantidad de esfuerso.

He estado escribiendo esto porque por un lado ves a algunos proyecto muy bien plantados con Qt4 tratando de migrar a Qt5 mientras que por otro lado vemos a algunos que están naciendo y tienen planificado el uso de Qt4.*, pues esto es algo sobre lo que devemos reflexionar, como mismo hasta aquí escribía refiriendome a que el “nuevo” Qt no trae tantos cambios entonces por qué deberiamos migrar?, aquí dejo algo de lo nuevo:

1. Ahora las Qwidgets  son un módulo aparte, pues existe una clase Qwindows de la cual heredan todas las ventanas, esto se implementó para permitir que QML pudiera tomar el control visual de las ventanas principales sin depender de Qwidget .

2. El procedimiento de creación de plugins se ha cambiado por completo(para bien, aunque debido a este cambio los modulos y plugins diseñados con Qt4 no son compatibles con los de la nueva versión).

3. Ahora connect en vez de  retornar un bool, retorna un QmetaObject::Connection .

4. C++11 viene con soporte de funciones lambda y Qt5 le añade soporte a las conecciones para  estas funciones .

5. Módulo de puerto serie incluido (Qt5.1).

6. QWS no forma parte de Qt5, desde la versión 4.8 se introdujo QPA, con eso puedes ir portando desde Qt4, en Qt5 QPA pasó a ser la parte central de Qt dejando atrás a QWS que tenía algunos problemas arquitectónicos.

7. Para usar c++11 puedes poner CONFIG += c++11  en el *.pro y basta.

Como podrás ver esta lista no es(ni pretende) exaustiva así que si quieres una lista completa de los cambios por release puedes consultar URLs como las que siguen:

5.1

5.2

5.3

Qt 5 Supported Platforms

Para ver un ejemplo de uso de Qt5 y c++11 revisa:

Alta disponibilidad de servidores y balanceo de carga.

Autotools (3): Integración de libtool en autotools para la creación de una biblioteca a instalar en el sistema.

En otros post anteriores vimos la escencia de las bibliotecas así como de libtool, si además haz realizado aunque sea un “hello world” con autotools entonces ahora veamos como integramos a libtool con autotool para la creación de una biblioteca.

#configure.ac

LT_INIT: Es la forma en que actualmente se define LIBTOOL.

# Checks for programs.

AC_PROG_CXX: Chequea por un compilador para c++.

AC_PROG_AWK: Chequea gawk, mawk, nawk, and awk, en ese orden y lo establece como variable.

AC_PROG_CC: Chequea por un compilador para c.

AC_PROG_CPP: Muetra el valor de la variable CPP que contiene el preprocesador.

AC_PROG_INSTALL: Muetra el valor de la variable INSTALL para instalación.

AC_PROG_LN_S: Chequea que ls sistema en que te encuentras soporta links simbólicos(ln -s), en caso que este no esté disponible lo establece a ln, en otro caso a cp -pR.

AC_PROG_MAKE_SET: Establece el comando make.

#lib/Makefile.am:

CLEANFILES: Para que make clean borre los archivos que coincidan.

AM_CPPFLAGS: El contenido de esta variable es pasado a todas las reglas de compilación que invoquen el preprocesador de C.

Definiciones para el uso de pkg-config una vez creada la lib.

pkgconfigdir = @libdir@/pkgconfig

pkgconfig_DATA = libmatX.pc

A diferencia del primer ejemplo donde poniamos bin_PROGRMAS para crear ejecutables aquí usamos esta macro a la cual le decimo el nombre de la lib a crear y en el source debe transformar el nombre a su forma canónica.

lib_LTLIBRARIES = libmatX.la

libmatX_la_SOURCES = \

matX.cc

libmatX_la_LDFLAGS: Flags para el elnlazador.

“#Headers/Makefie.am

includedir: Referencia al directorio include donde se pondran los headers

nobase_include_HEADERS: Para que no se instale dos veces con una invocación del programa.

Una vez configurado el proyecto procedemos a la contrucción:

1. mkdir -p m4

2. libtoolize --copy –force

3. aclocal -I m4

4. autoheader

5. autoconf

6. automake -a

7. ./configure

.8 make

Ya podrás ver que se ha creado lib/libmatX.la, incluso lo podrías leer(cat lib/libmatX.la) ya que es texto plano, en este punto la biblioteca ya es usable, esto sería en nuestro progrma usar la macro LDADD (tambien con el nombre del ejecutable como prefijo y con _ al final) para esto puedes consultar GNU Automake aunque este ejemplo cuneta con su *.pc.

9. sudo make install

Ya deberías poder verificar como instalada la biblioteca en tu sistema

10. pkg-config --list-all | grep hello_libtool

Ya teniendo esta infraestructura básica del proyecto veamos como crear las bibliotecas estática y dinámica correspondiente.

Biblioteca estática:

make clean

./configure --disable-shared

make

Biblioteca dinámica:

make clean

./configure --disable-static

make

NOTA: En caso de no especificar se crea la dinámica y la estática.

Desde aquí puedes descargar el ejemplo:

git clone https://github.com/denisacostaq/EmbeLinux --branch hello-libtool

Creación de bibliotecas mediante el uso de libtool (Parte 2).

Si ya revisaste el post anterior sobre construcción de bibliotecas podremos proseguir con el hecho de que ya tenemos algunos conceptos básicos de nuestro lado, esta vez relizaremos el mismo ejemplo lo que cambia es las herramientas. Primero construiremos la lib estática, después compartida y por último de ejecución (que no es más que la misma biblioteca compartida lo que se carga en tiempo de ejecución).

Libtool:

Según su propia documentación (apt-get install libtool-doc) fue diseñado desde sus inicios para soportar un número arbitrario de tipos de bibliotecas, más tarde se ha ido portando a otras plataformas y gradualmente se han ido desarrollando nuevos paradigmas que describen la relación entre las bibliotecas y los programas.

Consideremos el sigiente código con el cual crearemos la biblioteca estática y compartida:

//module.c

float mult (float fac1, float fac2)

{

return fac1 * fac2;

}

Biblioteca estática:

1. Creamos un directorio donde “instalaremos” la lib.

mkdir -p /tmp/install

2. Compiamos el código.

libtool --verbose --mode=compile gcc -g -O -c module.c -static

3. Enlazamos el código, si no ponemos -rpath /tmp/install al comando anterior tendremos que ejecutar

libtool --finish /usr/local/lib después para que se complete la instalación correctamente.

libtool --verbose --mode=link gcc -module -o module.la module.lo -rpath /tmp/install -static

4. Instalamos

libtool --mode=install install module.la /tmp/install

Ya tenemos lista la lib en /tmp/install que puedes usar como en el post anteriorque mencionaba al inicio y además notar que se encuentra en el direcorio oculto (ls .libs/).

Biblioteca dinámica:

Recomendable eliminar los archivos anteriores para ver el nuevo resultado y repitiendo los pasos para este caso tenemos:

1. mkdir -p /tmp/install

2. libtool --verbose --mode=compile gcc -g -O -c module.c -shared

3. libtool --verbose --mode=link gcc -module -o module.la module.lo -rpath /tmp/install -shared

4. libtool --mode=install install module.la /tmp/install

Biblioteca de ejecución:

Para ver como usamos una lib en tiempo de ejecución usaremos el siguiente código:

#include <stdio.h>

#include <ltdl.h>

#include <stdlib.h>

//declaramos una variable(puntero a la función así que

//debe coincidir en los tipos)

float (*mult)(float fac1, float fac2);

int main (int argc, char *argv[])

{

lt_dlhandle handle;

lt_dlinit ();

lt_dladdsearchdir ("./");

handle=lt_dlopenext ("module");

if (!handle)

{

printf ("Error, módulo no cargado: %s\n",

                   lt_dlerror());

exit (EXIT_FAILURE);

}

const lt_dlinfo *info;

info = lt_dlgetinfo (handle);

if (!info)

{

fprintf (stderr, "No se pudo obtener la información  del módulo: %s\n", lt_dlerror());

lt_dlclose (handle);

exit (EXIT_FAILURE);

}

if (info->name)

{

printf ("Nombre del módulo: %s\n", info->name);

}

else

{

printf ("No es un módulo libtool\n");

}

//casteo al tipo de la función

mult = (float(*)(float, float))lt_dlsym(handle, "mult");  

if (mult)

{

printf ("Resultado desde el módulo: %f\n", mult(5.0, 10.0));

}

else

{

perror ("No se pudo cargar la función\n");

lt_dlclose (handle);

exit (EXIT_FAILURE);

}

lt_dlclose (handle);

return 0;

}

Recomendable eliminar los archivos anteriores para ver el nuevo resultado y repitiendo los pasos para este caso tenemos:

1. libtool --verbose --mode=compile gcc -g -O -c module.c -shared

2. libtool --verbose --mode=link gcc -module -o module.la module.lo -rpath /tmp/install -shared

3. libtool --mode=link gcc -export-dynamic -o programdl program.c -lltdl

Un detalle importante es notar que la lib se contruye de la misma manera que la compartida, el programa es el que se contruye de forma diferente a la convencional y además con ldd como en el post anterior puedes ver como program no depende de module por lo que los pasos 2 y 3 se pueden cambiar de orden ya que program no necesita saber nada acerca de module en tiempo de compilación.

NOTA: Para tener más referencia consulte man libtool o /usr-sha-doc-libtool-doc.

Implementando mi propio shell usando una gramática LL1.

Lo primero que veremos, qué es un shell; después, qué es una gramática, cuando una gramática se clasifica como LL1 (y si no lo es como llevarla) y por último veremos una pequeña implementación en C de un shell.

Shell: Shell (del inglés cascarón, coraza, concha, etc) toma este nombre por ser el shell una interfáz entre el nucleo del Sistema Operativo y el usuario, es un intérprete a través del cual este le da órdenes(ver Fig 1).

Fig 1.

El shell es un programa capaz de interpretar comandos, hacer una petición al sistema y devolver un resultado. Exixsten varias implementaciones: sh, bash, csh, Tcsh, …, etc... Cada usuario tiene una shell predeterminada ej: adacosta:x:1008:1008:PEPSI,,,:/home/adacosta:/bin/bash el cual es ejcutado al autenticarse el usuario en una terminal, o al abrir una emulador de terminal en una sesión X11, lo primero que hace el shell es leer sus configuración de sistema (/etc) y después leer la configuración del usuario (/home/user-name/.*) pudiendo llegar a ser uno o varios archivos, en mi caso:

( /home/adacosta/.bashrc, /home/adacosta/.profile /home/adacosta/.bash_*)

Gramática: Intuitivamente, una gramática es un conjunto de reglas para formar correctamente las frases de un lenguaje; así ́ tenemos la gramática del español, del francés, etc. Según N. Chomsky existen 4 tipos fundamentales de gramáticas:

1. Gramáticas regulares, o de tipo 3: Las reglas son de la forma A → α B o bien A → α, donde A y B son variables (no terminales) y α es una constante (terminal). Estas gramáticas son capaces de describir los lenguajes regulares.

́

2. Gramáticas Libres de Contexto (GLC), o de tipo 2: Las reglas son de la forma X → α, donde X es una variable y α es una cadena que puede contener variables y constantes. Estas gramáticas producen los lenguajes Libres de Contexto.

́

3. Gramáticas sensitivas al contexto (dependientes del contexto) o de tipo 1: Las reglas son de la forma αAβ → αΓβ, donde A es una variable y α, β y Γ son cadenas cualesquiera que pueden contener variables y constantes.

4. Gramáticas no restringidas, o de tipo 0: Con reglas de la forma α → β, donde α no a puede ser vacío, que generan los lenguajes llamados “recursivamente enumerables”.

Los objetivos de una gramática son: definir las sentencias que pertenece a un lenguaje, así como describir estructuralmente dichas sentencias. Las gramáticas generan sentencias mediante secuencias de derivaciónes directas

Como ejemplo veamos una gramática subconjunto del idioma español:

G = ( {<frase>, <sujeto>, <predicado>, <artículo>, <sustantivo>, <verbo>},

{el, la, perro, luna, brilla, corre}, P, <frase>)

P:

<frase> → <sujeto> <predicado>

<sujeto> → <artículo> <sustantivo>

<artículo> → el | la

<sustantivo> → perro | luna

<predicado> → <verbo>

<verbo> → brilla | corre

En correspondencia con esta gramática podriamos generar frases como las que siguen.

{el perro corre , el perro brilla, la perro brilla, ...} estando todas ellas correctas sintácticamente aunque haciendo un análisis semántico (en otra etapa) podriamos detectar que algunas de las frases carecen de sentido.

Gramáticas LL1:

Un analizador LL es llamado un analizador LL (k) si usa k tokens cuando el analizador ve hacia delante de la sentencia. Si existe tal analizador para cierta gramática y puede analizar sentencias de esta gramática sin marcha atrás, entonces es llamada una gramática LL (k). De estas gramáticas, la gramática LL(1), aunque es bastante restrictiva, esta es muy popular (principalmente en actividades docentes) porque los analizadores LL correspondientes sólo necesitan ver el siguiente token para hacer el análisis de sus decisiones. Lenguajes mal diseñados usualmente suelen tener gramáticas con un alto nivel de k, y requieren un esfuerzo considerable al analizar.

Una gramática ambigua es aquella que produce más de una derivación más a la izquierda o más de una derivación más a la derecha para la misma sentencia. En general existen tres estrategias iniciales para eliminar la ambiguedad de las gramáticas, ellas son:

1. Definir la precedencia y asociatividad de los operadores.

2. Eliminar la recursividad izquierda o derecha.

3. Factorizar.

Veamos un ejemplo:

G = ({<Expresión>}, {id, +, - , *, / , (, )}, P, <Expresión>)

P:

(1) <Expresión> → <Expresión> + <Expresión> | <Expresión> - <Expresión>

(2) <Expresión> → <Expresión> * <Expresión> | <Expresión> / <Expresión>

(3) <Expresión> → id | ( <Expresión> )

Precedencia y asociatividad:

Definamos un nivel de prioridad para cada operador como sigue:

1. (), id

2. *, /

3. +, -

Nivel 1 Se introduce un nuevo símbolo No Terminal, que llamaremos <Factor> para describir una expresión indivisible y con máxima precedencia.

<Factor> → id | ( <Expresión> ) .

Nivel 2 Se introduce un nuevo símbolo No Terminal, que llamaremos <Término>, que generará una secuencia de uno o más términos generados por el No Terminal <Factor>, conectados con los operadores de nivel precedencia 2.

<Término> → <Término> * <Factor> | <Término> / <Factor> | <Factor>

Nivel 3 Se mantiene el símbolo No Terminal <Expresión> para describir secuencias de uno o más términos generados por el No Terminal <Término>, conectados con los operadores de nivel precedencia 3.

<Expresión> → <Expresión> + <Término> | <Expresión> - <Término> | <Término>

Aplicando las reglas anteriores la gramática definida anteriormente queda re definida como sigue:

G = ({<Expresión>, <Término>, <Factor>}, {id, +, - , *, / , (, )}, P, <Expresión>)

P:

<Expresión> → <Expresión> + <Término> | <Expresión> - <Término> | <Término>

<Término> → <Término> * <Factor> | <Término> / <Factor> | <Factor>

<Factor> → id | ( <Expresión> )

Recursividad Izquierda :

Una producción de la forma A → Aβ se dice que es recursiva inmediata. Para eliminar las recursividades inmediatas podemos seguir el procedimiento siguiente:

1. Se agrupan las A-producciones:

A→ Aα1 | Aα2 | . . .| Aαm | β1 | β2 . . .| βn

donde ningún βi comienza con A.

2. Se reemplazan las A-producciones por:

A→ β1 A’| β2 A’| . . .| βn A’

A’→ α1 A’| α2 A’| . . .| αm A’| ǫ

Aplicamos el procedimiento anterior para eliminar la recursividad directa en la gramática:

G = ({<Expresión>, <Término>, <Factor>}, {id, +, - , *, / , (, )}, P, <Expresión>)

P:

<Expresión> → <Expresión> + <Término> | <Expresión> - <Término> | <Término>

<Término> → <Término> * <Factor> | <Término> / <Factor> | <Factor>

<Factor> → id | ( <Expresión> )

Para ellos seleccionamos las reglas que son recursivas directa a la izquierda estas son:

(I) <Expresión> → <Expresión> + <Término> | <Expresión> - <Término> | <Término>

(II) <Término> → <Término> * <Factor> | <Término> / <Factor> | <Factor>

Aplicando la regla para la eliminación de ambiguedad 2 sobre (I) y (II) nos queda:

<Expresión> → <Término> <MasExpresión>

<MasExpresión> → + <Término> <MasExpresión> | - <Término> <MasExpresión> | E

<Término> → <Factor> <MasTérmino>

<MasTérmino> → * <Factor> <MasTérmino> | / <Factor> <MasTérmino> | E

Factorización por la izquierda.

La Factorización por la izquierda tiene el objetivo de reescribir las producciones de la gramática con igual comienzo para retrasar la decisión hasta haber visto lo suficiente de la entrada como para elegir la opción correcta. El procedimiento es simple. Si tenemos una regla de producción de la forma:

́ A → αβ1 | αβ2 | . . . | αβn | δi

esta se transforma en las regla.

A → α A′ | δi

A ′ → β1 | . . . | βn

A manera de ejemplo consideremos la regla de producción siguiente:

<Instruciones > → <Instrucción> ; <Instruciones > | <Instrución>

Aplicando la Factorización por la izquierda nos quedan las reglas equivalentes:

<Instruciones > → <Instrucción> <MasInstrucciones >

<MasInstrucciones > → ; <Instruciones > | E

A modo de conclusión podemos decir que las gramáticas constituyen la mejor vía para la descripción sintáctica de los lenguajes de programación. Existen diversas razones que justifican tal afirmación:

Las gramáticas brindan una especificacion sintáctica precisa de los lenguajes de programación.

Para ciertas clases de gramáticas pueden construirse analizadores sintácticos eficientes que determinan si el programa fuente está bien escrito. El proceso de construcción del parser puede además, revelar ambiguedades sintácticas no detectadas en la fase de diseño del lenguaje .

Una gramática bien diseñada puede ayudar a la traducción del programa fuente en código objeto y a la detección de errores.

Se pueden añadir nuevas construcciones al lenguaje de forma fácil.

Un ejemplo de implementación:

Un ejemplo de implementación de un intérprete basado en un gramática LL1 lo puede tomar clonando denishell(git clone https://github.com/denisacostaq/denishell), toda la documentación relevante forma parte del código fuente y/o de la documentación(valga la redundancia) generada con doxygen, en especial fijarse en el comando cd, en la manera que se “simula” la implementació de un pipe (char** run_pipe_on_node (struct ast_node *ast);), en la pesatña examples de dicha documentación puedes aprender cómo comunicar dos procesos con un pipe real, y además puedes ver algunos de los comandos a ejecutar, tambié revisar char** cat_args(); y char** ls_args (); para tener detalles sobre la internacionalización (deni-sh_i18n.h).

Autotools(2): Integracíon de getttext con autotools para internacionalizar aplicaciones (intltool).

Cuando deceamos que nuestra aplicación esté disponible bajo varios idiomas tenemos varias opciones, una de ellas es el conjunto de funciones gettext (glibc-reference-manual). En este pos veremos como inttool se integra de manera natural a autotools(see Autotools(1))., gettext es quien extrae las cadenas para su traducción pero inttool extiende sus funcionalidades permitiendo:

• -Detectar las herramientas necesarias para la configuración y contrucción del proyecto.
• -Extraer las cadenas a traducir.
• -Mezclar las cadenas en la app final.

A partir de este punto nos basaremos en nuesto “hola mundo” inicial (git clone https://github.com/denisacostaq/EmbeLinux --branch hola-mundo, puedes probar ahora ejecutar autoscan en el directorio del proyecto y después cat configure.scan ), agregaremos el directorio po en la raiz de nustro proyecto, aquí irán hubicados 3 archivos esenciales.

1. POTFILES.in: Listado de archivos que contienen cadenas a traducir. Si se crea vacio ejecutando
   make update-po dentro del directorio po tendrás las cadenas marcadas a trducir.
2. POTFILES.skip: Listado de archivos que contienen cadenas traducibles pero aún se trabaja en ellos(los programadores) por lo que los traductores no deben desgatarse en ellos.
3. ChangeLog: Lleva un control de los cambios efectuados en el proceso i18n, 110n (para ver más detalles sobre esto revise un exelente artículo publicado por la señorita Milagros Alessandra en el número 1 de la revista HD).

Además de estos 3 archivos se hubican el archivo con todas las cadenas traducibles(*.pot) y los archivos con todas las cadenas traducidas en los diferentes idiomas(*.po).

Debemos cambiar nuestro archivo configure.ac de manera que quede como en nuestro hola mundo internacionalizado(por lo que ha cambiado a la verción 0.0.2) pero es recomendable que usando las piezas de la primera verción llegues hasta la segunda siguiendo los pasos desde para que entiendas bien todo por ti mismo. Una forma cómoda de ver los cambios es usando una herramienta difftool(ej:meld), los cambio son menores y los comento a continucaión:

• AC_PROG_INTLTOOL ( [ 0.50.2-2 ] ): Para que ./configure chequee que esta intltool en la verción especificada(como minimo).
• GETTEXT_PACKAGE: Esta variable es usada para nombrar el paquete.
• AC_SUBST: Publica la variable pasada como parámetro para ser usada de manera gloval en el proyecto(en cualquier Makefile.am se podrá aceder a su valor), en este caso es útil para po/Makefile.in.in.
• AC_DEFINE_UNQUOTED: Esta macro se usa para declarar sus “parámetros” en config.h(para este caso ya que así le nombramos en AM_CONFIG_HEADER), si lo escribieramos en “C” sería: #define GETTEXT_PACKAGE “hola−mundo” que de hecho se puede observar en config.h que este es su resultado.
• ALL_LINGUAS: Contendría los idiomas que tenemos disponibles.
• AM_GNU_GETTEXT: Verifica que tengamos disponible gettext en nuestro sistema, además de agregar algunas entradas en config.h de manera automática.

En el archivo Makefile.am se han efectuado cambios en 3 variable de las que solo es nueva CLEANFILES en la que ponemos archivos que queremos eliminar con “make clean”. En src/Makefile.am solo es nueva INCLUDES que especifica donde estaran las cadenas traducidas. EL archivo src/hello_world_i18n.h es usado para garantizar que nuestra aplicación “siempre” compile aunque no esté disponible el soporte para internacionalización, basicamente si está _ (str) se sustituye en tiempo de preprocesamiento por ( const char ∗) gettext ( str), si no está se sustituye por si misma, o sea no es el resultado de gettext, si no el mismo parámetro lo que se optiene.

En src/main.c los únicos cambios destacables son:

• setlocale (LC_ALL, “”); al pasarle “” nuesto progrma uasará el “locale” definido por el sistema.
• bindtextdomain ( GETTEXT_PACKAGE, PACKAGE_LOCALE_DIR ); :Aquí usamos el valor establecido en src/Makefile.am.
• bind_textdomain_codeset ( GETTEXT_PACKAGE, “UTF-8″ ); : Aquí decimos la codificaciín de caracteres que vamos a usar.
• textdomain ( GETTEXT_PACKAGE ); define el dominio o ámbito de traducciones, normalmente reducido al dominio del programa y que se encuentra definido en GET- TEXT_PACKAGE.

La secuencia de comandos se ha modificado ligeramente:

mkdir m4 ; aclocal -I m4

autoheader

glib-gettextize --copy --force

intltoolize --copy --force --automake

autoconf

automake --add-missing

En el directorio “po” falta determinar el contenido del archivo POTFILES.in. Para ello, dentro

de dicho directorio basta invocar el comando:

cd po ; touch POTFILES.in ; intltool-update --maintain ; cd ../

esto mostrará los archivos que tienen cadenas a traducir y que no se encuentran en el archivo POTFILES.in. Para facilitar el trabajo, también se genera un archivo llamado missing(puede ser añadido al final de POTFILES.in).

./configure

cd po

make update-po

cp hola-mundo.pot es.po (Para estos archivos puedes usar Gtranslatro como explican en HD)

cp hola-mundo.pot fr.po (El francés lo dejaré sin traducir para que compruebes que la aplicación se ejecuta lo que solo en inglés)

cd ../

Traducir con Gtranslator(recomendación). Finalmente, tras ejecuta make dist, se tendrá la versión 0.2 del programa hola-mundo.

NOTA:

Para probar el prgrama debes tener los “locales” instalados (apt-get install locales-all), además la variable de entorno en el idioma que quieres, ej: export LANG=”es_ES.UTF-8″, deberás tener en cuenta que para este caso deberás instalar el progrmaa (sudo make install) por el lugar donde se ha especificado buscar los *.mo además debes establecer la codificacion de caracteres ej:UTF-8, si usas Gtranslator esto parecería tribial pero es muy importante. Por último la descarga de este ejemplo para que te guies y no te suene ambiuguo lo que he explicado, una tecnica puede ser usr una herramienta diff si ya habias entendido bien el ejmplo anterior.

git clone https://github.com/denisacostaq/EmbeLinux --branch hello-intltool

Autotools(1). Hola mundo a la autotools.

En lo que sique(incluido este como el primero) estaré publicando una serie de posts relacionados con la creación y configuración de proyectos basados en el grupo de herramientas de autotools(antes es aconsejable revisar el directorio /usr/share/doc/gnu-standards, de este no existir ejecuta apt-get install gnu-standards y además ver también este enlace a wikipedia) y algunas otras que se le integran muy bien, además mencionar que me basaré en los lenguajes C/C++ pero que bien se adapta a otro tipo de lenguajes como son C, C++, Java, Python, Fortran, Yacc, awk, etc.

Primero que todo veamos la estructura básica de un proyecto, los directorios y archivos principales que lo componen y después veremos como editamos estos últimos para lograr un proyecto muy básico, nuetro “hola mundo”.

Estructura básica:

Escojemos un directorio en el cual relizaremos nuestro trabajo y ejecutamos la siguiente secuencia de comandos para crear las bases del proyecto.

mkdir -p hola_mundo/src
cd hola_mundo/
touch Makefile.am configure.ac src/Makefile.am src/hello-world.c NEWS AUTHORS ChangeLog README MAINTAINERS HACKING VERSION THANKS TODO

Ejecutando el comando tree -v(man tree) ya visualizamos la estructura actual del proyecto (Fig 1) donde tenemos los archivos principales de información, (compuesto por 2 grupos, los obligatorios Fig 2 (aquí faltan COPYING e INSTALL lo que no los pondré ya que autotools te propone los correspondientes que deberás editar para adptarlo a las necesidades de tu proyecto) y los opcionales (Fig 3)), los archivos inherentes a las herramientas de autotools también llamados de configuración (Fig 4), y por su puesto los archivos/directorios donde estará el código fuente(en este caso solo uno).

Como contenido de estos archivos (los de información) se tiene una explicación sobre si mismos que se puede ver en un link que dejo al final con un ejemplo.

Edición de los archivos de configuración de autotools:

#configure.ac
AC_PREREQ([2.69])
AC_INIT([hola-mundo],[0.0.0], [denisacostaq@gmail.com], [hola_mundo], [blogspoot.com/embelinux])
AC_CONFIG_HEADERS([config.h])
AM_INIT_AUTOMAKE([1.10.1])
AC_PROG_CC
AC_OUTPUT([Makefile src/Makefile])

Comentaré superficialmente el contenido de este archivo, para una información más detallada ver /usr/share/doc/autoconf-doc/ (apt-get install autoconf-doc), este archivo se escribe en M4.

- AC_PREREQ advierte sobre la verción mínima de autoconf con que debe contar tu sistema (autoconf –version, para saber que valor poner en tu caso).

- AC_INIT tiene como parámetros el paquete, la verción, el e-mail de reporte de bugs, el nombre de empaquetamiento y la url del proyecto en ese orden y no siendo obligatorios todos estos parámetros.

- AC_CONFIG_HEADERS dice donde poner el archivo config.h(que puede tener otro nombre) el cual puede ser usado en el código de nuestro proyecto.

- AM_INIT_AUTOMAKE automake y especificamos que verción (automake –version). Se pueden escribir macros para automake, estas comienzan con el prefijo AM_ .

- AC_PROG_CC especificamos que usaremos el compilador de c y se le pudiera pasar un lista de comprobación, sino la pasamos autoconf comprueba usando una que tiene internamente.

- AC_OUTPUT especificamos los lugares en que queremos un Makefile(también se pueden obtener otros ficheros) como salida.

#Makefile.am
SUBDIRS = src
EXTRA_DIST =  README THANKS TODO HACKING MAINTAINERS

Para este archivo se puede leer el manual GNU Automake.

- SUBDIRS especifica los directorios por los que se debe mover make, es aproximadamente el orden que sequirá el “topological sort”.

- EXTRA_DIST es para incluir en el empaquetado archivos que no son indispensables en el proyecto.

#src/Makefile.am
bin_PROGRAMS = hola-mundo
hola_mundo_SOURCES = hello-world.c

En la variable bin_PROGRAMS especificamos el o los programas binarios que se van a crear. Después como muestra hello_world_SOURCES especificamos el código fuente a partir del cual se creará cada binario fijandote en tranformar el nombre del binario a su forma canónica, ej:hola-mundo -> hola_mundo y agregandole el sufijo _SOURCES.

Una vez editados estos archivos de configuración de proyecto ponemos el código, ej: printf (“hello world\n”); y por último coenzamos a invocar a las herramientas de autoconstrucción.

aclocal
autoheader
autoconf
automake -a (con la opcion -a no pone el archivo COPYING(enlace a /usr/share/automake-1.13/COPYING) e INSTALL(enlace a /usr/share/automake-1.13/INSTALL) como ya había mencionado)
./configure (en este punto se chequea si nuesto sistema está preparado para compilar el programa, por ejemplo desintala el compilador y verás lo que sucede).
make (ya podemos ejecutar nuestro programa que se llama hello_world y está en src).

La llamada a aclocal busca todas las macros m4 en todos los archivos *.m4 en el directorio donde se ejecuta y finalmente en configure.ac poniendolas todas juntas en el archivo aclocal.m4 que genera. El comando autoheader crea el archivo.h.in, autoconf es el responsable de crear el archivo(scrip) configure, automake genera los archivos Makefile.in ,y por ultimo ./configure es quien genera los Makefile a partir de Makefile.in y config.h a partir de config.h.in. A modo de resumen, se muestra en el siguiente diagrama el flujo del funcionamiento de las herramientas (Fig 5).

Fig 5

Adicionalmente podemos ejecutar como root make install que instala nuestro programa en el sistema, por defecto en /usr/local, podemos modificar esto volviendo a ejecutar ./configure pero esta vez con el parametro –prefix=PATH. También podemos ejecutar make dist y nos empaqueta el proyecto.
Como nota adicional comentar que debes tener todas estas herramientas en tu sistema para trabajar con autotools pero una vez que tengas el empaquetado solo necesitas los compiladores, bibliotecas, frameworks y todo de lo que dependa tu programa para compilarse pero no las herramientas con las cuales creates el paquete, o sea ya podrás ejecutar el clásico (./configure ; make ; sudo make install).

git clone https://github.com/denisacostaq/EmbeLinux --branch hola-mundo

Entendiendo la escencia de las bibliotecas mediante ejemplos de su creación y utilización.

Como ejemplo tomaremos la creación de una biblioteca para cálculos matemáticos, primero la haremos y usaremos estática y después compartida.

Biblioteca estática:

En una biblioteca estática tenemos una serie de procedimientos que son comunes pero cada programa que compilemos a partir de ella incluirá los archivos de los que use cualquier cosa dentro de su propio código atentando contra el tamaño del archivo binario final, no será necesario tener la biblioteca en el entorno en que va a correr el programa.

//plus.c
int plus (int sum1, int sum2)
{ 
    return (sum1 + sum2); 
}

//mult.c
int mult (int fact1, int fact2)
{
    return (fact1 * fact2);
} 

Para obtener el código objeto de estas dos funciones y/o archivos ejecutamos: gcc plus.c mult.c -c, con la opción -c le decimos a gcc que compile o ensamble nuestro código pero que no lo elnace (gcc se refiere a GNU Collection Compilers y/o a GNU C Compiler, pero en este último caso aclarar que no es en realidad gcc quien compila sino que es más bién un driver, o sea encarga a otros programas a hacer el trabajo). Para crear la bibliteca ejecutamos ar -r libmat.a plus.o mult.o, con esto libmat.a queda lista para ser usada como una biblioteca estática (rm *.o *.c).

//main .c
#include <stdio.h>
int plus (int, int);
int mult (int, int);
int main (int argc, char *argv[])
{
    int val1 = 2;
    int val2 = 5;
    printf (“%d + %d = %d\n”, val1, val2, plus (val1, val2));
    printf (“%d * %d = %d\n”, val1, val2, mult (val1, val2));
    return 0;
}
gcc main.c -lmat -o program (produce el siguiente error)
/usr/bin/ld: cannot find -lmat
collect2: error: ld returned 1 exit status 

Ahora ejecutamos gcc main.c libmat.a -o program que sí compila correctamente pero le estamos pasando la ruta de la lib de forma explícita, la manera elegante sería diciendole a gcc enlazate a mat(-lmat) para que él solo la busque pero no lo hemos conseguido porque el enlazador(ld) ha buscado en los directorios que tiene por defecto normalmente(/lib y /usr/lib más cat /etc/ld.so.conf.d/*) así que podemos agregar nustro directorio actual a las rutas de búsqueda con gcc main.c -L. -lmat -o program. Una forma más elegante de compilar es usando la variable de entorno LIBRARY_PATH, que sería así:

export LIBRARY_PATH=$LIBRARY_PATH:.
gcc main.c -lmat -o program

Además para ver lo que decía sobre que gcc es un driver podrias ejecutar gcc -### -lmat main.c -o program con lo que gcc te dice lo que haría si le quitas -### pero no lo hace.

Biblioteca compartida:

A diferencia de una biblioteca estática los programas que se compilan con bibliotecas compartidas (shared object, extención .so) no incluyen el código de estas dentro de sí, sino información de con que lib ha sido enlazado el programa de manera que cuando el programa se va a ejecutar el linkeador (ld-linux, no el que se usa para compilar) determina de qué bibliotecas depende nuestro programa para estar en RAM y de faltar alguna la carga, por ejemplo para el programa que habiamos compilado hasta ahora podemos saber de que depende usando ldd program, deberás notar que no depende de libmat.

Para crear una biblioteca comartida solo tenemos que especificarle esto a gcc con shared, usando todo el codigo que hasta ahora teniamos solo cambiaremos la manera en que creamos la lib y el programa y veremos el impacto:

gcc -c -fPIC mult.c plus.c
gcc -shared mult.o plus.o -o libmat.so
gcc main.c -lmat -o program (que tendrás un error, así que resuelvelo...  )

./prgram (te generará el siguiente error, ./program: error while loading shared libraries: libmat.so: cannot open shared object file: No such file or directory, si ejecutamos ldd program verás que a diferencia de el caso pasado este si depende de libmat y que además “not found”, para resolver esto tenemos que agregar como ruta de busqueda al elnlazador ld-linux(no el de compilar insisto), la ruta donde esté nuestra lib o mejor una solución más pacífica export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:. , con lo que puedes volver a ejecutar ldd para ver el cambio y además ya puedes ejecutar a ./program).

Bibliotecas dinámicas:

En este punto solo mencianaré que las bibliotecas dinámicas son una “forma” de las bibliotecas compartidas la diferencia es que en ahora el SO no autodetecta las bibliotecas de que depende el programa y las carga de forma automática, es el programador quien tiene esta responsabilidad, básicamente se cargan bajo demanda, tiene la ventaja de que la aplicación se carga en RAM más rápidamente y el inconveniente de que es el programador quien tiene la responsabilidad de hacer entonces ese trabajo, pudiera ser por ejemplo usando la lib ltdl que cuenta con funciones como dlopen.

En algún que otro post relacionado con autotools+libtool veremos como los humanOS hacemos esto, ya que hasta ahora solo vimos el método de los  “dinosauriOS” .