| BOOST_DEFINE_MATH_CONSTANT(half, 5.000000000000000000000000000000000000e-01, "5.00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e-01") |
| #include <tuple> | |
| #include <type_traits> | |
| template <int... I> | |
| using bar = std::tuple<std::integral_constant<int, I>...>; | |
| template <int... I> | |
| struct foo { | |
| int total(bar<I...> const&) const { return 0; } // error C3520: 'I' : parameter pack must be expanded in this context | |
| }; |
Writing benchmarks is not easy. Nonius simplifies certain aspects but you'll always need to take care about various aspects. Understanding a few things about the way nonius runs your code will be very helpful when writing your benchmarks.
First off, let's go over some terminology that will be used throughout.
101. All players must always abide by all the rules then in effect, in the form in which they are then in effect. The rules in the Initial Set are in effect whenever a game begins. The Initial Set consists of Rules 101-116 (immutable) and 201-213 (mutable).
102. Initially rules in the 100's are immutable and rules in the 200's are mutable. Rules subsequently enacted or transmuted (that is, changed from immutable to mutable or vice versa) may be immutable or mutable regardless of their numbers, and rules in the Initial Set may be transmuted regardless of their numbers.
103. A rule-change is any of the following:
| // Myth #1: constexpr is the same as const | |
| // (note: there is a difference between C++11 and C++14 here) | |
| // (see: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3598.html) | |
| namespace myth1 { | |
| struct foo { | |
| int i; | |
| constexpr int& get() { return i; } // not a const function | |
| } | |
| int f() { |
I hereby claim:
To claim this, I am signing this object:
ogonek::text is intended as a Unicode-based string class. Not as a glorified container of characters, like std::basic_string, but as an actual piece of Unicode text.
text is not about storage, so it delegates that to another container. That container can be customized, yielding a varied range of performance characteristics suitable to any situations. One could have a Unicode text array, similar to std::basic_string, or one could have a Unicode text deque, or even a rope.
This documents describes a proposal for providing authors of C++ libraries with a standard facility to mark code entities as deprecated.
Libraries change with time. Sometimes features are replaced by more powerful ones, or are found to be inherently flawed. A common way for library writers to deal with this problem is to recommend against such old features, i.e., to mark them as deprecated.
Right now there is no standard means of doing that. Library writers are thus forced to either simply document them as deprecated, or to use the preprocessor to decide upon one of the various compiler extensions that exist to support this feature.
The [Frontier Magic rules][wizards rules] created by Wizards are a good start but not as fun as we had expected. So we made up new rules based off of the same idea. These are those modified rules.
TODO: more complete description of the terrain
The home row is a row between a player and the land cards.
| > - This is a list item, in a quote! | |
| > - This is another list item, in a quote! |