Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Puede alguien explicar cómo esta inicialización de los campos es mejor que esto:
es mejor que esto:
¿Y qué sentido tiene?
Los campos const pueden ser inicializados.
Puede alguien explicar cómo esta inicialización de los campos es mejor que esto:
es mejor que esto:
¿Y qué sentido tiene?
la cuestión es puramente teórica:
han visto, posiblemente en SB, una llamada al constructor como esta:
en qué se diferenciaría este código:
Lo he descomprimido, no veo ninguna diferencia, entonces sé un poco más específico - ¿qué o por qué podemos usar una llamada forzada al constructor para los objetos a1 y a2?
¿cuál es la "conveniencia" de la primera opción?
La primera opción se llama - Inicialización del valor, la segunda - Inicialización por defecto. Hay sutilezas y diferencias según el tipo de objeto (si es un agregado o con constructor por defecto, ...). Por ejemplo, el resultado aquí será absolutamente diferente si se utilizan paréntesis y sin ellos:
Si quieres entender la teoría hasta las orejas, entra aquí https://en.cppreference.com/w/cpp/language/initialization
ZS: no todo es relevante para el mcl, sino para entender el modelo de referencia.
Si quieres ponerte hasta las orejas de la teoría, entra aquí https://en.cppreference.com/w/cpp/language/initialization
Todavía no es necesario, pero lo guardaré para saber dónde leer la fuente.
Gracias a todos.
En los pluses, la segunda opción se considera una mala forma.
Habrá el mismo problema que encontré - duplicación de código para la inicialización de los campos, cuando sea necesario escribir más de un constructor en la clase
si usas la variante 2, puedes poner el código duplicado en un método separado y llamar a este método después de las acciones necesarias en cada constructor (tengo la inicialización de la clase por la estructura y la variante 2 por el nombre del archivo donde se escriben los datos de esta estructura (backup save))
Escribir ese código repetitivo es malo... no es interesante, pero el problema es que si añado un nuevo campo a la clase, tengo que recordar inicializar este campo tantas veces como constructores - el hecho, que no es conveniente, pero el hecho, que usted puede olvidarse de hacerlo N-veces, es un problema, imho
Todavía no es necesario, pero lo guardaré, ya sabré dónde leer la fuente original.
Gracias a todos.
Habrá el mismo problema que encontré - duplicación de código para la inicialización de los campos, cuando sea necesario escribir más de un constructor en la clase
si usas la variante 2, puedes poner el código duplicado en un método separado y llamar a este método después de las acciones necesarias en cada constructor (tengo la inicialización de la clase por la estructura y la variante 2 por el nombre del archivo donde se escriben los datos de esta estructura (backup save))
Escribir ese código repetitivo es malo... no es interesante, pero el problema es que si añado un nuevo campo a la clase, tengo que recordar inicializar este campo tantas veces como constructores - el hecho, que no es conveniente, pero el hecho, que usted puede olvidarse de hacerlo N-veces, es un problema, imho
Una macro que también puede ser paramétrica. El olvido (yo mismo lo sufro), también se trata con este))))
habrá el mismo problema que yo encontré - duplicación de código de inicialización de campos cuando hay necesidad de escribir más de un constructor en la clase
Si utiliza la variante 2, puede poner el código duplicado en un método separado y llamar a este método después de todas las acciones necesarias en cada constructor (tengo la inicialización de la clase por la estructura y la variante 2 por el nombre de un archivo donde se escriben los datos de esta estructura (copia de seguridad))
Escribir ese código repetitivo es malo... No es interesante, pero el problema es que si añado un nuevo campo a la clase, tendré que acordarme de inicializar este campo tantas veces como constructores haya - el hecho de que no sea conveniente, pero el hecho de que puedas olvidarte de hacerlo N veces, es un problema, imho
Vamos, que todo tiene solución:
No estoy en contra de los constructores por defecto (o de la inicialización por defecto), pero si tu constructor deja el objeto (bueno, si no es un agregado tonto) en un estado indefinido y luego lo inicializas mediante unas muletillas, entonces lo estás haciendo mal.
ZS: por cierto, se puede delegar el constructor en los pros, faltando por supuesto
Vamos, que tiene solución:
un poco por delante de mí, acaba de sentarse en el PC.
El consejo de @Vladimir Simakov de inicializar los campos de la clase usando una macro, para no olvidarse de inicializar correctamente, bueno, sí - buen truco, pero el código se leerá como una llamada a un método que inicializa los campos, difícil de asumir que este es un buen tono...
Tu ejemplo tampoco es el más refinado, pero resuelve el problema exactamente como lo hice yo ahora: un método de inicialización separado \N -.
imho, es una cuestión de propósito - la forma correcta de escribir una clase base con todos los campos necesarios, heredar de ella, hacer el constructor protegido e inicializar la clase base de los herederos y por lo tanto será la protección de "olvidar" - no hay constructor por defecto, ¿verdad? - al menos puedes mirar en mikrosoft si buscas en google "constructor protegido" - habrá un artículo
Mi problema es un poco diferente, dejé a propósito la herencia, para guardar el estado de los campos de la clase en un archivo, tengo 2 campos de 2 clases, y su estado también se guarda en el mismo archivo llamando a los métodos correspondientes. Intenté guardarlo todo cuando heredé de una clase base, se me hizo muy lioso, lo reescribí sin herencia, todo se volvió "transparente" ahora.
Un poco por delante de mí, acaba de sentarse en el PC.
El consejo de @Vladimir Simakov de inicializar los campos de la clase usando una macro, para no olvidarse de inicializar correctamente, bueno, sí, es un buen truco, pero el código se leerá como si llamara a un método que inicializa los campos, difícil de asumir que es un buen tono...
Tu ejemplo tampoco es el más refinado, pero resuelve el problema exactamente como lo hice yo ahora: un método de inicialización separado \N -.
imho, es una cuestión de propósito - la forma correcta de escribir una clase base con todos los campos necesarios, heredar de ella, hacer el constructor protegido e inicializar la clase base de los herederos y por lo tanto será la protección de "olvidar" - no hay constructor por defecto, ¿verdad? - al menos puedes mirar en mikrosoft si buscas en google "constructor protegido" - habrá un artículo
Mi problema es un poco diferente, dejé a propósito la herencia, para guardar el estado de los campos de la clase en un archivo, tengo 2 campos de 2 clases y su estado también se guarda en el mismo archivo llamando a los métodos correspondientes. Intenté guardar todo cuando lo heredé de una clase base, se complicó mucho; lo rees cribí sin herencia, todo se volvió "transparente" ahora.
¿Qué tiene de confuso?
¿Qué tiene de confuso?
eso es exactamente lo que yo me alejé, y al principio lo hice
con este enfoque - heredar de una clase base, "donde está todo" - todo funciona, pero hasta que queremos intentar hacer varios campos de clase, y entonces queremos añadir varios campos en cada clase de campo y clavarlo todo con una matriz dinámica de clases
y entonces obtendremos que no podemos implementar el método Save(int hndl) propiamente dicho en una clase base - este método será en realidad una interfaz, que, como se ha comentado anteriormente, no será necesaria en absoluto - se puede escribir sin interfaces
Suelo maximizar mis esfuerzos en la flexibilidad del código - un mínimo de alboroto - el resultado es un nuevo problema resuelto, que mi terminología sea perdonada)))
el problema será que, al implementar el guardado en un archivo, es necesario elaborar el encabezado del archivo, que debe describir la cantidad total de los diferentes tipos de entradas y luego es necesario no perder la lógica / el orden de guardado de los datos, para poder leer todo correctamente.... y el final será si cambias aunque sea un campo de una clase
En mi opinión, la laboriosidad de una herencia tan "fácil" a partir de una clase base - se reduce al desarrollo y mantenimiento de una pequeña base de datos, a la supervisión constante de los cambios en cualquier clase