charlien@hpwale.HP.COM (Charlie Nuzzolo) (01/28/89)
>Thus, I would like to get away from memory pointers in my C++ programs and >make greater use of references. However, I seem to have no way of initializing >a reference to refer to nothing, or testing if it refers to nothing (akin >to a pointer to NULL). How about using macros: #define NULL_REF(type) *(type*)NULL #define IS_NULL_REF(arg) ((void*)&arg == NULL) Then you can do things like: MyClass& obj = NULL_REF(MyClass); and: MyTypedef& myType = NULL_REF(MyTypedef); You can also pass null references for arguments: void myFunction(MyType& t = NULL_REF(MyType)) { if (IS_NULL_REF(t)) printf("default\n"); else printf("not null default\n"); } You can do similar things with class references too but be sure to use 'const MyClass&' to avoid constructor problems. Charlie Nuzzolo Hewlett Packard (617) 890 6300 charlien@hpwarg.HP.COM
shawn@pnet51.cts.com (Shawn Stanley) (01/28/89)
dog@vilya.UUCP (SCHIEBEL) writes: >A comment was made at the C++ conference in Denver last year that an >object oriented program should not use memory pointers. The rationale >being that we should be dealing with objects and not be distracted by >the implementation of the objects, including the fact that they exist >at some location in a computer's memory. Sounds reasonable to me. > >Thus, I would like to get away from memory pointers in my C++ programs and >make greater use of references. However, I seem to have no way of initializing >a reference to refer to nothing, or testing if it refers to nothing (akin >to a pointer to NULL). > >Maybe if I am going to create objects on the free store with new, I might as >well resign myself to dealing with pointers. I don't know. Any comments? I think the ability to use memory pointers is quite important. For instance, C itself allows you to get closer to the machine -- work on device drivers, things like that, without having to add the ability to the compiler itself. The user-driven library is a great advantage. In C++, you should be able to create device "objects" that can be re-used by anyone. Or, an object that has the ability to change the EGA graphics mode, by port-twiddling and such. Without direct access to memory, many device-oriented objects would have to be built into the language itself, which puts the entire burden on the compiler author. I think it is more important that developers have the ability to write their own device-oriented objects (and related objects), and thus there becomes a wealth of objects from third-parties to control whatever you have a mind to plug into your machine... UUCP: {rosevax, crash}!orbit!pnet51!shawn INET: shawn@pnet51.cts.com
vilot@ie0013.dec.com (Michael J. Vilot) (01/28/89)
> However, I seem to have no way of initializing > a reference to refer to nothing, or testing if it refers to nothing (akin > to a pointer to NULL). Any reference must be initialized ("The C++ Programming Language", p. 56). You can borrow a trick from Ada programmers: define a null object for any class where such an object is sensible. The you can declare references as alternate names for it: class foo { int value; // ... public: foo(); foo(foo&); // X(X&) initializer // ... }; foo NULL_FOO; f() { foo& bar = NULL_FOO; } Hope this helps, Mike Vilot Self-employed. Consulting at: e-mail: vilot%csdpie.dec@decwrl.dec.com when that fails: (508)467-3631 [for now]
jima@hplsla.HP.COM (Jim Adcock) (01/28/89)
> Any comments?
Sounds like dogma to me. Good pointer support is much of what makes C
and C++ more efficient than other languages. I believe that one needs
to feel comfortable with the duality of thinking of an object either
as a chunk of memory, or as the address of that chunk of memory. Both
interpretations of an "object" have their usefulness. Using and understanding
both interpretations need not lead to wild confusion.
The question remains in my mind -- in general should a class implementer write
public methods that pass by reference, or pass a pointer? [For methods requiring
more than one object.] I think in general objects should be passed by
reference, not by pointer. In the internal implementation of those methods
the class implementator should feel free to use either pointers or references,
whichever is most suitable to the task at hand.
Comments?
ark@alice.UUCP (Andrew Koenig) (01/29/89)
Perhaps the most fundamental difference between references and pointers is that a pointer is an object and a reference is not. A reference is just a way of binding a name to an already existing object. Thus using pointers allows you to treat the pointers themselves as objects that can be copied, passed as arguments, returned, placed into structures, and so on. There's no way to do that with references. -- --Andrew Koenig ark@europa.att.com