Errores, fallos, preguntas - página 1358
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
Personalmente, esto es un problema constante para mí, tengo que estar siempre pendiente, o especificar A.operator=(B), A.operator!=(B) en todas partes, es decir, se pierde concisión y la sobrecarga de operadores en realidad no tiene sentido.
Ya planteé este problema una vez, pero el tema se estancó. Terminemos de una vez este asunto.
¿Para qué es eso? Está al revés.
Tiene más sentido al revés: < y > deberían llevar a la comparación de punteros.
Esto ya se discutió en su día (por favor, relee ese viejo hilo). En mis mensajes asumí que lo recordabas si sugerías: "terminemos esta pregunta".
Permítanme repetirlo: se sacrifican dos operadores (== y !=) para preservar las capacidades de todos(!) los demás (no sólo < y >). La belleza en detrimento de la funcionalidad.
para no tener que especificar explícitamente A.operator!=(B)
Bueno, eso se solucionará pronto, espero, ya que los desarrolladores por fin me han escuchado. Entonces será sencillo: *A != *B
Esto ya se discutió en su momento (por favor, relea ese viejo hilo) - repito - se sacrifican dos operadores (== y !=) para preservar las capacidades de todos(!) los demás (no sólo < y >)
Estoy de acuerdo en que todos estos operadores deberían tener el mismo estatus. Pero no de la forma que sugieres. Si ambos argumentos son punteros, son los punteros los que deben ser comparados entre sí. De lo contrario sería ilógico: ambos argumentos son dados explícitamente por GetPointer, pero de alguna manera se ejecutan los operadores de clase. Así que, en mi opinión, los signos de desigualdad se aplicarían más correctamente a los punteros en este caso.
Sin embargo, nadie va a cambiar el comportamiento de los operadores de todos modos, obviamente. De lo contrario, habrá un alboroto general por los programas que no funcionan.
Una vez más, te olvidas del operador de asignación. ¿Sugieres que lo implementemos también a través de una función? ¿No sería demasiado pesado?
Hola a todos,
Una pregunta así, me inscribí en una señal que es bastante fiable, luego de la nada se empezó a operar con lotes locos, todo habría estado bien al principio ya que había un beneficio que al final resultó ser una pérdida de dinero. ¿Puede decirme dónde está enterrado el perro (por culpa de quién?) y quién puede ayudar a solucionarlo?
Hola a todos,
Tal pregunta, se inscribió en una señal que es bastante fiable, aquí de la nada comenzó a operar lotes locos, todo habría estado bien en el principio, ya que había un beneficio que resultó ser una pérdida de dinero en el final. ¿Puede decirme dónde está enterrado el perro (por culpa de quién?) y quién puede ayudar a solucionarlo?
Una señal que es bastante fiable, aquí de la nada comenzó a operar lotes locos
+100500
¿Pueden decirme dónde está enterrado el perro (de quién es la culpa?) y quién puede ayudar a solucionarlo?
Te diremos dónde está enterrado el perro: detrás de los garajes, pero de quién es la culpa - deberías ir a la rama de telépatas, está en algún lugar de este foro, búscalo en Google.
sí la cosa es que las órdenes presentadas en la web en mi sección de señales y lo que la plataforma en mi teléfono pronunció no coinciden.
no se trata de la señal, la señal es fiable, se trata de la transmisión, ¿cuál podría ser la razón?
y qué puedo hacer para proporcionar el material si no lo entiendo en absoluto desde el punto de vista técnico
Y de nuevo, sigues olvidando el operador de asignación. ¿Te ofreces a implementarlo también a través de una función? ¿No sería demasiado pesado?
En el caso de operator=(...) no hay una solución más fácil que utilizar directamente a.operator=( b )
Si hacen que *A = *B - ¡bien!