C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Const correctness and lazy read... Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Meang Akira Tanaka Guest Posted: Mon Mar 28, 2005 12:34 am    Post subject: Const correctness and lazy read... Hi In connection with my work where data is read from the database. It hasn't always been optimal to read all the data associated to an object from the database. A way to optimize this is to introduce the concept of lazy read. But the idea is that only an id is set in the class and when necessary the rest is read to the object(typically in getters). However typically in getters const is applied and therefore an issue regarding constness will happen. In order to solve this several solutions exists: 1. Two class solution One class that contains the data and is read, the other one contains all the logic. Drawback: the data is separated from the logic, which in my humble opinion would be a step back from OO design. 2. const_cast solution One could const cast the this pointer and then invoke a non-const method. Drawback: doesn't look nice when reading through the code. 3. Mutable members One could make the members mutable. Drawback: all other functions even if they guarantee constness can alter these. 4. Mutable methods. C++ could give the mutable keyword a meaning for methods. My idea was that mutable methods are able to be called within const methods and mutable methods are able to alter the state of the object. The advantage of this approach is that not all methods are able to alter the state of the object as in solution 3, no need for const cast, and the data and the logic is kept together. Do anyone have an opnion about this suggestion Br Meang --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Yuriy Solodkyy Guest Posted: Mon Mar 28, 2005 6:47 am    Post subject: Re: Const correctness and lazy read... Can you clarify which members can a mutable member function modify: all or only mutable? If only mutable, then I don't see the point in declaring method as mutable, as it can be declared as const and hence be called from other const methods. If it can change any member, then I think we loose the point for which const declarations were introduced. By making a method const you give compiler information that content of the object won't be changed by a call to such method and that it can apply appropriate optimizations in accessing any non-mutable attribute. By allowing calls that basically can change content of the object from within const method, compiler wouldn't be able to assume anymore that content is not changed and hence avoid any optimization. If we'll think of method int C::method(int) const as a global function int C_method(const C*, int) what will be the meaning of information you give to compiler by stating: int C_method(mutable C*, int) ? Remember that in C++ definition of the method is not always available at the point of usage of this method (e.g. you've got header and lib file only) so it can not try to figure out himself what is changed by the method and what is not. Also C++ compiler works independently with translation units and doesn't have to keep information in between compilations of different translation units. Sorry if I didn't understand you right. Yuriy Meang Akira Tanaka wrote: Quote: Hi In connection with my work where data is read from the database. It hasn't always been optimal to read all the data associated to an object from the database. A way to optimize this is to introduce the concept of lazy read. But the idea is that only an id is set in the class and when necessary the rest is read to the object(typically in getters). However typically in getters const is applied and therefore an issue regarding constness will happen. In order to solve this several solutions exists: 1. Two class solution One class that contains the data and is read, the other one contains all the logic. Drawback: the data is separated from the logic, which in my humble opinion would be a step back from OO design. 2. const_cast solution One could const cast the this pointer and then invoke a non-const method. Drawback: doesn't look nice when reading through the code. 3. Mutable members One could make the members mutable. Drawback: all other functions even if they guarantee constness can alter these. 4. Mutable methods. C++ could give the mutable keyword a meaning for methods. My idea was that mutable methods are able to be called within const methods and mutable methods are able to alter the state of the object. The advantage of this approach is that not all methods are able to alter the state of the object as in solution 3, no need for const cast, and the data and the logic is kept together. Do anyone have an opnion about this suggestion Br Meang --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Alf P. Steinbach Guest Posted: Tue Mar 29, 2005 12:29 am    Post subject: Re: Const correctness and lazy read... * Meang Akira Tanaka: Quote: [snip] 4. Mutable methods. C++ could give the mutable keyword a meaning for methods. My idea was that mutable methods are able to be called within const methods and mutable methods are able to alter the state of the object. The advantage of this approach is that not all methods are able to alter the state of the object as in solution 3, no need for const cast, and the data and the logic is kept together. Do anyone have an opnion about this suggestion Simply inherit from the following class, one or more times, where 'Id_' is some dummy type that you define as a name for the member in question: template< typename Id_, class MemberType_ > class MutableMemberRef_ { private: MemberType_* myMemberPtr; protected: MutableMemberRef_( MemberType_* aMemberPtr ): myMemberPtr( aMemberPtr ) {} virtual void onGet( Id_, MemberType_& ) const {} MemberType_& get( Id_ ) const { onGet( Id_(), *myMemberPtr ); return *myMemberPtr; } }; In your derived class, override 'onGet' as appropriate. Disclaimer: I wrote this just to reply to this posting, so it's not been honed by real-world usage. Insight: now that I think of it, it seems to make 'mutable' of negative value! Wish: a new language feature so that a class nested in class X can be used in the inheritance list of class X. -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Meang Akira Tanaka Guest Posted: Tue Mar 29, 2005 12:30 am    Post subject: Re: Const correctness and lazy read... Quote: Can you clarify which members can a mutable member function modify: all or only mutable? a mutable member function should be allowed to alter all members except for those inherited private members. i.e. the access rules still apply. Quote: If it can change any member, then I think we loose the point for which const declarations were introduced. You are definitly right that we may loose the point in constness of a function but I think we already lost some with the introduction of mutable keyword, so I guess my suggestion is in the same league as mutable on attributes. But I guess I hope that mutable function will give somewhat a cleaner design than having mutable members. As far as I remember the ANSI ISO/IEC 14882 (First edition 1998-09-01) Section 7.1.1 states the following: "The mutable specifier on a class data member nullifies a const specifier applied to the containing class object and permits modification of the mutable class member even though the rest of the object is const (7.1.5.1)" The way I interpret this section is that mutable attributes are a workaround for functions which are declared const to alter the state of the instance. And I see the section in the ANSI standard as an acknowledgment that even if const correctness should be applied where applicable there are situation where constness conflicts in the way programs are designed. and especially when optimization is an issue. One could maybe argue that the design is wrong somehow, but if anyone can come up with a good solution on how to ensure that data is only read when necessary I am all ears. In cases where programs have to read its state from some source, and the reading takes longer time that accepted. It will need to be optimized some way or another I guess one of the most common ways are to only read those things that are needed. My suggestion is that following should be possible: class A { private int mAttribute; int mId; int getAttribute() const { lazyRead(); return mAttribute; } void lazyRead() mutable { if(!read) { ... read... mAttribute = 12; read = true; } } Const method should be allowed to invoke const and mutable functions. in this example getAttribute may invoke lazyRead which is able to alter the state. Why is this better than the other solution I have mentioned? Well the arguments are following (I've added some more concrete examples on what the alternatives are in the end of the mail): 1. Separating clean code from some code that is a workaround due to optimization. (i.e. By having a method that are able to modify attributes instead of doing a const_cast and then invoking a non-const method). 2. You ensure that only designated members are allowed to alter the state (as opposed to all members when using the mutable keyword) 3. You ensure that code and logic are tied together (as opposed to try to avoiding constness by separating the code from data) The following examples may illustrate more clearly the issues: Mutable attributes Solution: class A { private mutable int mAttribute; mutable int mId; int getAttribute() const { read(); return mAttribute; } void read() const { if(!read) { ... read... mAttribute = 12; read = true; } } The mutable solution means that any member can modify mAttribute and mId, which basically means that constness effectively is removed. Mutable functions still retains the value of constness. Two class solution: class A { private B *mImpl; A::A() { mImpl = new B(); } int getAttribute() const { read(); return mAttribute; } void read() const { if(!read) { ... set attribute... mImpl->setAttribute(12); read = true; } } class B { private int mAttribute; int mId; int getAttribute() const { return mAttribute; } } The two class solution separes the logic from the data. which is the opposite idea of what object-oriented strives too. Therefore in my humble opinion not good solution. The const_cast solution is as follows: class A { private int mAttribute; int mId; int getAttribute() const { A* ptr = const_cast<A>(this); ptr->read(); return mAttribute; } void read() { if(!read) { ... read... mAttribute = 12; read = true; } } The const_cast solution is somewhat ugly. First this pointer is const cast in order to remove const then a non-const method is invoked. Quote: By allowing calls that basically can change content of the object from within const method, compiler wouldn't be able to assume anymore that content is not changed and hence avoid any optimization. You are right It cannot assume that the method cannot be changed (I didn't thought of that). But wouldn't the same argument apply to mutable attributes? Can the compiler safely assume that content when invoking a const method which has mutable attributes? Quote: Sorry if I didn't understand you right. I'm apologize if I haven't been concise enough br Meang --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top wade@stoner.com Guest Posted: Tue Mar 29, 2005 12:31 am    Post subject: Re: Const correctness and lazy read... Yuriy Solodkyy wrote: Quote: ... By making a method const you give compiler information that content of the object won't be changed by a call to such method and that it can apply appropriate optimizations .. Typically you aren't telling the compiler that much. The compiler still has to consider that my const method might have a line like const_cast<T*>(this)->m_foo = bar; The only time the compiler "knows" I don't have that line is 1) The compiler can see the source code of my method or 2) The compiler can see (or infer) the definition of my object (not just the definition of a pointer or reference to my object) and 2a) the definition says my object is const and not on the heap and 2b) the compiler knows my method is not being called directly or indirectly from a constructor/destructor of my object (or of a larger object that contains my object as a sub-object). For both (1) and (2), the declaration of 'const' on the method makes no difference. If either (1) or (2) applies, the compiler can perform the optimization. The purpose of 'const' on methods is to document the programmer's intent. A side benefit is that this gives code reviewers (including compilers) a chance to tell him when he messed up. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Francis Glassborow Guest Posted: Wed Mar 30, 2005 2:36 am    Post subject: Re: Const correctness and lazy read... In article <1112024258.895473.322000 (AT) l41g2000cwc (DOT) googlegroups.com>, [email]wade (AT) stoner (DOT) com[/email] writes Quote: Typically you aren't telling the compiler that much. The compiler still has to consider that my const method might have a line like const_cast<T*>(this)->m_foo = bar; No, it does not and that is one reason that the mutable keyword was introduced. It is undefined behaviour to attempt to remove a const qualification from an object (i.e. the underlying object was declared as const). The purpose of a const_cast is to support removing a conts qualification from a reference (or pointer) when the referenced object (or the pointed to object) was not itself declared as const. -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit For project ideas and contributions: http://www.spellen.org/youcandoit/projects --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Alf P. Steinbach Guest Posted: Wed Mar 30, 2005 12:55 pm    Post subject: Re: Const correctness and lazy read... * Alf P. Steinbach: Quote: [description of class MutableMemberRef_] After reading Francis Glassborow's response elsewhere in the thread it became clear to me that this should instead be a class MutableMember_, with a 'mutable' member... ;-) Otherwise it could be very very dangerous. With that change, and perhaps a virtual 'update' function instead of 'onGet', I think it implements the OP's wishes w/o extending the language. -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top wade@stoner.com Guest Posted: Thu Mar 31, 2005 1:17 am    Post subject: Re: Const correctness and lazy read... I'm ignoring 'mutable' members in the following: YS said that compilers may assume that calls to const methods don't modify the underlying object. I disaggree. FG said that you can't remove 'const' from references or pointers to const objects. I disagree slightly: you can remove the const, you just can't modify the object. However I agree with the implication that compilers may assume that nothing modifies const objects (an entirely different assumption from YS's). I (BW) said that if the compiler can't see the source of the method, YS's statement is true only when the compiler knows -- The underlying object is const (and not on the heap). Pretty much what FG said. By example: struct foo { int m_bar; void FooBar() const { const_cast<foo*>(this)->m_bar = EXIT_FAILURE; } }; int main() { foo f; f.m_bar = EXIT_SUCCESS; f.FooBar(); // Call a const method on a non-const object return f.m_bar; } YS's statement would mean that the result is unpredictable because the compiler might (or might not) assume that f.m_bar cannot be modified by the call to the const function. I say that the program is well defined and must return EXIT_FAILURE. In particular, no attempt was made to modify a const object. There is nothing in the standard that allows the compiler to make the inappropriate optimization. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Meang Akira Tanaka Guest Posted: Fri Apr 01, 2005 11:22 pm    Post subject: Re: Const correctness and lazy read... On Mon, 28 Mar 2005 18:29:50 CST, [email]alfps (AT) start (DOT) no[/email] (Alf P. Steinbach) wrote: Quote: [snip] Simply inherit from the following class, one or more times, where 'Id_' is some dummy type that you define as a name for the member in question: template< typename Id_, class MemberType_ class MutableMemberRef_ { private: MemberType_* myMemberPtr; protected: MutableMemberRef_( MemberType_* aMemberPtr ): myMemberPtr( aMemberPtr ) {} virtual void onGet( Id_, MemberType_& ) const {} MemberType_& get( Id_ ) const { onGet( Id_(), *myMemberPtr ); return *myMemberPtr; } }; But that is basically the two class solution so you have separeted the data from the actual logic. But wasn't the intend of OO to tie the actual logic with the data rather than separating those br Meang. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Yuriy Solodkyy Guest Posted: Sat Apr 02, 2005 6:39 am    Post subject: Re: Const correctness and lazy read... Just checked the standard on this point, my assumption was indeed wrong. If anyone is interested, here there are some more explanations on the issue including why compiler almost never can take constness of the method into account for optimization purposes: http://new-brunswick.net/workshop/c++/faq/const-correctness.html#faq-18.7 But then I still don't understand the purpose of mutable members. Yuriy [email]wade (AT) stoner (DOT) com[/email] wrote: Quote: I'm ignoring 'mutable' members in the following: YS said that compilers may assume that calls to const methods don't modify the underlying object. I disaggree. FG said that you can't remove 'const' from references or pointers to const objects. I disagree slightly: you can remove the const, you just can't modify the object. However I agree with the implication that compilers may assume that nothing modifies const objects (an entirely different assumption from YS's). I (BW) said that if the compiler can't see the source of the method, YS's statement is true only when the compiler knows -- The underlying object is const (and not on the heap). Pretty much what FG said. By example: struct foo { int m_bar; void FooBar() const { const_cast<foo*>(this)->m_bar = EXIT_FAILURE; } }; int main() { foo f; f.m_bar = EXIT_SUCCESS; f.FooBar(); // Call a const method on a non-const object return f.m_bar; } YS's statement would mean that the result is unpredictable because the compiler might (or might not) assume that f.m_bar cannot be modified by the call to the const function. I say that the program is well defined and must return EXIT_FAILURE. In particular, no attempt was made to modify a const object. There is nothing in the standard that allows the compiler to make the inappropriate optimization. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Meang Akira Tanaka Guest Posted: Mon Apr 04, 2005 5:19 am    Post subject: Re: Const correctness and lazy read... [*snip*] Quote: But then I still don't understand the purpose of mutable members. Yuriy Basically for having a single or few method which are doing "dirty" work rather than spreading it all over the code. br Meang --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Alf P. Steinbach Guest Posted: Mon Apr 04, 2005 12:55 pm    Post subject: Re: Const correctness and lazy read... * Meang Akira Tanaka: Quote: On Mon, 28 Mar 2005 18:29:50 CST, [email]alfps (AT) start (DOT) no[/email] (Alf P. Steinbach) wrote: [snip] Simply inherit from the following class, one or more times, where 'Id_' is some dummy type that you define as a name for the member in question: template< typename Id_, class MemberType_ class MutableMemberRef_ { private: MemberType_* myMemberPtr; protected: MutableMemberRef_( MemberType_* aMemberPtr ): myMemberPtr( aMemberPtr ) {} virtual void onGet( Id_, MemberType_& ) const {} MemberType_& get( Id_ ) const { onGet( Id_(), *myMemberPtr ); return *myMemberPtr; } }; But that is basically the two class solution ? Quote: so you have separeted the data from the actual logic. ? Quote: But wasn't the intend of OO to tie the actual logic with the data rather than separating those ? Ignoring the issue of accessing a non-mutable member this way (addressed in my own follow-up), in what way doesn't this fix your problem? Exactly what _is_ the original problem then? -- A: Because it messes up the order in which people normally read text. Q: Why is it such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Nicola Musatti Guest Posted: Tue Apr 05, 2005 7:32 pm    Post subject: Re: Const correctness and lazy read... Meang Akira Tanaka wrote: [...] Quote: 1. Two class solution One class that contains the data and is read, the other one contains all the logic. Drawback: the data is separated from the logic, which in my humble opinion would be a step back from OO design. I do not agree. Separating the logic model from the persistence infrastructure improves the OO design because you separate the representation of a portion of the real world from low level details. Do you really think that a BankAccount class should have a readFromOracle() and a writeToOracle() member functions? This is particularly important when you deal with complex entities, which otherwise would result in unmanageable classes. Cheers, Nicola Musatti --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Meang Akira Tanaka Guest Posted: Thu Apr 07, 2005 12:26 am    Post subject: Re: Const correctness and lazy read... ===================================== MODERATOR'S COMMENT: This is getting away from the topics of comp.std.c++. ===================================== END OF MODERATOR'S COMMENT On Tue, 5 Apr 2005 13:32:27 CST, "Nicola Musatti" <nicola.musatti (AT) gmail (DOT) com> wrote: [*snip*] Quote: I do not agree. Separating the logic model from the persistence infrastructure improves the OO design because you separate the representation of a portion of the real world from low level details. Do you really think that a BankAccount class should have a readFromOracle() and a writeToOracle() member functions? true when you don't have to think about performance issues such as only getting data when necessary. but in cases where you have a large data structure, it may be beneficial to only read those parts that are needed when a method is invoked and I guess there are several ways to do that: 1. Let the caller ensure that data is read. 2. Let the object itself ensure that the data is read. Quote: This is particularly important when you deal with complex entities, which otherwise would result in unmanageable classes. oki so if you have lets say a bankaccount with may contain all the transactions. e.g. class bankaccount { std::string mBankAccountNumber; std::list<banktransaction> mTransactions; std::string getBankAccountNumber() { ... } } and for one instance of the an bank account you would have 700 transaction. If you only want to get the bank account number. how should this be done then? The caller could of course invoke a read method in order to get the bankaccount. but since it doesn't really know which data to be read, it will have to read the whole lot. The other option is to let the class it self read the data it "thinks" will be needed. that is if you invoke getBankAccount it may read all the data except for the transactions. But am not sure there are other ways or have I overlooked something Hopes it clearifies it br Meanb --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Meang Akira Tanaka Guest Posted: Thu Apr 07, 2005 4:22 am    Post subject: Re: Const correctness and lazy read... On 4 Apr 2005 12:55:01 GMT, [email]alfps (AT) start (DOT) no[/email] (Alf P. Steinbach) wrote: [*snip*] Quote: But that is basically the two class solution ? As I understood the MutableMemberRef_ solution: a "pointer type" is introduced in order which should handle the lazy read. which seems like a good idea. but as I see it it resembles the two class solution as I suggested previously in the thread... that is having a separate class which contains the data, and another class having the logic. Is that what is the intend of the MutableMemberRef_? If that is the case as I said this would separate the logic from the data e.g /** */ class Person { PersonData *ptr; public: Person() { ptr = new PersonData(); } int getAge() const { return ptr->getAge(); } void celebrateBirthdate { ptr->setAge(ptr->getAge() + 1); } } class PersonData { int mAge; public: int getAge() const { lazyRead(); return mAge; } void lazyRead() { ... get data ... } } The question is what have we achieved by doing this? Well For one we have separated the data from the logic. For example celebrateBirthdate is placed in Person class rather than in PersonData. But one could argue that one could just move celebrateBirthdate PersonData. True. but now we have to create all the methods that should be accessible in PersonData accessible from Person. Well that means more work. The other thing is that all methods in Person can basically be declared as const as they change the state of the PersonData object and not the Person object. that is for example: void celebrateBirthdate const { ptr->setAge(ptr->getAge() + 1); } is also possible because one changes the state of the instance of PersonData and not the state of the Person. So we have somehow made the const keyword non effective. Quote: Ignoring the issue of accessing a non-mutable member this way (addressed in my own follow-up), in what way doesn't this fix your problem? Well It does indeed fix my problem. but I guess not as elegant. because the logic is separated from the logic. Quote: Exactly what _is_ the original problem then? The original problem is how to solve that const member functions and lazy read pattern does not mix very well. hope this clarify it more br Meang --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.