On Tue, Oct 6, 2015 at 12:40 PM, Beman Dawes
On Fri, Oct 2, 2015 at 9:27 AM, Mikael Olenfalk
wrote:
Ouch! That is a large change. The line count is +231 −24.
I might have been able to keep the line-count lower I think but I did some cleanup (in separate commits) at the same time to make the review easier and the resulting code easier to read. For example: * 71df678 - universal-windows: Use CreateFile2: * also introduces a new wrapper so that call-sites look the same everywhere * 2635ec6 - universal-windows: Add helper for GetFileAttributesW: * same as above, introduces a new wrapper The biggest commit (+71) is: * 2f35d8a - universal-windows: Implement temp_directory_path(): * environment variables no longer exist (so getenv("TEMP") does not work anymore), however the application model introduced in winrt has a getter for the application specific temp directory, in order to be able to compile this on VS2015 I opted for using WRL rather than C++/CX (see separate discussion about how VS2015 is broken when compiling C++/CX from the command line) this makes this commit balloon from 1 line to 71 :/ To put that in perspective, the line count for adapting filesystem to
Android was +3 -1. Worse yet, the changes touch many different functions in the code, so the analysis of the changes is complex and time consuming.
I understand that this will take some time :-)
I really do not want to apply a change of that magnitude. It is also suspicious that all the changes are too the operational code. Why are there no changes to test code or documentation?
Thanks, I will add compilation fixes for the tests and figure out where the documentation needs updating or clarifying.
Have you talked with Steve Gates from Microsoft? He seems to be leading the effort to adapt boost libraries to winrt so may know who to talk to about universal apps.
I talked to him a couple of months ago. But nowadays his email @Microsoft.com bounces and from other softies I hear it seems he has left the company. I have reached out to OSG to figure out if somebody else is working on this but I am still waiting for answers.
Surely Microsoft does not expect developers to make such massive code changes to adapt their libraries.
In general the differences between universal apis and traditional apis get smaller if we target a newer windows version (e.g. increase our requirement for _WIN32_WINNT to 0x0A00 [win10]). However in this particular case I do not think we want to nor that it would make a difference (CreateFile[Ex] and e.g. FindFirstFile seem to be gone even when targeting _WIN32_WINNT=_WIN32_WINNT_WIN10).
There is a need to abstract away more of the differences between traditional Windows API's and Universal app API's.
Can you clarify what you mean? I am willing to make whatever changes or refactorings you want me to.
Boost.Filesystem has suffered for years from lack of maintenance effort while I worked on the Filesystem TS. Now that the TS is done, Boost.Filesystem is getting maintenance effort again and 1.60 will have a lot of fixes. But there are still many high priority issues outstanding, and they get priority.
That makes sense. If I can lend a hand with anything give me shout. Thanks, Mikael