Dado el tipo de error, lo que deberías postear es el contenido de SerialClass.h. Es casi seguro que ahí esté el problema. O cambia el parámetro de Serial::Serial a const char*, que de cualquier forma, independientemente de que compile o no, es lo correcto si quieres aceptar cadenas literales.

La forma en que funciona el sistema de diagnóstico y reporte de errores de Windows es algo compleja, y la información oficial está bastante dispersa, pero aquí se explica lo que se puede enviar cuando hay errores del sistema: https://learn.microsoft.com/en-us/troubleshoot/windows-server/performance/memory-dump-file-options

en Windows 10, el tipo de volcado predeterminado es el Automático, que es casi igual al de memoria del kernel.

Más interesante es lo que pasa cuando es una aplicación la que produce el error. De forma general se recogen datos parecidos a los de los errores de sistema: pila de llamadas, lista de módulos cargados y handles del proceso, estado de los registros, instrucción que provocó la excepción, etc. Lo llamativo en cuanto a la privacidad es que Windows 10 ya ni siquiera pregunta: con la configuración predeterminada, cuando un programa termina de manera inesperada, de forma automática y silenciosa se crea un reporte que es enviado a los servidores de Microsoft (a menos que el programa solicite que no se haga). Y el programa en cuestión puede pedir a Windows que anexe al reporte cosas adicionales como volcados de bloques específicos de memoria o archivos. Las empresas de software pueden registrar sus aplicaciones con Microsoft y así tener acceso a estos reportes, entre otras cosas. Si somos paranoicos, notaremos que, dado que es Windows el que recaba y envía los datos, esto permite que, sin siquiera acceder directamente a internet, los programas puedan enviar información más o menos arbitraria de manera indirecta... XD

Nah, la verdad es que exagero. El mecanismo es más complicado que esto, y aún si el programa solicita el anexo de datos extra, se requiere algún paso adicional para que sean realmente enviados. Y para acceder a esto, como decía, hace falta registrarse con Microsoft y proporcionar datos de contacto personales, de empresa, etc. Obviamente no es imposible falsificar esa información, pero es arriesgado y, como digo, no tan simple como pareciera, por lo que veo poco probable que pase. Y no es tan difícil saber si un programa está husmeando en directorios o archivos indebidos. De todas formas, esto puede ser una razón adicional para no ejecutar cualquier programa que se descarga uno de internet.

Es bueno ser precavido y tener un poco de paranoia, pero sin exagerar. Seguramente Microsoft recolecta más información de la estrictamente necesaria, pero yo no me alarmaría. A diferencia de Google o Facebook, ellos no son una empresa que dependa de la publicidad. Sus negocios principales, y que son los que más dinero le dejan por mucho, son servicios empresariales en la nube, suscripciones de Office y cosas por el estilo, y por las que la gente paga. Realmente no tiene un gran incentivo en la actualidad para espiar excesivamente a los usuarios (palabra clave: "excesivamente", porque yo creo que, en mayor o menor medida, la mayoría de las empresas lo hacen), arriesgándose a sanciones, multas y demandas, cuando la publicidad no es ni por mucho una de sus áreas esenciales.


No es así. Por lo menos una buena parte de lo que se envía sí que es información de diagnóstico que puede ser bastante útil para los desarrolladores. Es difícil saber exactamente qué datos se mandan, pero sí se sabe con precisión que incluye esto: información del hardware, consultas hechas en la barra de búsqueda de Windows, información de varias actividades de Windows (búsquedas de actualizaciones, por ejemplo), como el tiempo que tomaron, la fecha y hora, el resultado, códigos de error si los hay, etc., y creo que también la frecuencia con que ejecutas ciertas aplicaciones, aunque no estoy seguro de si esto sólo lo hace cuando eliges el envío de datos opcionales.

Además de lo anterior, cuando los reportes se generan en respuesta a un error de sistema o de alguna aplicación, hay bastantes cosas más que pueden ser enviadas, aunque esas ya no dependen totalmente de la configuración de datos de diagnóstico general, sino que influyen otros factores, pero no sé si también te interese saber sobre eso.

Difícilmente. Obviamente, todo eso ya lo había pensado cuando escribí: "no se me ocurre ninguna razón medianamente razonable o inteligente para haber borrado ése", por eso especifiqué lo de "razonable o inteligente".

Para empezar, ilegal no es. El usuario no preguntaba cómo conseguir cuenta premium gratuita, ni cómo entrar a cuentas ajenas, ni cómo acceder a una misma cuenta de Spotify desde dos dispositivos distintos simultáneamente, ni nada por el estilo. Lo único que quería era abrir dos instancias de la aplicación en su PC, con dos distintas cuentas, cosa que se puede hacer sin problemas desde el navegador, y desde la app de Android. Sospecho que la limitante en PC es más por cuestión técnica (muy poca gente querría esa funcionalidad, así que ¿para qué implementarla?), aunque no lo sé con certeza.

Por supuesto, tampoco atenta contra la privacidad de nada. Otra cosa muy distinta es que pueda ir en contra de los términos de uso, lo cual no sé, pero dudo mucho que sea el caso (no tendría sentido), y un vistazo rápido a los TOS de Spotify no muestra ninguna prohibición o restricción que remotamente se relacione con esto. De cualquier forma, sería bastante incongruente borrar un tema por eso, cuando, por ejemplo, los propios administradores les pasan a los usuarios links a activadores de Windows y Office, y hay una colección muy grande de manuales (muchos de los cuales prohíben expresamente la distribución de copias) que incluso están alojados en los servidores de elhacker.

Completamente de acuerdo.

También una cosa sería borrar temas sin respuesta. Ahí no creo que importe mucho, pero si el tema ya tiene respuestas...

Porque justamente eso pasó con un tema donde se preguntaba cómo abrir dos instancias de Spotify en PC, y ayer lo borraron. Digo, yo no lo creé, pero sí respondí, y al menos otros tres usuarios también dieron sugerencias, y ahora todo eso se fue a la basura. ¿Qué sentido tiene entonces tomarse el tiempo de responder preguntas si van a borrar los temas por borrarlos? Porque no se me ocurre ninguna razón medianamente razonable o inteligente para haber borrado ése.

Es porque ese manual está muy obsoleto (además de ser muy malo).

En el C++ estándar (desde 1998, para que veas lo obsoleto del manual) ostream está dentro del namespace std. Para que te compile, debes escribir std::ostream

C no da ninguna forma de hacerlo. Dado que es un lenguaje pensado para ser extremadamente portable y correr en prácticamente cualquier tipo de hardware, ni siquiera tiene concepto de secciones (ni de pilas ni de otras muchas cosas que aunque pueden parecer universales, no necesariamente lo son en algunas arquitecturas, o en sistemas embebidos).

Los compiladores sí que pueden añadir ciertas capacidades como la que tú pusiste, pero eso es cosa de GCC, no del lenguaje. El propio GCC, al menos en Linux declara los símbolos etext, edata y end, pero estos indican el final de las secciones, así que no sé si te sirvan de alguna manera.

Windows proporciona APIs (aunque no son estándar de C, sí lo son de Windows, por lo que son accesibles desde cualquier compilador para este SO) que facilitan mucho este trabajo, pero sólo para ejecutables PE.

Si forzosamente lo necesitas para ELF y sin usar APIs externas, creo que lo único que queda es leerte la especificación de ese formato y programar de cero la solución.

Si entendí bien lo que quieres, puedes lograrlo así:

=TEXTO(MIN(A2:C2), "0") & ", " & TEXTO(MIN(D2:F2), "0") & ", " & TEXTO(MIN(G2:I2), "0")

De hecho, dado que no necesitas un formato especial, esto también debería funcionar:

=MIN(A2:C2) & ", " & MIN(D2:F2) & ", " & MIN(G2:I2)

Eso huele a código copiado, pero dando el beneficio de la duda:

	putchar(argv[1][0]);  //El primer caracter en la salida estandar y escribe en la tuberia, imprime el primer caracter

*primer caracter*. ¿Cómo esperas que se muestre el nombre completo del archivo si sólo estás imprimiendo el primer caracter (algo que "tu" propio comentario explica  )?

Y además tienes esto:

#define NUM_HIJOS 10
...
pid_t pids[NUM_HIJOS];

pero la ruta que le pasas al programa puede tener más de 10 entradas, y de hecho, en tu caso, dices que son 17, así que estás provocando un desbordamiento de buffer. Y tienes estos for inconsistentes:

	for(i=1; i<argc; i++){
...
	for(i=1; i<NUM_HIJOS; i++){

pero NUM_HIJOS no tiene por qué ser igual a argc. De hecho casi nunca lo será. Lo que debes hacer es reservar dinámicamente la memoria para pids de acuerdo al número de archivos (argc - 1), y en tus dos for usar argc como límite superior.


Y esto:

            /*Redireccion de la entrada estandar al archivo*/
            if ((fd[0] = open(argv[1], O_RDONLY)) == -1){
                fprintf(stderr, "Error en la apertura del archivo de datos\n");
                return EXIT_FAILURE;
            }

 no tiene razón de ser. Sustitúyelo por un simple:

close(fd[0]);

Sí, a eso me refería, y mejor, porque eso lo podría complicar bastante.



Cuando escribí esto:


Me refería a que para calcular el ángulo inicial de v para la parábola, sólo se usan 2 dimensiones: la altura y la distancia "hacia adelante". Esta última tú la ves como 2 dimensiones (y como una diagonal en tu dibujo) porque la perspectiva es aérea, pero no tendría que ser forzosamente así. Una buena forma de visualizar esto es imaginar que observamos el tiro desde una perspectiva lateral donde el eje horizontal es paralelo a la trayectoria que seguirá la pelota. Se ve mejor en esta imagen:



Si estuviéramos donde está el círculo amarillo de esa imagen, y a ras de suelo, veríamos lo que te puse en la imagen de mi mensaje anterior, que es la que debes tener en mente todo el tiempo que hablemos de la parábola. Desde ahí sólo tenemos 2 dimensiones, ya que la pelota ni se acerca ni se aleja de nosotros. Los cálculos que se hagan son igualmente válidos. Ese cambio de perspectiva, por así decirlo, es lo que se consigue al hacer esto que te había escrito:


Nota que estamos combinando DistanciahastaDestinoX y DistanciahastaDestinoX en una sola dimensión, que llamamos x, para hacer los cálculos de la parábola. Naturalmente, luego habrá que reconvertir a 3D para mostrar en pantalla. No lo especifiqué porque no tenía idea de qué tanto conoces de estos temas, pero básicamente lo que se hace es revertir la combinación. Más adelante te digo cómo.

Para evitar confusiones, siempre que mencione x o y, me estaré refiriendo a estos ejes desde la perspectiva lateral del dibujo de mi mensaje anterior. Y cuando quiera hacer referencia a la toma aérea (llamémosla coordenadas de pantalla), usaré tus variables BallX, BallY, etc. Si ves el dibujo de la toma lateral, verás que x se refiere a la trayectoria de la pelota (que en coordenadas de pantalla puede ser diagonal, pero desde nuestra perspectiva siempre es de izquierda a derecha simplemente), mientras que y es la altura, que se correspondería con BallZ.


Si te refieres a la fuerza, es sólo por ser quisquilloso. Lo que pasa es que en física la fuerza es algo muy concreto que no se mide en distancia por segundo sino en newtons y se refiere a cuánta aceleración le puedes imprimir a un cuerpo de acuerdo con su masa, por lo que no se traduce directamente en velocidad. Solamente sería útil si quisieras una simulación ultra realista, que tome en cuenta la masa de la pelota, quizás resistencia del viento, etc., pero para algo como un juego sencillo sólo complicaría las cosas innecesariamente. Como dije es perfectamente válido llamarla fuerza en tu juego, pero si buscas información en internet o libros, el término que encontrarás es velocidad inicial.


En ese caso sí, pero es más bien por coincidencia. Como te comenté, la forma en que se distribuye la velocidad es: v0 = raiz(vx² + vy²). Si la velocidad es totalmente vertical, la horizontal será cero (y viceversa), luego v0 = raiz(vy² + 0), así que v0 = vy, pero sólo para este caso.


Más o menos, en el sentido de que va ejerciendo una aceleración hacia abajo a lo largo del tiempo. En la realidad es más o menos como el método que te pongo (salvo que simplificamos obviando resistencia del viento, masa, etc.). De hecho, las ecuaciones de parábola que uso son justo las que encontrarías en un libro de física.


Entonces hay que hacer algunos cambios, ya que la fórmula del rango R es para cuando la altura inicial y final son iguales. También se hacía esa suposición en la ecuación de la parábola para y, que ahora quedaría así (otra vez, en negrita lo que realmente necesitas calcular en el programa):

y = h + v0 * sen(θ) * t - (g * t²)/2

donde h es la altura inicial de la pelota.

La distancia en línea recta, x, entre la pelota y el objetivo se sigue calculando igual:

x =  raiz(DistanciahastaDestinoX² +  DistanciahastaDestinoY²)

El cálculo del ángulo se complica, pero sólo un poco. Queremos el valor de θ que permite que cuando la bola caiga (cuando y = 0) haya recorrido la distancia x deseada, así que la ecuación para y queda:

h + v0 * sen(θ) * t - (g * t²)/2 = 0

Pero como no conocemos t, necesitamos usar la otra ecuación que puse en el otro mensaje:

t = x/(v0 * cos(θ))

Sustituimos t por esto en la ecuación para y:

h + v0 * sen(θ) * x/(v0 * cos(θ)) - (g * (x/(v0 * cos(θ)))²)/2 = 0

Si la manipulamos un poco usando las propiedades de las funciones trigonométricas, la podemos convertir en una ecuación de segundo grado que se puede resolver con la fórmula general, y que al final reducimos a esto:

θ = arctan((v0² ± raiz(v0⁴ - (g * (g*x² - 2*v0²*h))))/(g*x))

Como toda ecuación cuadrática puede tener 2 soluciones, por lo que es posible que haya 2 ángulos válidos.

Aquí conviene primero calcular el valor del que se saca la raíz:

disc  = v0⁴ - (g * (g*x² - 2*v0²*h))

Si disc (que es equivalente al discriminante típico de la ecuación cuadrática) es negativo, significa que no tienes la "fuerza" necesaria para el tiro. Si es cero, las 2 soluciones son idénticas, así que sólo hay un ángulo. En caso contrario, hay dos ángulos distintos. Procedes a calcularlo(s):

θ1 = arctan((v0² + raiz(disc))/(g*x))
θ2 = arctan((v0² - raiz(disc))/(g*x))

Lo que seguiría es verificar, para cada ángulo, si pasa la red. Esto no cambia, y se sigue haciendo como en el mensaje anterior. Si sólo uno de los 2 ángulos lo consigue (o sólo había un ángulo), es el que hay que usar. Si los dos lo hacen, toca elegir el que quieras. Si lo que buscas es el que permita mayor velocidad hacia adelante (y menor altura), escoge el menor de θ1 y θ2.

Finalmente, para poder ir mostrando en pantalla la trayectoria, toca convertir las velocidades a 3D. BallZSpeed es la más simple (recuerda que en el mensaje anterior se calcularon vx y vy):

BallZSpeed = vy

aunque con este método no la necesitarías, ya que lo ideal sería calcular directamente la posición BallZ con la misma ecuación de la parábola:

BallZ = h + v0 * sen(θ) * t - (g * t²)/2

de nuevo, h es el valor original de BallZ al momento del tiro, y en t pones el número de segundos transcurridos.

Para las otras dos, hay que hacer unos cálculos. De la misma forma que nuestra x combina DistanciahastaDestinoX con DistanciahastaDestinoY, vx combina  BallXSpeed con BallYZSpeed. Para separarlas hay que conocer el ángulo de inclinación del trayecto de la bola visto desde arriba. Primero, hay que considerar el caso especial para cuando el destino está en línea totalmente vertical: eso significaría que toda la velocidad se aplicó en una sola dirección:

si (DistanciahastaDestinoX == 0)
   BallYSpeed = vx
   BallXSpeed = 0


en caso contrario, primero calculas la pendiente m de la trayectoria (vista desde perspectiva aérea/de pantalla):

m = DistanciahastaDestinoY/DistanciahastaDestinoX

luego su ángulo α:

α = arctan(m)

y con eso obtienes:

BallXSpeed = vx * cos(α)
BallYSpeed = vx * sen(α)

Sí, es vx en ambos casos, porque contiene las 2 velocidades combinadas.


No. Eso sólo te serviría si el tiro es exactamente en línea recta vertical (en coordenadas de pantalla/vista aérea), pero cuando es en diagonal esa distancia cambia, y además depende del punto de la red por el que la pelota pase.Como te había dicho, lo que se hace es calcular la intersección de la recta que define la red con la del trayecto de la pelota. Hay más de un método para la intersección; no sé si los conozcas.


¿Es el método que usas en tu juego? No está mal, salvo que, como dices, no toma en cuenta la gravedad, y si después la aplicas, descompones totalmente los cálculos. Además ese método hace que la pelota baje desde el primer momento, cuando para ciertos ángulos, primero debería elevarse. Así y todo se ve aceptable, pero no sé si podrías meterle la gravedad de forma convincente ni qué tan complicado sería.