Errores, fallos, preguntas - página 3122

 
Vitaly Muzichenko #:

y si alguien más tiene un programa con objetos gráficos, su tipo de prefijo "l" < donde es la eliminación por prefijo "l" (los nombres "etiqueta" y "línea" se utilizaron cuando los objetos fueron creados >

Matará todos los objetos que empiecen por"l" en un programa de terceros. Esta no es una buena solución.

Vitaly, ¿por qué no entras en el hilo de los principiantes? Estos fundamentos más o menos el programador sabe desde hace mucho tiempo. Y sólo las "estrellas" no lo saben todas...

 
Alexey Viktorov #:

Vitaly, ¿por qué no entras en el hilo de los principiantes? Estos fundamentos son conocidos por los programadores más o menos desde hace mucho tiempo. Y sólo las "estrellas" no lo saben todas...

¡Genial!

Sí, probablemente iré :)

 
Vitaly Muzichenko #:

y si alguien más tiene un programa con objetos gráficos, su tipo prefijo "l" < donde es la eliminación por prefijo "l" (los nombres "etiqueta" y "línea" se utilizaron cuando los objetos fueron creados >

Matará todos los objetos que empiecen por"l" en un programa de terceros. Esta no es una buena solución.

Eso es lo que yo también estaba pensando. Existe la posibilidad de que otro programador pegue nombres de objetos idénticos o con el mismo prefijo, por lo que eliminar objetos por el prefijo (especialmente el corto) es más peligroso que toparse y eliminar un objeto con un nombre completamente coincidente. También debemos tener en cuenta que un segundo programa no podrá crear un segundo objeto con un nombre ya existente, el objeto anterior debe permanecer (en mi opinión). En cualquier caso, un programa vecino que decida borrar un objeto de este tipo, asumiendo que es su objeto, borrará el objeto de otro con el mismo nombre.

Hasta ahora veo la única solución: nombrar los objetos dentro del mismo programa de la forma más exclusiva posible, para reducir la probabilidad de tropezar con un objeto ajeno con el mismo nombre y hacer manipulaciones no deseadas sobre él. Pero permítame recordarle que alargar el prefijo no siempre es técnicamente posible, porque la longitud del nombre del objeto es limitada.

 
x572intraday #:

Esto es algo en lo que yo también he pensado. Existe la posibilidad de que otro programador haga nombres de objetos idénticos o con el mismo prefijo, por lo que borrar objetos por el prefijo (especialmente uno corto) es más peligroso que toparse con un objeto totalmente coincidente con el nombre y borrarlo. También debemos tener en cuenta que un segundo programa no podrá crear un segundo objeto con un nombre existente, el objeto anterior debe permanecer (en mi opinión). En cualquier caso, un segundo programa que decida borrar dicho objeto, suponiendo que es su objeto, borrará el objeto de otro con el mismo nombre.

Hasta ahora veo la única solución: nombrar los objetos dentro del mismo programa de la forma más exclusiva posible, para reducir la probabilidad de tropezar con un objeto ajeno con el mismo nombre y hacer manipulaciones no deseadas sobre él. Pero permítame recordarle que alargar el prefijo no siempre es técnicamente posible, porque la longitud del nombre del objeto es limitada.

No hace falta que se lo recuerde, yo trabajo con objetos gráficos todos los días.

La lógica incorrecta es la clave para... ¿qué? Bien, la clave del fracaso. Ese es su caso.

 
Vitaly Muzichenko #:

No necesito que me lo recuerden, trabajo con objetos gráficos todos los días.

La lógica incorrecta es la clave para... ¿qué? Bien, la clave del fracaso. Ese es su caso.

¿Y qué es el fracaso?

Y le recuerdo, en general, no a usted (no estamos en correspondencia privada), sino al público que nos lee, entre el que probablemente haya aficionados.
 
x572intraday #:

¿Y cuál es el fracaso?

Ya lo he descrito, pero la elección es tuya.

Entiendo que se esfuerza mucho en la redacción, por lo que para usted este programa es valioso y correcto. Pero tiene defectos, incluso críticos, que le cuesta aceptar.

Eso es todo, resuélvelo por tu cuenta, yo he descrito mi valoración.

 
Vitaly Muzichenko #:

Ya lo he descrito, pero la elección es tuya.

Te he disuadido ampliamente, admitiendo que tienes razón sólo en un par de puntos menores no críticos. Pero si no te impresiona y te disuade, lo entiendo: es difícil aceptar los contraargumentos directamente del autor del código.

 

Hablando de buscar código libre.

Intente adivinar qué porcentaje de programadores busca programas para ayudar a su comercio rentable o para aprender el código. Personalmente, creo que la preponderancia será a favor de los primeros, porque son muchos menos los que se ven como programadores en este campo.

 
x572intraday #:

Hablando de buscar código libre.

Intente adivinar qué porcentaje de programadores busca programas para ayudar a su comercio rentable o para aprender el código. Personalmente, creo que la preponderancia está más a favor de la primera, ya que muchos menos de los que la buscan se ven como programadores en este campo.

La cuestión es que ese código no puede utilizarse en una máquina personal, pero usted nunca lo ha reconocido. Un programador ciertamente no lo pondrá, habiendo visto lo que hay dentro del código.

También empezaron a discutir sobre el prefijo, pero yo no he venido a discutir.

Buena suerte.

 
Vitaly Muzichenko #:

Esa es la cuestión: no se puede utilizar ese código en una máquina personal, pero nunca se ha reconocido.

Por supuesto que no. Porque para que esos defectos empiecen a ralentizar la máquina, hay que utilizarlos en cálculos muy cargados, por ejemplo, en bucles muy, muy gordos o reinicializaciones muy frecuentes. No recomiendo adoptar este código para estos casos. Pero en el presente caso todo vuela; la declaración ruidosa y contradictoria sobre el fracaso no es más que una humillación. Pero gracias por eso.

Y siempre estoy abierto a mejorar mi código a medida que me voy ilustrando.

Razón de la queja: