[dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro

Bruce Richardson bruce.richardson at intel.com
Thu Mar 10 10:26:03 CET 2016


On Thu, Mar 10, 2016 at 09:29:03AM +0100, Olivier MATZ wrote:
> >> If you have a better alternative, without duplicating the code,
> >> I'll be happy to learn.
> > 
> > I really don't like this dropping of const either, but I do see the problem.
> > I'd nearly rather see two copies of the function than start dropping the const
> > in such a way.
> 
> I don't think duplicating the code is a good option.

Personally, I'd actually prefer it to eliminating const-ness. I'm a big fan of
having the compiler work for it's pay by doing typechecking for us. :-) 
However, I would hope that by using a macro, as I suggest below, we could have
two functions without duplicating all the code.

> 
> > Also, I'd see having the function itself be a wrapper around a
> > macro as a better alternative too, assuming such a construction is possible.
> 
> Sorry, I'm not sure to understand. Could you please elaborate?
> 
The part of the code which iterates through the elements and calls a function
for each could be a macro, which would mean that it would be fine to use the
macro with a const mempool so long as the function being called took const
parameters too, i.e. the type checking is done post-expansion. Basically,
doing a multi-type function via macro (like MIN/MAX macros etc).

Haven't tried writing the code for it though, so no idea if it's actually doable
or what the result looks like. However, at worst I would think you could 
extract the body of the function to make it a macro, and then call it from two
wrapper functions, one of which takes non-const param, the other of which
takes const param. The macro itself could use typeof() internally to maintain
const-ness or not.

/Bruce


More information about the dev mailing list