Librería

[@synthesize]

Lo primero es modificar el post inicial con la lista de colaboradores, los requerimientos para las funciones y los objetivos. Elabora un post explicando mas o menos de que va el tema así la gente se va sumando, si no queda todo en el aire.
Los que se quieran ir sumando hacen un post aqui o envían un pm a GNU.

Cuando todo eso este terminado, pasamos a sourceforge o a cualquier otra. Es mucho mas ordenado así, ya que cuando el hilo se haga muy largo va a ser muy molesto de seguir.

Ya he empezado ^^

[Foxy Rider]

Yo más que SourceForge diría github o gitorious ...

Saludos.

[Gallu]

Pienso que sería buena idea incluir la implementación de TAD's (árboles , pilas , colas) que les parece ?

[eagle17]

A mí también me gustaría aportar mi granito de arena, si puede ser!

Salu2 

[@synthesize]

Pienso que sería buena idea incluir la implementación de TAD's (árboles , pilas , colas) que les parece ?

Siempre que sea necesario, es mejor organizar bien los datos 

[@synthesize]

Tengo una primera idea... Siempre estoy escribiendo funciones para recoger números, entre x y n... Mi idea es una función, int, a la cual se la pasa como parámetro el inicio y límite, para que la función recoja n número entre esos 2 valores.



Pseudo;

int ats_readNum(int min, int max);

inicio funcion()
    declaro num;
    limpiar buffer;

    mientras (num>min && num<max)
        limpiar buffer;
        pedir num;
    fin mientras;

    devolver num;
fin funcion



Os gusta?

[Horricreu]

Muy bonito pero, ¿por qué hacéis esto, si con un par de for(), no en este ejemplo, o lo que sea lo tenéis?

Es que así, uno no aprende C/C++.

Saludos

[Foxy Rider]

Espero no quedar muy criticón, es con buena intención, lo prometo ! (?)

Primero, la convención de nombres no me agrada, no es estético un guión parado en medio de la función, creo que el esquema de nombres debería similar al de OpenGL (del cual varias librerías tomaron el esquemas de nombre, como OpenCL, OpenAL, CUDA, Runtime de Cg, etc ...) ...

[prefijo][Comando][Muy Opcional : número de parámetros y tipos de datos]()

Código (c) [Seleccionar] Expandir


inline double atsPow2d(double base, double exp)
{
   return pow(base,exp); // aca iria un codigo que haga algo mas interesante que wrappear pow()
}


(si creativísimo el ejemplo, hay sueño, es lo que hay xD)

siendo [ats] el prefijo, [Pow] el comando, [2] la cantidad de parámetros y [d] el tipo de dato ....
como dije, el tipo de dato y cantidad de parámetros es opcional,muy ... dependiendo de lo que implementen ...

también una mini convención de como hacer las funciones, que formato visual deben tener ... (si el coding style es GNU, ISO, etc ...)
y como dividirían los encabezados (dentro de una carpeta, subcarpetas, un .h ... ) ... son varias cuestiones ...

aunque , ahora que lo pienso ... no veo claro lo que quieren hacer y en el sourceforge todavía no hay una sola línea de código ... (y de acuerdo al primer post original y un segundo post + pseudocode... me da la sensación de que esto es un eufemismo para que terceros programen, espero equivocarme)

Saludos.

P.S : vuelvo a pokear el asunto de git

[@synthesize]

Espero no quedar muy criticón, es con buena intención, lo prometo ! (?)

Primero, la convención de nombres no me agrada, no es estético un guión parado en medio de la función, creo que el esquema de nombres debería similar al de OpenGL (del cual varias librerías tomaron el esquemas de nombre, como OpenCL, OpenAL, CUDA, Runtime de Cg, etc ...) ...

[prefijo][Comando][Muy Opcional : número de parámetros y tipos de datos]()

Código (c) [Seleccionar] Expandir


inline double atsPow2d(double base, double exp)
{
   return pow(base,exp); // aca iria un codigo que haga algo mas interesante que wrappear pow()
}


(si creativísimo el ejemplo, hay sueño, es lo que hay xD)

siendo [ats] el prefijo, [Pow] el comando, [2] la cantidad de parámetros y [d] el tipo de dato ....
como dije, el tipo de dato y cantidad de parámetros es opcional,muy ... dependiendo de lo que implementen ...

también una mini convención de como hacer las funciones, que formato visual deben tener ... (si el coding style es GNU, ISO, etc ...)
y como dividirían los encabezados (dentro de una carpeta, subcarpetas, un .h ... ) ... son varias cuestiones ...

aunque , ahora que lo pienso ... no veo claro lo que quieren hacer y en el sourceforge todavía no hay una sola línea de código ... (y de acuerdo al primer post original y un segundo post + pseudocode... me da la sensación de que esto es un eufemismo para que terceros programen, espero equivocarme)

Saludos.

P.S : vuelvo a pokear el asunto de git

El 'formato visual' ya lo hemos intentado definir, al igual que la organización. Lo del estilo OpenGL me ha gustado bastante, voy a estudiar como implementarlo!

EN SF no hay líneas escritas porque todavía no hay código escrito, y no es para que terceros programen, el objetivo es que cada uno que quiera colaborar, colabore con sus ideas y conocimientos...

[do-while]

¡Buenas!

A mi, si se me dice que es lo que tengo que codificar, y que reglas de estilo tengo que seguir, me apunto. No es cuestion de ponerse a teclear y producir en serie un monton de clones de una misma funcion...

¡Saludos!