Initialisation d'un objet constant global de grande taille

Question

Comment utiliser un fichier pour initialiser un objet const global trop grand pour être créé dans la pile? Ceci est ma tentative à ce jour:

// test.h 
#pragma once 
#include <boost/array.hpp> 

typedef boost::array<int,100000> bigLut_t; 
extern const bigLut_t constLut; 

---

// test.cpp 
#include <fstream> 
#include <boost/filesystem.hpp> 
#include "test.h" 

bigLut_t& initializeConstLut() 
{ 
    if(boost::filesystem::exists("my_binary_file") == false) { 
     std::ofstream outStream("my_binary_file", ios::out | ios::binary); 
     bigLut_t* tempLut = new bigLut_t; 
     for(int i = 0; i < 100000; ++i) { 
      // Imagine this taking a long time, 
      // which is why we're using a file in the first place 
      tempLut->at(i) = i; 
     } 
     outStream.write(reinterpret_cast<char*>(tempLut), sizeof(bigLut_t)); 
     outStream.close(); 
     delete tempLut; 
    } 
    // We can't write "bigLut_t lut;" because that would cause a stack overflow 
    bigLut_t* lut = new bigLut_t; // lut gets never deallocated 
    std::ifstream inStream("my_binary_file", ios::in | ios::binary); 
    inStream.read(reinterpret_cast<char*>(lut), sizeof(bigLut_t)); 
    inStream.close(); 
    return *lut; 
} 

const bigLut_t constLut = initializeConstLut(); 

cela fonctionne dans AFAIK un sens qui se constLut corretly initialisé, mais il y a une fuite de mémoire depuis bigLut_t * LUT ne fait jamais désallouée. J'ai essayé d'utiliser un pointeur intelligent pour cela, mais cela a abouti à des valeurs dans constLut étant tout à fait aléatoire. Je suis déconcerté par le manque d'information que j'ai trouvé en essayant de google la solution.

Answer 1

Comment avez-vous utilisé shared_ptr? Effectuez les opérations suivantes:

// test.h 
#pragma once 
#include <boost/array.hpp> 

typedef boost::array<int,100000> bigLut_t; 
extern const bigLut_t constLut; 

---

// test.cpp 
#include <fstream> 
#include <boost/filesystem.hpp> 
#include "test.h" 

boost::shared_ptr<bigLut_t> initializeConstLut() 
{ 
    if(boost::filesystem::exists("my_binary_file") == false) { 
     std::ofstream outStream("my_binary_file", ios::out | ios::binary); 
     bigLut_t* tempLut = new bigLut_t; 
     for(int i = 0; i < 100000; ++i) { 
      // Imagine this taking a long time, 
      // which is why we're using a file in the first place 
      tempLut->at(i) = i; 
     } 
     outStream.write(reinterpret_cast<char*>(tempLut), sizeof(bigLut_t)); 
     outStream.close(); 
     delete tempLut; 
    } 
    // We can't write "bigLut_t lut;" because that would cause a stack overflow 
    boost::shared_ptr<bigLut_t> lut(new bigLut_t); // lut gets never deallocated 
    std::ifstream inStream("my_binary_file", ios::in | ios::binary); 
    inStream.read(reinterpret_cast<char*>(lut), sizeof(bigLut_t)); 
    inStream.close(); 
    return lut; 
} 

const bigLut_t constLut = *(initializeConstLut().get()); 

Answer 2

Il y a une ligne de pensée qui dit que les objets connus ne fuient pas, si la seule fuite est à la fin de la vie de l'application. Si tout ce que vous faites avec l'objet est de le retirer de la mémoire (et de ne pas libérer d'autres ressources, ni de mettre à jour des éléments externes comme les DB et les fichiers), vous pouvez simplement le laisser là. Après tout, en les supprimant explicitement de la mémoire, vous bloquez simplement la fin de l'application sans réel bénéfice: la mémoire sera libérée dans un sens ou dans l'autre.

Answer 3

Ajoutez une destruction explicite du lut. Vous êtes responsable de détruire tout ce que vous créez. Le mieux est de le faire explicitement:

void destroyLut(bigLut_t& lut) 
    { 
     delete &lut; 
    } 

Ensuite, il suffit appeler cette fonction avant de quitter main. Vous ne devriez jamais compter sur l'initialisation statique et la destruction en C++. Mieux vaut toujours faire une initialisation et une destruction explicites.

Answer 4

Ne serait-il plus facile de simplement faire de votre objet global un pointeur, new un objet temporaire initializeConstLut et définissez le pointeur global à cet objet avant de quitter la fonction ?

Si l'objet est trop grand, vous devez éviter toute solution impliquant une copie et/ou une affectation. Donc, vous vous retrouvez avec plusieurs choix:

• Faire l'objet global un pointeur (copie)
• Faire l'objet global non-const et lire directement dans ce
• Je ne peux pas croire que je » Je dis cela, mais utilise un motif Singleton comme et enveloppe l'objet. Cela vous permettra d'isoler l'initialisation et de fournir une méthode publique d'accès qui retournera une référence const au tableau.

Je n'ajoute pas beaucoup de détails ici parce que cela dépend vraiment de vos besoins (je pense à la sécurité des threads par exemple).

Answer 5

juste le faire à l'ancienne est très bien - créer un pointeur automatique dont le cycle de vie est le cycle de vie de l'application entière, et une référence externe au pointeur:

// test.h 
#pragma once 
#include <boost/array.hpp> 

typedef boost::array<int,100000> bigLut_t; 
extern const bigLut_t& constLut; // make it a reference 

// test.cpp 
#include <fstream> 
#include <boost/filesystem.hpp> 
#include "test.h" 

namespace { 
    std::auto_ptr<bigLut_t> initializeConstLut() 
    { 
     std::auto_ptr<bigLut_t> lut(new bigLut_t); 

     if(boost::filesystem::exists("my_binary_file") == false) { 
      std::ofstream outStream("my_binary_file", ios::out | ios::binary); 

      for(int i = 0; i < 100000; ++i) { 
       // Imagine this taking a long time, 
       // which is why we're using a file in the first place 
       lut->at(i) = i; 
      } 

      outStream.write(reinterpret_cast<char*>(lut), sizeof(bigLut_t)); 
      outStream.close(); 

      // no point writing then reading the same data 
     } else {    
      std::ifstream inStream("my_binary_file", ios::in | ios::binary); 
      inStream.read(reinterpret_cast<char*>(lut.get()), sizeof(bigLut_t)); 
      inStream.close(); 
     } 

     return lut; 
    } 

    // local to this compilation unit, deletes object on exit 
    std::auto_ptr<bigLut_t> constLutPtr (initializeConstLut()); 
} 

// the extern reference refers to the object held by the auto_ptr 
const bigLut_t& constLut (*constLutPtr.get()); 

Pas de copie supplémentaire, code client voit la variable externe comme précédemment, bien que le linker puisse avoir une indirection supplémentaire plutôt que la variable externe étant dans une adresse fixe (& constLutPtr est sur le tas plutôt que dans la zone de données statiques).

Si avoir une adresse fixe pour constLut est important, revenez à avoir une valeur externe plutôt qu'une référence externe, lisez les données en utilisant une distribution de réinterprétation et une const_cast de & constLutPtr. passez reinterpret_cast<char*>(const_cast<bigLut_t*>(&constLut)) au flux lu.

Answer 6

Il existe plusieurs bonnes solutions à votre problème. Les solutions proposées comme réponses ne sont pas parmi les bonnes solutions (en particulier, l'allocation dynamique et la copie et en s'appuyant sur la durée de vie des objets temporaires est juste très mauvais ™). Je vais juste vous donner une solution commune.

Une façon simple de fournir une grande constante est d'utiliser un Meyers de singleton, ce qui signifie définir la constante comme une variable locale static dans une fonction qui renvoie une référence à elle:

inline BigThing const& theBigThing() 
{ 
    static BigThing const theInstance; // Default constructor does the init job. 
    return theInstance; 
} 

Cette est pas encore une solution complète, mais nous allons d'abord voir comment vous pouvez vous débarrasser d'avoir à invoquer une fonction, et de traiter au lieu directement avec ce que-look-like-a-constante:

namespace detail { 
    inline BigThing const& theBigThing() 
    { 
     static BigThing const theInstance; // Default constructor does the init job. 
     return theInstance; 
    } 
} 

BigThing const& theBigThing = detail::theBigThing(); // No copying, just ref. 

Dans votre cas où BigThing est un tableau qui doit être initialisé à partir des données d'un fichier, vous ne pouvez pas compter directement sur le constructeur par défaut. Vous pourriez si vous avez défini une classe wrapper, et c'est un moyen. OK, nous allons faire cela (c'est ce que je choisirais, je pense):

namespace detail { 

    struct BigThingWrapper 
    { 
     BigThing thingy_; 

     BigThingWrapper() 
     { 
      // Initialize the thingy_ member here. 
     } 
    }; 

    inline BigThing const& theBigThing() 
    { 
     static BigThingWrapper const theInstance; 
     return theInstance.thingy_; 
    } 
} 

BigThing const& theBigThing = detail::theBigThing(); // No copying, just ref. 

Note 1: Je l'ai utilisé inline afin que le code pourrait en théorie être placé dans un fichier d'en-tête. Supprimez simplement l'implémentation placée dans un fichier d'implémentation.

Remarque 2: Ce code n'est pas touché par les mains du compilateur et peut donc contenir ERORS, TYPPOS et autres commandes. :-) Mais c'est l'idée qui est ta réponse.

Note 3: Il y a, comme mentionné, d'autres bonnes manières de le faire, donc ce n'est pas "la" réponse, et il n'y a pas de "la" réponse, mais c'est "une" réponse.

Vive & HTH.,