Boost logo

Boost :

From: Nick_at_[hidden]
Date: 2002-03-19 11:26:31

IMHO, Boost should have a set of efficient OS specific file copy functions
with a "wrapper" to call the function for whatever OS is being used. Of
course, there should be an efficient portable function also....

----- Original Message -----
From: "Brey, Edward D" <EdwardDBrey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, March 19, 2002 7:12 AM
Subject: RE: [boost] Remarkably efficient file copy

> All this talk of efficiency of byte-orientated file copying mechanisms in
> platform-specific realms (e.g. memory mapped I/O) seems out of place to
> Why would one not map onto the high level operating system calls to copy a
> file, e.g. CopyFile in Win32? Besides being presumably the most
> it is often the only correct choice. The Win32 documentation spells out
> copying a file by creating a new file and manually moving over the
> as bad practice, because doing so can defeat higher-level operating system
> functionality such as encryption.
> For the fallback, portable implementation, which is untweaked for any
> platform, of course, the stream buffer technique is very nice. But for
> platform-tailored code, it generally makes sense to tie into the OS at the
> highest level possible.
> -----Original Message-----
> From: Fedder Skovgaard [mailto:fsk_at_[hidden]]
> Sent: Tuesday, 19 March 2002 6:57 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Remarkably efficient file copy
> Hi,
> I think it's a viable route to take. Nicolai Josuttis writes: "This is
> probably the fastest way to copy files by using C++ I/O streams."
> See"The C++ standard Library" (ISBN 0201379260) Chapter 13.14.3.
> You should, obviously be able to get better performance by using platform
> specific calls and technologies (such as Asynchroneous IO and Memory
> files on Win32).
> But the point lies (in my perspective) in the subphrase "by using C++ I/O
> streams". Most operating systems also sports memory management routines
> that out-perform new / delete for specific purposes, but that doesn't mean
> that new / delete is a bad thing.
> Just my two cents.
> Fedder
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at