Ver Mensaje Individual
  #18 (permalink)  
Antiguo 15/01/2016, 05:10
eferion
 
Fecha de Ingreso: octubre-2014
Ubicación: Madrid
Mensajes: 1.212
Antigüedad: 9 años, 7 meses
Puntos: 204
Respuesta: Necesito orientacion con el siguiente codigo

Cita:
Iniciado por aguml Ver Mensaje
¿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 Ver Mensaje
Otra cosa que no se que hace es esto:
Código C++:
Ver original
  1. using Ruta = std::vector<Posicion>;
¿que hace exactamente?
Es equivalente a

Código C++:
Ver original
  1. typedef std::vector<Posicion> Ruta;

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 Ver Mensaje
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 original
  1. POO::POO(int valor)
  2.   : valor(valor)
  3. { }

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 original
  1. int main()
  2. {
  3.   // Todas las versiones de 'a' son válidas
  4.   int a = 0;
  5.   std::cout << a; // 0
  6.   {
  7.     int a = 1;
  8.     std::cout << a; // 1
  9.     {
  10.       int a = 2;
  11.       std::cout << a; // 2
  12.     }
  13.     std::cout << a; // 1; a=2 ya no existe
  14.   }
  15.   std::cout << a; // 0; a=1 ya no existe
  16.  
  17.   int b;
  18.   int b; // Esta línea da error, ya hay una variable llamada 'b' con el mismo ámbito.
  19. }

Cita:
Iniciado por aguml Ver Mensaje
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 Ver Mensaje
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.
__________________
La ayuda se paga con esfuerzo o con dinero. Si no estás dispuesto a esforzarte y quieres que te hagan los deberes pide presupuesto, al menos así ahorrarás tiempo.