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

Subject: Re: [boost] [Hana] Migrating sqlpp11 to Hana (hypothetically)
From: charleyb123 . (charleyb123_at_[hidden])
Date: 2015-06-16 18:33:16

On Tue, Jun 16, 2015 at 2:25 PM, Roland Bock <rbock_at_[hidden]> wrote:

> On 2015-06-16 16:09, Louis Dionne wrote:
> > Roland Bock <rbock <at> eudoxos.de> writes:
> >
> >> On 2015-06-15 21:08, Louis Dionne wrote:
> >>> Roland Bock <rbock <at> eudoxos.de> 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
> >> 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
> proving that there is need to add language support for compile time
> strings.
>

This.

+1.

Then, +1 again.

There was a cute suggestion at CppNow about performing Great Violence with
the preprocessor (and an illustration was shown for how it does actually
work):

(1) Put your clear-text in a text file.  (This isn't a C++ file, it's just
arbitrary text.)

(2) Use #include"" to pull that text-file into some arbitrary location
within your C++ code (perhaps within a "constexpr" function body).

(3) Use "constexpr" operations within that "constexpr" function-body to
perform arbitrary string-manipulation (at compile-time), thus achieving
compile-time arbitrary string manipulation.

There is a "suggested-limit" regarding the number of compile-time execution
operations a given compiler might implement to support constexpr-function
bodies (I think the guidance was something like 500 operations executed at
compile-time by the compiler, don't remember), but you could "reset" this
limit with each translation unit.

So, I was actually thinking about making a library that would perform this
string-manipulation at compile-time to assemble massively complex strings.
Typical manipulations are (of course) things like embedding version
information, embedding resources and paths, and other
higher-order-operations like embedding SQL queries.

However, even though I think it would really work, I think it's a horrible
work-around that becomes completely useless when we, "doing it right" and
actually adding language support for compile-time strings.

--charley