Re: [Plplot-devel] A comment style issue

2010-02-08 Thread Alan W. Irwin
On 2010-01-22 08:39+0100 Arjen Markus wrote:

> Hi Alan,
>
> I have so far been using the /* ... */ for most, if not all, my C code.
> The reason being that it was C, not C++. As all compilers that are
> relevant to me are indeed accepting this by default, I have no objection
> whatsoever to adopting //. In fact, it makes it much clearer what is and
> what is not comment.

It's been some time now with no further comments on this thread so I would
like to follow up on this topic with a decision. The consensus (with no
dissenting opinions) seems to be that // comments would be fine for C code.
So I intend to use // style comments from now on in C code, and I encourage
their use with other developers.  Of course, converting our existing
comment-style to the // form would be a pain if done by hand.  Therefore, in
the interests of uniform style I am going to inquire with the uncrustify
developers whether they would be willing to implement a style option for
both C and C++ code that converts all single and multiple line /*... */
comments to the // form.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__

Linux-powered Science
__

--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel


[Plplot-devel] [PATCH] Move definitions of pltr0f and pltr2f to plcont.c

2010-02-08 Thread David MacMahon

Moves the definitions of pltr0f and pltr2f (both declared in plplot.h)
from the sccont.c files of the FORTRAN bindings into plcont.c.
---
 bindings/f77/sccont.c |  197 -
 bindings/f95/sccont.c |  197 -
 src/plcont.c  |  197 +
 3 files changed, 197 insertions(+), 394 deletions(-)

diff --git a/bindings/f77/sccont.c b/bindings/f77/sccont.c
index 5e96c23..3b277f9 100644
--- a/bindings/f77/sccont.c
+++ b/bindings/f77/sccont.c
@@ -25,203 +25,6 @@
 #include "plstubs.h"
 
 /*--*\
- * pltr0f()
- *
- * Identity transformation for plots from Fortran.
- * Only difference from C-language identity function (pltr0) is that the
- * Fortran paradigm for array index is used, i.e. starting at 1.
- \*--*/
-
-void
-pltr0f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data )
-{
-*tx = x + 1.0;
-*ty = y + 1.0;
-}
-
-/*--*\
- * pltr2f()
- *
- * Does linear interpolation from doubly dimensioned coord arrays
- * (row dominant, i.e. Fortran ordering).
- *
- * This routine includes lots of checks for out of bounds.  This would
- * occur occasionally due to a bug in the contour plotter that is now fixed.
- * If an out of bounds coordinate is obtained, the boundary value is provided
- * along with a warning.  These checks should stay since no harm is done if
- * if everything works correctly.
- \*--*/
-
-void
-pltr2f( PLFLT x, PLFLT y, PLFLT *tx, PLFLT *ty, void *pltr_data )
-{
-PLINT   ul, ur, vl, vr;
-PLFLT   du, dv;
-PLFLT   xll, xlr, xrl, xrr;
-PLFLT   yll, ylr, yrl, yrr;
-PLFLT   xmin, xmax, ymin, ymax;
-
-PLcGrid *cgrid = (PLcGrid *) pltr_data;
-PLFLT   *xg= cgrid->xg;
-PLFLT   *yg= cgrid->yg;
-PLINT   nx = cgrid->nx;
-PLINT   ny = cgrid->ny;
-
-ul = (PLINT) x;
-ur = ul + 1;
-du = x - ul;
-
-vl = (PLINT) y;
-vr = vl + 1;
-dv = y - vl;
-
-xmin = 0;
-xmax = nx - 1;
-ymin = 0;
-ymax = ny - 1;
-
-if ( x < xmin || x > xmax || y < ymin || y > ymax )
-{
-plwarn( "pltr2f: Invalid coordinates" );
-
-if ( x < xmin )
-{
-if ( y < ymin )
-{
-*tx = *xg;
-*ty = *yg;
-}
-else if ( y > ymax )
-{
-*tx = *( xg + ( ny - 1 ) * nx );
-*ty = *( yg + ( ny - 1 ) * nx );
-}
-else
-{
-ul  = 0;
-xll = *( xg + ul + vl * nx );
-yll = *( yg + ul + vl * nx );
-xlr = *( xg + ul + vr * nx );
-ylr = *( yg + ul + vr * nx );
-
-*tx = xll * ( 1 - dv ) + xlr * ( dv );
-*ty = yll * ( 1 - dv ) + ylr * ( dv );
-}
-}
-else if ( x > xmax )
-{
-if ( y < ymin )
-{
-*tx = *( xg + ( nx - 1 ) );
-*ty = *( yg + ( nx - 1 ) );
-}
-else if ( y > ymax )
-{
-*tx = *( xg + ( nx - 1 ) + ( ny - 1 ) * nx );
-*ty = *( yg + ( nx - 1 ) + ( ny - 1 ) * nx );
-}
-else
-{
-ul  = nx - 1;
-xll = *( xg + ul + vl * nx );
-yll = *( yg + ul + vl * nx );
-xlr = *( xg + ul + vr * nx );
-ylr = *( yg + ul + vr * nx );
-
-*tx = xll * ( 1 - dv ) + xlr * ( dv );
-*ty = yll * ( 1 - dv ) + ylr * ( dv );
-}
-}
-else
-{
-if ( y < ymin )
-{
-vl  = 0;
-xll = *( xg + ul + vl * nx );
-xrl = *( xg + ur + vl * nx );
-yll = *( yg + ul + vl * nx );
-yrl = *( yg + ur + vl * nx );
-
-*tx = xll * ( 1 - du ) + xrl * ( du );
-*ty = yll * ( 1 - du ) + yrl * ( du );
-}
-else if ( y > ymax )
-{
-vr  = ny - 1;
-xlr = *( xg + ul + vr * nx );
-xrr = *( xg + ur + vr * nx );
-ylr = *( yg + ul + vr * nx );
-yrr = *( yg + ur + vr * nx );
-
-*tx = xlr * ( 1 - du ) + xrr * ( du );
-*ty = ylr * ( 1 - du ) + yrr * ( du );
-}
-}
-}
-
-/* Normal case.
- * Look up coordinates in row-dominant array.
- * Have to handle right boundary specially -- if at the edge, we'd
- * better not reference the out of bounds point. */
-
-else
-{
-xll = *( xg + ul + vl * nx );
-