bug-gsl
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gsl] Gsl_vector_const_view


From: Leibs, Jeremy
Subject: [Bug-gsl] Gsl_vector_const_view
Date: Mon, 4 Dec 2006 17:21:09 -0800

I think the way const's are dealt with in gsl_vector_views (and matrix
views) is possibly flawed.  If it's not flawed I'm missing something
fundamental in the way they are intended to  be used.

The gsl_vector_const_view is currently just implemented as a const
gsl_vector_view (which I'm sure was the easiest way to do it that works
in most cases).  While this forces the vector member to be const, it
means that the block pointer becomes a const pointer to non-const data
("gsl_block* const block" when I think we want "const gsl_block*
block"?).  This means there is nothing actually protecting the data
itself other than the const wrapper being interpreted by functions that
are designed to take gsl_vector*s as inputs.

As a demonstration of the problem consider:

  const double data1[] = {1, 2, 3, 4};
  const double* data2;

  data2 = data1;    //This is appropriately legal

  // Clearly these will not work:

  // data1[0] = 10;

  // data2[0] = 10;


  gsl_vector_const_view A = gsl_vector_const_view_array(data2, 4);

  // constness keeps this from working:
  // gsl_vector_set(&A.vector, 0, 10);


  // But this works just fine:
                                                       
  gsl_vector_view B;
  B.vector = A.vector; //This assignment should not be legal

  gsl_vector_set(&B.vector, 0, 10);

  printf("data1: [ %g, %g, %g, %g]\n", data1[0], data1[1], data1[2],
data1[3]);
  //---> data1: [ 10, 2, 3, 4]  -- We've changed our const data.


Morever, the current construction also prevents re-use of
gsl_vector_const_view structures since they are unnecessarily const
themselves.  Just because the view points to const data does not mean
the view itself should have to be const.

Something along the lines of:

gsl_vector_const_view A;
A = gsl_vector_const_view_array(data1, n);
A = gsl_vector_const_view_array(data2, n);

ought to be a legal statement as long as.

gsl_vector_set(A, 0, 10);

Is not legal.  Sadly, this is not the case and a completely new view
object must be created for each view we wish to use.

It seems the more correct way of dealing with this is an actual
const_vector struct such as:

typedef struct
{
  size_t size;
  size_t stride;
  const gsl_block* block;
  int owner; 
}
gsl_const_vector;

I'd offer suggestions to fix the actual code but I'm having trouble
wading through the nest of macros that allow code re-use for all the
different types.

--Jeremy Leibs



reply via email to

[Prev in Thread] Current Thread [Next in Thread]