You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ben Laurie <be...@algroup.co.uk> on 2000/07/10 10:57:38 UTC
Re: cvs commit: apache-2.0/src/lib/apr/lib apr_hash.c
gstein@locus.apache.org wrote:
> -=head1 void *ap_hash_get(ap_hash_t *ht, void *key, size_t klen)
> +=head1 void *ap_hash_get(ap_hash_t *ht, const void *key, size_t klen)
Surely ap_hash_get() should return a const void *???
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: cvs commit: apache-2.0/src/lib/apr/lib apr_hash.c
Posted by Ben Laurie <be...@algroup.co.uk>.
Tony Finch wrote:
>
> Ben Laurie wrote:
> >Greg Stein wrote:
> >>
> >> [ and no, tracking const-ness would not be a good thing to add ]
> >
> >Why not?
> >
> >> Adding the "const" on the ap_hash_set() allows you to actually place const
> >> data in there. Without the const, you get errors on the set() if you have
> >> const data. But if the get() is non-const, then you can place it into const
> >> or non-const pointers.
> >
> >Which means you can deconstify a const, accidentally. Which is why
> >tracking constness _is_ a good thing. IMO.
>
> I think that you are trying to do something that the language will not support.
Oh?
> I agree that it is a good idea to try to find as many errors at compile time
> as possible, and constness and other type issues are a substantial part of
> this, but in this situation the problem can only be solved by the sort of fully
> polymorphic type system that C doesn't have. If you want Haskell you know where
> to find it.
>
> The *only* way to fix this problem in C is with code duplication for the const
> and non-const cases. (In C++ the compiler can do this for you; I doubt the
> implementation of templates is clever enough yet to avoid pointless code
> duplication.)
Ah, so it will support it, but not in a way you approve of. Two minor
points:
a) You can probably reduce the duplication to a small amount of wrapper
code, and none at all for the non-developer case (but then you also lose
the checking).
b) Templates are allegedly clever enough to avoid pointless code
duplication if you are clever enough to write them correctly. Stroustrup
goes into an alarming amount of detail about how this works in the
fatter versions of his book.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: cvs commit: apache-2.0/src/lib/apr/lib apr_hash.c
Posted by Tony Finch <do...@dotat.at>.
Ben Laurie wrote:
>Greg Stein wrote:
>>
>> [ and no, tracking const-ness would not be a good thing to add ]
>
>Why not?
>
>> Adding the "const" on the ap_hash_set() allows you to actually place const
>> data in there. Without the const, you get errors on the set() if you have
>> const data. But if the get() is non-const, then you can place it into const
>> or non-const pointers.
>
>Which means you can deconstify a const, accidentally. Which is why
>tracking constness _is_ a good thing. IMO.
I think that you are trying to do something that the language will not support.
I agree that it is a good idea to try to find as many errors at compile time
as possible, and constness and other type issues are a substantial part of
this, but in this situation the problem can only be solved by the sort of fully
polymorphic type system that C doesn't have. If you want Haskell you know where
to find it.
The *only* way to fix this problem in C is with code duplication for the const
and non-const cases. (In C++ the compiler can do this for you; I doubt the
implementation of templates is clever enough yet to avoid pointless code
duplication.)
Tony.
--
f.a.n.finch fanf@covalent.net dot@dotat.at
307 wriggling grunion in your slipstream
Re: cvs commit: apache-2.0/src/lib/apr/lib apr_hash.c
Posted by Ben Laurie <be...@algroup.co.uk>.
Greg Stein wrote:
>
> On Tue, Jul 11, 2000 at 10:38:12PM +0100, Ben Laurie wrote:
> > Greg Stein wrote:
> > >
> > > On Mon, Jul 10, 2000 at 09:57:38AM +0100, Ben Laurie wrote:
> > > > gstein@locus.apache.org wrote:
> > > > > -=head1 void *ap_hash_get(ap_hash_t *ht, void *key, size_t klen)
> > > > > +=head1 void *ap_hash_get(ap_hash_t *ht, const void *key, size_t klen)
> > > >
> > > > Surely ap_hash_get() should return a const void *???
> > >
> > > Nah. You might store a modifiable buffer into the hash table:
> > >
> > > buf = ap_pcalloc(p, BUFSIZE);
> > > ap_hash_set(ht, "hello", 0, buf);
> > > ...
> > >
> > > buf = ap_hash_get(ht, "hello", 0);
> > > sprintf(buf, "%d/%d", foo, bar);
> > >
> > > The get() function treats it as "const", and we store into the internal
> > > tables that way. But we drop the const right as we return it, since the
> > > notion of "const" is really up to the person who shoved the value in there.
> >
> > In which case you should be honest about that and not mark the value you
>
> We would need to do ap_hash_set_c() and ap_hash_set(). But of course, we
> don't track const-ness in the ADT, so the ap_hash_get() could switch it.
>
> [ and no, tracking const-ness would not be a good thing to add ]
Why not?
> Adding the "const" on the ap_hash_set() allows you to actually place const
> data in there. Without the const, you get errors on the set() if you have
> const data. But if the get() is non-const, then you can place it into const
> or non-const pointers.
Which means you can deconstify a const, accidentally. Which is why
tracking constness _is_ a good thing. IMO.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: cvs commit: apache-2.0/src/lib/apr/lib apr_hash.c
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Jul 11, 2000 at 10:38:12PM +0100, Ben Laurie wrote:
> Greg Stein wrote:
> >
> > On Mon, Jul 10, 2000 at 09:57:38AM +0100, Ben Laurie wrote:
> > > gstein@locus.apache.org wrote:
> > > > -=head1 void *ap_hash_get(ap_hash_t *ht, void *key, size_t klen)
> > > > +=head1 void *ap_hash_get(ap_hash_t *ht, const void *key, size_t klen)
> > >
> > > Surely ap_hash_get() should return a const void *???
> >
> > Nah. You might store a modifiable buffer into the hash table:
> >
> > buf = ap_pcalloc(p, BUFSIZE);
> > ap_hash_set(ht, "hello", 0, buf);
> > ...
> >
> > buf = ap_hash_get(ht, "hello", 0);
> > sprintf(buf, "%d/%d", foo, bar);
> >
> > The get() function treats it as "const", and we store into the internal
> > tables that way. But we drop the const right as we return it, since the
> > notion of "const" is really up to the person who shoved the value in there.
>
> In which case you should be honest about that and not mark the value you
We would need to do ap_hash_set_c() and ap_hash_set(). But of course, we
don't track const-ness in the ADT, so the ap_hash_get() could switch it.
[ and no, tracking const-ness would not be a good thing to add ]
Adding the "const" on the ap_hash_set() allows you to actually place const
data in there. Without the const, you get errors on the set() if you have
const data. But if the get() is non-const, then you can place it into const
or non-const pointers.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apache-2.0/src/lib/apr/lib apr_hash.c
Posted by Ben Laurie <be...@algroup.co.uk>.
Greg Stein wrote:
>
> On Mon, Jul 10, 2000 at 09:57:38AM +0100, Ben Laurie wrote:
> > gstein@locus.apache.org wrote:
> > > -=head1 void *ap_hash_get(ap_hash_t *ht, void *key, size_t klen)
> > > +=head1 void *ap_hash_get(ap_hash_t *ht, const void *key, size_t klen)
> >
> > Surely ap_hash_get() should return a const void *???
>
> Nah. You might store a modifiable buffer into the hash table:
>
> buf = ap_pcalloc(p, BUFSIZE);
> ap_hash_set(ht, "hello", 0, buf);
> ...
>
> buf = ap_hash_get(ht, "hello", 0);
> sprintf(buf, "%d/%d", foo, bar);
>
> The get() function treats it as "const", and we store into the internal
> tables that way. But we drop the const right as we return it, since the
> notion of "const" is really up to the person who shoved the value in there.
In which case you should be honest about that and not mark the value you
store as const.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
Coming to ApacheCon Europe 2000? http://apachecon.com/
Re: cvs commit: apache-2.0/src/lib/apr/lib apr_hash.c
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Jul 10, 2000 at 09:57:38AM +0100, Ben Laurie wrote:
> gstein@locus.apache.org wrote:
> > -=head1 void *ap_hash_get(ap_hash_t *ht, void *key, size_t klen)
> > +=head1 void *ap_hash_get(ap_hash_t *ht, const void *key, size_t klen)
>
> Surely ap_hash_get() should return a const void *???
Nah. You might store a modifiable buffer into the hash table:
buf = ap_pcalloc(p, BUFSIZE);
ap_hash_set(ht, "hello", 0, buf);
...
buf = ap_hash_get(ht, "hello", 0);
sprintf(buf, "%d/%d", foo, bar);
The get() function treats it as "const", and we store into the internal
tables that way. But we drop the const right as we return it, since the
notion of "const" is really up to the person who shoved the value in there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/