Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - pucheto

#71
No es un algoritmo de ordenamiento...
Es un algoritmo para insertar ordenado en un vector.

*Busca la posicion donde va a meter a 'VALIN' (justo detras del primer elemento mayor q VALIN, los anteriores son menores q VALIN).
*Agranda el vector en 1.
*Corre todos los elementos mayores que VALIN 1 posicion hacia adelante.
*Inserta VALIN en la posicion que le corresponde.
#72
estuve pensando un poco y el algoritmo que nombre tiene problemas en las esquinas... donde se junten mas de 2 provincias.

Aplicaria la primer idea y despues lo que haria seria escanear la imagen de manera secuencial, analizando un cachito de n*n pixels ( el n lo elijo de forma que un punto donde se junten varios limites entre adentro con un poco de su contorno para distinguir las provincias ).
#73
Se me ocurre una idea pero la tendria q programar para ver que tal anda...

*Conocer que pixels pertenecen a cada provincia es facil, se hace haciendo un BFS sobre la imagen y voy numerando cada provincia.

*Despues elegiria una cantidad de puntos al azar distintos para cada provincia... ( mientras mas mejor ).

*Y veria si trazando una recta  desde los puntos de una provincia, llamemosla P1, hacia todos los puntos de otra provincia P2.

*2 provincias son adyacentes si existe una linea negra en una recta que separe puntos de P1 con puntos de P2, sino es asi, existe alguna provincia entre medio de estas, por la recta que estoy tomando.

Igual no es un metodo exacto, habria q probarlo a ver si es bueno o no.
#74
Programación C/C++ / Re: Orientacion c/c++
22 Mayo 2011, 00:04 AM
Cita de: ShotgunLogic en 21 Mayo 2011, 22:21 PM
Estaba hablando de Java y C++. De hecho me he confundido, y es que estaba mirando un libro porque no me acordaba de la palabra interpretado, y he leido C# como C++. Ya me parecia a mi muy raro que C++ fuese interpretado...Fallo mio sorryxDDD
Ninguno de los q nombraste ahi es interpretado...  Compilan a bytecode y una maquina virtual ejecuta el bytecode.
#75
Ta, estabamos pensando distinto el problema... Yo suponia que el tipo 'personaHospital' venia ya de arriba, pq lo crea una funcion o algo asi... mi funcion con la version que yo proponia era tomar directamente el struct personaHospital, y no un puntero para despues convertirlo.

Mi idea era hacerlo algo similar a herencia.
#76
Cita de: xD4RIOx en 19 Mayo 2011, 21:25 PM
El cast directamtnte es mejor.

No fue lo que expuse. La diferencia, aclaro, es que necesitas una variable local para usar la union.
Este sería el otro caso. Si no usas una variable local, pasas las uniones desde que las creas... probablemente desde el main. Entonces, si una función o grupo de funciones trabajan con "struct paciente", necesitas una funcion intermediaria (un dispatcher), que les pase el puntero. Eso significa una funcion para adaptar a cada flujo que use solo una estructura, cosa que no pasaría si las estructuras fueran siempre diferentes. Solo los flujos que aceptan ambos tipos necesitan el dispatcher.

Saludos
Del 1er punto sigo sin ver que variable local uso...
Del punto 2, si una funcion trabaja con un paciente solamente, le paso el puntero al paciente, no toda el struct con el flag... el struct con el flag solamente lo uso cuando tenga q manejar de manera generica a medicos y pacientes por igual, y tal vez aplicarle alguna funcion generica que necesite tratarlos de maneras distintas. Depende mucho del contexto de uso todo esto.
#77
Cita de: xD4RIOx en 19 Mayo 2011, 18:23 PM
1 - Necesitas una variable extra en la pila local de la función... solo a fin de alojar el puntero que te llega por parámetro, y para enviarlo a otra función. Es innecesario.
Una cosa que no veo aca, hagas como hagas, si o si vas a tener que pasarle el puntero a la otra funci\'on. No veo donde esta el problema. En tu codigo tambien tenes que pasar el puntero a una funcion.

Cita de: xD4RIOx en 19 Mayo 2011, 18:23 PM
2 - Si declaras desde el main los datos como instancias de la union para evitar las variables locales innecesarias, pierdes la posibilidad de tener flujos donde se manejen solo pacientes, o solo médicos (en el ejemplo), sin pasar previamente por un dispatcher. Si los dispatchers son siempre necesarios, es porque tienes dos flujos separados. Seguramente perderás más de dos bytes haciendo dispatchers para cada flujo, y es la diferencia entre crear una instancia de cada tipo, y una union.

Si se desea castear un puntero, entonces se usa un cast, solo por mantener el código simple.

Saludos
Tampoco veo pq se pierde la posibilidad de tener secciones donde solo se manejan solo medicos o solo pacientes.

Si podes pone un ejemplo donde se vea mejor.
#78
Cita de: xD4RIOx en 19 Mayo 2011, 16:24 PM
Obviamente, debes conocer las diferencias de tamaños para decidir si una union es buena idea o no, y saber si realmente necesitas ese almacenamiento. En ESTA situación, cualquier uso de uniones es DISPARATADO  ;D
Estoy usando una union de punteros, no de structs... todos los punteros ocupan lo mismo, no hay ningun desperdicio de espacio (al menos q sean near, far etc, pero eso ya depende mucho del sistema y es raro encontrarlo en la programacion en modo usuario).

Cita de: xD4RIOx en 19 Mayo 2011, 16:24 PM
¿Porqué?
Porque cuando aún no sabes si es un médico o un paciente, usas el flag para tratarlo. Entonces ¿realmente necesitas almacenar las estructuras en un espacio de memoria común?
Sin importar el tipo, puedes tener dos funciónes diferentes, con lo que la función que hace de dispatcher, no tiene que hacer más que pasar el puntero a quien le corresponda... que me parece mucho más razonable  ;), y si quieres probar si es NULL, lo haces al principio, cosa que te quedaría como....
Guardo el flag, con la union de punteros pq estan asociados, estan muy relacionados... Como estan tan relacionados, los pongo en el mismo struct...
#79
Para indicar q puntero tenes q usar... y distinguir si es paciente o medico...
#80

union {
    medicos* m;
    pacientes* p;
}p_e;

struct persona {
    p_e data;
    tipo_persona flag;
} personaHospital;


pseudocodigo...


personaHospital p = /*... hago lo q tengo q hacer, inicializo y demas*/

switch(p.flag){
    case f_medico:
         //lo manejo como medico
        handleMedico(m.data.m);
        break;
    case f_paciente:
         //lo manejo como paciente
        handlePaciente(m.data.p);
        break;
}


me falto definir el enum tipo_persona, pero se entiende masomenos... No esperes q compile, es pseudocodigo puesto asi nomas para ejemplificar.