On Fri, Aug 24, 2012 at 10:50 AM, Marc Glisse <marc.gli...@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
