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


"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.

Ideally, it should have the semantics of std::copy().
On the other hand, it is not reasonable to expect GSL
to mirror all the semantic content of C++ std algorithms.
The language is limited, and so is the time of the developers.


> Can't application programmers check for this error
> just as easily as the GSL function does?

And similarly, GSL can check as easily as they.


> 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.


> What should application programmers do
> if they know that the vectors are the same length?

Continue typing?


> Are they obliged to test the return value anyway?

It is not an error to ignore a returned value
in the C computer programming language.


> 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. You could argue that the
compare interferes with pipelined
instruction scheduling. My response
to that: Yeah, so what?


> It seems to me that the GSL could easily provide one function
> ...
> that does not check vector lengths and another
> ...
> which does

That's not the right solution.


> Who is supposed to use the GSL?

People who need it right now.

> Apparently, performance isn't the first priority?

Correct.

> Is safety the first priority?

No.

> Does it really make sense to impose safety features
> on numerical application programmers
> who use a computer programming language like ANSI C
> which is inherently unsafe?

Yes.

> I don't think it is going to work.  Extensive testing
> is what makes ANSI C application programs safe and reliable --
> not run time error checking and handling.

Ok.


-- 
G. Jungman

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