2010-01-29 9 views
19
class Help 
{ 
public: 
     Help(); 
     ~Help(); 

     typedef std::set<string> Terms; 
     typedef std::map<string, std::pair<int,Terms> > TermMap; 
     typedef std::multimap<int, string, greater<int> > TermsMap; 

private: 

     TermMap terms; 
     TermsMap termsMap; 
}; 

¿Cómo podemos encontrar la memoria utilizada (en bytes) por los objetos y termtermsMap. ¿Tenemos alguna biblioteca?Cómo encontrar la memoria utilizada por cualquier objeto

Respuesta

-1

el operador sizeof() debería hacerlo:

size_t bytes = sizeof(Help::TermMap); 
+5

'sizeof' es un operador, no una función. –

+1

@Carl Norum: está bien. ¡Gracias por el recordatorio! –

+1

Hmm. Esto no parece funcionar, por dos razones: los miembros son privados, y no se le permite tomar el tamaño de una variable miembro no estática. ¡Interesante! –

1

Si usted está buscando para el bloque actual de la memoria, el valor numérico de un puntero a ella debe ser la misma. (Entonces solo agrega el número de bytes, y tienes el final del bloque).

12

Si está buscando el uso total de la memoria de un objeto, esto no se puede resolver en general en C++ - mientras que podemos obtener el tamaño de una instancia a través del sizeof(), el objeto siempre puede asignar memoria dinámicamente según sea necesario .

Si usted puede averiguar cuán grande es el elemento individual en un contenedor son, se puede obtener una cota inferior:

size = sizeof(map<type>) + sum_of_element_sizes; 

Tenga en cuenta sin embargo que los recipientes todavía pueden asignar memoria adicional como un detalle de implementación y que para contenedores como vector y string debe verificar el allocated size.

+0

Considere eso como una subestimación aproximada. En muchos casos, al igual que con los mapas, el STL debe contener otras cosas (el mapa es un árbol equilibrado, por lo que necesitará al menos tres punteros (izquierda, derecha, padres - padres para garantizar una iteración rápida del iterador) y alguna forma de mantener la información para el saldo invariable, probablemente un valor extra (entero, byte de color) ... y el tamaño del elemento tiene que considerar tanto la clave como el valor. –

+0

David, lo cambió a * límite inferior * para hacerlo más claro, el resto debería ser cubierto por * detalles de implementación *. –

7

Respuesta corta: No

respuesta Largo:
-> El objeto básico sí. sizeof (<TIPO>) pero esto solo es útil para cosas limitadas.
-> un recipiente y sus miembros contenían: NO

Si hace suposiciones sobre las estructuras utilizadas para implementar estos objetos se puede estimar la misma. Pero incluso eso no es realmente útil (aparte del caso muy específico del vector).

Los diseñadores de la STL deliberadamente no definieron las estructuras de datos que deberían usar estos contenedores. Hay varias razones para esto, pero una de ellas (en mi opinión) es evitar que las personas hagan suposiciones sobre las partes internas y, por lo tanto, intentar hacer cosas tontas que no estén encapsuladas por la interfaz.

Entonces, la pregunta se reduce a por qué necesita saber el tamaño?
¿De verdad necesita saber el tamaño (poco probable pero posible).

¿O hay una tarea que intentas lograr donde crees que necesitas el tamaño?

8

¿Cómo podemos encontrar la memoria utilizada (en bytes) por el término objetos y termsMap. ¿Tenemos alguna biblioteca?

Debe usar su propio tipo de asignador.

typedef std::set<string, 
    your_allocator_1_that_can_count_memory_consumption_t> Terms; 

typedef std::map<string, std::pair<int,Terms>, 
    your_allocator_2_that_can_count_memory_consumption_t> TermMap; 

typedef std::multimap<int, string, greater<int>, 
    your_allocator_3_that_can_count_memory_consumption_t> TermsMap; 

que aún no han comprobado esta idea para std :: string lo que si es difícil de poner en práctica sólo tiene que utilizar su propio fixed_string clase que simplemente se envuelve s char [-serie-máx Longitud].

Y cuando se necesita en su programa para averiguar el consumo de memoria acaba de obtener de your_allocator_1_that_can_counts_memory_consumption_t, your_allocator_2_that_can_counts_memory_consumption_t, your_allocator_3_that_can_counts_memory_consumption_t.

Editado

Para UncleBens quiero aclarar mi punto.

Por lo que entiendo por la cuestión del ARV, es necesario saber cuánta memoria se asigna para set :: set y std :: map, incluida toda la memoria asignada para los elementos del conjunto y el mapa. Entonces no es solo sizeof (términos).

Así que acabo de sugerir un asignador muy simple. Sin entrar en demasiados detalles que podría tener este aspecto:

template <class T> 
class your_allocator_1_that_can_counts_memory_consumption_t { 
public: 
    // interfaces that are required by the standart 
private: 
    std::allocator<T> std_allocator_; 
    // here you need to put your variable to count bytes 
    size_t globale_variable_for_allocator_1_to_count_bytes_; 
}; 

Este asignador simplemente cuenta el número de bytes asignados y desasignado y para la asignación real y cancelación de asignación utilice su std_allocator_ miembro. Necesitaría depurarlo bajo gdb para establecer un punto de interrupción en malloc() y en free() para asegurarme de que cada asignación y desasignación en realidad pasan por mi asignador.

Estaría agradecido si me señala algunos problemas con esta idea ya que ya la he implementado en mi programa que se ejecuta en Windows, Linux y HP-UX y simplemente pregunto mis asignaturas para encontrar cuánta memoria cada uno de mis contenedores usa

+1

Sospecho que a menos que su asignador use algunas rutinas de asignación muy específicas del sistema operativo, no podrá decir el uso de la memoria incluso entonces. Si no me equivoco, si su código contiene algo como de alto nivel como 'malloc (n);' aún podría estar completamente definido por la implementación cuánta memoria realmente se "agotó". – UncleBens

+0

Ver la parte editada. –

+0

Un punto más acerca de 'podría ser implementado por completo ación definió cuánta memoria realmente se "agotó". Eso es verdad. Por ejemplo, en HP-UX cuando solicita 5 bytes, a veces se asignan 16 bytes, ya que libc se preocupa por la fragmentación de la memoria. Sin embargo, también recibo información de HP-UX/Linux sobre la cantidad de memoria asignada a un proceso. Como resultado, sé que el consumo real de memoria es mayor. Por cierto, ARV no dijo que quería saber el consumo exacto de memoria de los contenedores, incluido lo que podría ser agregado por una libc. –

Cuestiones relacionadas