2013-04-03 11 views
5

Zuerst werde ich die Domain mit Quelle umreißen.Boost interprocess allocator - Dateigröße verwalten

namespace bip=boost::interprocess; 

typedef bip::allocator<int, bip::managed_mapped_file::segment_manager> allocator; 
typedef bip::vector<int, allocator> vector; 

bip::managed_mapped_file m_file(open_or_create, "./file", constant_value);  
bip::allocator alloc(m_file.get_segment_manager()); 
bip::vector *vec = m_file.find_or_construct<vector>("vector")(alloc); 

Ich interessiere mich nicht für die endgültige Größe einer zugrunde liegenden Datei, aber ich kann diesen Wert nicht voraussehen. Gibt es einen Boost-Mechanismus, mit dem die Größe einer zugrunde liegenden Datei angepasst werden kann? Oder muss ich bip :: bad_alloc fangen und mich darum kümmern?

Antwort

6

Lesen Sie diese this section der Dokumentation.

Sie haben die statische Member-Funktion grow(), die, was Sie brauchen könnten:

bip::managed_mapped_file::grow("./file", extra_bytes); 

Aber Sie müssen sicher sein, dass niemand die Datei verwendet, das ist, warum sie es off-line wachsenden nennen. Und das ist je nach Problem nicht möglich.

+0

Oh. So einfach. Ich muss zugeben, dass ich nach der Lösung ähnlicher Probleme direkt auf POSIX mmap und der Verwendung von Boost IOstreams pokerte. Siehe z. B. diese Antwort [wie eine Zeile mit einer anderen in C++ ausgetauscht wird] (http://stackoverflow.com/a/17374711/85371). Ich frage mich, wie sie es implementiert haben, um tragbar zu sein. – sehe