Debate Sobre C++ Y Oop

[Jare]

 Y dejar a los pobres de General en paz.

[seryu]

 Que bien, voy a estrenarlo. ¿Cuantos compiladores conoceis que para una cadena de texto definida tal que asi:

char variable[] = "Meto lo que me da la gana.";

no guarde los datos de la cadena de forma alineada?

[Jare]

 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.

[Pogacha]

 No entiendo este thread :( , es para gente que este aburrida?

Edit:http://www.stratos-ad.com/forums/index.php...7&t=5773&st=270
Ignoren el post.

[ethernet]

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 ...

En este foro discutimos las opiniones y las ideas, cosa que es sana, lo que es el colmo es que discutimos los datos. Nos empezamos a parecer a los políticos españoles.

En cuanto al tema, hay un montón de cosas tan caracterísitcas de los lenguajes.. de hecho por la red proliferan test de conocimientos del lenguaje sobre C/C++ como este.  

[zxs]

 

Y vamos a ver... Zupervaca... lo de la alineación de la memoria, no es ni mucho menos lo que estás imaginandote. Lo que se intenta con la alineación es que datos de más de 4 bytes de tamaño, estén en colocados en posiciones múltiplo de 4 (0, 4, 8, 12, 16, ...) Porque a la hora de hacer una lectura en memoria con los micros de 32 bits, ante una situación como esta, puedes leer 4 bytes de golpe ahorrando ciclos del micro. Es un tema complicado, que seguramente en los manuales de Intel sobre la arquitectura de sus micros de 32 bits vendrá claramente explicado.

cierto y digo más, poneos a usar cosas que corran sobre otras tecnologías x86 como los buses (PCI/acceso a memoria directo I-O/ISA), en mi caso uso el bus PC/104, te puedes encontrar cosas de lo más "raro" y que respetan el status quo del PC/104: necesidad de leer datos en dos lecturas, en una, en la madre que lo parió... manuales que no explican el tipo de las tarjetas (8-16bits) econtrándote tarjetas de 8 bits con las ranuras de 16 bits y las sorpresitas que te llevas luego al intentar leer la memoria y ver que salen "cositas especiales" y tu te vuelves loco (bueno, esto es un galimatias, pero os aseguro que es bastante divertido  (nooo)  el programar los drivers de tarjetas de estas con los datasheet que vienen incluidos con ellas)

[[Over]]

 Hola.

Si teneis más test como ese que habeis pasado os lo agradeceria :D.

Un saludo.

[marcode]

 He visto en el hilo anterior que se está discutiendo sobre si la memoria está en ocasiones dividida, o fragmentada y alguien dijo anteriormente que había limitaciones con la memoria estática en cuanto al acceso.

Supongamos que quiero quitar el primer carácter de la cadena, desplazando el resto al principio, y lo hago así:.

Código [Seleccionar] Expand


char cadena[]="@quítame la berruga";

char *pIndCadena = cadena;
char *pFinCadena = cadena + strlen(cadena);

do
{
    *(pIndCadena) = *(pIndCadena+1);
}
while ( (pIndCadena++) != pFinCadena );



y ya puestos me interesaría asegurarme de que esta forma también es correcta, a mi no me da ningún problema:

Código [Seleccionar] Expand


memcpy( cadena, cadena+1, strlen(cadena));


¿Veis algún problema en manejar así la memoria en cualquier compilador o circustancia?

[synchrnzr]

 Me gusta más el código de arriba. En el segundo no tienes ninguna garantía que la implementación de memcpy copie los datos de delante hacia atrás como lo has hecho en el primer fragmento de código. Además, suele haber una recomendación sobre no usar memcpy con fragmentos de memoria solapados (ya sabes, may cause unpredictable results) si no recuerdo mal.

sync

[marcode]

 Gracias, tampoco me fiaba yo mucho del segundo caso, ni se gana mucho en velocidad, aunque lo cierto es que funciona.

Pero si alguien me dice que el primer caso pueda dar algun problema en alguna circustancia........... me la corto. (asco)

Tendría que tirar a la basura todo lo que he hecho hasta ahora. :lol:  

[Lex]

...

[Pogacha]

 

Código [Seleccionar] Expand

d(char*c){while(*c)*c++=c[1];}

Me gane algo ?

[zupervaca]

 segun mi forma de programar que difiere a los demas (se presupone que esta funcion solo vale para nSlide positivos)

Código [Seleccionar] Expand

char *SlideString( char *psz, size_t nLength, int nSlide )
{
if( psz != NULL && nLength > 0 )
{
 size_t nCount = nLength -nSlide +1;
 if( nCount > 0 )
 {
  char *pszRet = new char[nCount];
  if( pszRet != NULL )
  {
   memcpy( pszRet, psz + nSlide, nCount );
   return pszRet;
  }
 }
}
return NULL;
}

[Lex]

...

[senior wapo]

Dios que manía tiene la gente de usar la aritmética de punteros, cuando podrían usar el [] y sería más claro XD Además no se que problema hay con usar un int para el indice, y si te apuras usas un unsigned int, que creo que cadenas de más de 4GB no vais a encontrar por ahí, de hecho cadenas de texto de 2GB tampoco son especialmente frecuentes en memoria...

El hecho de usar punteros en lugar de índices es porque "potencialmente" es más rápido si el compilador no optimiza como debe (o puede). No es por el desbordamiento de la variable que hace de índice.

Generalmente, yo uso punteros antes que indices, menos cuando me da pereza y nadie va a ver el código :D

Pero vamos, eso ya lo sabrías, lo dices por claridad del código. Que más da, al fin y al cabo.


A mi estos hilos, quitando el post suelto que muestra alguna curiosidad, me dan repelús porque al final se convierten en un concurso para ver quien la tiene más grande (y yo, si me da mucho el aire, me costipo en seguida).  (twist)