Re: [boost] Remarkably efficient file copy

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
me.
> 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
efficient,
> 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
contents
> 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
given
> 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
mapped
> 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:
http://lists.boost.org/mailman/listinfo.cgi/boost