Hi,
There's a C++14 library that is able to do basic reflections for PODs
without any macro magic or markup: https://github.com/apolukhin/magic_get
Would it be interesting for Boost? Could it pass Boost review if it has a
reinterpret_cast in it?
--
Best regards,
Antony Polukhin
Am 02.06.2016 8:56 nachm. schrieb "Edward Diener" <eldiener(a)tropicsoft.com>:
>
> I have finished all the main work on the Cxx dual library at
https://github.com/eldiener/cxx_dual. The library is also in the Boost
Library Incubator at
> http://rrsd.com/blincubator.com/bi_library/cxx_dual-2/?gform_post_id=1597.
>
> The Cxx dual library, or CXXD for short, is a C++ macro header-only
library which chooses between using a Boost library or its C++ standard
equivalent library …
[View More]for a number of different C++ implementations, while
using the same code to program either choice. An 'implementation' is a
Boost library which has a C++ standard library equivalent whose public
interfaces are nearly the same in both cases. An 'implementation' is called
a 'dual library' in this documentation, or 'CXXD-mod' for short.
>
> The library does this by defining object-like macros for including the
appropriate header file and namespace or using either the Boost library
version or the C++ standard library version of a particular dual library.
CXXD currently supports twenty eight different dual libraries, where the
Boost version and the C++ standard version is nearly interchangeable in
some respects. CXXD also provides a macro-based solution for distinguishing
between the Boost version and the C++ standard version of a dual library so
that specific code for a particular dual library choice may be written in
those cases where the public interfaces diverge.
Personally, I'm not a big fan of such a solution, especially when those
macros "leak" into the public interface. We had a similar interface which
would automatically switch between std and boost function. The result
looked nice at first sight, however the subtle differences between the two
led to various problems, one of which was that documenting the public
interfaces containing this macro was very difficult, where does it point to
know? Where should we send users to who look for more information about
this function type? Should they be aware of both? Switching compilers or
even boost version and now suddenly everything seems broken?
The solution for us was to just decide which one to use and go with it,
setting the requirements to the used standard library/boost version as
needed.
[View Less]
Hello all,
I wanted to thank everyone who participated in the CMakeLists.txt and
related threads. I'm sorry I wasn't able to participate all the way
through, but I found the majority of the posts to be civil and constructive
(some of my own heated posts being notable exceptions).
Here is my take away. No one is arguing that the current guidelines
disallow authors from placing a CMakeLists.txt in the root of their
library's directory. Some pointed out drawbacks of placing them there and
…
[View More]recommended 'build/' or 'CMake/' instead. Others saw value in having
CMakeLists.txt in the root directory, but felt these should be short
wrappers where the real work is done in the 'build/' directory.
Louis and Paul, I know you felt it important for your gitHub distribution
to have 'CMakeLists.txt' in the root directory as is typical for CMake
projects. Does this result satisfy your concerns?
-- David Sankel
[View Less]
Hi all,
GitHub finally allows us to set permissions on the level of granularity that we always wanted.
When we moved to GitHub, we received many request like "can I please get admin rights to my repository?" We wanted to do that, but it just was not possible. As a workaround, we have created a team per repository and many of those teams had just one member. That way, we could at least give you write access to individual repositories. Not quite what you requested, but at least something.
…
[View More]Anyway, it is now possible to set permissions on a per repository level. I have started to delete the teams with a single member and added the member as the owner of the repository.
How do those changes affect you? As the owner of a repository you have write access as before, but you can also add collaborators, modify the repository descriptions, enable/disable issue tracking and wiki, and so forth.
I will continue this cleanup soon, but I need your input. For teams with multiple members, I don't know whether you want to share ownership or whether you prefer to have a single owner and additional contributors. Please create new issues for that matter: https://github.com/boostorg/admin/issues
Cheers, Daniel
[View Less]
Hi all,
The Boost.Fiber candidate library by Oliver Kowalke begins a
mini-review today, Monday May 23, which will close Wednesday June 1.
It was last reviewed in September 2015; the verdict at that time was
"not yet." Oliver has been working steadily to address review comments
and to improve the library in other ways, and has brought the library
back for mini-review.
The updated documentation is here:
http://olk.github.io/libs/fiber/doc/html/index.html
The code is on the master branch of …
[View More]this repository:
https://github.com/olk/boost-fiber/tree/master
I believe it is Oliver's intention to respond to review feedback on
the develop branch, leaving the master branch stable during the
review.
I will monitor reviews and discussion on both the boost-users@ list
and the boost@ developers' list. Please include at least "fiber" and
"review" in the subject line of your mail, e.g. by replying to this
message. (Please reply to only ONE list, however.)
I will also check the Boost Library Incubator for Fiber reviews:
http://rrsd.com/blincubator.com/bi_library/fiber/?gform_post_id=859
though I check that less frequently than email.
Please do remember to state in your review whether you think the
library should be accepted as a Boost library.
Thank you for your interest and your feedback!
-----------------------------------------------------
Here follows a synopsis of issues raised during the September 2015 review:
Cross-thread fiber migration: Evidently the community strongly desires
the ability to transfer a suspended fiber from one thread to
another. Now supported, with documentation.
Cross-thread migration support implies a requirement to document the
thread safety requirements of the customization API. Addressed.
Standard required timing specifications: meet (30.2.4 Timing
specifications [thread.req.timing]). Addressed.
Adapt one or more existing test suites for thread facilities to
validate the correctness of the Fiber library's synchronization
constructs. The requester clarified in private mail that I misstated
his suggestion: he wanted Oliver to review one or more such test
suites to discover the kinds of issues that can arise with thread
synchronization constructs. He has professed himself satisfied with
the current state of the Fiber library's synchronization constructs.
std::chrono support: ensure that wait_until() can accept any supported
time_point specialization. Addressed.
C++11 compatibility. Addressed.
Document that this_fiber::yield() (et al.) are valid from main(), or
in general from a thread function, as well as from explicitly-launched
fibers. Addressed.
Make shared_state lock requirements explicit: for example, make
mark_ready_and_notify_() accept a std::unique_lock<>& (or &&) to force
its caller to provide one. Addressed.
Avoid holding mutex during condition_variable::notify_*() calls. Addressed.
packaged_task must not decay-copy its task arguments. Addressed.
Align fibers::async() signature, result description and invoke_helper
implementation with std::async(). Avoid returning std::move(...). Addressed.
Wait list implementation: try an intrusive linked list of
fiber_context objects. Addressed.
Avoid sleeping thread when no fibers are ready -- block on external
event. Better handling of waiting tasks (decentralized wait queues?). Addressed.
Optimization to resume awakened fiber on the thread that awakens it.
Hooks provided.
Template redundancy: eliminate duplication between specializations for
T, T& and void. The future, shared_future, shared_state, promise and
task_object templates were specifically cited. Addressed.
Leverage predicate-based condition::wait() overload internally. Addressed.
Nested schedulers: make schedulers be schedulable entities themselves.
Not implemented.
Improve robustness of `promise' handling in Asynchronous Callbacks
documentation. Avoid overconfident remarks about it. Addressed.
Fix Note overstating the requirements on condition_variable::wait(). Addressed.
[View Less]
