Programacion general desde cero

Sigo sin entender. Si ponés:
Int S[2] = {2, 22, 56};
por una parte el vector S tendría 2 posiciones, no 3, y la inicialización no debería funcionar.
Por la otra, ¿cuál debería ser el valor de la posición 6 de un vector con 3 posiciones?
Me parece que no estamos hablando del mismo lenguaje de programación, entre otras cosas porque usás Int en vez de int.
A no ser que quieras mostrar cómo C y C++ no tienen chequeo de subíndices.

He programado bastante bajo EUPHORIA y la verdad es q la mayor ventaja es su relación sencillez/potencia ademas de un exhaustivo control de errores. Por suerte si necesito velocidad critica hecho mano de ASSEMBLER el cual se introduce en el código de una manera muy sencilla. Si además resulta que puedes acceder a rutinas de librerías dinámicas fácilmente creo que es uno de los mejores programas para empezar y continuar.
EUPHORIA+ASM+SDL+OPENGL = libertad de expresión.

Veo que hay algún otro que programa en EUPHORIA en Argentina (supongo).

Soy español y no argentino, pero para el caso es lo mismo, si necesitaras resolver algo sobre el lenguaje Euphoria...

ufff, q tirado deje este post.

Int -> int , porque aveces cuando tipeo pongo las mayus, Int No existe , no te lo toma como un tipo de varible.
Y int S[2] era 3, la verdad no se porque le puse 2 en vez de 3, le habre pifiado el numpad

Igualmente el ejemplo, se podria dar con un vector vacio de X posiciones y mostrar X+7 posiciones y "algo" hay a eso referia, sorry q no respondi antes, pero recien me llego al mail un aviso del post.

Ando con problemas de ACC, no me deja estar logueado mas de 5 min, como si el cookie tiviera TTK y se le borran las inscripciones a los post. Tengo el favoritos llenos de post del foro de polica Y_Y

Gracias. Hace un tiempo que no entro en el foro de EUPHORIA, pero en algún momento fui asiduo visitante y he contribuido a la Biblioteca con varios programas.
Saludos.
-----Agregado el 17/8/2009 a las 09 : 14 : 01-----
Lo que entiendo que decís es que si por ejemplo definís:
int v[5];
y luego usás por ejemplo:
printf("%d\n", v[7]);
algo te va a imprimir, aunque la posición no exista desde el punto de vista teórico.
Eso es cierto, y muestra una de las debilidades de C, que consiste en no verificar los índices en aras de la velocidad de ejecución.
</desvirtúe y chivo on/>
Eso no pasa en EUPHORIA.
</desvirtúe y chivo off/>
De cualquier manera, no es un buen ejemplo para un principiante (que aún cree que la computadora es mágica).

Permitanme un comentario que espero que resulte útil. Soy de los que empezaron con Assembler en 1971 (oops), pasamos por Fortran, Basic y varios más, ahora trabajo con Delphi porque me resulta muy claro y es un lenguaje muy rico y eficiente. El tema es que veo que los principiantes se orientan demasiado rápidamente hacia los sistemas de Base de Datos, un invento que trajo muchos avances desde hace 30 años y actualmente es como un Mandamiento Sagrado.

Veámoslo así: una vez dominado el aspecto algorítmico de un proceso, su ingreso, validación, procesamiento y salida, nos encontramos con el problema de dónde poner los datos masivos, y después cómo extraerlos para mostrarlos de diferentes formas, compartirlos con otros sistemas, asegurar que no se borren, etc.

Ahí es donde aparecen las luces cegadoras: BASE DE DATOS. Parecería que nada se puede hacer sin estudiar SQL, BDE, IDE, ADO, ODBC, ORACLE, INFORMIX, y cien siglas más que ofrecen TODO: es decir, "Dime cómo son tus datos, Yo te los almaceno, Yo te los mantengo, Yo te los doy, Yo me encargo, tú no tienes que saber cómo lo hago" (Obviamente, "tú pagas")

Esto es tentador, pero más tentador es "Yo te doy pantallas de ingreso de datos, Yo te valido todo, Yo busco lo que necesites, Yo te doy reportes ordenados y subtotalizados como quieras, Yo te hago los cálculos y finalmente te hago la copia de backup"

Pero esto tiene su costo. Además del precio del sistema, que puede oscilar entre los 500 y los 50,000 dólares según la magnitud, hay que considerar que:
- El sistema donde van mis datos es una Caja Negra donde no puedo ver nada si no es a través de los programas propios de la Base de Datos.
- La velocidad de proceso puede ser entre 10 y 1000 veces menor que haciéndolo uno mismo
- El espacio en memoria y en disco puede ser entre 100 y miles de veces mayor
- Si falla el sistema, puedo perder los datos desde el último backup igual que si lo hiciera yo mismo.
- Los mensajes de error generalmente aparecen en inglés (al usuario, que no lo habla)
- La dependencia con el sistema y sus defectos es total
- Los programas más simples, para aplicaciones pequeñas, se transforman en pesados monstruos

Pero quizá el peligro más grande se encuentra en el entrenamiento: los programadores se ven tan restringidos por las normas del sistema, que no consiguen desarrollar la esencia de sus programas, que está en el algoritmo del proceso. Se pasan semanas y meses intentando cumplir con todas las normas para tareas que SIN base de datos tomarían un día. Dependen exclusivamente de rutinas hechas por otros, en una terminología abstracta que no dice nada sobre el proceso físico que se está produciendo.

Ignoran totalmente que el manejo de datos en disco está resuelto desde hace 40 años mediante rutinas sencillas que hacen del disco una extensión de la memoria RAM (a la que dan un uso limitadísimo), y que existen métodos de indexación y búsqueda que permiten el acceso directo, a cualquier sector del disco en milisegundos, y la lectura en microsegundos. Y que también está muy bien resuelto el tema de conflicto entre dos procesos que quieren modificar un mismo dato. (record lock y file lock)

Para no hacerla demasiado larga, la sugerencia es que al estudiar programación, inmediatamente se estudien los archivos de Acceso Directo, también llamados despectivamente Archivos Planos, y que se usen extensivamente hasta que llegue la verdadera necesidad de una Base de Datos que haga todo a su modo y sin decirme cómo lo hace.

Cuándo llegará esa necesidad ?
- Cuando tengamos cientos de miles de datos en estructuras complejas interdependientes
- Cuando varios programadores deban compartir los mismos datos y no hay tiempo para entrenar a todos
- Cuando las estructuras sean muy variables y hay que buscarle ubicación a nuevos campos sin parar el sistema
- Cuando la casa matriz internacional así lo exija.

Hace poco un pibe principiante se asombraba de que yo no uso base de datos, en un sistema administrativo y contable muy complejo. Me decía "eso es antiguo!!" Y bueno, la matemática también es antigua..

Hacerlo que vos decis, es decir trabajar con la memoria tiene el drama mismo de la ram.

Es volatil, si por alguna razon el usuario esta haciendo carga de una lista de 700 objetos y es diario y por casualida cayo un dia feriado, pero el servicio siguio.
Al dia siguiente tiene 1400 registros, es decir que si los ingresan y a los 1100 se le corta la luz y los datos se pierden.

Es muy posible que al otro dias vos muera de una forma paranormal y totalmente sobre narutal.
Ademas de que el dataentry que perdio el registro 1100 y tuvo que empesar de nuevo tiene un muñeco voodu en su freezer con un foto tuya en la cara y al menos 2 centenares de aguajas clavadas .

Por lo que usar la memoria para registos cortos y procesos rapidos como liquidacion de haberes x persona, no es malo.

Pero si es la ejecucion de los dividendos dentro de las distintas sucursales ( imaginte si sos una tercerizadora de liquidacion de haberes y tramites de RRHH ).
La gran cantidad de registros lo hace, un arma de 2 filos.

Por consiguiente uno usaria un sistema de base de datos. Obvio, esto tiene su defecto.

Bien, como vos decis, tener que pagar muchos Dolare$ o en algunos casos hay gestores freeware que sirven, pero pocas veces se da la ocacion.

Lo cual, puede llevar a realizar tu propio sistema de almacenamiento de datos.

XML, puede ayudar muy bien con esto, el hacer un ORDER BY o JOIN y diferentes cosas, no son tan dificiles.

Quien no ha hecho ? alguna vez : Ordenar un vector de menor a mayor u ordenar una lista de palabras tomando las pababras como un vector de caracteres donde se usa el Valor ASCII para acomodarlo.

Estos conocimientos basicos son altamente utiles a la hora de hace un pequeño archivo de almacenamiento.

Luego uno puede genera librerias para hacer su depuracion de datos, es decir su consulta.

Obviamente,esto demanda aunque sea 2 dias de nuestro tiempo y para que nos vamos a molestar si esta SQL

Pero no es mala idea.
El drama es que uno, no debe fiase de la RAM, porque es volatil y por ende, los datos que manejas tmb.

No hace falta que estes en contra de los sistemas de base de datos con alcenamiento, sin embargo tampoco hay que esperar que ellos lo hagan todo.

No, esperá, quizá no me expliqué bien: confiar datos a la RAM nunca. Cuando digo que los principiantes (y expertos también, si el sistema no es enorme) usen ARCHIVOS DE ACCESO DIRECTO, y cuando digo que el disco se usa como una extensión de la RAM, quiero decir que se GRABA EN EL ACTO CADA DATO. No sólo se graba, sino que se obliga a Windows a grabar físicamente, y se verifica que fue grabada toda la transacción !

Nunca se deja nada en RAM, ni por un milisegundo.

Y tengo otra ventaja importante: de esta manera propia (que yo llamo irónicamente ChotoBase) elimino la posibilidad de que el servidor haga sus peligrosos manejos de DISK CACHEING. Qué es esto ? Es la técnica de los servidores, y de las propias PCs para ahorrar tiempo: reciben el pedido de grabación, responden TODO OK, pero no graban. Dejan los datos en su RAM esperando la oportunidad de grabar varios bloques juntos, lo que beneficia la velocidad del servidor y de las redes. Si en ese momento se corta la luz (y en estos países del Tercer Mundo no tenemos una fuente ininterrumpible (UPS), simplemente vuelan por el aire todos los datos de los últimos segundos, o minutos.

En Delphi existe la sentencia FlushFileBuffers, y en otros lenguajes debe existir, para OBLIGAR a Windows a grabar de verdad, y en el mismo acto, aun a costa de una velocidad menor. Pero qué me importa, si con mis archivos de ChotoBase trabajo 500 veces más rápido que una Base de Datos ?

De paso me gustaría hacer una encuesta: cuántos jóvenes programadores saben cómo grabar y leer un archivo de acceso directo ? Creo que no son muchos. Otro día, si les interesa, podemos hablar de cómo extraer datos de un archivo plano mediante índices, optimizando la lectura. Y muy de acuerdo en que no hay que esperar que las bases de datos lo hagan todo.

escamillo:
Totalmente de acuerdo con vos. Y no es porque no conozca Bases de Datos. En mi último empleo trabajé extensivamente con Oracle. Y años antes programé una Base de Datos generalizada desde cero.
Yendo todavía más allá de tus comentarios, en muchos casos he descubierto que lo más eficiente y económico para una Base de Datos es un sencillo editor de textos, o también Word o Excel, dependiendo de las circunstancias.
Si los requerimientos son simples, las soluciones deben ser simples.