marina@cs.hw.ac.uk (Marina Georgiadou) (06/18/91)
I'm currently working in Borland C++, and I have encountered
the following construct in one of Borland's examples :
class A{
// ...
public :
virtual int f() const;
//...
};
Does anybody know the meaning of this const postfix ??
In addition, I was wondering if it possible to print the on-line help
concerning Microsoft Windows Reference.
Marina Georgiadoueuamts@eua.ericsson.se (Mats Henricson) (06/19/91)
marina@cs.hw.ac.uk (Marina Georgiadou) writes: >I'm currently working in Borland C++, and I have encountered >the following construct in one of Borland's examples : >class A{ >// ... >public : > virtual int f() const; >//... >}; >Does anybody know the meaning of this const postfix ?? Well, I suppose you have got 600 replys allready, but who knows: The const postfix means that the function f() may not change any of the data members of the class A. This is a very neat feature since you know that this function is safe for the data in the object of type A. It has however yet another meaning: if you have a constant object of type A: const A a; Now you can only use the member functions of A that are declared const. This is rather natural; since a is declared const it cannot be changed, and hence only safe functions that does not change the inner state of a should be possible to call. If you were using g++, i.e. GNU:s version of C++, this const postfix would have yet another meaning, since the GNU compiler does not allow const functions to change ANYTHING, i.e. not even global constants. You are using Borland C++ and it should not put this restraint on const declared functions. So just forget you heard about it ;-) Mats Henricson, Sweden
mattel@auto-trol.com (Matt Telles) (06/19/91)
In article <3257@odin.cs.hw.ac.uk> marina@cs.hw.ac.uk (Marina Georgiadou) writes: > >I'm currently working in Borland C++, and I have encountered >the following construct in one of Borland's examples : > >class A{ >// ... >public : > virtual int f() const; >//... >}; > >Does anybody know the meaning of this const postfix ?? Funny you should mention this. We are arguing about using these at work. The const postfix notation indicates that the method (f) does NOT modify the object for which it is messaged (this). In other words, if I have an object x of class A, then doing: x.f() is GUARANTEED not to change x in any way. What do other people think of using this notation? Is it useful? Are there any side effects? Matt -- ============================================================================== Matt Telles mattel@auto-trol.COM {...}ncar!ico!auto-trol!mattel Auto-trol Technology 12500 N Washington Denver, CO 80241-2404 (303)252-2874
sorrow@oak.circa.ufl.edu (06/19/91)
As for printing out the On-Line Windows Reference, this has been done and it costs 39.95. It is called the Microsoft Windows Programmer's Reference, and over 80% of it is duplicated (WORD for WORD) in the Online Help used by Borland. It also includes a reference section on the Resource Scripts commands. It is around 1000 pages, so just printing out the online help wouldn't be much of a savings (especially when you factor in the time to interpret and decompile the help files....or use the Clipboard and do a bunch of copies... ick...) Brian /* Brian Hook -- MS-DOS Programmer for Contract ----------------------------------------------------------------- "Seamus, that's my dog...I saw her today at the reception...sorry, sixTEEN inches....better save the women and children first...but this one goes to 11! ..anymore of that plutonium nyborg?....there can be only ONE!....like a finger pointing to the moon....ease the seat back...one day closer to death */
hitz@csi.uottawa.ca (Martin Hitz) (06/19/91)
In article <3257@odin.cs.hw.ac.uk> marina@cs.hw.ac.uk (Marina Georgiadou) writes: >class A{ > virtual int f() const; >}; > >Does anybody know the meaning of this const postfix ?? It denotes the promise, that f() will not change *this (it's hidden argument). Martin Hitz@csi.uottawa.ca
mittle@blinn.watson.ibm.com (Josh Mittleman) (06/20/91)
In article <3257@odin.cs.hw.ac.uk>, marina@cs.hw.ac.uk (Marina Georgiadou) writes: > class A{ > // ... > public : > virtual int f() const; > //... > }; > Does anybody know the meaning of this const postfix ?? It indicates that the member function will not modify *this. It allows the member function to be safely applied to a const object. Invoking a non-const member function on a const object is an error. See ARM p.177 for details. =========================================================================== Josh Mittleman (mittle@watson.ibm.com or joshua@paul.rutgers.edu) J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598
markr@and.cs.liv.ac.uk (06/22/91)
mattel@auto-trol.com (Matt Telles) writes: > marina@cs.hw.ac.uk (Marina Georgiadou) writes: > > > > Does anybody know the meaning of this const postfix ?? > > The const postfix notation indicates that the method (f) does NOT modify the > object for which it is messaged (this). > > What do other people think of using this notation? Is it useful? > I have one small gripe about the const postfix. I have a smart pointer class. Each pointer has an ID number for the object it "points" to; when the smart pointer is dereferenced the first time it will load the object from a database, or locate it via an object table. The address of the object is stored in a member of the smart pointer so that access is as quick as possible next time:- class Smart { int ident; Object* address; public: Object* operator->() { if( ! address ) { address = find_or_load_object( ident ); } return address; } // etc. }; The thing is, I would like to have "const" smart pointers for which the identifier cannot be changed -- like an "Object *const". But if I declare operator->() as a const member function, it cannot assign to "address". If operator->() is not const postfixed, it cannot be called for a const smart pointer, making the latter just a bit useless. What I am trying to say is, I would prefer the const postfix to mean that the programmer doesn't mind that function being called on a const object, rather than meaning that no members may be changed by that function. This would seem to me to make more sense since the notion of a constant object is not as simple as the notion of a constant integer or float. An object is, after all, an abstraction over finer-grained data inside, so shouldn't the notion of what makes an object constant/nonconstant also be abstracted? Protecting the bit pattern of a const object's allocated space is IMHO over-protective. A programmer should be able to use "const Car" to mean that the colour cannot change or the engine cannot be removed, without preventing the lights being switched on or the tank being filled :-) My 2p's worth. Mark Rivers CompSci, Liverpool Uni, UK.
benson@odi.com (Benson I. Margulies) (06/23/91)
the const function declaration item serves two purposes. It declares
an characteristic of an Interface, and it enforces restrictions on its
contents.
Well, the referenced posting is an example of something that happens
fairly commonly in my experience -- a member function whose interface
is const actually needs to modify its private internal state.
You can argue till the cows come home as to whether this is
"legitimate." The argument in favor is that the private contents of an
object are no one's business but the object's, and if it chooses to
modify them in a "const" method that's its business. The anti-
argument is that const on a member function is a statement about
storage integrity -- a const object, in this theory, can be stored in
a ROM.
In the real world, do the following. Decide which of the positions to
believe. If you believe that pro is appropriate for your application,
you write
((myclass *)this)->state = whatever;
to cast away the const.
If you believe that anti is the ticket, then you have to maintain,
for example, a hash table from this pointers to non-const state
containers, and modify those.
myclass::state_hash[this]->address = whatever;
--
Benson I. Marguliesbmk@m2.csc.ti.com (Brian M Kennedy) (06/24/91)
>>>=marina=> >>>Does anybody know the meaning of this const postfix ?? >>=mattel=> >> The const postfix notation indicates that the method (f) does NOT modify the >> object for which it is messaged (this). >> >> What do other people think of using this notation? Is it useful? >=markr=> >I have one small gripe about the const postfix. >[...example deleted...] >What I am trying to say is, I would prefer the const postfix to mean that the >programmer doesn't mind that function being called on a const object, rather >than meaning that no members may be changed by that function. This would >seem to me to make more sense since the notion of a constant object is not as >simple as the notion of a constant integer or float. An object is, after all, >an abstraction over finer-grained data inside, so shouldn't the notion of what >makes an object constant/nonconstant also be abstracted? >Protecting the bit pattern of a const object's allocated space is IMHO >over-protective. =bmk=> For a class with a user-defined constructor or destructor, the const postfix does mean what you want it to, Mark. For such a class, the const postfix implies that the member function can be freely called on a const object of that class. Within the member function you are guaranteed that you can cast away the const-ness and it will behave as if it was never const. Requiring such casts may be overprotective, but it is much better than not providing any protection. The compiler cannot infer the "meaning" of a class to enforce meaningwise const-ness, so it simply enforces bitwise const-ness and provides a mechanism for you to override it. For a large number of cases bitwise const-ness and meaningwise const-ness are the same thing. >=markr=> >But if I declare >operator->() as a const member function, it cannot assign to "address" =bmk=> Yes, you can: ((smartPtr*)this)->address = ...; This is guaranteed to work if class smartPtr has a user-defined constructor or destructor. >=benson=> >You can argue till the cows come home as to whether this is >"legitimate." The argument in favor is that the private contents of an >object are no one's business but the object's, and if it chooses to >modify them in a "const" method that's its business. The anti- >argument is that const on a member function is a statement about >storage integrity -- a const object, in this theory, can be stored in >a ROM. =bmk=> There is no argument -- it is well-defined (though not necessarily well- described in many of the texts; see the end of this note for a reference). If the class has a user-defined constructor or destructor, then it is legal. Const objects of such classes are "meaningwise const". If the class has no user-defined constructors or destructor, then it is illegal. Const objects of such classes are "bitwise const" and may be placed in ROM. >=benson=> >In the real world, do the following. Decide which of the positions to >believe. =bmk=> No, decide which kind of const-ness you want for your class. If you want meaningwise const-ness, then define at least one constructor or destructor for it. Then you may cast-away-const at will and you are guaranteed that it will behave as if the object was never const. Now to return to this question: >>=mattel=> >> What do other people think of using this notation? Is it useful? =bmk=> It is a *necessary* part of programming in C++. If you are defining abstract types, then you must use this notation to describe which operations can be invoked on const objects of that type. If you do not use this notation then you essentially disallow the use of const objects of that type, and in effect toss one of the best features of C++ -- strong typing. I consider any code that does not use const where appropriate to be broken. REFERENCE One final note to those that are confused or surprised by the above discussion: I highly recommend reading the pair of articles by Jonathan Shopiro that appeared in Feb 1991 and Mar/Apr 1991 issues of JOOP (J. Object-Oriented Programming) titled "The semantics of const" -- but most importantly, the second part. == Brian M. Kennedy <bmk@csc.ti.com> == == Computer Systems Laboratory ======== == Computer Science Center ============ == Texas Instruments ==================