| | Another problem, IMO, is that client code will need to be more | complicated, in order to find out if a value is null or not.
I don't understand that. One of the objectives of a null object is that you don't have to worry about a value being null.
really? I thought the purpose of null was to say "there's no object here. You can't do anything with me other than compare other pointers to me."
| > | And, for each new (virtual) function you add, you should update the | > | null_object class - which I think can turn into a maintenance nightmare :( | > | > if your inheritance hierarchy contains N distinct classes, you would need to | > add N implementations of that virtual function anyway, right? | | Not necessary... I can add one implementation, and some of those | distinct N classes don't have to override it ;)
you could insert the null object class between the abstract base class and the leaf classes.
I've never seen a design like this, would never do something like this myself, and I think I would really dislike any design that exibits this.
| > | > | > | > ok, also if it means loss of optimality in for map/set with uinque keys? | > | | > | Would you please exemplify? Thanks. | > | > for example, consider | > | > boost::ptr_set<T> set; | > boost::ptr_vector<T> vec; | > ... | > // fill vec with many duplicates as defined by operator< on T | > | > for( 0..vec.size() - 1 ) | > { | > // #1 | > set.insert( vec[i] ); | > // #2 | > set.insert( allocate_clone( vec[i] ) ); | > } | > | > #1 can check if vec[i] already exists as defined by operator< on T. | > If it does exists, there is no need to make a new clone. #2 always make a new | > clone | > and might need to delete it afterwards | | I might be totally off-base here, but why not an insert_clone function?
That would be more explicit.
It might be worth to have the existing interface if users want to try changing from vector<string> to ptr_vector<string> just to see what happens.
I don't like phrases like "hey, let's change from std::vector to std::map, just to see what happens" (I know I exagerated a bit). When you change something, you should have a reason, and know what you're doing (tradeoffs, etc.). Best, John -- John Torjo -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.4 - save_dlg - true binding of your data to UI controls! + easily add validation rules (win32gui/examples/smart_dlg)