Re: [boost] [Hana] Migrating sqlpp11 to Hana (hypothetically)

16 Jun 2015

      Roland Bock  writes:
...
...
Roland Bock  writes:
...
[...]
_Compile__time strings:_
[...]
* I do not want to "using namespace ::boost::hana::literals" at
    top-level or in one of the namespaces in the header.
Is it acceptable to only import the `_s` string literal from Hana?
using boost::hana::literals::operator""_s;
Not really. This code has to be provided by the user of the library. It
On 2015-06-15 21:08, Louis Dionne wrote:
lives outside the sqlpp namespace. I cannot just tell them, to please
import some string literal into their namespace.
[...]
I must admit I don't have a solution. This is such a pain since it is a
__joke__ in terms of implementation difficulty at the compiler/language
level, but I think it is not solvable at the library level.
...
[...]
...
...
_any/all/none:
_Quite a bit of code is tuned to stuff like std::is_same: a type that
contains a value (true or false). My current versions of any/all/none
work like that, too.
If I wanted to get rid of my own versions, could I use a drop-in from
hana? Or would I have to write something like
template
struct my_all
{
   static constexpr bool value =
::boost::hana::all(::boost::hana::make_tuple(B...));
};
The best way would be this:
hana::all(hana::tuple_c)
This would return a boolean IntegralConstant (which is convertible to
bool). This could also be made just as efficient as your clever
implementation using std::is_same (that you posted on the list a
while ago), because we have the knowledge that the content of the
tuple are compile-time bools. However, using
`hana::all(hana::make_tuple(b...))` will be comparatively
__very__ inefficient, because we can't know what's in the tuple
and we must guarantee proper short-circuiting.
Oh, because the it could be tuple_t and you still want this
to work in case it short-circuits in the bool element?
If so, that sounds quite strange to me.
Notice that I used `tuple_c`, not `tuple_t<...>`. `tuple_c`
creates a Tuple containing IntegralConstants, in that case boolean
IntegralConstants. Using `tuple_c` allows the representation
of the tuple to be optimized for some types of computations, like
`all()` & friends.

Using `all(tuple_t<...>)` does not make sense, because `tuple_t<...>`
creates a tuple containing types, but types do not have a logical value.

Does that make sense?
...
[...]
Regards,
Louis