From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 175DF29B6 for ; Thu, 10 Mar 2016 10:26:26 +0100 (CET) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 10 Mar 2016 01:26:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,315,1455004800"; d="scan'208";a="933702774" Received: from ugavish-mobl1.ger.corp.intel.com ([10.252.20.226]) by fmsmga002.fm.intel.com with SMTP; 10 Mar 2016 01:26:04 -0800 Received: by (sSMTP sendmail emulation); Thu, 10 Mar 2016 09:26:03 +0025 Date: Thu, 10 Mar 2016 09:26:03 +0000 From: Bruce Richardson To: Olivier MATZ Message-ID: <20160310092602.GA14712@bricha3-MOBL3> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E1304F.1000808@6wind.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) 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 09:26:27 -0000 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