public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Gerard Jungman <jungman@lanl.gov>
To: gsl-discuss@sourceware.org
Subject: Re: containers tentative design summary
Date: Tue, 27 Oct 2009 23:06:00 -0000	[thread overview]
Message-ID: <1256684949.19313.2.camel@manticore.lanl.gov> (raw)
In-Reply-To: <m34opqnred.wl%bjg@network-theory.co.uk>

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

On Fri, 2009-10-23 at 14:58 +0100, Brian Gough wrote: 
> 
> I think this is an interesting example.  How would these two classes
> work in practice in C? For example, how would one pass a non-const
> matrix (taken as a view of a non-const multi-array) to a function
> taking a const matrix argument.  Dealing with the interaction between
> const and non-const arguments is a fundamental issue.

> The challenge for any scheme is getting reasonable const behavior in
> C.  If that problem can be solved better then everything else follows
> more easily.


Ok. The attachment is the obvious solution. I don't want to have
theological wars about this, but it seems to me like it is
the "C way". Let's debate.

--
G. Jungman


[-- Attachment #2: foobar.c --]
[-- Type: text/x-csrc, Size: 1438 bytes --]

#include <stdlib.h>


/* The union guarantees that the structs are aligned, in C99.
 *
 * In C90, standard does not discuss the issue, but all
 * compilers known to man align them anyway. The C99
 * guarantee seems to be an attempt to standardize
 * that behaviour.
 *
 * The union type is never actually used, unless somebody
 * can think of a reason to use it...
 */
union gsl_vector_union_t
{
  struct gsl_vector_struct_t
  {
    double * data;
    size_t   size;
    int      stride;
  } as_vector;

  struct gsl_const_vector_struct_t
  {
    const double * data;
    size_t   size;
    int      stride;
  } as_const_vector;
};


typedef  struct gsl_vector_struct_t        gsl_vector;
typedef  struct gsl_const_vector_struct_t  gsl_const_vector;



void gsl_some_typical_function(const gsl_vector * v)
{
  /* do something which might twiddle v.data[] */
}

void gsl_some_typical_const_function(const gsl_const_vector * v)
{
  /* do something which does not twiddle v.data[] */
}



int main()
{
  gsl_vector v;
  gsl_const_vector cv;


  /* might be twiddling v.data[] */
  gsl_some_typical_function(&v);

  /* claims not to twiddle cv.data[] */
  gsl_some_typical_const_function(&cv);

  /* claims not to twiddle v.data[] */
  gsl_some_typical_const_function((const gsl_const_vector *) &v);

  /* a misuse; but this sort of thing can never be prevented anyway */
  gsl_some_typical_function((const gsl_vector *) &cv);

  return 0;
}

  reply	other threads:[~2009-10-27 23:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-05 10:12 Gerard Jungman
2009-10-05 14:50 ` James Bergstra
2009-10-05 23:00   ` Gerard Jungman
2009-10-05 23:45     ` James Bergstra
2009-10-06 19:59       ` Gerard Jungman
     [not found]     ` <645d17210910060537s762d6323pfd2bec8590ad28e9@mail.gmail.com>
2009-10-06 20:02       ` Gerard Jungman
2009-10-23 21:28     ` Brian Gough
2009-10-27 23:06       ` Gerard Jungman [this message]
     [not found]         ` <7f1eaee30910271628h70785125m68e47c7a7b5c25b7@mail.gmail.com>
2009-10-27 23:49           ` Gerard Jungman
2009-10-29 18:06         ` Brian Gough
2009-10-29 20:41           ` Gerard Jungman
2009-10-29 21:40             ` James Bergstra
2009-10-30 16:54               ` Brian Gough
2009-10-30 16:54             ` Brian Gough
2009-10-05 23:04   ` some general questions Gerard Jungman
2009-10-06 16:21     ` Brian Gough
2009-10-06 20:32       ` Gerard Jungman
2009-10-10 14:45         ` Tuomo Keskitalo
2009-10-24 11:16           ` Brian Gough
2009-10-14 20:00         ` Brian Gough
2009-10-15 18:39           ` Tuomo Keskitalo
2009-11-03 19:44 containers tentative design summary Gerard Jungman
2009-11-09 20:41 ` Brian Gough
2009-11-09 23:06   ` Gerard Jungman
2009-11-14 15:25     ` Brian Gough
2009-11-15  9:13       ` Tuomo Keskitalo
2009-11-15 16:44         ` Jonathan Underwood
2009-11-15 18:41           ` Robert G. Brown
2009-11-16 11:56         ` Brian Gough
2009-11-20  9:37 Justin Lenzo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1256684949.19313.2.camel@manticore.lanl.gov \
    --to=jungman@lanl.gov \
    --cc=gsl-discuss@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).