Cita:
Iniciado por aguml ¿eso vale para C también o es solo a partir de alguna revisión de c++?
C no es orientado a objetos. Las estructuras son simplemente paquetes de datos sin ningún tipo de lógica de funciones por medio.
Cita:
Iniciado por aguml Otra cosa que no se que hace es esto:
¿que hace exactamente?
Es equivalente a
Como te comenté, interesa estar al tanto de las novedades que traen los nuevos estándares. Esta en concreto aparece por primera vez en C++11.
Cita:
Iniciado por aguml Otra cosa ¿el código que puso eferion hacia:
fila (fila)
Y me dices que eso equivaldría a inicializar la variable asi:
fila=fila
Donde la primera seria una variable miembro de la estructura y la segunda seria un parámetro pero en ambos casos se llama igual la variable y tenia entendido que eso no estaba permitido ¿podéis explicarme eso también?
Código C++:
Ver originalPOO::POO(int valor)
: valor(valor)
{ }
En el ejemplo anterior, el primer
valor se ha de referir
sí o sí a un miembro de
POO ya que estás inicializando la clase (así es como funciona este apartado del constructor. En el segundo
valor sí que tendríamos un solapamiento (la variable pasada como parámetro y la variable miembro). En este caso la ambigüedad desaparece porque no estamos usando
this->valor, que sería el código que tendríamos que poner para usar la variable miembro. Como no se pone lo anterior el compilador entiende que estamos haciendo uso de la variable pasada como argumento.
¿Por qué? La regla que sigue el compilador en caso de solapamiento de variables es elegir aquella que tiene un menor ámbito. En el caso que nos ocupa, la variable miembro vive mientras exista el objeto mientras que el argumento únicamente vive dentro del constructor. El ámbito de la variable miembro puede que no esté definido claramente, pero desde luego es mucho mayor que el del argumento, luego en caso de conflicto el compilador va a elegir el argumento.
Lo que el compilador no tolera es que dos variables con el mismo ámbito se llamen igual. Dicho con un ejemplo:
Código C++:
Ver originalint main()
{
// Todas las versiones de 'a' son válidas
int a = 0;
std::cout << a; // 0
{
int a = 1;
std::cout << a; // 1
{
int a = 2;
std::cout << a; // 2
}
std::cout << a; // 1; a=2 ya no existe
}
std::cout << a; // 0; a=1 ya no existe
int b;
int b; // Esta línea da error, ya hay una variable llamada 'b' con el mismo ámbito.
}
Cita:
Iniciado por aguml Otra duda que tengo del código de eferion es si siempre daría la misma solución o cambiaría en cada ejecución.
El algoritmo se para con la primera solución que encuentra y ésta siempre va a ser la misma.
Cita:
Iniciado por aguml Si siempre da la misma me interesaría hacer que ese código me diera todas las soluciones correctas.
Eso ya requiere algo más de trabajo dentro del algoritmo. Intenta adaptar el código para que cumpla esa nueva tarea.
Yo empezaría por cambiar el retorno de la función, debería devolver una lista de rutas en vez de una única ruta.
Un saludo.