Cosas Ocultas En Una Lib

[Pogacha]

 Se puede de alguna forma hacer una .lib que tenga cosas ocultas en una clase sin que sea una clase virtual?

o sea ... que en verdad sea:

Código [Seleccionar] Expand

class {
  int mimiembro_oculto;
 public:
   miclase();
};
y la cabecera que el usuario de la lib vea:

Código [Seleccionar] Expand

class {
  public:
    miclase();
};
Haciendola virtual puedo pero no se como hacerla normal.

Saludos y gracias de antemano

[Topper]

 creo haber entendido tu pregunta ...  :ph34r:

Has probado con Protected o Private?

Protected: Sólo es accesible desde clases heredadas y private sólo es accesible desde la propia clase.

Código [Seleccionar] Expand


class {
public:
  miclase();
private:
  int mimiembro_oculto;
};

class {
public:
  miclase();
protected:
  int mimiembro_oculto;
};


[_Grey]

 La ocultacion de la implementacion, o las clases proxy, es lo que estas buscando.

A ver como lo explico de forma que se me entienda.....

Al usuario le das un .h con la clase "proxy", con las funciones que quieras pueda ver. Luego en la .cpp (que no se la das, esta claro,no?), lo que haces, es que cada funcion llame a su homologa de la clase que estas ocultando.

A ver, con un ejemplo....:

claseproxy.h

Código [Seleccionar] Expand


class claseReal;

class claseProxy{
void loQueSea();
private:
claseReal *cr;
};


clasereal.h

Código [Seleccionar] Expand


class claseReal{
void loQueSea();
private:
int montones_de_variables;
};


claseproxy.cpp

Código [Seleccionar] Expand


#include "claseproxy.h"
#include "clasereal.h"
claseProxy::claseProxy(){
cr = new claseReal ();
}
claseProxy::~claseProxy(){
delete cr;
}
void claseProxy::loQueSea(){
cr->loQueSea();
}


clasereal.cpp

Código [Seleccionar] Expand


#include "clasereal.h"
void claseReal::loQueSea(){
tu codigo...
}


basicamente le das al usuario solo la "claseproxy.h", y si , tendras que tirar de un punterito en la clase proxy. Y si no te gusta usas una interface, Ala!

Saludos!!.

PD: Es algo enrebasado espero se comprenda...

[TheAzazel]

 Exacto, grey se me adelanto... asi lo he hecho yo con CRM32Pro.... para que desde el punto de vista del usuario final(programador) no tenga porque liarse con cosas que no puede utilizar :)

Y la verdad que el codigo queda mas limpio en el .h de cara al usuario final... no asi tu propio codigo, que tiene un poco mas de engorro, pero es manejable...

[Topper]

 Vaya, no había caído en los patrones de diseño. Buen apunte chavales...  (ole)  

[Pogacha]

 Pero entonces es mas facil tener una clase virtual y una clase interface ...  

[ShAq]

 una cosa, y simplemente borrando lo que no quieres que se vea del .h para el usuario??
yo en mi libreria LTML, simplemente borré las variables miembro de las clases y dejé
los métodos y me funcionó...

[Topper]

 

una cosa, y simplemente borrando lo que no quieres que se vea del .h para el usuario??

hombre, para hacer eso creo que sería más elegante dejar esas variables miembro como privadas o protegidas, aunque la opción del proxy que han comentado me parece la más adecuada.

Saludos.

[zupervaca]

 los dos sistemas estan bien aunque tiene sus pros y sus contras, por ejemplo, el proxy queda muy elegante, pero implica tener que escribir codigo cada vez que cambiamos la clase aunque tambien da la ventaja de solventar problemas si la clase cambia y queremos mantener compatible todas las aplicaciones, el otro sistema es que se ha utilizado siempre y da la ventaja de que cuando cambias la clase solo tienes que borrar los miembros que no quieres que se vean otro .h

[ethernet]

 Cual es la razón para querer ocultar una variable? que el coder no pueda cambiarla de propiedad y mangarla ?

[zupervaca]

 en principio el ocultar un miembro es por que sea protegido o privado, a mi solo se me ocurren esos casos

[Pogacha]

 

una cosa, y simplemente borrando lo que no quieres que se vea del .h para el usuario??
yo en mi libreria LTML, simplemente borré las variables miembro de las clases y dejé
los métodos y me funcionó...

Perdon la demora en contestar ...
Eso me da un poco de miedo, pues en un new MiClase; cuanta memoria se reserva? ni te cuento en un MiClase[3000]. Si bien las declaraciones de funciones no tienen problema, no se quien dice cuanta memoria tiene un objeto (el constructor?) o si es legal declarar dos clases con distintas con mismo nombre, no tengo la menor idea de esto, pero era el camino que me gustaria tomar ... alguien sabe algo de esto? deberia ser un fanatico religioso del C++ ...

Cual es la razón para querer ocultar una variable? que el coder no pueda cambiarla de propiedad y mangarla ?

Eso se arreglaria con un private, pero en realidad la idea seria dejar algo mas claro para el usuario de la lib ya que no le interesa como haces tu para hacerlo y a la vez proteger tus secretos  ... así como tambien solo tener que actualizar el .h cuando halla un cambio que al usuario le interese, no por un cambio interno.
Inclusive todo esto ayudaria a la portabilidad.
Ejemplo:

Código [Seleccionar] Expand

class TPantalla {
 hInstance hinst;
 hWND hwnd;
 DDrawInterface *DDraw;
 Crear_Ventana();
 Crear_DDraw();
public:
     TPantalla(int x, int y, int bpp);
     ~TPantalla();
};

Ahora si yo le doy un

Código [Seleccionar] Expand

class TPantalla {
public:
     TPantalla(int x, int y, int bpp);
     ~TPantalla();
};
Al tipo le sentaria mucho mejor, no te parece?

Saludos.

[zupervaca]

 cada vez que veo ddraw me da vueltas la cabeza jeje

en mi practica con librerias de c++ siempre hay una funcion global o que pertenece a otra clase que nos devuelve la clase creada solucionando el problema que mencionas, un ejemplo de ello se ve en direct3d, siempre que quieres crear un objeto com le pasas un puntero y el te crea el objeto, de esta forma el usuario tendra solo acceso a los miembros que pongas en el .h que le des, pero estaras creando correctamente el objeto ya que lo hace tu libreria, espero que se entienda lo que quiero decir ;)

[_Grey]

 

Pero entonces es mas facil tener una clase virtual y una clase interface ...

De ti depende, pero con la clase proxy, mantienes el funcionamiento de objeto normal que no tendrias con una interface. Ademas puedes meter las funciones de la clase proxy como inline :P .

una cosa, y simplemente borrando lo que no quieres que se vea del .h para el usuario??
yo en mi libreria LTML, simplemente borré las variables miembro de las clases y dejé
los métodos y me funcionó...

Seguro que funciona, pero entramos en el pantanoso terreno de sin documentar.... casi me extrañaria que fallara pero no lo podriamos descartar, algun experto en el estandard ISO podria ayudar....  :rolleyes:

Cual es la razón para querer ocultar una variable? que el coder no pueda cambiarla de propiedad y mangarla ?

Ademas de ocultar las funciones de "utileria" que te has hecho, tanto para que no se metan en tu codigo, como para que no pongan como public, algo que podria romper el funcionamiento del objeto.

[Pogacha]

 

Pero entonces es mas facil tener una clase virtual y una clase interface ...

De ti depende, pero con la clase proxy, mantienes el funcionamiento de objeto normal que no tendrias con una interface. Ademas puedes meter las funciones de la clase proxy como inline :P .

Pero igual así requiere de un trabajo muy extra ya que cada función la tengo que poner 2 veces y no me gusta para nada ...

Como interface y virtual me referia a :

Código [Seleccionar] Expand

class TInterface
{
  public:
      TPantalla *Crear_Pantalla(int x,int y,int bpp);
};

class TPantalla
{
    TPantalla();
public:
     virtual ~TPantalla();
     virtual Todas las otras funciones;
};

Habria que investigar la solución de ShAq que es por lejos la mas interesante ...
Los experimentos serian

Código [Seleccionar] Expand

proyecto pp.lib:
pp.cpp
class PP {
  int p
 public:
   pp();
   static int sgetp();
   int getp();
};
pp:pp() { p=sizeof(PP); };
int pp:sgetp() { return sizeof(PP); };
int pp:getp() { return p; };

proyecto nuevo
main.cpp
#pragma lib pp.lib
class PP {
 public:
  pp();
  static int sgetp();
  int getp();
};

void main(){
  printf("%d %d %d\n", sizeof(PP), PP::sgetp(), p.getp());
} No tengo un compilador aca para probar ... pero incluso si todo esto resultara bien, no estoy seguro de que como andará en todo momento ( en debug en release, en otro compilador) ... la mayor pregunta es ¿dónde dice cuanta memoria se debe reservar?, ¿en el constructor? pues de ser así no habria problemas ... ahora con un PP p[3000]; ¿se seguiría manteniendo el sizeof adecuadamente? ¿En todos los compiladores esto anda?

Si alguien sabe algo ...
Saludos y gracias