Re: Pointer of Reference ?
From: Joseph M. Newcomer (newcomer_at_flounder.com)
Date: 06/27/04
- Next message: Joseph M. Newcomer: "Re: Porting MFC to Mac OS X and Linux"
- Previous message: Jerry Coffin: "Re: why does minimizing my app cut mem usage by 90%?"
- In reply to: Michael Schlenger: "Re: Pointer of Reference ?"
- Next in thread: Michael Schlenger: "Re: Pointer of Reference ?"
- Reply: Michael Schlenger: "Re: Pointer of Reference ?"
- Messages sorted by: [ date ] [ thread ]
Date: Sun, 27 Jun 2004 13:50:33 -0400
No, the problem is that pnly "traditionally trained C programmers" as a class see pointers
and references as different entities. Those of us who were not corrupted by such poor
designs simply see designators of objects. Whether these are done as pointers, as stack
objects, or whatever, is a detail of implementation so completely irrelevant to the
programmer that a special syntax is not needed. There is no need to make it obvious that
they are different, because they are NOT different. What I intend is very simple: I have
something that designates an object, and I wish to access a method or value member of that
object. If the compiler has to dereference a pointer to achieve that goal, that is work
the compiler has to do for us, and we should not be concerned about using a different
syntax to represent the same concept just because there is an implicit derference. What
amazes me is how passionately C programmers "defend" this incredibly poor design.
Your example, of course, is meaningless. It should not compile, because you have a string
parameter to a function that requires an integer value. This is a type mismatch, which is
unrelated to the above discussion.
In REAL languages, as opposed to languages like C, it is not possible to misuse an integer
value or pointer value as a boolean result. ASSERT wants a Boolean value, TRUE or FALSE. I
insist that there never be a t ype error; if you want to compare something against 0, you
should write != 0, == 0, or for pointers, != NULL or == NULL. Using a value as you show in
ASSERT(pDC) declares that a pointer is a boolean value. This is so ridiculous that no sane
language would even allow it to compile. But it also means the code is unreadable to
anyone who expects to see a boolean value. So why write illegible code based on some poor
design?
And no, you do not ever write == true or == false, because Boolean values stand for
boolean values and writing == true or == false is foolish. But treating integers and
pointers as booleans is equally foolish.
The reason I say that the argument about pointer-vs-reference is specious is exactly
because of what you point out. So you are saying the same thing that I am. The argument of
the deluded souls who think that you should never use references in such a context is that
the programmer is forced to actually READ THE DOCUMENTATION OR THE FUNCTION DEFINITION,
and no programmer should EVER be forced to actually do such real work! So I agree
completely with you: the const is sufficient. That's why I say the argument is specious.
joe
On Mon, 14 Jun 2004 18:11:32 GMT, Michi-Schlenger@web.de (Michael Schlenger) wrote:
>On Fri, 11 Jun 2004 17:34:04 -0400, Joseph M. Newcomer
><newcomer@flounder.com> wrote:
>
>>It also saves you from that ugly misfeature of C where you must use . for objects and ->
>>for pointers (but if you get it wrong, the compiler complains. Of course it never occurred
>>to the language designers that if the compiler can tell the difference, the programmer
>>shouldn't need to!).
>
>I see it exactly the other way around. A pointer is something
>completely different from a reference, and you should make it damn
>clear in your code what you mean. It is good that the compiler tells
>you if you do something other that you mean - that is, "the compiler
>is your friend", as I always say.
>
>More general, it usually is NO GOOD IDEA to have the compiler make
>assumptions about what you might have intended. Things like
>
> void f( int );
> f( "5" );
>
>simply should not compile although there is an obvious semantic
>interpretation of the two statements.
>
>[snip]
>
>> ASSERT(pDC != NULL);
>> ASSERT(pBitmap != NULL);
>
>is there any reason why you do not simply write
>
> ASSERT( pDC );
>
>Do you also write
>
> if ( someBool == true )
>
>?
>
>BTW, in C++ the null pointer is noted as 0, NULL is not part of the
>language, it is some library thing.
>
>[snip]
>
>>Some will argue that putting the & at the call site makes it obvious that the object can
>>be modified, but I think this argument is specious.
>
>This argument is completely wrong. To specify that a server does not
>modify an object, the language provides the const specifier.
>
>For some type T, the statements
>
> void f( const T& );
> void f( const T* );
>
>both signal to the caller that the function cannot modify the object.
>That has nothing to do with the pointer/reference thing. The good
>thing of course is that the compiler can enforce this - again: the
>compiler is your friend.
>
>
>------------------------------------------------
>Michael Schlenger
>------------------------------------------------
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Next message: Joseph M. Newcomer: "Re: Porting MFC to Mac OS X and Linux"
- Previous message: Jerry Coffin: "Re: why does minimizing my app cut mem usage by 90%?"
- In reply to: Michael Schlenger: "Re: Pointer of Reference ?"
- Next in thread: Michael Schlenger: "Re: Pointer of Reference ?"
- Reply: Michael Schlenger: "Re: Pointer of Reference ?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
