Overflowing an integer is undefined behavior. Then the compiler is allowed to assume you are not going to overflow integers and optimize accordingly.
I was doing some delicate bit-fiddling code and got a surprise, that if you put in a file this
#include <stdint.h>
void consume(bool);
extern long maxInt;
It turns out that both GCC and Clang compile recursive code for factorial as a simple loop:
template<typename T>
constexpr
T factorial_impl(T value) {
return value <= 1 ? 1 : value * factorial(value - 1);
}
long factorial(long arg) { return factorial_impl(arg); }
I have been working on a simple precision-doubling template.
The largest integer supported by GCC and Clang are the __int128 and unsigned __int128 types.
In general, there is no way to access the carry flag necessary to implement multiple precision additions. Fortunately Clang detects that's what one is doing and generate good assembler, at least in AMD64 (x86-64):
#include <stdint.h>
The code below emulates "restrict", the function argument attribute that indicates the ranges of the pointers do not overlap. It explains its limitations:
struct Aligned {
alignas(1024) double d;
};
using u = unsigned;
constexpr u count = 1 << 10;
using ul = unsigned long;
Imagine there is a template that tells you from an operation type a class-function "operate", and a type called "inverse" which gives you the inverse operation:
template<typename Operation>
struct OperatorTraits {
template<typename Argument>
static Argument operate(Argument x, Argument y);
using Inverse = // ...
};
noexcept of swapvisitvisitMaxer, Largest, ...BadVariant
This is a description about a recent small project:
I've been researching and working on how to implement the best mechanisms for event handlers. Frequently the events are received by a dispatcher component that classifies the event and activates the correct processing function. For example, if the event is a market data message which could be a trade, a bid or an ask:
void dispatch(int eventType, void *data) {
switch(eventType) {
case 0: processTrade(data); break;
case 1: processBid(data); break;
case 2: processAsk(data); break;
The main aim of AnyContainer is to solve the need for subtyping without the problems of subclassing, i.e., not forcing user types to inherit from base classes, allowing value semantics, and having the option of the performance of normal C++ code rather being forced to the inefficient dynamic dispatch through a virtual table.
We think the goals have been achieved: the performance and object code size are optimal as far as we know, and it is possible to have general solutions for runtime polymorphism, including infinite refinement.
First let us see a comparison to another type-erasure framework.
| // This example requires the boost preprocessing library headers | |
| #include <boost/preprocessor/seq/for_each_i.hpp> | |
| #include <boost/preprocessor/seq/for_each.hpp> | |
| #include <boost/preprocessor/punctuation/comma_if.hpp> | |
| #include <boost/preprocessor/cat.hpp> | |
| #include <boost/preprocessor/seq/transform.hpp> | |
| #include <boost/preprocessor/seq/enum.hpp> | |
| // Macro naming convention: |