But it would Re: [gil] [announcement] New IO lib
But it would introduce the dependency to boost::filesystem
That would be a show-stopper for shur. I definately could not use your IO library if it had a boost::filesystem dependency. PLEASE - keep it header only.
Tom Brinkman wrote:
But it would introduce the dependency to boost::filesystem
That would be a show-stopper for shur. I definately could not use your IO library if it had a boost::filesystem dependency. PLEASE - keep it header only.
I have no interest in boost::filesystem or gil. Just trying to understand your requirement for being header-only: You *want* to compile the same code over and over rather than just once? -- Sohail Somani http://uint32t.blogspot.com
Sohail Somani wrote:
Tom Brinkman wrote:
But it would introduce the dependency to boost::filesystem
That would be a show-stopper for shur. I definately could not use your IO library if it had a boost::filesystem dependency. PLEASE - keep it header only.
I have no interest in boost::filesystem or gil. Just trying to understand your requirement for being header-only: You *want* to compile the same code over and over rather than just once?
No, he's probably using a pre-compiled header. :-) Bo Persson
Bo Persson wrote:
Sohail Somani wrote:
Tom Brinkman wrote:
But it would introduce the dependency to boost::filesystem That would be a show-stopper for shur. I definately could not use your IO library if it had a boost::filesystem dependency. PLEASE - keep it header only. I have no interest in boost::filesystem or gil. Just trying to understand your requirement for being header-only: You *want* to compile the same code over and over rather than just once?
No, he's probably using a pre-compiled header. :-)
So the pch is taking the place of a .lib. Anyway... -- Sohail Somani http://uint32t.blogspot.com
But it would introduce the dependency to boost::filesystem
That would be a show-stopper for shur. I definately could not use your IO library if it had a boost::filesystem dependency. PLEASE - keep it header only.
I assume Christian was referring to the extension function in boost filesystem -- I can't really think of why else filesystem would be used to provide the feature I was asking about, which was a read_image function that would choose the appropriate file format based on the name or first bytes of the file. -- John
Hi guys, sorry for being so unresponsive. I took a short vacation to recharge my batteries. On Sat, Apr 26, 2008 at 6:20 AM, John Femiani <JOHN.FEMIANI@asu.edu> wrote:
But it would introduce the dependency to boost::filesystem
That would be a show-stopper for shur. I definately could not use your IO library if it had a boost::filesystem dependency. PLEASE - keep it header only.
I assume Christian was referring to the extension function in boost filesystem -- I can't really think of why else filesystem would be used to provide the feature I was asking about, which was a read_image function that would choose the appropriate file format based on the name or first bytes of the file.
Yes, if I would have to implement such a feature, I would use boost::filesystem. What's the point of having such a lib when nobody is using it? Also, I have some dependencies to boost::filesystem already in io_new. But they are all wrapped by ADD_FS_PATH_SUPPORT. On the other hand I don't get why boost::filesystem isn't header only? Asio managed to do that, why not filesystem? I think both libs are more or less thin wrappers around operation system's SDKs. Please correct me if I'm wrong. Christian
participants (5)
-
Bo Persson -
Christian Henning -
John Femiani -
Sohail Somani -
Tom Brinkman