c++ question

Grant Robinson santiago at mr-r.net
Mon Sep 25 14:27:23 MDT 2006


On Sep 24, 2006, at 10:04 PM, Dave Smith wrote:
<snip>
> Look, the original poster just wanted to know how to print the  
> address of a character array. You just demonstrated that using the  
> & operator with array2 gives you the WRONG answer, which was my  
> point originally, so I stand behind my original argument in the  
> context of the OP's question. I wasn't saying that the & would  
> never work, just that the OP shouldn't use it to solve this  
> problem. Your code defends that argument pretty well.

Ambiguity is the mother of many a mis-understanding.  After re- 
reading your post, I assume when you say "character array" you mean  
"char *" and when I see "character array" I think "char []", so I  
thought you were saying something different than you actually were.

The rule I was suggesting was that for all non-pointer types, to get  
the address use & (that's what its for).  For pointer types, no & is  
needed.  This give consistent results across types, whether you are  
doing assignment, comparison, printf, etc.

>
> By the way, the best answer was already given days ago with a  
> simple printf( "%p\n", var ), which I'm sure worked just fine  
> without all the pedantic ramblings about the intricacies of & and  
> why C++ is so evil and such (which I have thoroughly enjoyed). I  
> sure hope the OP has moved on to bigger and better problems to solve.

For what the OP was trying to do, you are right.  I was simply  
pointing out that little shortcuts that work with arrays don't  
necessarily work with other non-array variables, so I think it is  
important to understand at least a little of the "intricacies of &"  
and to actually understand what a pointer is and how it differs from  
non-pointers.

<snip>
>
> --Dave
>
> P.S. I happen to think C++ is a great language, and I use it in  
> lots of new projects all the time. I work with several hundred  
> other people who do the same thing. I've never run into a bug that  
> was *caused* by a deficiency in C++ that could not have been easily  
> reproduced in other languages. C++ is just fine for me. This from a  
> person who has written lots of Java, PHP, Python, and Perl code  
> (and even a tiny bit of Scheme).

Everyone is entitled to their own opinion.  This was a surprising  
statement considering you have coded in these other languages.  You  
may not have run into them (which I find hard to believe), but there  
are whole classes of bugs that are possible in C/C++ that are not  
possible in Java, PHP, Python, Perl, Scheme, etc, etc, etc.  You can  
call these language characteristics "features" or "deficiencies", it  
all depends on your point of view.  Improper use of &, buffer  
overflows, bad pointer math, data corruption from incorrect casts are  
just a few examples of bugs that are possible in C/C++ but not in  
other languages.  Functions such as sprintf, memset, strcpy, strcat,  
etc, all make these bugs possible.  And yes, you can avoid them by  
using the 'n' versions and doing proper bounds checking, but the fact  
still remains that they are possible in C/C++ and not in the other  
languages you have mentioned.  That being said, C/C++ are excellent  
languages in the hands of people who understand the power they give  
and are judicious in it's use.

Grant

P.S.  To rat Dave out, he actually isn't as fond of C++ as he makes  
it seem.  In CS 431, he wrote his compiler in *gasp* PHP! :)  Shame  
on you, Dave!




More information about the PLUG mailing list