Juan Manuel Ollé | 23 Dec 19:52 2008
Picon

Re: suerte en los firings


Bueno, Daniel, aca va mi tirito, espero no errarle por mucho

1) se puede hacer ésto?

void f(int x)
{
   const int pepe = 1;
   switch(x)
   { case pepe: blablabla
     case pepe+1: blablablabla
     case 3+4-1: blablablablabla
   }
}

Si es valido pues en todos los casos son constantes integrales.

2) se puede hacer ésto?
   this++;
Eso no se puede hacer porque this es un puntero constante (a donde
apunta es constante)

3) un struct, tiene this? Y un union?

struct tiene this no cabe duda. En cuanto al union, puede tener
metodos, lo que no puede tener es constructores, por lo tanto si tiene
miembros estimo que para que dichos metodos puedan modificar los
miembros, las uniones deben tener this.

4) y esto?
(Continue reading)

Marcelo Caro | 23 Dec 20:14 2008
Picon

Re: suerte en los firings


>>2) se puede hacer ésto?
>>  this++;
>>Eso no se puede hacer porque this es un puntero constante (a donde
>>apunta es constante) 

Creo que lo que  apunta es constante si la instancia o el metodo es constante.
Lo que es seguro es que el puntero es constante. si la clase es T, this es de tipo cv T *const (cv depende del cualifier de la instancia y del metodo en particular).




On Tue, Dec 23, 2008 at 4:52 PM, Juan Manuel Ollé <juanmanuelolle-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Bueno, Daniel, aca va mi tirito, espero no errarle por mucho

1) se puede hacer ésto?

void f(int x)
{
  const int pepe = 1;
  switch(x)
  { case pepe: blablabla
    case pepe+1: blablablabla
    case 3+4-1: blablablablabla
  }
}

Si es valido pues en todos los casos son constantes integrales.

2) se puede hacer ésto?
  this++;
Eso no se puede hacer porque this es un puntero constante (a donde
apunta es constante)

3) un struct, tiene this? Y un union?

struct tiene this no cabe duda. En cuanto al union, puede tener
metodos, lo que no puede tener es constructores, por lo tanto si tiene
miembros estimo que para que dichos metodos puedan modificar los
miembros, las uniones deben tener this.

4) y esto?
   const int& x = 4;   // Esto es correcto, con el cuatro crea un
temporal y este temporal se asigna a la referencia constante. el
temporal vive hasta que dicha referencia deja de existir

   const int* y = &4;  // Esto no compila, no se puede tomar la
direccion de un literal
   const int* z = &(int)4;  // Esto se ve muy parecido al anterior no
creo que funcione





--
          Marcelo

--~--~---------~--~----~------------~-------~--~----~
¿Eres miembro de "CyC++ Buenos Aires" verdad? Si no lo eres, has recibido este mesaje por error.
En caso de duda visita "http://groups.google.com/group/cppba"
-~----------~----~----~----~------~----~------~--~---

Fernando Cacciola | 23 Dec 20:29 2008
Picon

Re: suerte en los firings


Hola Marcelo,

> 
>  >>2) se puede hacer ésto?
>  >>  this++;
>  >>Eso no se puede hacer porque this es un puntero constante (a donde
>  >>apunta es constante) 
> 
> Creo que lo que  apunta es constante si la instancia o el metodo es 
> constante.
> Lo que es seguro es que el puntero es constante. si la clase es T, this 
> es de tipo cv T *const (cv depende del cualifier de la instancia y del 
> metodo en particular).
> 
En realidad, el standard no dice *precisamente* eso, aunque dice algo 
que es efectivamente equivalente:

this in an rvalue expression

(de un tipo que depende del contexto)

Saludos

Fernando

Hernán Leoni | 23 Dec 20:26 2008
Picon

Re: suerte en los firings

Hola, voy a tratar, a ver que sale

1- yo diria que no, ya que el compilador espera built in constants en cada case.

2- tambien creo que es un puntero constante, si se pudiera hacer dafasaria toda la estructura de la clase y se romperia todo

3- el union yo supongo que no tiene this (ni tabla virtual) ya que en runtime el union no existe, entiendo que el ejecutable lo veria como estructuras normales en memoria (solo que algunas estructuras se alojan en el mismo lugar de memoria), segun entiendo solo tiene sentido para el programador y para que en tiempo de compilacion el compilador manipule la estructura.

4- en realidad no lo prob'e, pero supongo que no deberia andar ninguna, ya que el 4 no tiene una direccion de memoria, es una constante que el compilador pone directamente en el ejecutable, no es una variable con memoria asignada.

5-
a)  void f(void);  

     x = f;          <<<< esto creo que no andaria, porque no se puede asignar la funcion en si misma
     y = &f        <<<<  esto anda si "y" esta declarada como puntero al tipo de f, seria algo asi void (*y) ();

 b) struct Pepe { void f(void); };
      z = &Pepe::f;         <<<<  esto anda si "z" esta declarada como puntero al tipo de f, seria algo asi void (*z) ();
      z2 = Pepe::f;          <<<< esto creo que no andaria, porque no se puede asignar la funcion en si misma



--~--~---------~--~----~------------~-------~--~----~
¿Eres miembro de "CyC++ Buenos Aires" verdad? Si no lo eres, has recibido este mesaje por error.
En caso de duda visita "http://groups.google.com/group/cppba"
-~----------~----~----~----~------~----~------~--~---

Fernando Cacciola | 23 Dec 20:47 2008
Picon

Re: suerte en los firings


Hola Hernán, ya te cansaste de Mountain View? :)

> 4- en realidad no lo prob'e, pero supongo que no deberia andar ninguna, 
> ya que el 4 no tiene una direccion de memoria, es una constante que el 
> compilador pone directamente en el ejecutable, no es una variable con 
> memoria asignada.
> 

Eso es totalmente cierto, pero daniel preguntó por el caso especial de:

const int & c = <integral constant expression>

porque esto está especificamente soportado.

Qué es lo ocurre en este caso exactamente?

  const int& r = 1 ;

los objetos referenciados son lvalues o rvalues?

el literal 1 es un lvalue o un rvalue?

y entonces? qe ocurre cuando se "bindea" r al 1?

Saludos

Fernando

Daniel Gutson | 23 Dec 21:55 2008
Picon

Re: suerte en los firings

MAÑANA voy a hacer un resumen de todo lo q dijeron (ya estando en San Juan, tal vez lo haga esta noche en el micro) y las rtas.

Ahora me gusta más, todos respondieron (bueno, faltan Esteban y Matías, sugiéranles q participen :) ).

Sólo para aportar malicia....

   int f();
 
   int (*x)()  = f++;

?

On Tue, Dec 23, 2008 at 5:47 PM, Fernando Cacciola <fernando.cacciola <at> gmail.com> wrote:

Hola Hernán, ya te cansaste de Mountain View? :)

> 4- en realidad no lo prob'e, pero supongo que no deberia andar ninguna,
> ya que el 4 no tiene una direccion de memoria, es una constante que el
> compilador pone directamente en el ejecutable, no es una variable con
> memoria asignada.
>

Eso es totalmente cierto, pero daniel preguntó por el caso especial de:

const int & c = <integral constant expression>

porque esto está especificamente soportado.

Qué es lo ocurre en este caso exactamente?

 const int& r = 1 ;

los objetos referenciados son lvalues o rvalues?

el literal 1 es un lvalue o un rvalue?

y entonces? qe ocurre cuando se "bindea" r al 1?


Saludos

Fernando





--~--~---------~--~----~------------~-------~--~----~
¿Eres miembro de "CyC++ Buenos Aires" verdad? Si no lo eres, has recibido este mesaje por error.
En caso de duda visita "http://groups.google.com/group/cppba"
-~----------~----~----~----~------~----~------~--~---

Marcelo Caro | 23 Dec 23:48 2008
Picon

Re: suerte en los firings

No, eso no anda, la justificación que creo correcta es la siguiente:

Según el standar hay una conversión implícita de nombre de función a puntero a función. Aunque esta conversion sea exact match al realizarse  lo que tenemos es un r-value. El operador ++ solo opera sobre lvalues.

Este caso es parecido al siguiente:

int x[10];
int *r=x++;

Por otro lado, creo que no se puede hacer aritmetica de punteros con punteros a funciones.
Sospecho que un puntero a funcion no es un tipo completo (por ese motivo no se puede hacer aritmerica), por eso no se puede hacer aritmetica de funciones.

(Alguien me podria confirmar la ultima hipotisis?)

Saludos!!




2008/12/23 Daniel Gutson <danielgutson-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
MAÑANA voy a hacer un resumen de todo lo q dijeron (ya estando en San Juan, tal vez lo haga esta noche en el micro) y las rtas.

Ahora me gusta más, todos respondieron (bueno, faltan Esteban y Matías, sugiéranles q participen :) ).

Sólo para aportar malicia....

   int f();
 
   int (*x)()  = f++;

?


On Tue, Dec 23, 2008 at 5:47 PM, Fernando Cacciola <fernando.cacciola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Hola Hernán, ya te cansaste de Mountain View? :)

> 4- en realidad no lo prob'e, pero supongo que no deberia andar ninguna,
> ya que el 4 no tiene una direccion de memoria, es una constante que el
> compilador pone directamente en el ejecutable, no es una variable con
> memoria asignada.
>

Eso es totalmente cierto, pero daniel preguntó por el caso especial de:

const int & c = <integral constant expression>

porque esto está especificamente soportado.

Qué es lo ocurre en este caso exactamente?

 const int& r = 1 ;

los objetos referenciados son lvalues o rvalues?

el literal 1 es un lvalue o un rvalue?

y entonces? qe ocurre cuando se "bindea" r al 1?


Saludos

Fernando









--
          Marcelo

--~--~---------~--~----~------------~-------~--~----~
¿Eres miembro de "CyC++ Buenos Aires" verdad? Si no lo eres, has recibido este mesaje por error.
En caso de duda visita "http://groups.google.com/group/cppba"
-~----------~----~----~----~------~----~------~--~---

Hernán Leoni | 23 Dec 23:23 2008
Picon

Re: suerte en los firings

Hola Fernando,
Aca andamos, todavia no me canse, pero en esta epoca dan ganas de volver. Lo bueno es que tenemos 24, 25 y 26 libres (igual que 31, 1 y 2).

Bueno, te cuento que"const int& r = 1 ;" compila y corre, y ademas si usas r, esta referencia al valor 1, con lo cual anda, trate de dedicarle un rato, pero no llego a deducir que esta haciendo el compilador.
Por favor decime que pasa con eso porque me esta intrigando mucho, jaja

Un saludo y felicidades,

Hernan


2008/12/23 Fernando Cacciola <fernando.cacciola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Hola Hernán, ya te cansaste de Mountain View? :)

> 4- en realidad no lo prob'e, pero supongo que no deberia andar ninguna,
> ya que el 4 no tiene una direccion de memoria, es una constante que el
> compilador pone directamente en el ejecutable, no es una variable con
> memoria asignada.
>

Eso es totalmente cierto, pero daniel preguntó por el caso especial de:

const int & c = <integral constant expression>

porque esto está especificamente soportado.

Qué es lo ocurre en este caso exactamente?

 const int& r = 1 ;

los objetos referenciados son lvalues o rvalues?

el literal 1 es un lvalue o un rvalue?

y entonces? qe ocurre cuando se "bindea" r al 1?


Saludos

Fernando





--~--~---------~--~----~------------~-------~--~----~
¿Eres miembro de "CyC++ Buenos Aires" verdad? Si no lo eres, has recibido este mesaje por error.
En caso de duda visita "http://groups.google.com/group/cppba"
-~----------~----~----~----~------~----~------~--~---

Daniel Gutson | 23 Dec 23:38 2008
Picon

Re: suerte en los firings

hint:

pensá en ésto:

const int* pr = &r;


On Tue, Dec 23, 2008 at 8:23 PM, Hernán Leoni <leoni.hernan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Hola Fernando,
Aca andamos, todavia no me canse, pero en esta epoca dan ganas de volver. Lo bueno es que tenemos 24, 25 y 26 libres (igual que 31, 1 y 2).

Bueno, te cuento que"const int& r = 1 ;" compila y corre, y ademas si usas r, esta referencia al valor 1, con lo cual anda, trate de dedicarle un rato, pero no llego a deducir que esta haciendo el compilador.
Por favor decime que pasa con eso porque me esta intrigando mucho, jaja

Un saludo y felicidades,

Hernan


2008/12/23 Fernando Cacciola <fernando.cacciola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>


Hola Hernán, ya te cansaste de Mountain View? :)

> 4- en realidad no lo prob'e, pero supongo que no deberia andar ninguna,
> ya que el 4 no tiene una direccion de memoria, es una constante que el
> compilador pone directamente en el ejecutable, no es una variable con
> memoria asignada.
>

Eso es totalmente cierto, pero daniel preguntó por el caso especial de:

const int & c = <integral constant expression>

porque esto está especificamente soportado.

Qué es lo ocurre en este caso exactamente?

 const int& r = 1 ;

los objetos referenciados son lvalues o rvalues?

el literal 1 es un lvalue o un rvalue?

y entonces? qe ocurre cuando se "bindea" r al 1?


Saludos

Fernando








--~--~---------~--~----~------------~-------~--~----~
¿Eres miembro de "CyC++ Buenos Aires" verdad? Si no lo eres, has recibido este mesaje por error.
En caso de duda visita "http://groups.google.com/group/cppba"
-~----------~----~----~----~------~----~------~--~---

Fernando Cacciola | 26 Dec 17:43 2008
Picon

Re: suerte en los firings


Hola Hernán,

> Hola Fernando,
> Aca andamos, todavia no me canse, pero en esta epoca dan ganas de 
> volver. Lo bueno es que tenemos 24, 25 y 26 libres (igual que 31, 1 y 2).
> 
Groso Google!

> Bueno, te cuento que"const int& r = 1 ;" compila y corre, y ademas si 
> usas r, esta referencia al valor 1, con lo cual anda, trate de dedicarle 
> un rato, pero no llego a deducir que esta haciendo el compilador.
> Por favor decime que pasa con eso porque me esta intrigando mucho, jaja
> 
OK, veamos:

Todo "objeto" es aquello que tiene "storage", es decir que ocupa un 
lugar en memoria. (1.8 en el standard)

Toda referencia "refiere" a un objeto (o subobjeto) o una función (8.5.3)

Todo lvalue (digamos toda variable) corresponde a un objecto (3.10) y 
por tanto toda referencia puede initializarse con un lvalue.

Un rvalue puede ser de tipo fundamental (enteros, floats, etc), o de 
tipo clase, o de tipo array.

Si el rvalue es de tipo clase o array entonces corresponde a un objeto 
(que por tanto tiene storage):

   struct X {} ;
   X foo();

foo() es un rvalue de tipo X.

Una referencia no constante solo puede referir a un lvalue, por tanto:

   X& rx = foo(); // ERROR, foo() es un rvalue, no un lvalue

Pero una referencia constante puede referir además a un rvalue:

   X const& crx = foo(); // OK, const& puede referir a un  rvalue

Y este rvalue puede ser de tipo fundamental (entero, flotante, etc)

   double const& crd = 2.3 ;

Un objeto es un rvalue en lugar de un lvalue cuando es un objeto 
temporario (como el que devuelve foo).
Por tanto, cuando una referencia constante refiere a un rvalue de tipo 
clase está 'bindeando' a un objeto temporario (que existe de por sí, por 
el mismo rvalue y no un lvalue)

Cuando la referencia refiere a un rvalue de tipo fundamental, no existge 
en sí mismo un objeto correspondiento al rvalue y entonces se CREA un 
objeto temporario para que exista un objeto al cual referir (8.5.3/5)

   double const& crd = 2.3 ; Ahora existe un objeto correspondiente a 2.3

El objeto referido por crd es temporario y rvalue, pero objeto al fin 
(de lo contrario no podría haber una referencia al mismo)

Que la referencia siempre refiera a un objeto, aun cuando este sea un 
temporario (cuando 'bindea' un rvalue) hace posible esto:

  X const& crd = foo();
  X const* p = &crdK:

siendo que no es posible directamente esto:

  X const* p = foo();

Para ello, los temporatios que ocurren de bindear una referencia a un 
rvalue (temporario que puede existir de por si mismo cuando el rvalue es 
de tipo clase) ven su cliclo de vida explicitamente 'extendido' al de la 
referencia (12.2/5).

Nota: Desde el punto de vista del nuevo estandard (C++0x), todo lo 
anterior corresponde a las ahora llamadas "lvalue references". Exite un 
nuevo tipo de referencias llamadas "rvalue references", declaradas con 
"&&" en lugar de "&", de las cuales voy a hablar en otro post.

Saludos

Fernando

Fernando Cacciola | 26 Dec 17:54 2008
Picon

Re: suerte en los firings


Fernando Cacciola wrote:

> Exite un nuevo tipo de referencias llamadas "rvalue references",
 > declaradas con &&" en lugar de "&", de las cuales voy a hablar
 > en otro post.

En realidad este thread tiene el contexto ideal para presentar 
básicamente las nuevas "rvalue references".

Esecialmente, como su nombre lo indica, pueden referir a rvalues, algo 
que antes solo era posible con referencias constantes:

double & rd = 2.3 ; //  ERROR: 2.3 es un rvalue

double const & crd = 2.3 ; // OK

double && rd = 2.3 ; // Tambien OK: un rvalue reference puede
                      // bindear a un rvalue

Le dejo como ejercicio la pregunta: ¿Para qué sirven?

Saludos

Fernando

Hernán Leoni | 31 Dec 08:15 2008
Picon

Re: suerte en los firings

Hola Fernando, bien, me parece que voy entendiendo, a ver

Esto no se puede hacer, comprendido, (la referencia no puede referenciar a un rvalue)
  X& rx = foo(); // ERROR, foo() es un rvalue, no un lvalue
en cambio esto si, (la referencia constante si puede referenciar al rvalue)
  X const& crx = foo(); // OK, const& puede referir a un  rvalue

y la ventaja que tiene sobre esto
  X  crx = foo(); o X const crx = foo();

es que la copia desde el temporal a crx no se efectua, (bien?)
  (y el temporal tiene el alcance que tendria crx, es decir se le libera la memoria al salir del bloque en que se declara crx)

bien, estoy leyendo un poco el tema de las rvalue references, ya vere si tengo tiempo de hacer alguna pregunta o comentario, la verdad muy interesante el tema, y bueno, segun veo, y si no estoy tan mareado de lo que acabo de leer, esto termina evitando copias innecesarias, que no para despreciar sobre todo con objetos complejos, al contrario.
voy a tratar de digerirlo un poco mas.

un saludo,

feliz a~no

hernan





2008/12/26 Fernando Cacciola <fernando.cacciola-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

Fernando Cacciola wrote:

> Exite un nuevo tipo de referencias llamadas "rvalue references",
 > declaradas con &&" en lugar de "&", de las cuales voy a hablar
 > en otro post.

En realidad este thread tiene el contexto ideal para presentar
básicamente las nuevas "rvalue references".

Esecialmente, como su nombre lo indica, pueden referir a rvalues, algo
que antes solo era posible con referencias constantes:


double & rd = 2.3 ; //  ERROR: 2.3 es un rvalue

double const & crd = 2.3 ; // OK

double && rd = 2.3 ; // Tambien OK: un rvalue reference puede
                     // bindear a un rvalue


Le dejo como ejercicio la pregunta: ¿Para qué sirven?


Saludos

Fernando





--~--~---------~--~----~------------~-------~--~----~
¿Eres miembro de "CyC++ Buenos Aires" verdad? Si no lo eres, has recibido este mesaje por error.
En caso de duda visita "http://groups.google.com/group/cppba"
-~----------~----~----~----~------~----~------~--~---

Fernando Cacciola | 2 Jan 14:04 2009
Picon

Re: suerte en los firings


Hola Hernán,

> Hola Fernando, bien, me parece que voy entendiendo, a ver
> 
> Esto no se puede hacer, comprendido, (la referencia no puede referenciar 
> a un rvalue)
>   X& rx = foo(); // ERROR, foo() es un rvalue, no un lvalue
> en cambio esto si, (la referencia constante si puede referenciar al rvalue)
>   X const& crx = foo(); // OK, const& puede referir a un  rvalue
> 
> y la ventaja que tiene sobre esto
>   X  crx = foo(); o X const crx = foo();
> 
> es que la copia desde el temporal a crx no se efectua, (bien?)

>   (y el temporal tiene el alcance que tendria crx, es decir se le libera 
> la memoria al salir del bloque en que se declara crx)
> 
En realidad no.

El temporal se destruye cuando termina la expresión que lo crea, o sea 
justo despues de que crx es construido y antes del sequence point (el ; 
al final)

Por otro lado, si bindeamos el temporal a una referencia:

   X const& crx = foo();

o bien

   X && crx = foo();

entonces la referencia mantiene al temporal vivo mientras viva ella, que 
es dentro del bloque donde esta definida.

> bien, estoy leyendo un poco el tema de las rvalue references, ya vere si 
> tengo tiempo de hacer alguna pregunta o comentario, la verdad muy 
> interesante el tema, y bueno, segun veo, y si no estoy tan mareado de lo 
> que acabo de leer, esto termina evitando copias innecesarias, que no 
> para despreciar sobre todo con objetos complejos, al contrario.

Exacto.. esto se propuso para permitir

*) Move Semantics

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm

*) Perfect forwarding

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1385.htm

NOTA: Esos son los papers iniciales, del 2002.. sobre el tema se ha 
discutido una y otra vez en sucesivos papers.

Saludos

Fernando


Gmane