gsl_vector_const_view: pointer to constant or constant pointer

gsl_vector_const_view: pointer to constant or constant pointer

[Fleur Kelpin]

Hi all!

Compiling

#include <gsl/gsl_vector.h>

int main()
{
  const double x[]={1,2,3,4};
  gsl_vector_const_view xview;
  xview = gsl_vector_const_view_array(x,4);
  return 0;
}

gives a
warning: assignment of read-only variable `xview'
since (in gsl_vector_double.h) gsl_vector_const_view is declared as a
constant pointer to a _gsl_vector_const_view:

typedef struct
{
  gsl_vector vector;
} _gsl_vector_const_view;

typedef const _gsl_vector_const_view gsl_vector_const_view;
        ^^^^^

Is this as intended? The manual states that 'Vector views can be defined
for both constant and non-constant vectors, using separate types that
preserve constness'. It seems to me that the point of the special const
type is to prevent changes to the vector viewed, not also changes to the
pointer to the view. I could easily prevent such changes to the pointer
myself when necessary, declaring

const gsl_vector_const_view xview;

But currently you cannot choose!

Am I missing something or can/could/should this be fixed?
(I think this can be done by moving the const inside the struct:

typedef struct
{
  const gsl_vector vector;
} _gsl_vector_const_view;

typedef _gsl_vector_const_view gsl_vector_const_view;

)

Greetings,
Fleur

Re: gsl_vector_const_view: pointer to constant or constant pointer

[Fleur Kelpin]

Hi again!

Obviously the point I missed is that there are no pointers being used so
moving the const inside the struct makes no difference at all.

Next time I'll drink my coffee first, then post to the list.

Greetings,
Fleur

Re: gsl_vector_const_view: pointer to constant or constant pointer

[M Joonas Pihlaja]

On Sat, 10 Aug 2002, Fleur Kelpin wrote:

> Hi all!

[snip code with gsl_vector_const_view]

> Am I missing something or can/could/should this be fixed?

IMHO, the 'const' structures in GSL should be avoided.  The basic
trouble is the constness-of-container vs. constness-of-containee
difficulty as you point out, punctuated by the fact that vector
views are themselves 'containers' for vectors (that in turn are
containers for the vector data itself).  C (and arguably C++,
without jumping through hoops) does not really facilite making
the difference.

Regards,

Joonas Pihlaja

Re: gsl_vector_const_view: pointer to constant or constant pointer

[Brian Gough]

Fleur Kelpin writes:
 > Am I missing something or can/could/should this be fixed?
 > (I think this can be done by moving the const inside the struct:
 > 
 > typedef struct
 > {
 >   const gsl_vector vector;
 > } _gsl_vector_const_view;

It's not possible to initialise the struct element with this form in
ANSI C (although it is possible in gcc).  This is why the const'ing is
done at a higher level in a wrapper.

Re: gsl_vector_const_view: pointer to constant or constant pointer

[Fleur Kelpin]

> It's not possible to initialise the struct element with this form in
> ANSI C (although it is possible in gcc).  This is why the const'ing is
> done at a higher level in a wrapper.

I found this out later, when I tried and considered some of the
alternatives and I think I discovered some of the the reasons for the gsl
vector setup.

Is it correct that the definition
typedef struct
{
  const gsl_vector *vector;
} gsl_vector_const_view;
would have the advantage that gsl_vector_const_view s can be initialized
and reassigned but the disadvantage that memory is allocated for the
vectors in the views and will need to be freed after use?

I ended up changing to non-const gsl_vector_view and casting the const
from my arrays, as Joohnas Pihlaja suggested. The other solution I could
think of was sticking to const double * s and creating the
gsl_vector_const_view only last minute when I need it.

Re: gsl_vector_const_view: pointer to constant or constant pointer

[Brian Gough]

Fleur Kelpin writes:
 > Is it correct that the definition
 > typedef struct
 > {
 >   const gsl_vector *vector;
 > } gsl_vector_const_view;
 > would have the advantage that gsl_vector_const_view s can be initialized
 > and reassigned but the disadvantage that memory is allocated for the
 > vectors in the views and will need to be freed after use?

Views are intended to be lightweight objects -- this is the main
reason they are allocated on the stack, to avoid the overhead of
calling malloc.  It also means that they don't have to be freed.

 > I ended up changing to non-const gsl_vector_view and casting the const
 > from my arrays, as Joohnas Pihlaja suggested. The other solution I could
 > think of was sticking to const double * s and creating the
 > gsl_vector_const_view only last minute when I need it.

The latter is definitely preferred.  Views should always be
initialised at the same time they are defined, opening up a new scope
if needed.  It should not be necessary to cast away const when using
GSL.

e.g.

int main()
{
  const double x[]={1,2,3,4};
  ...
 
   {
      gsl_vector_const_view xview = gsl_vector_const_view_array(x,4);
      ....
    }
  return 0;
}