Poll: Primary D version
SeeWebsiteForEmail at erdani.org
Sun May 23 06:36:08 PDT 2010
On 05/23/2010 04:47 AM, Pelle wrote:
> On 05/23/2010 10:14 AM, Mike Parker wrote:
>> And I would argue that it's unreasonable to expect the declarations of C
>> functions to be declared const-correct based on their usage. To my
>> knowledge, all of the C bindings for D to date either don't use const at
>> all (because they were created for D1) or use it according to the
>> declarations in the C headers. Which means there are numerous C
>> functions out there with non-const params that do not modify them.
> I do them according to the C headers, and the constness is almost always
> correct. Otherwise, it's a bug in the C headers!
Yes. My experience with C headers is that they're always careful about
inserting const for read-only pointer parameters.
>> Then there's the issue of compatibility between D1/D2. I've bound
>> several C libraries for D that need to support both D1/D2, Phobos/Tango.
>> Supporting const was one of the first headaches I encountered when
>> porting the original D1 bindings to D2. Finding that toStringz returned
>> a const string was a big surprise.
> It should probably be inout(char)* toStringz(inout(char)), or
> something like that.
It could, but what C functions output to a zero-terminated char*? I can
only think of unsafe ones, such as strcat() and gets(). Both are
More information about the Digitalmars-d