Roland Bock writes:

...

[...]

_Compile__time strings:_ This one seems easy. There probably won't be a C++14 version of sqlpp11, but there will be a C++17 version, hopefully allowing me to use the string literal without relying on a non-standard compiler extension.

This is what I currently have [2]:

struct _alias_t { static constexpr const char _literal[] = "delta"; using _name_t = sqlpp::make_char_sequence; };

This is what I would like to do:

struct _alias_t { using _name_t = decltype("delta"_s); };

But the whole thing is in a header.

* 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. It would be acceptable, if I could just do it inside a struct, but this is illegal: struct A { using boost::hana::literals::operator""_s; }; I could use a function instead of a type and then use decltype when I want the type of the name. struct A { static constexpr auto test() { using boost::hana::literals::operator""_s; return "cheesecake"_s; } }; I will let this sink in a bit...

...

[...] * I also cannot use the BOOST_HANA_STRING macro, btw, because that would be a lambda in a decltype... Yeah, the decltype + lambda restriction is annoying. Frankly, I don't know of any way to use UDLs from another namespace without importing them, and I'm not sure it's feasible. That would be annoying. In the end, they are functions, aren't they. If it is not possible yet, it should be so in the next standard...

I asked on the standard proposal list if there is anything like that available or proposed yet. [1]

...

_type sets:_ Currently I store a bunch of types in type sets to do all kinds of tests at compile time. My type set code will need some cleanup or replacement one fine day. Hana to the rescue...

Er, wait a second. There is no type set, or is there? There is a set for objects (which might represent types). Replacing all those types with objects would take some time, but I could live with that, I guess. But then I would have to replace all my type_sets (which are types themselves) with static constexpr objects, which use tons of constexpr template variables. And there are other constructs which use the types I now have replaced with objects. So I would have to adjust them, too, probably turning even more types into objects. In theory, that would be the "right" way to do it. What Hana is proposing is a completely new metaprogramming paradigm. However, in practice, it's usually possible to isolate the part of the system using Hana from the rest of the system, or to have Hana interoperate with the rest of the system in some way. I would say this is something that must be handled on a case-per-case basis.

For an example of a code base that was partially adapted to Hana with success, see this fork [1] of the Units-BLAS library by Zach Laine.

...

Can I be sure (given today's compilers) that all these objects stay away from the generated binary? I guess you can't be __sure__ of it. My view on this is that as long as the objects are very small (they're basically empty) and constexpr, the compiler should be able to optimize it away. If that's not the case, and if this paradigm turns out to be as great as I advertise, perhaps compiler writers will have more incentive to apply such optimizations. Also, it is possible that the language will evolve in the direction of making these things easier.

However, in practice, you can usually ensure that no objects are generated at all by doing your computations in a function with value-level syntax, and then using `decltype` on the result of that function. For example, here's something taken from the Units-BLAS code I linked above. Here's the original code (edited for simplicity):

[...]

The trick is to enclose your value-level computations inside functions, and then use decltype on your functions to ensure they are never actually called. In practice, doing this in a non-messy way must be studied in a case-per-case basis, or at least I don't have clear guidelines for now. That is a very nice approach for partially migrating (and as you said it might also increase the likelihood that there are no leftovers in the resulting binaries).

Thanks for the detailed reply!

...

Also, I did not find some of the methods I would expect for sets:

* Create a joined set * Create an intersect set * Create a difference set * Test if two sets are disjunct * Test if A is a subset of B, no, strike that, just found it in Searchable

I probably could create the methods above with just a few lines of code using the available functions. But it would be convenient to have them available, of course (or did I just miss them?). This is a simple oversight. Like I said elsewhere, the associative sequences (Set and Map) are still very naive and their interface is incomplete. So far, I have focused on the simplest and most frequently used structure, Tuple. I added this issue [2] to remind me of these missing functions. Great :-)

...

By the way, I guess it would be easy for you to compile a list of available methods for each type, e.g. Set. Such a mini-index would be quite helpful IMO. Good idea. It would be a pain with my current Doxygen setup, but I think I'm about to break up with Doxygen anyway. I noted your idea in this issue [3]. Looking forward to it.

...

_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.

...

_Intermediate summary:_

* I am not sure if I could replace my current compile-time string yet It depends on which compromises you are willing to do. As far as I know, you can't do it properly without using the GNU string-literal extension. Oh wait, I could also write a macro similar to BOOST_MPLLIBS_STRING from Metaparse, but that wouldn't be very C++14ish.

No worries. The current way is OK, and in the long run, I want name-literals anyway [2] :-)

...

* I would like to have a few more convenience methods for Set. You will get that and much more by the end of the summer, or I won't get my GSoC T-shirt. :-)

Lol, that is a great incentive!

...

* It seems to me like if I wanted to use Hana, I should switch to Hana-style completely. Otherwise it will just be a weird mixture. Mixing Hana and classic metaprogramming is indeed very difficult for things that have to travel a lot in your interface (e.g. compile-time strings that are exposed to the user). This is simply because Hana is such a different paradigm that if you want your interface to be Hana-like, then you must do it all in this way. However, you can still use Hana under the hood to simplify some metaprogramming locally while keeping your interface as-is. This is essentially what was done in the Units-BLAS project. But of course, the benefit of using Hana will then be limited to those local simplifications.

I would be very curious to try and port sqlpp11 to Hana. If you ever want to give it a shot, please let me know. However, that will have to wait for a while because I'm neck deep right now.

Yes, I am also curious to give it a try. Preferably in combination with Concepts Lite. Oh, that reminds me, I found a serious conceptual problem in ConceptsLite with template-template parameters (at least I think I did). Need to check on that with Andrew Sutton again... I am also drowning in work at the moment. I'll let you know when I get started :-) Cheers, Roland [1] https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposal... [2] https://groups.google.com/a/isocpp.org/forum/#!msg/std-proposals/hYh3hWB0mwg...

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. I do hope that libraries like Hana, Metaparse and sqlpp11 help in

On 2015-06-16 16:09, Louis Dionne wrote: proving that there is need to add language support for compile time strings.

...

[...]

...

...

_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? Got it, thanks!

I'll try to do some more testing before the end of the review (but I am a bit swamped right now). Regards, Roland

Louis Dionne writes:

Roland Bock writes:

...

...

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.

It seems there is the obvious solution of also defining operator"" _boost_hana_s in the global namespace. I guess it is just a question of how common this problem is likely to be.

Roland Bock writes:

On 2015-06-17 08:39, Jeremy Maitin-Shepard wrote:

...

[...]

It seems there is the obvious solution of also defining operator"" _boost_hana_s in the global namespace. I guess it is just a question of how common this problem is likely to be.

Sure, but doesn't that feel like we're back in the dark ages before namespaces?

I would also prefer not putting Hana's literals in the global namespace.

There was a nice suggestion from Tomasz on the std-proposals list [1]:

[...] auto s = boost::hana::"sample"_s; [...]

I think that is a very nice solution. Who's writing the paper? :-) Louis