Mensajes

El problema viene principalmente por un mal diseño de la aplicación. Haces lecturas del teclado en sitios diferentes:

* En Nave::Mover
* En el main, en el bucle del juevo

Esto hace que la lectura del main te borre las pulsaciones que te permiten mover la nave. Si pruebas a centralizarlo en una única lectura deberías ver que ya no es necesario dejar el dedo pegado a la tecla.

Matemáticas básicas. a - b no es lo mismo que b - a.

Cuando tu escribes "a-b" el compilador sustituye ese código por a.operator-(b), es decir, llama a la función "operator-" de a, no de b.

Si la implementación de la función luce tal que:

Código (cpp) [Seleccionar] Expandir

POO POO::operator-( POO b )
{
  POO res.variable = b.variable - variable;
}

Entonces el resultado de la operación es b - a, no a - b. Y con la división lo mismo.

Hay que tener especial cuidado con ciertas operaciones aritméticas.

Por otro lado, te digo lo que a todos, va siendo hora de que aprendas a utilizar el depurador de código. Se que al principio cuesta un poco, pero tienes que pasar por ello antes o después... y cuanto antes mejor para ti.

Un saludo.

si tu haces v.erase( it ), el iterador it queda invalidado, cualquier operación que hagas sobre el mismo después del "erase" será errónea.

Lo que puedes hacer es crear en el momento de borrar un segundo iterador, incrementas el primero y después haces un erase sobre el segundo:

Código (cpp) [Seleccionar] Expandir

if (dist > med)
{
  auto it2 = it;
  it++;
  v.erase(it2);
}


Un saludo.

"0-130" no es un char*, es un const char*. Aunque pueda parecer una tontería no lo es. Si intentas modificar un const char* durante la ejecución del programa puedes conseguir que tu aplicación funcione incorrectamente.

Si tu idea es copiar ese string en la variable, usa strcpy. No lo hagas a pelo.

¿Proyecto final de curso y no sabes trabajar con ficheros????

¿Qué tienes hecho? ¿Qué te falla?

[pueda]

Ha, pero si yo nunca dije que QBasic es mejor que cualquier compilador de hoy dia de Cpp. Al contrario, recuerdo haber dicho que use qBasic como ejemplo de lo peor que haya existido.

Te cito:

Es más, invertiendo tiempo se puede hacer que le infame compilador QBasic de Microsoft de los 80 genere codigo más optimizado que VC++ o Intel C++. Pero claro, ¿Quien va a invertir en eso?

¿Entonces a qué te refieres?

Lo que en realidad discuto es que aqui se habló de que Rust es más rápido que Cpp.

Lo cierto es que en el mundo de la programación aparece con demasiada frecuencia la intención de optimizar y hacer todo más rápido cuando lo cierto es que en el 90% de los casos no es necesario. Puedo entender que si un código tiene que ejecutarse en una millonésima de segundo o si resulta que la función en cuestión se llama de forma iterativa millones de veces pueda hacerse necesario algún tipo de optimización... pero una aplicación de escritorio que lee 1000 entradas de una base de datos y presenta una serie de datos, salvo que el programador sea un inutil o surja un requisito específico, no suele necesitar ningún tipo de optimización.

El ser humano mide el tiempo en segundos, minutos y horas y no es por casualidad. No somos capaces de notar la diferencia entre un evento de una milésima de segundo y otro de media milésima... de hecho nuestra vista no suele alcanzar los 100 imágenes por segundo, es decir, no es capaz de distinguir dos eventos que se producen en un intervalo menor a una centésima de segundo. Es más, aunque el evento que se lanza al presionar un botón tardase cerca de medio segundo (que ya es tiempo con los procesadores actuales) el usuario no le daría mayor importancia porque, simplemente, es un tiempo demasiado pequeño para percibirlo.

En cualquier caso, al que le preocupe el rendimiento y la velocidad, que pruebe a programar sistemas distribuidos y a programar los núcleos CUDA de las tarjetas gráficas, pero vamos, que se pueden contar con los dedos de una mano las situaciones en las que hace falta llegar a este extremo: ciencias experimentales, cálculos balísticos... vamos, algoritmos que se suelen aplicar en superordenadores.

Pero vamos, que las peleas en cuanto a la velocidad y rendimiento no es algo nuevo...

E insisto, ¿Como un lenguaje puede ser más rápido que otro en sentido que produce mejores ejecutables?
Cuando en realidad es el compilador de dicho lenguaje  que es el encargado de esa tarea.

A ver, un lenguaje, perdón, el código generado a partir de de un lenguaje de programación puede ser por definición más lento que otro diferente, es un echo. Por ejemplo lo dicho, declarar una variable en C++ puede suponer una cantidad indeterminada de llamadas anidadas, mientras que en C tienes más control sobre este mismo proceso.

Como te comenté, los compiladores encargados de lidiar con un lenguaje de programación en completo pueden llegar a hacer maravillas en cuanto a optimización, pero éstas tienen un límite, ya que no pueden impedir, en el caso concreto del C++, las llamadas encadenadas que se producen en los constructores en herencia.

La naturaleza propia de un lenguaje de programación va a marcar la hoja de ruta del proceso de compilación y eso va a limitar la capacidad del compilador para proporcionar código eficiente.

Si se quiere comparar dos lenguajes, pues el parametro a mi criterio es la versatilidad por ejemplo. Pero de ninguna manera velocidad.

Comparar lenguajes de programación siempre es polémico. Generalmente no se pueden comparar... es como comparar dos frutas, cómo catalogas el tamaño? y el sabor? y el color? ... la versatilidad tampoco se libra, ¿cómo se mide?

Se pueden hacer estudios más o menos específicos que apliquen un baremo establecido previamente para intentar dar una nota a cada lenguaje, pero aun así sigue siendo algo totalmente subjetivo. Cada lenguaje se ha creado pensando en satisfacer una serie de necesidades más o menos concretas.

Aparte de lo dicho por rir3760, debes plantearte también quitarte el miedo y empezar a depurar tus programas. Al principio puede parecer complicado, pero es una herramienta tremendamente útil a la hora de localizar problemas en el código.

PD.: deberías revisar el uso que haces de las variables "i" y "j"... especialmente en el segundo bucle

Lo primero que deberías hacer antes de escribir una sola línea de código es pensar en la forma de resolver el problema que te plantean.

Puedes hacer diagramas, pseudocódigo, ... el caso es que el método que uses debería decirte la forma que debe tener el programa para hacer lo que tu quieres.

Tú me pides que te diga algo del estilo "mira, en la línea X pegas este texto; en la línea Y sustituye esto por esto otro y lo de la línea Z lo comentas todo" pero ese tipo de soluciones las va a borrar el moderador en cuanto las vea.

Te he dado una solución a tu problema... el if tiene como finalidad ejecutar su contenido únicamente cuando se haya encontrado una secuencia más larga que la actual... seguro que eres capaz de encontrar el sitio adecuado donde insertar el código

Cuando digo invertir tiempo, me refiero a  reiscribir el codigo del  compilador de QBasic... llamalo qBasic64 para plataforma de 64 bit inclusive y que incluya optimizaciones SSE3, SSE4 y demas.

Eso es justamente lo que ha pasado con los compiladores que tienes hoy en día... han ido evolucionando a partir de lo que había en ese momento.

No puedo hablar de Basic porque no es mi campo y hace como que 15 años que no lo toco pero en C++ ha pasado justamente eso: El compilador C++ de gcc, por ejemplo, creo que nació en los 90... y desde entonces se le han ido aplicando mejoras y optimizaciones hasta llegar al día de hoy. Si me dices que un compilador de gcc de esa época era mejor que los de hoy en día entonces te digo con toda la tranquilidad del mundo que te equivocas.

Otra cosa que puede pasar es que estés más familiarizado con los compiladores de ese momento y sea más sencillo para ti usarlos, pero de ahí a afirmar que eran mejores que los que encuentras hoy en día...

Creo que lo tomaste en contra, y de hecho, el comentario mio fue apoyando el tuyo...

Vale... es lo que tienen los foros... no suelen transmitir lenguaje no verbal .

En serio que es que no entendía la respuesta, pensaba que habías malinterpretado mi comentario o algo así, no se.

Mil disculpas por intentar liarte jejejeje.

Es más, invertiendo tiempo se puede hacer que le infame compilador QBasic de Microsoft de los 80 genere codigo más optimizado que VC++ o Intel C++. Pero claro, ¿Quien va a invertir en eso?

Pues fíjate que no me lo creo. Los procesadores nuevos tienen características que no existían en los años 80. Por tanto los compiladores de esa época no están preparados para trabajar a nivel óptimo con los compiladores actuales y, en consecuencia, no van a poder aprovechar todo el potencial que ofrecen los equipos modernos.