Mensajes

[el programa funciona]

Tengo un curioso problema que me esta mareando un poco, os explico:

Código [Seleccionar] Expandir



int main(){
   string entrada;
   map <int, bool> A;
   map <int, bool> B;
   getline (cin, entrada);
   cout << entrada << endl;
   A = separa (entrada);
   while (getline (cin, entrada)){
       B = separa (entrada);
       map<int, bool>::iterator it = A.begin();
       for (; it != A.end(); it++){
           map<int, bool>::iterator itb = B.find(it->first);
           if (itb == B.end()){
               A.erase(it->first);
               map<int, bool>::iterator it = A.begin();
           }
       }
       muestra (A);
   }
}



Omito las funciones y cabeceras, se que funcionan y no me dan problemas, y aclaro un poco este follón de código.

Lo que hago, es capturar secuencias de enteros y filtrar solo los que aparecen en todas las líneas. Mi idea es capturar una linea y meterla en un mapa (Mapa A), las siguientes en el mapa "B".

Luego, itero el mapa "A" y compruebo si la llave del iterador existe en el mapa "B", y en caso de que no sea así, borro de A esa clave.

El caso es que el programa, tal y como está "revienta". Solo puedo asumir que tengo un iterador "loco" corriendo por ahi, pero no acabo de ver cual, porque veamos:

Tengo un iterador "it" que va a recorrer los valores del mapa A, y lo ubico en su primera casilla. Luego, compruebo con el iterador ITB si el valor de la llave de ese iterador existe en "B", si el valor devuelto es "B.end" entonces es que no está, por lo que borro ese contenido en "A".
Soy consciente desde luego, que desde el momento en que efectuo una operación de borrado, ese iterador deja de ser valido, por lo que lo devuelvo a su punto inicial, pero vamos... no se porque "explota"

Estoy pensando obviamente en no borrar nada, y usar el valor asociado a la clave (que es booleano) para marcarlo, y ya os diré como va la cosa, pero claro, el tema es que si quisiera borrar datos, me veo ante un código que falla, y no tengo claro porque.

A ver si alguien ve donde estoy metiendo la gamba

Por cierto, si hago eso que os he comentado, el programa funciona... os pongo el código entero por si alguien quiere aclararse un poco mas

Código [Seleccionar] Expandir


#include <iostream>
#include <sstream>
#include <map>
using namespace std;

map <int, bool> separa (string& s){
   istringstream S (s);
   map<int, bool> ret;
   int n;
   while (S >> n){
       ret[n] = false;
   }
   return ret;
}

void muestra (const map<int, bool>& m){
   map<int, bool>::const_iterator itm = m.begin();
   for (; itm != m.end(); itm++){
       if (itm->second == false) cout << itm->first << ' ';
   }
   cout << endl;
}

int main(){
   string entrada;
   map <int, bool> A;
   map <int, bool> B;
   getline (cin, entrada);
   cout << entrada << endl;
   A = separa (entrada);
   while (getline (cin, entrada)){
       B = separa (entrada);
       map<int, bool>::iterator it = A.begin();
       for (; it != A.end(); it++){
           map<int, bool>::iterator itb = B.find(it->first);
           if (itb == B.end()){
               it->second = true;
           }
       }
       muestra (A);
   }
}


Claro, el programa ahora va, pero sigo sin saber porque la versión anterior que borraba los elementos no repetidos no lo hace, y preferiría saber porque es eso, antes que pensar "buenooooo ahora funciona, no me preocupo mas"

[muy]

Eso si, sin ánimo de desanimar a nadie, y desde la perspectiva de alguien que todavía está aprendiendo este lenguaje.... C++ es un lenguaje complicado, muy complicado en algunos aspectos. Tiene fama de ser puñetero, y la tiene con motivos.

Eso si, lo único que vas a encontrar que genere código ejecutable mas rápido es o el C puro (en algunos casos) o el ensamblador.

Los lenguajes interpretados (Java, Basic, etc...) tienen la ventaja de cuando algo "casca", puedes tener una idea bastante clara de donde y porque... en los compilados, aunque hay herramientas para ello, es bastante mas complicado.

No lo digo para desanimar ni mucho menos (es de hecho un lenguaje apasionante), sino para que el que se meta en estos jardines, sepa que las rosas tienen pinchos

[es como zeus]

¿podemos demostrar la inexistencia de dioses como zeus?...

Carl Sagan dijo una vez, citando a Marcelo Truzzi : "Afirmaciones extraordinarias requieren pruebas extraordinarias"

Vamos, que si alguien quiere que creamos en algo inusual, mejor será que presente pruebas inusuales.

Lo que también preocupa, es que haya tanta gente excelentemente pagada en esos puestos y tan enormemente ignorante como para no entender que esa solución no va a aumentar sus ingresos, incluso aunque la aplicaran. Es posible de hecho que ocurriera todo lo contrario

Er... si y no.. las matemáticas no son solo bailes de numeros y cifras en la febril cabeza de los matemáticos, son también descripciones de lo que ocurre en la naturaleza muy a menudo.

Una sucesión de Fibonacci por ejemplo se da en la naturaleza de forma habitual, por ejemplo en la forma de ciclones, moluscos e incluso galáxias. Esa misma sucesión se da en la genealogía de las abejas, en las falanges de tus dedos, etc.


La definición de recta como "camino mas corto entre dos puntos" la siguen puntualmente las fuerzas de la naturaleza, y hay muchos ejemplos mas al respecto.

Los planetas y estrellas suelen ser esferas, y no por casualidad (exceptuando deformaciones gravitatorias desde luego).

Una demostración matemática podría ser perfectamente entendida por cualquier otra criatura inteligente (que tenga una tecnología desarrollada obviamente). La simbología no sería la misma, pero los postulados son universales.

Y desde luego, como han comentado que una cosa "pueda existir" desde luego no quiere decir que exista, y algunas cosas simplemente no pueden existir por su propia naturaleza.

No podemos tener (por ejemplo) un electrón del tamaño de una pelota de tenis, entre otras razones (que hay muchas) porque un electrón no es un objeto sólido en forma de bolita.

Paradójicamente, si que podemos tener un "núcleo atómico" tan enorme como casi 20 kilometros de diametro, pero no podemos tener uno de 50 Km de diametro 

Apunto que no podemos, porque semejante masa colapsaría en un agujero negro, y por lo tanto dejaría de ser una estrella de neutrones.

El pensar que en otro universo sea posible es irrelevante, porque no podemos acceder al mismo y comprobarlo, no deja de ser una especulación sin fundamento.

¿Algo mas?... pues no podemos tener un poliedro que sea inestable en todas sus caras, simplemente porque estaría "cayendose" eternamente, tendríamos una maquina de movimiento perpetuo, y eso en nuestro universo, no está permitido

Yo te diría "depende"

Depende de tus necesidades, si el juego es un juego de tablero relativamente sencillo, supongo que con VB te apañas

C++ es mucho mas potente, rápido y tiene herramientas para tratar datos increiblemente eficaces (listas, vectores, mapas, etc...). Obviamente no se programa igual, hay que aprender a pensar "de otro modo".

Si necesitas esa potencia, sin duda C++, si pretendes (por ejemplo) hacer una versión en ordenador del juego de la Oca o parchís me parecería exagerado aprender un idioma nuevo solo para eso, pero si necesitas manejar muchos datos y de forma muy rápida, entonces sin duda C++

Incluso por ejemplo un Monopoly (donde la rapidez no es tan importante) las estructuras de datos de C++ te facilitarían mucho la vida

Si la pregunta es "para guardar en un fichero", te diría que simplemente lo separaras con espacios y lineas

Por ejemplo:

22.5 13.22 11.55 -52.22
13.5 11.13 -9.5 6.33
.
.
.
.
etc...

Simple y fácil, sobre todo porque a la hora de leer el fichero puedes pillar los numeros directamente sin complicarte la vida con separadores de ningún tipo

Lamento preguntar algo tan "tonto" pero... ¿que se supone que es una ciudad inteligente?

[no el valor de la variable]

Quizás no me he explicado apropiadamente.

Un objeto según creo (e intento comunicar) no tiene una probabilidad de existencia (mecánicas cuánticas aparte, ese es otro tema). Un objeto está, o no está.

Por ponerlo en lenguaje de programación, una variable booleana puede tener un valor true, o false.

En un programa dado, es posible que la probabilidad de que una variable tenga un valor puede medirse según un porcentaje, pero ese valor es "la probabilidad de que una variable tenga un valor", no el valor de la variable

Vamos, que "o true o false", no existe un estado de "mitad y mitad". La probabilidad nos dice algo sobre como puede ser el estado de una variable, pero no sobre el estado real de la misma.

Si yo asigno una variable de tipo entero "A" el resultado de un generador de números aleatorios, que he puesto que me de un entero entre 0 y 9, la probabilidad de que ese número sea mayor que 5 es del 50% (a lo bestia y descartando muchos factores). No obstante, el valor real de la variable sigue siendo un entero, entre 0 y 9. El valor de "A" no es estadístico, aleatorio o una probabilidad, es un hecho claro desde el momento en que lo asigno. Antes de eso, esa variable no existe, y lo que existe es una probabilidad, pero esa probabilidad no es un valor intrínseco de una variable de tipo entero

erest0r, lo que intento decir es que tenemos que "jugar con unas reglas", según esas reglas existen o no cosas posibles. Si, en un plano curvo es posible tener un triángulo cuyos ángulos midan mas de 180 º, pero eso invalida la proposición de "en un plano euclideo", de manera que si... es imposible según esas reglas. Si cambiamos las reglas, cambia el juego, no podemos jugar al futbol y comernos a la torre  

De todos modos, habría quizás que delimitar hasta cierto punto el "debate" sobre si hablamos de objetos o cosas físicas o formalismos, porque en el ámbito de la lógica o la matemática es muy sencillo encontrar "imposibles".

Por ejemplo, en arimetica no es posible un resultado entero sin resto de la división de un numero primo por un número que no sea 1 y el mismo. Simplemente porque esa es la definición de primo, si un numero es primo, lo es... o no lo es. No cabe en este caso un "asi asi" de probabilidades. U otro ejemplo, en base 10, un numero es par o impar según sea o no divisible entre dos sin dejar resto. Un numero par no puede dejar un resto en una división entre dos, porque para empezar eso es incompatible con su definición.

Fuera del campo "platónico" ya el tema puede volverse mas complejo, y nuevamente necesitamos poner barreras, límites y normas, porque la posibilidad o no de la existencia de un objeto dado viene definida por unas normas o leyes, y esas leyes deben de ser conocidas. Si existe un objeto que las viola, entonces esas leyes ya no son válidas.

Por poner un ejemplo, según la teoría de la relatividad, ningún objeto con masa puede alcanzar o superar la velocidad de la luz en nuestro universo. Esto se ha comprobado hasta el cansancio pero... ¿y si ocurre?

Si ocurre, deberemos de revisar esas leyes, porque se ha demostrado que tienen un fallo, o que forman un caso particular de unas leyes mas amplias, tan sencillo como eso

Como se suele decir, tenemos que jugar con las cartas que nos han repartido, no podemos asumir "imposibles" según las cartas que tenemos como validos, pero si estos aparecen pese a todo, será porque tenemos una carta de la que no nos habíamos percatado

Como supongo que estamos hablando de un presupuesto muy limitado, ya que optas por AMD intenta poner algo mas de memoria y un SO de 64 bits, algo mas de memoria en estos programas nunca viene mal