public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
* orthogonal issues
@ 2014-11-05 22:52 Gerard Jungman
  0 siblings, 0 replies; only message in thread
From: Gerard Jungman @ 2014-11-05 22:52 UTC (permalink / raw)
  To: gsl-discuss


The previous message does not address a couple of
orthogonal issues. The first one seems simple,
but I am unsure of the consequences of a
change.

Currently, the 'stride' arguments are all size_t, and
therefore unsigned. This seems odd, since it precludes
the possibility of traversing vectors in reverse. Could
all the strides be changed to signed quantities?

As an aside, I will say that I really loathe unsigned types.
They are almost useless. The common arguments for their use
are spurious. I learned this many years ago, from painful
experience, and from Lakos' book "Large-Scale C++ Software Design",
where he advocates eliminating unsigned types from all interfaces.


The second issue is big and painful. What do we do about the
'restrict' keyword? There is no doubt that 'restrict' helps
in some situations. Sometimes it helps a lot.

The 'restrict' keyword is technically a modifier of the same class
as 'const'. So it multiplies the number of implied types in your head.
Very nasty for interface explosion.

One possibility is to bake-in the 'restrict' keyword
to the container types. It could be turned off with
a compile-time option. Of course, this requires that
all GSL implementations be truly restrict-correct.
But I am willing to guess that they are.

When used in C++ code, the headers can test for
an appropriate platform-dependent substitute,
like '__restrict__' or '__restrict'.


It would become part of the contract that clients should
insure that their data segments do not overlap, just like
when they choose to use memcpy().

Is this too much to ask?

Be careful how you answer. For example, if you are using
a drop-in replacement for matrix operations or linear algebra
(any library other than libgslcblas), then you might already
be subject to such a contract. The underlying implementation
may well be written in Fortran.

To understand aliasing problems and the motivation for
'restrict', I recommend reading Ulrich Drepper's series
of articles, starting with part 5 if you are in a hurry:
   https://lwn.net/Articles/255364/

--
G. Jungman

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2014-11-05 22:52 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-05 22:52 orthogonal issues Gerard Jungman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).