From: Knut-Håvard Aksnes (knut_at_[hidden])
Date: 2000-03-01 02:47:22
Andreas Scherer writes:
> beman dawes <bema-_at_[hidden]> wrote:
> > So it really isn't something we can fix by changes in our files by
> > picking one of the native formats and converting everything to that
> > format.
> The problem is not that <smart_ptr.hpp> (and possibly other files in
> the boost archive as well) is in one of the native formats (say Unix
> versus Win32); the problem in this particular case is that
> <smart_ptr.hpp> is in a _mixed_ file format. The last time I looked
> (must have been version 1.11), one line in a multiline macro definition
> had the "wrong" eof character(s), so the preprocessor of gcc hickups.
> Apart from multiline macros, gcc on Unix/Linux is perfectly happy with
> "native Win32" source files, just as, e.g., MSVC deals fine with
> "native Unix" source files.
Thats exatly the point, unzip -a usually does a good job in
conversting between Microsoft and unix conventions, in this case I
suspect that the files have been edited on Mac's. The \r endings
persisted after unziping with the -a option.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk