Translating C const

Jonathan M Davis jmdavisProg at gmx.com
Sat May 26 10:34:08 PDT 2012


On Saturday, May 26, 2012 13:05:00 Jacob Carlborg wrote:
> On 2012-05-26 01:17, Jonathan M Davis wrote:
> >> Ok I see, thanks. Is that true for fields in structs and global
> >> variables as well?
> > 
> > Anyway, I suppose that that's not terribly conclusive, but the lack of
> > ability to have non-transitive const declarations is a bit of a problem
> > when dealing with extern(C) functions given that it has behaviors that D
> > _doesn't_ have. As far as I can see, whether constifying the whole thing
> > or making it all mutable makes more sense really depends on what the C
> > function is doing and how it's called, which naturally doesn't go well
> > with a tool like you're creating. You'll probably have to go with what is
> > _least_ likely to cause bugs and then let the programmer adjust it as
> > needed.
> > 
> > - Jonathan M Davis
> 
> What do you think about translating the C const to D where possible and
> then just leave it mutable in all other cases. Then assuming the C code
> will not cast away const. A user is always free to edit the bindings
> manually.

That seems like a good approach, since then you're not marking things as const 
in D that C would consider mutable and therefore be likely to be altered, 
breaking D's guarantees. It does make me think that it could be valuable to 
include a comment with the original declaration though (at least in cases 
where a direct translation isn't possible). That way, it would be clearer that 
the signature in D isn't quite right. e.g.

/**
    Comment
  */
extern(C) void func(int*const* param);

becomes something like

/**
    Comment
  */
extern(C) void func(int** param);
//orig: void func(int*const* param);

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list