Re: Re-implement VEC_* to be member functions of vec_t<T>

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Fri, Aug 24, 2012 at 10:50 AM, Marc Glisse <marc.glisse@inria.fr> wrote:
> On Thu, 23 Aug 2012, Diego Novillo wrote:
>
>> There is another issue that I need to address and I'm not quite
>> sure how to go about it: with the macro-based API, we make use of
>> pre-processor trickery to insert __FILE__, __LINE__ and
>> __FUNCTION__ into the argument list of functions.
>>
>> When I change VEC_pop(V) with V->pop(), the macro expansion no
>> longer exists and we lose the caller references.  Richi, I
>> understand that your __builtin_FILE patch would allow me to
>> declare default values for these arguments? Something like:
>>
>> T vec_t<T>::pop(const char *file_ = __builtin_FILE,
>>                 unsigned line_ = __builtin_LINE,
>>                 const char *function_ = __builtin_FUNCTION)
>>
>> which would then be evaluated at the call site and get the right
>> values.  Is that more or less how your solution works?
>>
>> If so, then we could get away with that in most cases.  However,
>> we would still have the problem of operator functions (e.g.,
>> vec_t::operator[]).
>
>
> Hello,
>
> it seems like you have found a better solution, but I'll just mention
> quickly a way to handle operator[]:
>
> struct debug_int
> {
>   debug_int (int i_, const char *file_ = __builtin_FILE ())
>     : i (i_), file (file_) {}
>   int i;
>   const char *file;
>   operator int () const { return i; }
> };
>
> struct vec {
> ...
>   T operator[] (debug_int arg) const {
>     gcc_assert (...);
>   }
> ...
> };
>
> vec v;
> v[3];
>
> This gets the information into the function. Extracting it in gcc_assert is
> a bit painful and forces the name arg to be the same everywhere :-(
> But at least the callers are not uglified.


Did not we discourage implicit conversions?

I would just use C++ standard function `at()' (e.g. as found in vector<T>)
for this.

-- Gaby