C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Standard Library-Style Nested Typenames and UDTs          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Greg Hickman Guest Posted: Thu Nov 18, 2004 12:26 am    Post subject: Standard Library-Style Nested Typenames and UDTs When designing application domain-specific classes, we occasionally find ourselves defining nested types that are very similar to types defined in parts of the Standard Library. For example, we often want to provide STL-style iterators on the interfaces of domain-specific composites (in the GoF sense) where possible. Given that my project's coding guidelines require the first letter of user-defined typenames to be capitalized, this suggests using 'Iterator' and 'Const_iterator' as nested iterator typenames. Another example might be a library-specific smart pointer: although std::auto_ptr and boost::shared_ptr define a nested 'element_type', my project's naming convetions suggest using 'Element_type' instead. When integrating UDTs with generic Standard Library components (and perhaps even non-standard generic components), compliance with the naming conventions mandated by those components is a prerequisite. My question is: In general, should we depart from project-specific naming conventions when defining nested typenames like these, or should we delegate that responsibility to auxilliary wrappers instead? Thanks, Greg [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Daniel Krügler (ne Spange Guest Posted: Thu Nov 18, 2004 12:12 pm    Post subject: Re: Standard Library-Style Nested Typenames and UDTs Good morning Greg Hickman, Greg Hickman schrieb: Quote: When designing application domain-specific classes, we occasionally find ourselves defining nested types that are very similar to types defined in parts of the Standard Library. For example, we often want to provide STL-style iterators on the interfaces of domain-specific composites (in the GoF sense) where possible. Given that my project's coding guidelines require the first letter of user-defined typenames to be capitalized, this suggests using 'Iterator' and 'Const_iterator' as nested iterator typenames. Another example might be a library-specific smart pointer: although std::auto_ptr and boost::shared_ptr define a nested 'element_type', my project's naming convetions suggest using 'Element_type' instead. When integrating UDTs with generic Standard Library components (and perhaps even non-standard generic components), compliance with the naming conventions mandated by those components is a prerequisite. My question is: In general, should we depart from project-specific naming conventions when defining nested typenames like these, or should we delegate that responsibility to auxilliary wrappers instead? I also have philosophised about that theme, because our company has similar source code style guides. Here are my current thoughts about it: The mentioned standardized typenames do provide a (static) interface in the sense of compile-time polymorphism. Thus any of your (my) member classes/typenames, which are named "Iterator" instead of "iterator" do not match the required interface for a given concept (Btw.: Similar reasoning applies for "Begin" versus "begin" and so on). So one legitime point of view is: Write your classes as you must according to the demanded programming style and provide interface adapters for interaction with standard C++ components (algorithms, etc.). But there is one further problem: Consider the situation that the companies style guide also demands that **every** (non-member) function should start with an upper case letter, e.g. void Swap(MyType&, MyType&); Now we have a situation where the (object-oriented) adapter pattern does not make sense and we have to provide an additional function for proper customization of std:.swap (lets forget the current problems with the std::swap customization for the while of the discussion): inline swap(MyType& lhs, MyType& rhs) { Swap(lhs, rhs); } OK, this kind of wrapping can also be understood as a kind of adapter pattern, but I am not fully convinced about that. Severe problems occur, if performance tests would reveal that a bottleneck occured **due to** this further indirection, but there are two counter arguments: 1) I can't remenber to have ever hit that hypothetic case in real life. 2) Even if it would be a provable corner case, it is solvable as every other optimization: The optimized code will hurt someone else (the style guide or programming style fetishist), but that is ok in this special situation, because otherwise the demanded optimization would not be possible. As a conslusion I would say: Your proposed separate provision of an std interface adapter class /mechanism seems to be the cleanest approach in general, it ensures that class interfaces stay as concise and homogenous in style as possible. This is a Good Thing. One exception is (at least to my point of view), if we need to specialize a **complete** class template of the standard library: In this case I don't see any reason, to 1) Define the actual implementation in terms of the companies style guide, e.g. struct IteratorTraits<typename IteratorType>; template <> struct IteratorTraits<MyIteratorType> { typedef .. ValueType; .. }; 2) Adapt this class to the std interface: template <> struct std::iterator_traits<MyIteratorType> { typedef IteratorTraits<MyIteratorType>::ValueType value_type; .. }; and I would directly define the specialization of the given std class template w/o indirection using a style-conforming helper class ) Greetings from Bremen, Daniel Krügler [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top jakacki Guest Posted: Thu Nov 18, 2004 12:23 pm    Post subject: Re: Standard Library-Style Nested Typenames and UDTs Greg Hickman wrote: Quote: When designing application domain-specific classes, we occasionally find ourselves defining nested types that are very similar to types defined in parts of the Standard Library. For example, we often want to provide STL-style iterators on the interfaces of domain-specific composites (in the GoF sense) where possible. Given that my project's coding guidelines require the first letter of user-defined typenames to be capitalized, this suggests using 'Iterator' and 'Const_iterator' as nested iterator typenames. Another example might be a library-specific smart pointer: although std::auto_ptr and boost::shared_ptr define a nested 'element_type', my project's naming convetions suggest using 'Element_type' instead. When integrating UDTs with generic Standard Library components (and perhaps even non-standard generic components), compliance with the naming conventions mandated by those components is a prerequisite. My question is: In general, should we depart from project-specific naming conventions when defining nested typenames like these, or should we delegate that responsibility to auxilliary wrappers instead? Clearly your coding guidelines are counterproductive in this particular situation. This is a good reason to make an exception, especially that any STL-aware C++ programmer should instantly figure out why you do this. BR Grzegorz -- Free C++ frontend library: http://opencxx.sourceforge.net China from the inside: http://www.staryhutong.com Myself: http://www.dziupla.net/gj/cv [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ulrich Eckhardt Guest Posted: Fri Nov 19, 2004 1:00 pm    Post subject: Re: Standard Library-Style Nested Typenames and UDTs Greg Hickman wrote: Quote: When designing application domain-specific classes, we occasionally find ourselves defining nested types that are very similar to types defined in parts of the Standard Library. For example, we often want to provide STL-style iterators on the interfaces of domain-specific composites (in the GoF sense) where possible. Given that my project's coding guidelines require the first letter of user-defined typenames to be capitalized, this suggests using 'Iterator' and 'Const_iterator' as nested iterator typenames. Another example might be a library-specific smart pointer: although std::auto_ptr and boost::shared_ptr define a nested 'element_type', my project's naming convetions suggest using 'Element_type' instead. When integrating UDTs with generic Standard Library components (and perhaps even non-standard generic components), compliance with the naming conventions mandated by those components is a prerequisite. My question is: In general, should we depart from project-specific naming conventions when defining nested typenames like these, or should we delegate that responsibility to auxilliary wrappers instead? This is rather a topic for alt.lang.style.religion, but here's by two cent anyway: Integrate your code with the code you are handling. When you provide a custom streambuffer, keep with the standardlibrary's naming connventions, when making a class based on the MFC, start its name with a C, etc etc. In that sense, when supplying STL-style typedefs, I'd stay with STL's style. There is the other argument that the interface of a class should be homogenous and that therefore you should exactly not do that. As usual: YMMV. regards Uli -- Questions ? see C++-FAQ Lite: http://parashift.com/c++-faq-lite/ first ! [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Fri Nov 19, 2004 4:53 pm    Post subject: Re: Standard Library-Style Nested Typenames and UDTs Greg Hickman <greg.hickman (AT) lmco (DOT) com> wrote Quote: When designing application domain-specific classes, we occasionally find ourselves defining nested types that are very similar to types defined in parts of the Standard Library. For example, we often want to provide STL-style iterators on the interfaces of domain-specific composites (in the GoF sense) where possible. Given that my project's coding guidelines require the first letter of user-defined typenames to be capitalized, this suggests using 'Iterator' and 'Const_iterator' as nested iterator typenames. Another example might be a library-specific smart pointer: although std::auto_ptr and boost::shared_ptr define a nested 'element_type', my project's naming convetions suggest using 'Element_type' instead. When integrating UDTs with generic Standard Library components (and perhaps even non-standard generic components), compliance with the naming conventions mandated by those components is a prerequisite. My question is: In general, should we depart from project-specific naming conventions when defining nested typenames like these, or should we delegate that responsibility to auxilliary wrappers instead? Todate, the only problems of this sort that I've encountered have been typename (e.g. iterator, const_iterator); my policy for that has been to follow the local coding conventions, and then add a typedef where necessary. -- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] 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 (Moderated) All times are GMT Page 1 of 1   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.