Added Environment and Job

[klemens-morgenstern]

For my boost.process 0.6 version, I need those two headers, which are currently in the boost.process Repository. Though not approved yet, I think it wouldn't hurt to have them in this repository.

[klemens-morgenstern]

Is there a pattern on how to use enumerators? I need to add JOBOBJECTINFOCLASS to the jobs.hpp, but I don't know how that should be integrated into the winapi module, but is an enumerator. I really don't know how this could be solved without causing an ambiguity error.

[Lastique]

I think you won't be able to add that enumeration to Boost.WinAPI and will have to include windows.h in your code. Enum forward-declarations are allowed only since C++14 (IIRC) ,and Boost.WinAPI is supposed to be compatible with C++03. Without the enum you won't be able to forward-declare the WinAPI function from Windows SDK.

[Lastique]

Actually, enum forward-declarations are allowed since C++11, but that won't help as the enum does not have a fixed underlying type in Windows SDK anyway.

[klemens-morgenstern]

Darn, though actually, the forward declaration can work the following way.

enum _JOBOBJECTINFOCLASS : typename boost::underlying_type<::boost::detail::winapi::JOBOBJECTINFOCLASS_>::type;

This compiles with msvc, but gcc doesn't like that very much - but maybe I'll find something.

Is the C++03 an absolute requirement or could we make an exception for one header I only use in a C++11 library anyway?

[Lastique]

Darn, though actually, the forward declaration can work the following way.

I'm not sure that that approach is legitimate since the definition of the enum in the Windows SDK does not specify the underlying type. I'm not sure the two types are considered the same in this case, I'll have to dig into the standard.

Is the C++03 an absolute requirement or could we make an exception for one header I only use in a C++11 library anyway?

I guess we could add an exception but I'd prefer if the rest of the headers were C++03. Can the enum-related stuff be isolated to a separate header? Does it make a meaningful set of API for a header?

[klemens-morgenstern]

Well it is needed for one function and it would make sense to have that in the job header. I could also add an #ifdef for the C++ Version so you could include the header into C++03. Or the C++03 version automatically includes Windows.h, so you had the same symbols.

Ok, well I assumed, that two enums declared with the same values would have the same type. I'll look if I find a portable solution and look if this is just hacking or matches the standard and get back to you.

[klemens-morgenstern]

I checked this again, and this will indeed not work. That is because the solution that compiles with msvc is actually non-standard. You can only forward-declare a non-scoped enum with an underlying type, but if you declare an enum without a type, it will be considered non-fixed. So even if the types match, it won't compile. Maybe I find a subset of the JobObject Features I can use without the enum; if not I'll remove it from this PR altogether.

[klemens-morgenstern]

So, I removed the functions that depend on the enumerator, I might get lucky to find a way to work around them So I'll look into that. Thanks!

[klemens-morgenstern]

Now, I implemented a workaround for the functions taking the enums in my repository. I would consider this PR complete, I have implemented everything I need. I.e. I would only open another one for bugfixes.

[Lastique]

I'll close this PR for now. If there's still something you would like to merge to Boost.WinAPI, please create a separate PR - one for each topic like environment, jobs, etc.