[vox] things that really suck about C!

[Kevin Schultz]

Const pointers vs. pointer to const is one of the nooks and crannies of C.
:)

Via http://blog.voidnish.com/?p=37:

"People new to C/C++ are sometimes confused about the difference between a
const pointer and a pointer to const. A const pointer essentially means you
can’t change the pointer variable itself, but you can change the value it
points to. A pointer to const means you can change the pointer but not what
it points to. You can use them both together and have a const pointer to a
const. The code snippet below should make it really clear I hope."

//pointer to a const
void f1()
{
int i = 100;
const int* pi = &i;
//*pi = 200; <- won't compile
pi++;
}

//const pointer
void f2()
{
int i = 100;
int* const pi = &i;
*pi = 200;
//pi++; <- won't compile
}

//const pointer to a const
void f3()
{
int i = 100;
const int* const pi = &i;
//*pi = 200; <- won't compile
//pi++; <- won't compile
}

On Sun, Feb 28, 2010 at 10:49 PM, Carl Boettiger <cboettig at gmail.com> wrote:

>
>
> On Sun, Feb 28, 2010 at 6:35 PM, Brian Lavender <brian at brie.com> wrote:
>
>> I think if anything, C has been a certain detriment to the field of
>> computer science!
>>
>> One calls a function and the arguments are passed by value. Call a
>> function with an array as an argument, and feel free to modify its
>> contents!
>>
>> so declaring an array as const prevents this, func(const double * a).  I
> understand that this also helps the compiler make optimizations it cannot do
> when you don't use const.  I think you could still modify the contents of
> the array by first copying the pointer though,
>
> double * b = a;
> b[i] = something new.
>
> So there's also the modifier "restrict", which I believe would prevent
> this, and again helps out the compiler do smart things.  Others can probably
> confirm/correct this?  Is it good practice to use these modifiers as often
> as possible/appropriate?
>
>
>> Certainly, C++ added the idea of reference, but I think Pascal
>> simplifies these concepts much better. Yet, Pascal seems to be relegated
>> to the status as a legacy language!
>>
>> brian
>>
>>
>> #include <stdio.h>
>>
>> #define CAP 10
>>
>> void mod_array(int a[])
>> {
>>  a[2] = 5;
>> }
>>
>> void trychange(int a)
>> {
>>  a = 2;
>> }
>>
>> void reallychange(int *a)
>> {
>>  *a = 2;
>> }
>>
>> int main() {
>>  int b[CAP];
>>  int c;
>>  int i;
>>
>>  printf("Load array and change a value\n");
>>  for (i=0; i < CAP; i++)
>>    b[i] = i + 20;
>>
>>
>>  mod_array(b);
>>
>>  for (i=0; i < CAP; i++)
>>    printf("b[%d] has value of %d\n",i,b[i]);
>>
>>  c = 10;
>>
>>  printf("c has a value of %d\n",c);
>>  trychange(c);
>>
>>  printf("c has a value of %d after trychange(c)\n",c);
>>
>>  reallychange(&c);
>>
>>  printf("c has a value of %d after reallychange(&c)\n",c);
>>
>>
>> }
>>
>> --
>> Brian Lavender
>> http://www.brie.com/brian/
>>
>> "There are two ways of constructing a software design. One way is to
>> make it so simple that there are obviously no deficiencies. And the other
>> way is to make it so complicated that there are no obvious deficiencies."
>>
>> Professor C. A. R. Hoare
>> The 1980 Turing award lecture
>> _______________________________________________
>> vox mailing list
>> vox at lists.lugod.org
>> http://lists.lugod.org/mailman/listinfo/vox
>>
>
>
>
> --
> Carl Boettiger
> Population Biology, UC Davis
> http://two.ucdavis.edu/~cboettig <http://two.ucdavis.edu/%7Ecboettig>
>
> _______________________________________________
> vox mailing list
> vox at lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.lugod.org/pipermail/vox/attachments/20100301/9c7fd6b3/attachment.html