Re: [review] [sqlite]

From: Ruben Perez (rubenperez038_at_[hidden])
Date: 2024-11-16 11:17:44

(CC-ing the list)

On Sat, 16 Nov 2024 at 12:11, Klemens Morgenstern
<klemensdavidmorgenstern_at_[hidden]> wrote:
>
> On Sat, Nov 16, 2024 at 7:07 PM Ruben Perez <rubenperez038_at_[hidden]> wrote:
> >
> > > > 3.  What's the rationale behind BOOST_SQLITE_NO_VIRTUAL? Wouldn't
> > > > setting it cause trouble, being a compiled library?
> > >
> > > It would. The idea is that you can use that for constrained (i.e.
> > > embedded environments) to avoid the unnecessary vtable and to enforce
> > > devirtualization if your compiler misses this.
> >
> > If I have read the code correctly, these functions seem to only be
> > used in headers. Why do they need to be virtual? It looks like it
> > could have been made a compile-time interface (i.e. a concept),
> > completely avoiding the need for the macro. What's the rationale
> > behind this?
>
> That's correct, that's also what it was originally. But the error
> messages were horrendous.
> By creating a base class you get good error messages (purely virtual
> because method X is missing) and the compiler is still compelled to
> devirtualize by the way it's used.
> And because it's effectively unused, you can disable it.

Couldn't you achieve a similar effect (scoped to C++20 and later) by
conditionally using concepts? In a way similar to what Asio does to
diagnose completion tokens (i.e. BOOST_ASIO_COMPLETION_TOKEN_FOR).