Ciertamente migrar a NET te ayudaría, pero no hay que ser drástico, puedes perfectamente operar con VB6 y ocultar datos del usuario... la operación básica se llama cifrado.

- Una sencilla forma es codificarlo por ejemplo en Base64 (o base32 o base16, pero con base64, tendrás un tamaño más ligero).
- No obstante esto es solo codificado (un cambio de código), no queda cifrado... para cifrarlo de modo sencillo, puedes usar el operador lógico XOR, con uso de alguna clave.
- Si exiges contraseña, exige SIEMPRE una contraseña de al menos 16 caracteres... nunca menor.

0 - Al iniciar el programa solicitas la clave al usuario. La clave, no la guardas ni la mantienes en memoria, simplemente se usa para generar un array muy grande (1Mb. por ejemplo) y esa puede ser la clave de cfrado y descifrado.
Podrías verificar si la clave es correcta o no antes de seguir, pero en general es preferible no hacerlo excepto si se han de modificar los ficheros... sí o sí. (por ejemplo imagina winrar, si vas a extraer un contenido (el original queda intacto), no importa verificar si la clave es correcta, simplemente se usa como si fuera, el resultado será urliburli, si no es la clave correcta, pero ha empeñado su tiempo en intentar descifrarlo, eso le da resistencia a intentos de fuerza bruta.
En cambio si el original ha de ser modificado, entonces es exigible asegurarse que la clave es correcta antes de modificar nada.
Para ello creas un array de contenido aleatorio (cuando se genera la aplicación), y realizas un hash a dicho contenido. Luego lo cifras y lo escribes a fichero y detrás el hash resultante.
Cuando se abre la aplicación y se solicita la contraseña y a partir de ella generas la clave, la usas para descifrar ese fichero en memoria (descontando esos bytes finales del hash), luego lo hasheas y veriificas que el hash coincide con el que aparece al final del fichero... si es ok, procedes a seguir cargando la aplicación, si no libera toda la memoria, y avisas del error de contraseña antes de cerrar la aplicación o exigir nuevamente la contraseña.
 
1 - Empiezas leyendo todo el contenido de un fichero en un array de bytes, luego cierras el fichero. Descifras usando la clave de 1Mb. byte a byte mediante xor. Si el fichero es mayor que la clave (1Mb. hemos dicho), vuelves a comenzar usando la clave desde el comienzo.
Tras esto, si todavía está codificado en base64, lo decodificas... y procede igual con cada fichero.

2 - Cuando debas escribir a fichero (haz lo mismo en orden inverso).
Primero codifícalo a base64 (si lo crees conveniente) y luego lo cifras con la misma clave (la función es la misma para cifrar que para descifrar).

Recuerda siempre sobrescribir el array que es la clave con contenido aleatorio antes de liberar el array...

Si los datos no son especialmente sensibles, posiblemente te baste con codificarlo en base64 y listo, pero si hay datos más sensibles, mejor cífralo.
No importa el orden:
 Si primero codificas a base64 y luego cifras
 O si primero cifras y luego codificas a base64.
Pero si debe es tener en cuenta dicho orden seguido para el momento de leer o escribir el fichero...
 

Veremos si le hará gracia a los nacionalistas, si se queman fotos de sus representantes... la cosa evidentemente será recíproca.

Y tampoco queda claro, si se aplica también a la quema de banderas. ...ya puestos, ya reunidos, creo que no hubiera costado mucho esfuerzo aclararlo también y no esperar a que existan juicios y haya reclamaciones y eternas esperas prolongadas en los años...

Hay propiedades que no deben ser de lectura y escritura...

Monto es un propiedad que requiere ser de lectura y escritura, pero deposito y retiro, deben serlo de solo escritura... esto es, una función única.


Como ves es más sencillo...
Fíjate que si el valor a retirar es superior al monto, la cuenta quedará en números rojos...
Al caso podría añadirse funcionalidad para indicar si se permite retirar dejando la cuenta en números rojos o no, y si se permite números rojos si hay un límite...
Te pongo lo primero, y te dejo que tu realices lo segundo:


Otra cosa es que puedas retener la última (ó x últimas) operaciones efectuadas...  por eso, comentado:
cout <<"El saldo es: "<<p1.getMonto()<<endl; <---- perfecto, OK
cout <<"El saldo es: "<<p1.getRetiro()<<endl; <---- carece de sentido
cout <<"El saldo es: "<<p1.getDeposito()<<endl; <---- carece de sentido

A cambio deberías teneruna propiedad llamada UltimaOperacion

Ahora ya puedes consultar además del saldo, la última operación y el valor de dicha operación... nota que leer el saldo, no se considera una operación, porque nunca  modifica ningún valor (por el mero hecho de consultarse).

Listo... queda a tu esfuerzo pasarlo a código.

Es curioso, que los portadores de armas... amantes ellos de la puntería, yerren tan locamente disparando a los videojuegos.

Claramente es un problema de educación, pero que alguien muera de un tiro, antes que nada es un problema de armas y solo de armas... ¿que después quieren revisar otras historias?. Vale... pero lo primero es lo primero, y es tan evidente que resulta un insulto tratar de culpar a ninguna otra cosa.

..en realidad, con las estúpida postura de tantos 'usasenses' respecto de las muertes y las armas, están reconociendo el derecho de Corea del Norte y a cualquier otro país, bananero a tener armas nucleares... ya que reclaman exactamente lo mismo que ellos alegan: "es para defendernos..." ...y qué curioso, que jamás ninguno diga: "es para atacar, para matar".

Espinosa cuestión...

Un ladrón es por robar, se demuestre o no, aunque claro legalmente solo demostrado el caso, el palabro deja de ser un insulto, para ser una verrdad.

Cuando se le dice a alguien Hij0 de put@, no lo refiere en una forma genética, si no como un insulto... se lo merece o no?.

Ciertamente un político del que se haya demostrado ser un ladrón, el calificativo de hij0 de put@ (al menos para mi), es inapelable... lo es.

Hay cosas que a veces te dejan asombrado...  

Yo diría que eso es "meter al lobo en casa".
Una cosa es no poner impedimentos para que los linuxeros puedan instalar Linux en el mismo disco sin machacar (por ejemplo el GRUB) una instalación existente o secuestrar el arranque... y otra dar facilidades para Linux dentro de windows... en todo caso al revés sería lo razonable (empresarialmente hablando), facilitar que los que operen con Linux pudieran virtualizar windows dentro...

De entrada se va a aganar un poquito el corazón de los linuxeros, pero al tiempo imagino, que lo que va a suceder es que la cuota de Linux aumentará y finalmente esos usuarios se distanciarán de windows...

...pero bueno, ellos habrán calculado y asumido los riesgos... aunque sigo pensando que una empresa lo que debe hacer es limitarse a no entorpecer a la competencia...

Ya veo un titular dentro de 10-12 años: "Windowx 30 se fusiona con Linux 30", vamos lo mismo que está pasando con Firefox siguiendo la estela de Chrome.  

La función 'por defecto', para hacer una captura de pantalla es "volumen abajo+power", pero es tan complicado el mecanismo que es muy difícil, lograrlo a la primera... desde luego no es lo más óptimo que s epuede hacer.

En el mío me toca perder 1 minuto intentándolo hasta que se consigue, creo que el detalle debe residir entre el teimpo entre pulsar uno y otro botón, que en teoría deben ser simultáneos, esa simultaneidad es imposible y quizás deba pasar menos de cierto tiempo, o mayor de cierto tiempo, o una antes que otra cierto tiempo... y lo peor es que ese comportamiento puede variar de móvil a móvil...

Otra cosa es grabar vídeo de la pantalla... para lo que sin duda hay que requerir de alguna app.

ERROR... CODE: AB-SURDO 27465890-TRUMP

grabar con impuestos algo, no deja que ese algo deje de suceder, la consecuencia que tiene un gravamen, es que se recauda dinero, pero del problema... nada se sabe.

Yo (y cualquier persona que se tenga por inteligente), no ve ninguna consecuencia directa.

jajaja... yo lo que quiero mandar al Sol, es a todos los políticos del planeta (+ algún extra)... pero tranquilos que los mandaría de noche...