This is the mail archive of the
gsl-discuss@sourceware.org
mailing list for the GSL project.
Re: containers tentative design summary
- From: "Justin Lenzo" <j-lenzo at northwestern dot edu>
- To: gsl-discuss at sourceware dot org
- Date: Thu, 19 Nov 2009 13:51:04 -0600 (CST)
- Subject: Re: containers tentative design summary
> At Thu, 29 Oct 2009 17:40:30 -0400,
> James Bergstra wrote:
> > If the purpose is to protect the user from accidentally messing around
> > with data then, as Gerard suggests, maybe we shouldn't bother. This
> > is not a battle that we can win in C. Good naming conventions for
> > functions, which indicate the arguments that will be modified, is the
> > most that a C library is expected to provide.
>
> The purpose is to make programs safer, rather than provide any hints
> for optimisation. The current system is type-safe and gives a
> "discarding const" compiler warning if people try to pass const
> objects to functions as non-const arguments - these seem like useful
> features. It's not clear to me what the actual benefit would be if we
> only had non-const vectors and matrices.
>
What if you went with a structure like the following:
typedef struct {
const double *data;
double *wdata;
...
} gsl_vector;
When a gsl_vector is allocated, the array is attached to 'wdata' and
aliased to 'data'. When a read-only vector view is made, it returns a
new instance of the gsl_vector datatype where the 'data' and other
members are copied over, but sets 'wdata' to NULL. Basically, you
would be allowing the same datatype to cover allocated vectors,
read-write views, and read-only views. It seems to me this achieves
the goal of protecting underlying read-only data, as long as your
willing to check for NULL pointers in the routines that write to a
vector. I don't know anything about the security implications, so
forgive me if this is a dangerous approach.