Hi Sebastian, Thanks for your input. I think you're right about the second "const". I added it for the extra checking from the compiler, to prevent the dumb bugs from accidentally changing pointer. It's a lot of extra verbiage just for that one benefit, though.
The reason I put the const after the type specifier is due to the right-to-left order for reading pointer declarations: http://en.wikipedia.org/wiki/Const-correctness#C.2B.2B_syntax So my mild preference would be this: pmCartCartDot(PmCartesian const *v1, PmCartesian const *v2, double *dot) I can understand that this might conflict with style and other coder's intuition, though, so I'm definitely fine with your version if that's more widely favored. You mentioned release 2.6; is there a release date / milestones for this next version? -Rob On Thu, Oct 24, 2013 at 11:14 PM, Sebastian Kuzminsky <s...@highlab.com>wrote: > On 10/24/2013 11:23 AM, Robert Ellenberg wrote: > > It seems like the "right" way is to pass pure inputs by reference using > > constant pointers: > > I almost agree! > > I think the right way to pass big inputs is to use pointers to constant > memory. > > > > Instead of this: > > > > pmCartCartDot(PmCartesian v1, PmCartesian v2, double * dot) > > > > It would look like this with "constant pointer to constant" inputs: > > > > pmCartCartDot(PmCartesian const * const v1, PmCartesian const * const v2, > > double * const dot) > > I like the first const in the declaration of v1 and v2, but I don't > think the second const (or the const in the declaration of dot) is all > that useful. It says pmCartCartDot() won't change v1, v2, or dot, but > those variables are all locals, so who cares? > > I guess the second const (and the only const on dot) would give us a > compile-time warning if the called function modifies where in memory its > local copy of the pointer is pointing to, but that seems like a small > benefit for the added syntactic complexity. > > My preference would be: > > pmCartCartDot(const PmCartesian *v1, const PmCartesian *v2, double *dot) > > > > I've tested this change on a few of the posemath functions already > without > > any issues, but I'd like to know what the community thinks before I start > > making major changes. > > I approve (modulo the minor quibble above), and I'd welcome a change > like this in master for 2.6. > > > -- > Sebastian Kuzminsky > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
