Re: C++ API: Vector arguments / error detection

["Marc Nieper-Wißkirchen" <marc.nieper+gnu@gmail.com>]

Am Mo., 31. Jan. 2022 um 16:20 Uhr schrieb David Malcolm <
dmalcolm@redhat.com>:

> On Mon, 2022-01-31 at 16:08 +0100, Marc Nieper-Wißkirchen wrote:
> > Am Mo., 31. Jan. 2022 um 15:49 Uhr schrieb David Malcolm <
> > dmalcolm@redhat.com>:
> >
> > > On Sun, 2022-01-30 at 16:35 +0100, Marc Nieper-Wißkirchen via Jit
> > > wrote:
> > > > This is about two unrelated issues regarding the C++ API:
> > > >
> > > > (1) At the moment, a lot of API functions like new_function take
> > > > non-
> > > > const
> > > > referenced to vectors, e.g. std::vector <param> &params;
> > > >
> > > > Can we change this into const references?  This way, one can write
> > > >
> > > > auto param1 = ctxt.new_param (...);
> > > > auto param2 = ctxt.new_param (...);
> > > > auto func = new_function (..., {param1, param2}, ...);
> > > >
> > > > instead of the more complicated and less convenient
> > > >
> > > > auto param1 = ...;
> > > > auto param2 = ...;
> > > > auto params = std::vector {param1, param2};
> > > > auto func = new_function (..., params, ...);
> > >
> > > I wonder why they're not const already - maybe I just forgot?
> > >
> > > Making the refs const sounds like a good idea to me.
> > >
> >
> > The reason why you didn't make them const may be that the C API that is
> > called takes non-const arrays of pointers.  The latter is probably a
> > good
> > idea because of the const model in C and the const-cast restrictions.
>
> Yeah, that was probably it.
>
> >
> > But when the C API doesn't change the arrays, all that is needed is a
> > const_cast <...> (...) in the C++ API implementation.  If you can
> > confirm
> > the former, I can do the latter.
>
> Sounds like a good idea to me.
>
> > >
>
> > > > (2) When using gccjit::context::compile_to_file, how can I check
> > > > whether
> > > > the compilation succeeded without errors or not? In libgccjit++.h
> > > > no
> > > > error
> > > > is checked and no exception thrown.
> > >
> > > Looks like I forgot to:
> > > (a) give a return value to gcc_jit_context_compile_to_file, and
> > > (b) add C++ bindings for gcc_jit_context_get_first_error and
> > > gcc_jit_context_get_last_error.
> > >
> > > Looks like fixing (a) would be an ABI break, bother (perhaps we could
> > > add a revised gcc_jit_context_compile_to_file symbol and do it with
> > > symbol versioning)
> > >
> >
> > A workaround would be to check that the context is without an error
> > before
> > the context to gcc_jit_context_compile_to_file and then to check
> > afterward
> > again, right?
>
> That could work.
>
> > If this is true, a return value (while nice) is not
> > absolutely necessary and an ABI break would not be needed.  (By the
> > way, is
> > changing the return type from void to int, say, an ABI break on any
> > platform?
>
> I'm not sure; I think I'm erring on the side of caution.
>
>
> >
> > The C++ API could throw an error whenever there is an error in the
> > context
> > after compiling.
>
> Sounds good.
>

Thanks for all these prompt responses.  You can expect some patches during
the next few days. :)



>
> >
> >
> > > With those in place, it looks like either the client code needs to
> > > check gcc::jit::context::get_last_error on failure, or, better, it
> > > should probably change to look something like this (untested):
> > >
> > > inline void
> > > context::compile_to_file (enum gcc_jit_output_kind output_kind,
> > >                           const char *output_path)
> > > {
> > >   if (gcc_jit_context_compile_to_file (m_inner_ctxt,
> > >                                        output_kind,
> > >                                        output_path))
> > >     throw error (m_inner_ctxt);
> > > }
> > >
> > > where error's ctor should call gcc::jit::context::get_last_error on
> > > the
> > > ctxt, or something similar to this.
> > >
> > >
> > > Sorry about the C++ API being much less polished that the C API.
> > >
> >
> > There absolutely no need to excuse :).  libgccjit is a great idea and
> > piece
> > of software.  That's the nice thing about free software that people who
> > need a more polished API can contribute.
> > Marc
>
> Indeed.  I was tempted to say "patches welcome", but that can come
> across as rather passive-aggressive :)
>

:) "Welcome" is a nice and friendly word, isn't it?


> Out of curiosity, are you using the C++ API for something, and would
> you like it on the "Who's using this code?" section on
> https://gcc.gnu.org/wiki/JIT ?
>

My "something" is far from finished.  But I will come back to you when I
have something to show.  What I can say so far is that the C++ API really
saves a lot of typing.

Marc