This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GSL Error Handling


Gerard Jungman <jungman at lanl dot gov> wrote:

> "E. Robert Tisdale" wrote:
> >
> > Take this function,
> >
> >         int
> >         gsl_vector_memcpy(gsl_vector* dest, const gsl_vector* src) {
>
> Yes, there is no reason it should not copy part of the vectors
> if size(src) < size(dest). Brian may want to change that.

So would it still return an error code if size(src) < size(dest)?

> > Is this necessarily a fatal error?
>
> It is if size(src) > size(dest).
> That is the meaning of that copy operation.
> If you want to introduce another semantic for copy, fine.
> Maybe it will even be implemented.
>But it won't be _this_ copy.

No.
I don't want to introduce another semantic.
I think that the the result (the contents of dest)
should be undefined unless size(src) == size(dest).

> > Isn't the error checking a waste of time and
> > doesn't it contribute to code bloat
> > if the source and destination vector lengths
> > are always the same length?
>
> Yes, we're all very worried about the bloat
> caused by single register compare instructions.

Did you forget about the error reporting and handling?

    GSL_ERROR ("vector lengths are not equal", GSL_EBADLEN);

I think you have sacrificed performance for no real benefit at all.
The GSL won't help ANSI C numerical application programmers
write safer, more reliable code.
It will just slow down their applications.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]