Para gamberrear con la PSP, necesitas el firmware 1.0 o (idealmente) el 1.5. Ya se están haciendo cosas bajo 2.0, pero no parece que la cosa vaya a prosperar mucho más que eso.

La comunidad de desarrolladores homebrew de PSP parece andar mayormente por http://forums.ps2dev.org/index.php?c=5

[", si 'a' no tiene el operator[] sobrecargado, está definido por el lenguaje como "*( a + b )", lo que establece la relación entre aritmética de punteros e indexación de arrays. Un curioso efecto secundario es que]

 Algunas notas sobre lo que se ha dicho en el thread:

sizeof(char) == 1 por definicion del lenguaje, no hay que "asumirlo" porque es tan cierto como que 1+1 = 1.9999f. ;)

El almacenamiento de datos en la memoria es decisión del compilador. SIN EMBARGO, lo que el compilador debe garantizar es que la aritmética de punteros es consistente. "a", si 'a' no tiene el operator[] sobrecargado, está definido por el lenguaje como "*( a + b )", lo que establece la relación entre aritmética de punteros e indexación de arrays. Un curioso efecto secundario es que

Código [Seleccionar] Expand

char a = 3["abcdefg"];
compila perfectamente (¡probadlo!), y asigna el carácter 'd' a la variable a. Por cierto, que esto es de C, y C++ no lo altera.

Este tipo de peculiaridades es importante, porque EXISTEN arquitecturas de lo más raro, sobre las que se han implementado compiladores de C y C++. En esas arquitecturas, la implementación de los punteros puede incluir estructuras de datos internas complejas, con selectores, modificadores, descriptores y dios sabe qué mas. Es un dolor de cabeza para los programadores del compilador, pero ahi están. El C y el C++ son lenguajes muy cercanos a un concepto concreto de arquitectura, pero si otro sistema diferente quiere tener su compilador de C/C++, tiene que garantizar la sintaxis y semántica definida por el lenguaje, o establecer sus propias extensiones.

En cualquier caso, lo que es absurdo es manejar este tipo de discusiones como si estuvieran sujetas a opinion. La Referencia del lenguaje C++ existe y es quien dice lo que es cierto y lo que no - nuestra opinión al respecto es irrelevante. La referencia anotada original de Stroustrup (no he leido las ultimas ediciones) incluía notas sobre cómo los compiladores puede implementar determinados aspectos, con la intención de aclarar posibles ambiguedades; no se tiene por qué implementar así, pero la implementación debe respetar esos resultados.

 El que quiera seguir discutiendo sobre C++, propongo que lo haga aqui:

http://www.stratos-ad.com/forums/index.php...t=ST&f=8&t=5819

 Y dejar a los pobres de General en paz.

 Citando la referencia de C++:

"C++ supports three kinds of object types:
Fundamental types are built into the language (such as int, float, or double). Instances of these fundamental types are often called "variables."
Derived types are new types derived from built-in types.
Class types are new types created by combining existing types. These are discussed in Classes, Structures, and Unions."

me imagino que sera por el '<!--POST BOX-->', lo pone este foro cuando se encuentra con un barra 0, en mi post original explicaba que debia de ser sustituido por el barra 0, me gusta poner mas barra 0 ya que asi si por algun casual el codigo es compilado en una plataforma que no usa null o cero para indicar el final de un string funcione sin tener que adaptar el codigo, si es por el memcpy, es necesario ya que no se puede modificar una cadena declarada de esta forma: char *psz = "Hola mundo", este es uno de los motivos por el que me gusta que una funcion nunca modifique el buffer de entrada que se la pasa

Si, ya se que el barra cero no le sienta bien al foro. ;-)

Las cadenas de C y C++ por definicion van terminadas con un barra cero, y si la plataforma por casualidad no usa un cero binario para eso, el compilador se lo tiene que currar para que *p = 0 meta un terminador. Lo mismo con el puntero NULL.

El memcpy() es bueno usarlo para copiar bloques de memoria, aunque para tratamiento de cadenas en general el strncpy() resulta más claro. Pero la declaracion podria haber sido

Código [Seleccionar] Expand

char asz[] = "Hola Mundo";
que es C++ perfectamente legal, y no te obliga a contar cuantos caracteres tiene la cadena que quieres asignar.

El suspenso es porque reservas 10 caracteres y luego asignas en la posición número 11. :) Durante una hipotética entrevista también podría preguntar cual es el bug implícito en escribir "printf(psz);", pero de verdad que, aparte de ilustrar los diferentes niveles de conocimiento que se le pueden exigir a un programador en una entrevista,  coincido en que el thread ya se ha ido de madre y que quien quiera continuar, lo haga en programación. :)

Código [Seleccionar] Expand


char *psz = new char[10];
memcpy( psz, "Hola mundo", 10 );
psz[10] = 0; // he cambiado lo de '<!--POST BOX-->';


Eso es un suspenso. ;-)

Pero la metodologia no se puede aprender, se tiene o no se tiene, desde pequeño se desarrolla.

Como mucho te pueden enseñar soluciones a problemas ya resueltos y entonces hacer copy/paste.

Pero la unica diferencia entre los buenos programadores y los normales, es el encontrar soluciones y optimizaciones a problemas nuevos.

No puedo estar más en desacuerdo con cada una de esas tres frases.

 

esta claro que si no sabes c++ se aprende y no creo que lleve mas de un par de semanas

En mi opinion, si no has trabajado de continuo en C++ al menos un año, es probable que no sepas C++, y solamente sepas "hacer cosas" en C++. Pero bueno, es cosa de criterios, yo me considero alguien que solamente sabe "hacer cosas" en PHP pero mi weblog, galería de fotos, guestbook y tal los he escrito yo enteros. :)

 

el problema que tienen es que muchas personas no sabrian responderte ya que son preguntas muy abstractas

Precisamente por eso no son preguntas que hago directamente en una entrevista. Bueno, sí puedo hacerlas para conocer lo que el candidato piensa sobre el tema, pero me interesa más sacar mis propias conclusiones a partir del test (y toda la entrevista), y contrastar ambos. El test se hace cara a cara y con constante diálogo; ese flujo de información ocurre durante toda la entrevista. Si planteo ese tipo de preguntas abstractas y el candidato no sabe muy bien cómo contestar, pues eso significa algo... o bien puede dar una respuesta correcta, pero no completa, o una respuesta completa pero que no comparto, o... etc. No se trata de que la pregunta sea imposible de contestar, sino que la FORMA de abordarla y contestarla (y también el contenido de la respuesta) me pueden decir mucho sobre cómo piensa y trabaja esa persona.

Por ejemplo, si te pregunto qué son las funciones virtuales: la pregunta te puede parecer una chorrada porque o bien te resulta muy fácil contestar, o bien no lo sabes pero es irrelevante ya que aprender lo que són no te costaría mucho. Sin embargo, eso me da una idea sobre el tipo de desarrollos en C++ que has hecho. Si me das una respuesta de libro, te puedo empezar a preguntar sutilezas sobre eficiencia, implementaciones típicas de los compiladores, interacción con otros aspectos de las clases, posibles problemas derivados de su uso, etc. hasta averiguar tanto como pueda sobre la amplitud de tu experiencia con ellas. Antes o después, sacaré conclusiones sobre tu experiencia y tu filosofía de programación.

Pues eso con funciones virtuales, o con herencia, o con patrones de diseño, o con el static, o con los templates, o con las macros, o con excepciones, o con typecasts... Hay 10mil temas que usar.

Si vas fino con la teoría, pasaré rápidamente a la parte práctica. Si los problemas los cazas rápido, los retorceré para saber si ya los conocías, y cómo de rápido te adaptas a un problema nuevo. Si me das respuestas simples y directas, te haré preguntas ambiguas o confusas. Si tienes problemas con el enunciado de las preguntas, las separaré en partes más concretas y precisas. Si no te mojas en una opinión te daré una propuesta que es errónea a ver si despiertas. Si estás nervioso, intentaré relajarte contando alguna "anécdota del abuelo", pero si estás tranquilo te pondré presión a ver si es todo fachada.

Una situación real que le ocurrió a un amigo en una entrevista: nada más empezar, le dicen "Queremos contratar a 16 personas, ya tenemos a gente suficiente para cubrir esos puestos, y por tu CV, tu no estás entre ellos. Además, exigimos inglés y tú dices que no sabes, así que vamos a ir al grano. ¿Por qué deberíamos cogerte a tí en lugar de a uno de los otros?" Menuda putada, ¿eh? Me consta que no era una pregunta genérica que les hacían a todos, porque más amigos se habían presentado y no pasaron por nada similar. (Y sí, el tío consiguió el puesto, y le mandaron a currar a USA sin saber apenas inglés, pero no veas lo rápido que se puso las pilas)

Puede que al final lo hayas hecho bastante bien, pero aún así me quede con el runrún de "algo me dice que no mola", o que la hagas regular y "algo me dice que el tío vale", pero no sabes decir exactamente el qué. Después de años de entrevistas, vas teniendo confianza en tus juicios, y harás caso a ese instinto.

Una entrevista (por lo menos en el marco en que suelen ocurrir en videojuegos) es algo muy subjetivo, las ambiguedades y los "depende" son el pan nuestro de cada día. No es una ciencia exacta, y no tiene NADA que ver con ningún examen que hayas hecho durante los estudios.

Ah, y recordad una cosa: cualquier entrevistador QUIERE que la persona que está entrevistando demuestre ser un candidato cojonudo. No hay nada mejor que salir de una entrevista convencido de que quieres que el tío se venga a trabajar contigo. El candidato se pasa la entrevista nervioso pensando "¿Sabré demostrar lo que valgo?", pero el entrevistador pasa por un proceso similar preguntandose "¿Será un tio muy bueno y no lo sabré ver?"

Y si, a veces el entrevistador la caga, y deja escapar a un tío que vale. Así es la vida... como me dijo una vez un jefe, el que quiera garantías que se compre una lavadora. :)

 Me temo que con tanta discusion sobre las pruebas técnicas en las entrevistas, al final todo cristo va a conocer las que hacemos en Pyro, asi que.... ¡año nuevo, test nuevo! :)

Lo primero que digo a los entrevistados antes de empezar el test es: "esto NO es un examen, no se trata de aprobar o suspender. Lo que buscamos con esto es ver qué sabes, en qué aspectos de la programación eres más fuerte, y cómo abordas la resolución de problemas." Y aunque suene a rollo de siempre, es exactamente para lo que la utilizamos. Por supuesto, como en cualquier entrevista o examen, si el candidato se pone nervioso, será un problema para que pueda transmitir todo eso, pero también intentamos tener ese aspecto en cuenta.

En cualquier caso, entrevistar a gente no es una ciencia exacta. Diferentes personas tenemos diferentes criterios, cometeremos errores, y seguro que habrá gente que no nos convenza aunque en realidad sean unos fieras, pero en general creo que las conclusiones que sacamos sobre las entrevistas se han mostrado bastante certeras.

Por último, indicar que el que crea que la tarea de programar es simplemente escribir código, lo lleva crudo. :) ¿Cuánto sabes sobre teoría de la programación? ¿Cuánto sobre los detalles del C++? ¿Y de Matemáticas, estructuras de datos, algoritmica en general, geometría, optimización? ¿Cómo de bueno eres analizando código de otros? ¿De qué forma estudias un problema antes de buscar una solución? ¿Cómo exploras las posibles soluciones? ¿Qué haces cuando te atascas? ¿Cómo describes a otras personas un problema, una técnica, un diseño, una solución? Etc etc etc...

 Pero hombre, Over, ¿en serio crees que alguien de Pyro se molesta en traer a alguien a Madrid y pasar un par de horas entrevistandole, si no hay intención de contratarle? Si tú mismo dices que el examen te salió fatal, ¿hace falta pensar que en realidad hay motivos oscuros y secretos?

Vale que Pyro sea la empresa mas gorda y más visible, y que por tanto sea el blanco más fácil de cualquier crítica o suspicacia, pero de verdad que a veces os pasais tres pueblos. :) Luego hay quien se queja de no ver a más gente de Pyro participando y compartiendo experiencias en foros como Stratos, pero es que leyendo cosas como esa, a uno se le quitan las ganas!

Más de la mitad de la plantilla de Pyro ha entrado en la empresa sin experiencia previa en videojuegos. Hay venido gente con experiencia en otros trabajos, y recién salidos de la carrera. Gente con doctorado, y gente con el COU y por los pelos. Magos del C++, y gente que no había tocado un PC en su vida. Hasta gente que ni siquiera le gusta jugar. Hay DE TODO, y cada caso es único. Creo que lo mismo se puede decir de practicamente cualquier estudio de desarrollo, en España y en cualquier otro país.

 

http://www.20minutos.es/noticia/72360/0/qu...es/experiencia/

Juzguen ustedes mismos...a mi me parece un poco triste que digan estan cosas...

Me pregunto si les pagaran lo mismo a los extranjeros que a los españoles...

Pero bueno, es logico pensar que fuera hay mayor cantidad de profesionales, tambien hay mayor industria, pero una cosa está clara, en esa empresa hay muchisima gente con talento que ha hecho grandes proyectos y sigue haciendo grandes cosas, vamos, como si ahora Pyro le deberia su talento a los extranjeros... en fin.

Creo que los únicos que están satisfechos con esa entrevista en la manera que ha sido publicada, son los "genios" de ese periodico. Es totalmente cierto que TODOS tenemos mucho que aprender (el que se crea que ya lo sabe todo lo lleva crudo), que podemos aprender mucho de extranjeros (y españoles) con experiencia en otros estudios, y que en España NO hay mucha gente con experiencia en videojuegos. De ahi, a lo que ha salido impreso, hay un mundo. En fin...

 Joer vaya follon me ha montado el soft de los foros estos, si intento editar mi mensaje el resultado es un desastre. :P

[QUOTE]

 

QUOTE (seryu)

[/quote] Por lo que recuerdo, la IGDA solo permite la creación de chapters asociados a una ciudad, no a un pais completo. Antes no era así, pero cuando lo cambiaron no obligaron a recrear los chapters ya existentes. ¿cuando veremos un estudio español afiliado? Supongo que cuando afiliarse desde fuera de USA sirva para algo. :) El hecho de que la IGDA no se moleste en contemplar la realidad de otros paises con una industria mucho menor (como en el caso de los chapters) es prueba de ello. :( #60 General / Ex-trabajadores De Gextech Cuentan Su Experiencia 11 de Noviembre de 2005, 08:12:05 AM  Pues espero que esa "mayoría" cuyo apoyo tan rápidamente te inventas, entienda que hasta ahora lo único que han oido es a dos histéricos posteando sus vendettas personales en tantos foros como encuentran. Publicar información interna de una compañía sin permiso, sacarla de contexto, y intentar utilizarla para intentar desprestigiar a esa compañia y a los que trabajan en ella, demuestra vuestra total falta de ética y profesionalidad, además de ser ilegal. Yo por mi parte, brindaré el día que os metan el puro que os mereceis. Páginas 1 2 3 4 5 Ayuda | Ir Arriba ▲ SMF 2.1.7 | SMF © 2013, Simple Machines Síguenos en Aviso legal Tratamiento de datos Seguridad Cookies © 2026 Stratos Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad. Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante. Muchísimas gracias. Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad. Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante. Muchísimas gracias.

 Pues espero que esa "mayoría" cuyo apoyo tan rápidamente te inventas, entienda que hasta ahora lo único que han oido es a dos histéricos posteando sus vendettas personales en tantos foros como encuentran. Publicar información interna de una compañía sin permiso, sacarla de contexto, y intentar utilizarla para intentar desprestigiar a esa compañia y a los que trabajan en ella, demuestra vuestra total falta de ética y profesionalidad, además de ser ilegal.

Yo por mi parte, brindaré el día que os metan el puro que os mereceis.