Skip to content

Port to Windows Runtime - #17

Closed
john-peterson wants to merge 4 commits into
boostorg:masterfrom
john-peterson:rt
Closed

Port to Windows Runtime#17
john-peterson wants to merge 4 commits into
boostorg:masterfrom
john-peterson:rt

Conversation

@john-peterson

Copy link
Copy Markdown
Contributor

@swatanabe

Copy link
Copy Markdown
Collaborator

AMDG

  • There's no reason to use vector. An array should
    work just fine, since the size is known at compile
    time
  • Is there a reason to go through DataReader instead of
    just calling CryptographicBuffer::CopyToByteArray?
  • I'd prefer not to use auto. Boost.Random is still
    C++03 compatible.
  • When was WINAPI_FAMILY_PARTITION defined? I don't
    want to break compatibility with older compilers.
    I still test with VC9.
  • Similarly, will it work with MinGW or clang-cl?
  • Where are these components coming from? I notice
    that you #ifdefed out the #include <windows.h>.
  • Can these functions fail? What happens if they do?
    The MSDN documentation is nearly useless.

In Christ,
Steven Watanabe

@john-peterson
john-petersonforce-pushed the rt branch 2 times, most recently from 4d5f94c to 7d073b8CompareMarch 10, 2015 05:15
@john-peterson

Copy link
Copy Markdown
ContributorAuthor

There's no reason to use vector.
Is there a reason to go through DataReader

i fixed it

When was WINAPI_FAMILY_PARTITION defined?

i fixed the config to the same as https://github.com/boostorg/asio/blob/master/include/boost/asio/detail/config.hpp so it should work

I'd prefer not to use auto.

there's no winrt compiler that doesn't support auto

will it work with MinGW or clang-cl?

do they have an rt compiler?

Where are these components coming from?

the namespaces comes from /ZW

Can these functions fail?

doesn't seem so

edit: maybe they can throw an exception? should they be in a try/catch?

@swatanabe

Copy link
Copy Markdown
Collaborator

AMDG

On 03/09/2015 11:20 PM, John Sebastian Peterson wrote:

I'd prefer not to use auto.

there's no winrt compiler that doesn't support auto

Okay.

will it work with MinGW or clang-cl?

do they have an rt compiler?

My concern wasn't so much compiling for WinRT
as the use of an unknown macro breaking desktop
compilation.

In Christ,
Steven Watanabe

@john-peterson

Copy link
Copy Markdown
ContributorAuthor

k i get it

@swatanabe

Copy link
Copy Markdown
Collaborator

AMDG

By array I meant unsigned char[sizeof(result)].
Also, I'd rather not put any kind of WinRT
configuration in the header when it's only
used by random_device.cpp.

In Christ,
Steven Watanabe

@john-peterson

Copy link
Copy Markdown
ContributorAuthor

done

By array I meant unsigned char[sizeof(result)].

it doesn't accept that type

https://msdn.microsoft.com/en-us/library/windows.security.cryptography.cryptographicbuffer.copytobytearray.aspx

Type: array of Number [JavaScript] | System.Byte[] [.NET] | Platform::Array [C++]

because it's rarely used
@swatanabe

Copy link
Copy Markdown
Collaborator

AMDG

The most recent version of the WinRT #ifdefing
is broken:

compile-c-c++
......\bin.v2\libs\random\build\msvc-12.0\debug\threading-multi\random_device.obj
random_device.cpp
......\libs\random\src\random_device.cpp(117) : error C2653:
'CryptographicBuffer' : is not a class or namespace name

In Christ,
Steven Watanabe

@john-peterson

Copy link
Copy Markdown
ContributorAuthor

u need to add /ZW boostorg/build#62

@swatanabe

Copy link
Copy Markdown
Collaborator

AMDG

On 03/13/2015 04:03 PM, John Sebastian Peterson wrote:

u need to add /ZW boostorg/build#62

I'm NOT building for WinRT.

In Christ,
Steven Watanabe

@john-peterson

Copy link
Copy Markdown
ContributorAuthor

k so winapifamily.h is included for all vc 2013 builds then https://github.com/jp9000/OBS/blob/master/extras/winapifamily.h#L34

@swatanabe

Copy link
Copy Markdown
Collaborator

I've rebased this and applied it to develop.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

@john-peterson@swatanabe