Commit Graph

8 Commits

Author SHA1 Message Date
Marshall Clow 425f00817c Add a note about debug mode being non-functional
llvm-svn: 210162
2014-06-04 04:49:49 +00:00
Howard Hinnant 145afa17ca Rename _LIBCPP_DEBUG2 to _LIBCPP_DEBUG.
llvm-svn: 189140
2013-08-23 20:10:18 +00:00
Howard Hinnant 2f51de568f debug mode for unordered_map. Also picked up a missing check and test in unordered_multimap. This wraps up debug mode for the unordered containers.
llvm-svn: 187659
2013-08-02 17:50:49 +00:00
Howard Hinnant 42a3046eef Ok, 3 major changes for debug mode in one commit:
1.  I had been detecting and trapping iterator == and \!= among iterators
    in different containers as an error.  But the trapping itself is actually
    an error.
    
    Consider:
    
    #include <iostream>
    #include <vector>
    #include <algorithm>

    template <class C>
    void
    display(const C& c)
    {
        std::cout << "{";
        bool first = true;
        for (const auto& x : c)
        {
            if (\!first)
                std::cout << ", ";
            first = false;
            std::cout << x;
        }
        std::cout << "}\n";
    }

    int
    main()
    {
        typedef std::vector<int> V;
        V v1 = {1, 3, 5};
        V v2 = {2, 4, 6};
        display(v1);
        display(v2);
        V::iterator i = std::find(v1.begin(), v1.end(), 1);
        V::iterator j = std::find(v2.begin(), v2.end(), 2);
        if (*i == *j)
            i = j;    // perfectly legal
        // ...
        if (i \!= j)   // the only way to check
            v2.push_back(*i);
        display(v1);
        display(v2);
    }

    It is legal to assign an iterator from one container to another of the
    same type.  This is required to work.  One might want to test whether or
    not such an assignment had been made.  The way one performs such a check
    is using the iterator's ==, \!= operator.  This is a logical and necessary
    function and does not constitute an error.

2.  I had a header circular dependence bug when _LIBCPP_DEBUG2 is defined.
    This caused a problem in several of the libc++ tests.
    Fixed.

3.  There is a serious problem when _LIBCPP_DEBUG2=1 at the moment in that
    std::basic_string is inoperable.  std::basic_string uses __wrap_iterator
    to implement its iterators.  __wrap_iterator has been rigged up in debug
    mode to support vector.  But string hasn't been rigged up yet.  This means
    that one gets false positives when using std::string in debug mode.  I've
    upped std::string's priority in www/debug_mode.html.

llvm-svn: 187636
2013-08-02 00:26:35 +00:00
Howard Hinnant e5c13decbe Debug mode for unordered_multiset. The exercise spotted a few places I had missed on unordered_set, so I picked those up as well.
There are actually two debug modes:

   1.  -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1
       This is a relatively expensive debug mode, but very thorough.  This is normally what you want to debug with, but may turn O(1) operations into O(N) operations.

   2.  -D_LIBCPP_DEBUG2=0
       This is "debug lite."  Only preconditions that can be checked with O(1) expense are checked.  For example range checking on an indexing operation.  But not iterator validity.

llvm-svn: 187369
2013-07-29 19:05:47 +00:00
Howard Hinnant 9a20da75ef I believe this finishes up debug mode for list. The testing is a little weak, but I believe all of the functionality is there. Certainly enough for people to checkout and start beating up on.
llvm-svn: 179632
2013-04-16 21:42:36 +00:00
Howard Hinnant 97b8ebe600 I believe debug mode for vector<T> (T != bool) is complete. If anyone sees anything more they would like to see on it, please let me know. Debug mode is activated by compiling with -D_LIBCPP_DEBUG2=1. Eventually _LIBCPP_DEBUG2 will be renamed to just _LIBCPP_DEBUG.
llvm-svn: 178288
2013-03-28 20:35:29 +00:00
Howard Hinnant d70e6570fd Some forward-looking and optimistic documentation.
llvm-svn: 177093
2013-03-14 18:37:48 +00:00