Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / Managed C++ / March 2007

Tip: Looking for answers? Try searching our database.

basic_fstream and large files

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Eric Twietmeyer - 27 Mar 2007 01:41 GMT
Hello,

I have code written using the basic fstream object on a Win32 system.  This
is of course simply a typedef for basic_fstream<char, char_traits<char> >.

This object can not be used to write or read files that are larger than 2Gb
in size, as it would appear (from looking at the iosfwd header) that the
underlying streamoff and streamsize types are typedef'd to long and int. On
Win64 systems, these are typedef'd to __int64, so it seems that on Win64
systems fstream can in fact be used to read and write large files.

However, is there a way I can define a new type and define a char_traits for
this type so that I can use basic_fstream to read and write large files on
Win32?  Looking into the std c++ iostream headers, it is not clear that this
is in fact doable, as many things seem to depend on these basic streamoff
and streamsize typedefs, which are not mutable in my own class.

I would like to know whether I am reading this correctly, or whether people
have had success in doing this, i.e. creating a char_traits type that when
used with basic_fstream will allow for large (>2Gb) file reading and
writing.

Thanks,

-Eric Twietmeyer

(MSDN no-spam alias: MSDNNospam170@nospam.nospam)
Bo Persson - 27 Mar 2007 17:06 GMT
:: Hello,
::
[quoted text clipped - 20 lines]
:: type that when used with basic_fstream will allow for large (>2Gb)
:: file reading and writing.

You CAN read and write larger files, as long as you do it sequentially. The
size of streamoff limits the amount of positioning you can do. Do you really
do seeks with offsets >2GB?

Bo Persson
Eric Twietmeyer - 28 Mar 2007 00:52 GMT
> :: Hello,
> ::
[quoted text clipped - 26 lines]
>
> Bo Persson

Yes, unfortunately, I do in fact need to be able to offset in the stream to
locations greater than 2Gb from the current point.

I'm also just curious how one may specialize the basic stream / buf objects
using different char_traits, whether that is actually doable given this
implementation provided with DevStudio, or whether it is expected that only
char_traits<char> and char_traits<wchar_t> would be used, and no others.

-Eric
Bo Persson - 28 Mar 2007 18:16 GMT
::: Eric Twietmeyer wrote:
::::: Hello,
[quoted text clipped - 30 lines]
:: Yes, unfortunately, I do in fact need to be able to offset in the
:: stream to locations greater than 2Gb from the current point.

Too bad.

The Band-Aid solution is to do multiple seeks, 2 GB at a time. Works for
moderate file sizes.

:: I'm also just curious how one may specialize the basic stream / buf
:: objects using different char_traits, whether that is actually doable
:: given this implementation provided with DevStudio, or whether it is
:: expected that only char_traits<char> and char_traits<wchar_t> would
:: be used, and no others.

It is possible, but hard. It will probably not help you here, anyway.

Eventually, all the seeks will probably come down to a C level fseek(),
which also takes a long parameter. The real solution is to have a 'long'
type that is actually sort-of-long, and not just a different name for 'int'.
A bit late for that now, unfortunately.

Bo Persson

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.