2008-11-16 14 views
16

का उपयोग कर 4 जीबी से बड़ी फ़ाइलों को पढ़ना कुछ हफ्ते पहले मैं कुछ फ़ाइलों में पढ़ने के लिए std :: ifstream का उपयोग कर रहा था और यह तुरंत खुलने में विफल रहा क्योंकि फ़ाइल 4 जीबी से बड़ी थी। उस समय मुझे एक सभ्य उत्तर नहीं मिला क्योंकि यह 32 बिट फ़ाइलों के आकार तक सीमित क्यों था, इसलिए मैंने मूल ओएस एपीआई का उपयोग करके अपना खुद का लिखा।C++ stl

तो, मेरे सवाल तो: वहाँ एक रास्ता का उपयोग कर std :: ifstream/std :: ostream आकार में 4GB से अधिक फ़ाइलों को संभालने के लिए है (आईई: मानक C++)

संपादित करें: से एसटीएल कार्यान्वयन का उपयोग करना वीसी 9 कंपाइलर (विजुअल स्टूडियो 2008)। EDIT2: निश्चित रूप से 4 जीबी से बड़े आकार के फ़ाइल आकार का समर्थन करने के लिए मानक तरीका होना चाहिए।

+0

एसटीएल इस प्रश्न के लिए विशेष रूप से प्रासंगिक नहीं है; इसे हटा दो? मैं सुझाव दूंगा कि iostreams उस सी ++ मानक लाइब्रेरी के हिस्से का नाम है जिसके बारे में आप बात कर रहे हैं। – Alastair

+0

एलिस्टेयर के रूप में पुनः प्रयास किया गया। और उत्तर देने के लिए, मानक कुछ भी नहीं कहता है कि बड़ी फ़ाइलों को कैसे समर्थित किया जाना चाहिए, या कितना बड़ा आकार_ होना चाहिए।यह पूरी तरह कार्यान्वयन-परिभाषित है। तो आप किस कार्यान्वयन का उपयोग कर रहे हैं? – jalf

+0

प्रश्न के शीर्षक को भी संपादन की आवश्यकता है। –

उत्तर

13

स्पष्ट रूप से यह इस बात पर निर्भर करता है कि लाइब्रेरी द्वारा off_t लागू किया गया है।

#include <streambuf> 
__int64_t temp=std::numeric_limits<std::streamsize>::max(); 

आपको वर्तमान अधिकतम क्या देता है।

STLport बड़ी फ़ाइलों का समर्थन करता है।

5

कई वर्षों पहले मैंने लिनक्स पर जीसीसी का उपयोग करके इस समस्या में भाग लिया था। ओएस ने बड़ी फाइलों का समर्थन किया, और सी लाइब्रेरी (फॉपेन, आदि) ने इसका समर्थन किया, लेकिन सी ++ मानक लाइब्रेरी नहीं थी। मैंने बताया कि मुझे सही कंपाइलर झंडे का उपयोग कर सी ++ मानक पुस्तकालय को दोबारा बनाना था।

+1

मैं आपके साथ कीथबी हूं, इसमें एमएसवीसी/एसटीएल या अन्य की किसी भी समस्या के साथ _NOTHING_ todo है, यह एक सिस्टम परिनियोजन मुद्दा है। सीआरटी/एसटीएल पुस्तकालयों के लिए स्रोत कोड किसी कारण के लिए कंपाइलर के साथ शामिल किया गया है, आपको अपनी वांछित कार्यक्षमता प्राप्त करने के लिए एप्रोपिएट प्रीप्रोसेसर मैक्रो को परिभाषित करने की आवश्यकता हो सकती है। यह नहीं है कि लाइब्रेरी प्रवर्तन एक या दूसरा (उदा। * 32 बिट फाइलों के आकार के लिए fgetpos या fgetpos64 का उपयोग कर nix), लाइब्रेरी दोनों का समर्थन करता है, यह पुस्तकालय का उचित उपयोग करने के लिए डेवलपर पर निर्भर करता है। एसटीएलपोर्ट का उपयोग एमएसवीसी एसटीएल के किसी भी तरह के पुनर्मूल्यांकन के समान है, दोनों में मैन्युअल ट्वीक्स – RandomNickName42

2

मानक बिंदु से, ऐसा कुछ भी नहीं है जो इसे रोकता है। हालांकि, हकीकत में, अधिकांश 32 बिट कार्यान्वयन std::size_t के लिए 32 बिट का उपयोग करते हैं। अब, सी ++ मानक अनिवार्य है कि सी ++ मानक पुस्तकालय में मानक आवंटक आकार मात्रा के रूप में std :: size_t का उपयोग करता है। इस प्रकार, आप कंटेनरों, तारों और सामानों के लिए भंडारण के 2^32 बाइट तक सीमित हैं। स्थिति std::off_t के लिए एक और हो सकती है, मुझे नहीं पता कि वहां क्या हो रहा है।

आपको मानक पुस्तकालय कार्यान्वयन पर भरोसा किए बिना, इसे करने में सक्षम होने के लिए, ओएस के मूल एपीआई का उपयोग सीधे करना होगा, या कुछ पुस्तकालय इसे लपेटना होगा, जो बड़े पैमाने पर कार्यान्वयन-निर्भर हैं।

+0

शामिल हैं, मैंने ओएस एपीआई को सीधे उस मामले के लिए लपेट लिया जहां मेरा फ़ाइल आकार 4 जीबी से बड़ा था – Raindog

0

यदि आप अपने आप को केवल मानक सी ++ का उपयोग करने से दूर ले जा सकते हैं, तो आपको boost::iostreams में रुचि हो सकती है।

0

कम से कम वीएस2013 में, सी ++ मानक फाइलस्ट्रीम बड़ी फ़ाइलों (> 4GBytes) के साथ अच्छी तरह से काम करता है।

मैंने वीएस2013 (अद्यतन 3 के साथ) पर परीक्षण किया। https://connect.microsoft.com/VisualStudio/feedback/details/627639/std-fstream-use-32-bit-int-as-pos-type-even-on-x64-platform

छोटे के लिए

:

int64_t file_pos = 4LL * 1024 * 1024 * 1024 + 1; 
file.seekp(file_pos, SEEK_SET); 
assert(file); 
cout << "cur pos: " << file.tellp() << endl; // the output is: 4294967297(4GB + 1) 

नीचे दिए गए लिंक एक अतिरिक्त पुष्टि है कि यह एक बग है और है निर्धारित किया गया है स्टीफ़न टी Lavavej (विजुअल C++ पुस्तकालय डेवलपर) ने कहा

हमने इसे ठीक कर दिया है, और फिक्स वीसी 11 में उपलब्ध होगा ... इसलिए बड़ी फ़ाइल समर्थन सही ढंग से काम करनी चाहिए (x86/x64 प्लेटफ़ॉर्म पर ध्यान दिए बिना)