C++ API: Vector arguments / error detection

[Marc Nieper-Wißkirchen]

Probably more important than changing std::vector <...> &args to const
std::vector <...> &args is to offer an extra set of methods that take a
std::initializer_list instead of a vector.  These should be allocated on
the stack and not on the heap, improving efficiency when the argument lists
are known ahead.


Am Mo., 31. Jan. 2022 um 16:32 Uhr schrieb 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> ¶ms;
>> > > >
>> > > > 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
>
>