From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.droids-corp.org (zoll.droids-corp.org [94.23.50.67]) by dpdk.org (Postfix) with ESMTP id 1F3C52BB2 for ; Thu, 10 Mar 2016 11:05:52 +0100 (CET) Received: from was59-1-82-226-113-214.fbx.proxad.net ([82.226.113.214] helo=[192.168.0.10]) by mail.droids-corp.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1adxV5-0006ub-CG; Thu, 10 Mar 2016 11:07:23 +0100 To: Bruce Richardson References: <1457540381-20274-1-git-send-email-olivier.matz@6wind.com> <1457540381-20274-11-git-send-email-olivier.matz@6wind.com> <56E08BE7.6030906@6wind.com> <20160309212232.GB8020@bricha3-MOBL3> <56E1304F.1000808@6wind.com> <20160310092602.GA14712@bricha3-MOBL3> From: Olivier MATZ X-Enigmail-Draft-Status: N1110 Message-ID: <56E146F8.2070403@6wind.com> Date: Thu, 10 Mar 2016 11:05:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <20160310092602.GA14712@bricha3-MOBL3> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [RFC 10/35] eal: introduce RTE_DECONST macro X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2016 10:05:52 -0000 Hi Bruce, On 03/10/2016 10:26 AM, Bruce Richardson wrote: > 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. Does it mean we should duplicate all iterate-like functions of the DPDK to have a const and a non-const version? I would personally find this quite odd. >>> 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. OK, it's clearer, thanks. But I'm not sure having several lines of code inside a macro is something we should encourage either. To summarize, I see 4 solutions: 1 do a discreet cast: I think that's what people usually do in these cases, I would not be suprised to find several in current DPDK 2 use a RTE_DECONST() macro: it points out that we are doing a bad cast, which is a valuable info for the reviewer (proof: you saw it :) ) 3 duplicate the iterate functions to have a const and a non-const version and use a macro to duplicate the code 4 remove the const for these iterate functions, implying to remove const in some other functions like dumps. I still personally prefer solution 2, because it keeps the API clean, giving the proper information to the user and the compiler "this mempool structure won't be modified". Using a cast like this should of course be avoided most of the time, but I think it's acceptable in cases like this, knowing that it is properly pointed-out by the RTE_DECONST macro. Regards, Olivier