Abstract
The C++ Standard Template Library is the flagship example for libraries based on the generic programming paradigm. The usage of this library is intended to minimize classical C/C++ errors, but does not warrant bug-free programs. Furthermore, many new kinds of errors may arise from the inaccurate use of the generic programming paradigm, like dereferencing invalid iterators or misunderstanding remove-like algorithms. In this paper we present some typical scenarios that may cause undefined or weird behaviour. We present approaches that can be used for developing different safe iterators to avoid run-time errors. Some of these iterators are able to manipulate the container directly, hence they cannot result in undefined behaviour when an algorithm needs to add elements to the container or delete elements from the container. Our iterators are able to indicate if they are invalid. Algorithms’ preconditions are evaluated with our iterators.
Highlights
The C++ Standard Template Library (STL) was developed by generic programming approach
In this paper we present extensions of the C++ STL, that is able to check iterators’ validness at runtime
In this paper we argue for some new kinds of iterators that subserve the correct usage of the STL
Summary
The C++ Standard Template Library (STL) was developed by generic programming approach. Std::lower_bound( v.begin(), v.end(), x, std::greater() ); Other typical STL-related mistakes are related to iterator invalidation This problem occurs when a container that is being processed using an iterator has its shape changed during the process, for example anything that causes a vector’s reallocation (increase in the result of capacity()) will invalidate all iterators. Std::vector::iterator i = v.begin(); been moved to front of the container, but the tail is unchanged The result of this algorithm may be counterintuitive at first time. The following code snippet can be compiled, but it results in an undefined behaviour [20]: std::list li; std::vector vi; v.push_back( 3 ); std::copy( vi.begin(), vi.end(), li.begin() ); there are some adaptors in the library to overcome this situation: back inserter and front inserter adaptors.
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
