no es cierto.

Tienes que comprar licencia comercial si quieres, por ejemplo, hacer cambios en las librerías sin publicarlos o si pretendes crear librerías estáticas de qt... con librerías dinámicas puedes hacer uso comercial de qt sin pagar un duro.

Lo de la licencia comercial era para la versión 3.x ... la versión 4 ya venía con licencia gratuíta y la 5 igual.

Desde que nokia ha vendido qt ahora, por lo visto, la versión comercial tiene, además, objetos y características que no vienen en la versión gratuíta.

No uses Devcpp... no tiene mantenimiento, es obsoleto y tiene errores.

En su lugar tienes varias alternativas, aunque yo creo que la más llamativa es code::blocks.

También imagino que podrías usar la versión express del visual, pero sabiendo que la de .net, por ejemplo, no soportaba múltiples proyectos abiertos a la vez lo mismo es una opción desaconsejable.

La pregunta entonces es... ¿ Es aplicable ese resultado a cualquier compilador ?

Creo que habría entonces que hacer una batería de pruebas con diferentes compiladores, porque no creo que todos implementen las mismas optimizaciones...

Eso si... te lo has currado mirándote el código en ensamblador

Por lo que he visto en tu código, la variable r no tiene razón de ser.

Es una variable que guarda un resultado temporal que no tiene sentido más allá de la función en la que defines su valor. Es decir, si haces una suma, en r guardas el resultado... pero ese resultado no se vuelve a usar para nada... en cuanto hagas otra operación, ese valor se pierde y nadie va a suspirar por el.

En estos casos es mejor reducir su ámbito de uso y declarar variables dentro de las funciones que las necesiten.

Saber declarar cada variable dentro de un ámbito correcto es bastante importante, aunque eso es algo que irás aprendiendo con el tiempo.

Además te faltaría definir el constructor de la clase. ¿ Qué sucede si se te olvida llamar a asignar1 y/o asignar2 antes de realizar alguna operacion? Pruébalo, verás que los resultados serán raros raros. Los constructores te ayudan a evitar ese tipo de problemas.

La declaración que haces del main es un poco rara... es una sintaxis propia del visual studio 12???

Dicho lo dicho, yo dejaría tu código así:

#include "stdafx.h"
#include "iostream"
 
using namespace System;
using namespace std;
 
class PROCESOS
{
private:
    int a, b;
public: 
 
    PROCESOS( )
    {
      a = 0;
      b = 0;
    }
 
    void asignar1(int y)
    {
        a = x;
    }
    void asignar2(int z)
    {
        b = y;
    }
    void suma()
    {
        int r = a + b;
        cout<<"La suma de " <<a <<" y " <<b <<" es " <<r <<"\n";
    }
    void resta()
    {
        int r = a - b;
        cout<<"La resta de " <<a <<" y " <<b <<" es " <<r <<"\n";
    }
    void multi()
    {
        int r = a * b;
        cout<<"La multiplicacion de " <<a <<" y " <<b <<" es " <<r <<"\n";
    }
    void div()
    {
        if (b != 0)
        {
            int r = a / b;
            cout<<"La divicion de " <<a <<" y " <<b <<" es " <<r <<"\n";
        }
        else
        {
            cout<<"ERROR :(" <<"\n";
            cout<<"No existe la divicion por " <<b <<"\n";
        }
    }
 
};
int main(array<System::String ^> ^args)
{
    int j, k;
    PROCESOS objFUN;
    cout<<"Introduce 2 numeros\n";
    cin>>j;
    cin>>k;
    objFUN.asignar1(j);
    objFUN.asignar2(k);
    objFUN.suma();
    objFUN.resta();
    objFUN.multi();
    objFUN.div();
    system("PAUSE");
    return 0;
}

Está claro que, pese a ser más pesada, una operación de división está lo suficientemente optimizada ( al menos cuando se manejan números enteros ) como para no ser un lastre excesivo... salvo que estés en un entorno de tiempo real crítico.

Lo que sí está claro es que, sobretodo en el caso de bucles con un gran número de repeticiones, las pequeñas optimizaciones se van notando cada vez más... obviamente hacer una sustitución así en, por ejemplo, una función que se ejecuta una vez cada vez que un usuario hace click sobre un botón no es una mejora a la que el vayas a sacar partido realmente.

La siguiente mejora que podrías plantearte en este código es el que sea capaz de manejar números realmente grandes... de 100, 200 ... 1000 cifras.

Funciones matemáticas optimizadas y con opción a manejar números grandes... más sus optimizaciones para números enteros normales, sería una buena base para sacar una librería matemática interesante.

Tenía entendido que en el caso de los procesadores empleados en PCs... intel, amd, etc... si se da esa condición.

Desgraciadamente no dispongo de esa documentación... no me dedico a programar a ese nivel.

Lo que está claro que a no ser que el fabricante te proporcione el datasheet de la tarjeta, donde se detallará toda la información que necesitas, te toca patearte foros en inglés para ir recabando información.

También puede ser que esos datasheet tengas que comprarlos, como te digo, desconozco como está el mercado en este tema.

Aclaremos un poco los conceptos:

1. No se realizan tareas... o si alguno te las realiza, seguramente te cobre por ella.

2. Lo que dices del usb es realizable, tienes que configurar un autoarranque en el usb que ejecute tu programa... otra cosa es que puedas tener problemas con antivirus o con permisos de acceso.

3. Para controlar la pulsación de teclas sin afectar al usuario, es decir, que éste pueda ejecutar otros programas mientras tanto... necesitas que el programa sea residente y tendrás que programar unos hooks del teclado.

4. Como imagino que el punto 3 te habrá sonado a chino ( y que conste que en ese punto no te estoy tomando el pelo ) mi consejo es que te olvides de esta tarea y empieces a familiarizarte con c con cosas más sencillas y realizables por un nobel... te proporcionará más satisfacción, aprenderás más y consolidarás conocimientos.

5. No te ha contestado nadie más en 6 horas... por algo será. Yo en tu lugar meditaría seriamente lo que te he puesto.

Un saludo.

Si te hicieses una clase Pieza, por ejemplo, con la funcionalidad mínima de todas las piezas y luego creases una clase que herede de esta por cada pieza diferente del ajedrez ( peon, caballo, torre, alfil, reina y rey ) ganarías bastante en organización del código, por ejemplo.

Además con esa estructura podrías llegar a concretar las responsabilidades de cada parte del código, lo que te podría ayudar a corregir problemas con más facilidad.

... pero vamos ya me metí en el otro código echándole ganas... con este es que no tengo ni siquiera tiempo... refactoriza un poco el código y hazlo más legible. Una función de 200 o más líneas no es precisamente sinónimo de legible.

Si quieres darle una pequeña vuelta de tuerca más puedes usar los siguientes trucos:

mejor preincrementos a postincrementos:

// esto
++variable;
 
// es mas optimo que esto ( como norma general, ya que depende de las optimizaciones del compilador )
variable++;[/code ]
 
Para dividir entre dos, es muuuucho más óptimo usar desplazamientos binarios:
 
[code=c]
// esto
variable = variable >> 1;
 
// es más óptimo que esto
variable = variable / 2;

Esto lo podrías optimizar un pelin ( siendo quisquillosos )

// Con código redundante
if(n == 0)
    return 0;
if(n == 1)
    return 1;
if(n == 2) //Evitamos recurion infinita si n == 2
    return 1;
 
// Optimizado
if(n == 0)
    return 0;
if(n <= 2) // Se evita una comprobacion en cada pasada
    return 1;

Si reutilizas algún cálculo costoso, intenta precalcularlo

// Sin optimizar
return fibo(n / 2) * (fibo((n / 2) + 1) + fibo((n / 2) - 1));
 
// Optimizado
int temp = n / 2; // o mejor aun temp = n >> 1;
return fibo( temp ) * ( fibo( temp + 1 ) + fibo( temp - 1 ) );

También creo recordar, no estoy 100% seguro, que para saber si un número es divisible entre 2 se puede optimizar también de la siguiente forma ( como no aprovechando desplazamientos binarios ):

// Sin optimizar
if(n % 2) //n impar y mayor que 2
 
// optimizado
if ( ( n >> 1 << 1 ) == n )

Esto último básicamente consiste en eliminar el bit de menor peso del número ... si es par, ese dígito es cero y el número permanece invariable.

Son truquillos tontos si quieres conseguir arañar hasta la última señal de reloj del procesador.

Eso si, te lo has currado, no voy a ser yo el que te quite el mérito.

Enhorabuena.[/code]