STL::fstream or ATL::CAtlFile? 
Author Message
 STL::fstream or ATL::CAtlFile?

Just wondering is there any advantage in CAtlFile?

David Bell



Tue, 28 Jun 2005 04:17:30 GMT  
 STL::fstream or ATL::CAtlFile?
CAtlFile is a very thin wrapper around HANDLE and Win32 file
manipulation APIs such as ReadFile and WriteFile. As a result:

- it is not restricted to disk files, but to any device you can open a
HANDLE on, with full range of options available in CreateFile (e.g.
sharing or overlapped I/O)
- it has no dependencies on CRT
- it does not rely on C++ extensions

- it only provides low-level binary I/O, no text formatting
- it's not portable

Essentially, its only advantage over just going ahead and using raw API
is RAII - CAtlFile destructor calls CloseHandle on the underlying
HANDLE.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken



Quote:
> Just wondering is there any advantage in CAtlFile?



Tue, 28 Jun 2005 06:07:59 GMT  
 STL::fstream or ATL::CAtlFile?
Thank you . I'm using CRT anyway, but I'll think about it. Is CAtlFile
thread-safe?

David Bell


Quote:
> CAtlFile is a very thin wrapper around HANDLE and Win32 file
> manipulation APIs such as ReadFile and WriteFile. As a result:

> - it is not restricted to disk files, but to any device you can open a
> HANDLE on, with full range of options available in CreateFile (e.g.
> sharing or overlapped I/O)
> - it has no dependencies on CRT
> - it does not rely on C++ extensions

> - it only provides low-level binary I/O, no text formatting
> - it's not portable

> Essentially, its only advantage over just going ahead and using raw API
> is RAII - CAtlFile destructor calls CloseHandle on the underlying
> HANDLE.
> --
> With best wishes,
>     Igor Tandetnik

> "For every complex problem, there is a solution that is simple, neat,
> and wrong." H.L. Mencken



> > Just wondering is there any advantage in CAtlFile?



Tue, 28 Jun 2005 17:00:24 GMT  
 STL::fstream or ATL::CAtlFile?

As thread-safe as underlying API. All its methods are one-liners that
just call a corresponding API function. The class itself does not
synchronize any calls.
--
With best wishes,
    Igor Tandetnik

"For every complex problem, there is a solution that is simple, neat,
and wrong." H.L. Mencken



Quote:
> Thank you . I'm using CRT anyway, but I'll think about it. Is CAtlFile
> thread-safe?



> > CAtlFile is a very thin wrapper around HANDLE and Win32 file
> > manipulation APIs such as ReadFile and WriteFile. As a result:

> > - it is not restricted to disk files, but to any device you can open
a
> > HANDLE on, with full range of options available in CreateFile (e.g.
> > sharing or overlapped I/O)
> > - it has no dependencies on CRT
> > - it does not rely on C++ extensions

> > - it only provides low-level binary I/O, no text formatting
> > - it's not portable

> > Essentially, its only advantage over just going ahead and using raw
API
> > is RAII - CAtlFile destructor calls CloseHandle on the underlying
> > HANDLE.
> > --
> > With best wishes,
> >     Igor Tandetnik

> > "For every complex problem, there is a solution that is simple,
neat,
> > and wrong." H.L. Mencken



> > > Just wondering is there any advantage in CAtlFile?



Tue, 28 Jun 2005 22:33:08 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. ATL conflict between VC 7 STL and SGI STL - how to resolve

2. bug in fstream? (works with fstream.h)

3. fstream ./. fstream.h

4. ATL and STL, any problems?

5. ATL and STL

6. STL, MFC, ATL

7. ATL and STL/CRT...

8. STL+ATL = link error in release version!?!

9. ATL wrapping STL collection

10. Using STL within ATL

11. Newbie question: How To Make a map (stl or ATL) with BSTRs

12. Q)Using stl map in an Atl project...

 

 
Powered by phpBB® Forum Software