¿qué se puede esperar cuando un tonto entra en un laboratorio?. Que crea que es una 'nevera' más grande que la de su casa... Es lo único capaz de ver, muy grande y muchos recipientes, no puede ver más.

Y ya desde ahí, viendo el tamaño, pedirá un yogur y cuando le digan que no, se quejará alegando que: "pués vaya la nevera de mi casa es mucho más pequeña y siempre tengo yogures, o la de cualquier amigo o conocido que tengo".

La ignorancia supina, los hace ser valientes.

No es buena idea que un sistema que deba hacer loogin, permita dejar el usuario escrito.
Un buen sistema cuando falle la contraseña, debería borrar el usuario y la contraseña (o no borrar el usuario), pero al menos SIEMPRE indicar que "el usuario, la contraseña o ambos no son correctos.". Por que indicar que el 'usaurio no existe' o 'contraseña incorrecta' es dar pistas... Ya se sabe que quienes diseñas estas cosas muchas veces tampoco tienen un mínimo de consideración con la seguridad, o bien son forzados por aquello de: "...hazlo para usuarios torpones." 

Entonces lo que pides, podrá o no ser posible, en base a cómo se haya diseñado el sistema de login.

Piénsalo un poco, es como si le dijéramos a los fabricantes de cerraduras: "Oye cuando rompa el muelle que sujeta cierta pieza de la cerradura, por favor, no solteis la alarma hasta que no corte el cable, de la alarma que hay un poco más allá del muelle"... y naturalmente más 61L1P0LL45 aún, si los fabricantes hacen caso.

La ayuda no es correcta proporcionarla sin saber como te va a ayudar.

Mejor indica como tienes pensado aocmeterlo y desde ahí se ve si el enfoque que llevas es válido, correcto, tiene defectos, qué fallos o complejidades te encontrarás, etc...

Cuéntanos, tu enfoque primero, así la ayuda será precisa y no genérica.

No es habitual tener que retener entradas fallidas. si son fallos se aporta info y se devuelve un error y listo. Si el sistema es desatendido y no va a estar presente nadie  (o no conviene dejar al programa en espera por una interacción con el usuario), simplemente se escribe un log y listo.

Indistintamente de que una clase provea o no una cola y un manejo profundo de la cola, nada le impide a uno, generarlo si lo precisa y en ese caso basta que el sistema provea exclusivamente la entrada actual (quiero decir que con que solo provea eso nos es suficiente, y ya aportaríamos nosotros el resto).

El siguiente pseudocódigo procesa entradas (de una forma muy simple) mientras el buffer del sistema nos provea de ellos. aunque se supone que lo correcto es que haya una suscripción a un evento del sistema que avisa automáticamente cuando esto sucede.



Da igual si usas una lista enlazada o una pila... básicamente una pila es una estructura ligera pensada para contener pocos ítems e introducirlos y rescatarlos en un orden específico. Ese orden también puede manenerse con una lista enlazada, aunque no tan evidente como la pila, sin embargo una lista enlazada está pensada para mantener una cantidad indefinida de elementos, una pila en general requiere especificar cuantos elementos ha de tener...

La cuestión, es que si mantienes aparte un buffer de fallos, la pregunta es para que lo quieres, es realmente necesario????.  Y más aún, es la forma correcta retener sólo los fallidos y no todos desde el primer fallo?, etc... (etc = surgen muchas más preguntas, que no es preciso enumerar y que hay que responder). Un breve comentario, para hacerte reflexionar...

Imagina un usuario que abre un vídeo, este está ultracomprimido y tarda en cargarse, mientras el usuario, pulsa 'play' 'avance hasta x posición', luego 'pausa', luego 'volumen +', luego 'fullscreen', luego como todavía no responde, pulsa 'stop'... Puede optarse por guardar todas esas acciones y procesarlas en ese mismo orden cuando se haya completado la carga del vídeo... pero ahora imagina el mismo caso con un menú... uno lo despliega y pulsa 'play', no responde, lo despliega nuevamente y pulsa 'play' , luego 'pausa', luego otra vez 'play'...etc... en este caso puede no interesar procesar cada entrada, ni mucho menos guardar en un buffer todos los fallos...

esto es, si uno considera que se deben procesar, o se procesan todos en el orden en que se producen o tras un fallo, hay que investigar que produce el fallo y en tal caso decidir, si abortar todo o bien guardar todos desde el fallo 8incluído la entrada con fallo) y esperar (si procede), para luego volver a intentar procesarlo todo desde ese punto.

La cuestión es que 'play', 'pausa', 'stop':
- A - Solo deben ser procesables si hay un vídeo cargado.
- B - Guardar al búffer si hay un vídeo cargándose.
- C - E ignorarlas por completo si no hay un vídeo cargado....
Incluso podría simplificarse para incluir B en el caso C.
Y por su parte cuando se carga un vídeo (al completarse la carga), debe verificar si hay un buffer de entradas sin procesar, y en consecuencia lanzar un evento para comunicar que ya está disponible para las entradas 'play', 'pausa' 'stop'...
en cambio fíjate que la entrada 'volumen +' y 'volumen -', se pueden ejecutar independientemente de si el vídeo está listo o no... y aunque sean entradas en medio de las otras. Al caso se provee otro parámetro asociado a cada entrada, que indica si  es prioritario su ejecución es ignorable, o encolable...

Si las entradas de esas acciones fueran del modo 'P' para pausa, 'Y' para 'play', 'S' para 'Stop', 'V' para 'volumen +' y 'v' para 'Volumen -', y 'L' para 'Cargar vídeo' y 'D' para 'Descargar vídeo' tu debes mantener si 'L' ha sido procesado ya o no, 'D', deshabilita 'L'. Tras un fallo debes hacer un segundo procesado en base a su 'priorización', y en este caso ver el estado de 'L'...

En fin, uno debe saber que entradas pueden ser procesadas y cuales no... pero espero que esto te haga reflexionar para encontrar la solución adecuada que necesites.

Claro...

PC, es el registro Contador de Programa (Program Counter), también conocido como IP (Instruction Pointer).
Cuando dicho registro apunta a una dirección, lee la siguiente instrucción (read Address), y en consecuencia el contador de programa luego debe añadir los bytes necesarios para apuntar a la siguiente instrucción (por eso aparece el sumador (Adder).  Los procesadores ARM, tienen un ancho fijo para sus instrucciones ensamblador de 4 bytes, en cambio en los 86, el formato no es fijo.
el sumador tiene dos patillas, porque una suma se compone de dos operandos (sumando y sumador), el sumador son 4 bytes, el sumando es la posición de memoria actual, es decir además de ser un operando es el acumulador:  PC = (PC + 4)

El panel donde pone "Instruction Memory, refleja la memoria, concretamente el área de código del programa, y donde está la flecha "Instruction, quiere indicar que tras ser leída la instrucción, pasa a ser decodificada, en general suele entrar en una etapa en cascada, que no aparece....

La imagen ciertamente ni es muy clara ni muy precisa...

Vaya, esta vez han acertado de pleno 


...ahora compremos la privacidad de todos los políticos, y sáquemosla a la luz pública, especialmente la de aquellos que han votado por que esto sea así...

Bueno, esto es fácil de bloquear, si uno es consciente de ello. Basta una cinta adhesiva tapando la cámara y listo.

Pero no deja lugar a dudas que la definición de espionaje incluye lo de: "sin tu conocimiento ni tu consentimiento", así que sí... eso es espionaje y me temo que es ilegal...

Puedo entender que las empresas quieran exprimir la tecnología para sacar beneficios, pero nunca por encima d ela ley, ni forzando nuevas leyes para dejarles dentro de la ley.

Ya está 'descifrado' kalcetins@gmail.com
Ah y si no es esa, puedes probar con las 4'05*10^67 contraseñas más...

 

Cuando haces un trabajo y tiras para adelante... lo haces de unammanera concreta...
Luego a veces te vienen con cambio de especificaciones, y quieren cosas que antes no venían...

Bueno, entonces toca remodelar de nuevo toda esa área, despreciar esa parte y no tratar de aprovecharla al 100%, porque será un engorro el código necesario para soportar esos cambios. Mucho mejor rehazlo ahora pensando en que si antes solo tenías que soportar el objeto A, ahora lo rediseñas teniendo presente el objeto A y el objeto B.

Que sean distintos, implica que debes pensar en una solución común a ambos casos.

en general usa una función donde pases diferentes parámetros y al menos tenga uno de retorno, para verificar diferentes casos que pudieren darse.

Si antes tenías algo equivalente a esto 8da igual como implementes el código):

Ahora podrías tener esto otro (también da igual como implementes tu código):

Has hecho lo mismo que antes con el objeto A (la materia en cuestión que hacías antes, sea cual sea), ahora puedes chequear además lo que sea para el objeto B, aunque sea de otro tipo.
Y al final, devuelves un entero, es decir puedes unificar un criterio, incluso por cuestiones distintas.
Si el criterio fuera inaceptable para ser unificado, entonces el valor para el objeto B, lo podrías devolver por referencia, dejando libre el retorno de la función para el objeto A... Y al retorno, debes verificar además del resultado del objeto A, el retorno por referencia del objeto B (antes o después del A, eso debe saberlo quien lo programa), o descartarlo, según proceda.

Aunqe no te lo parezca, yo he usado por lo menos una docena de veces la serie de Fibonacci en diferentes campos.

La serie de Fibonacci, presenta escalones de una curiosidad intelectual enorme, que luego si tienes ocasión puedes aplicar generosamente con más eficacia que otros medios más simples y toscos.