Files
boost_iterator/include/boost/iterator/detail/config_def.hpp
T

48 lines
1.6 KiB
C++
Raw Normal View History

2003-07-07 14:20:34 +00:00
// (C) Copyright David Abrahams 2002.
// (C) Copyright Jeremy Siek 2002.
// (C) Copyright Thomas Witt 2002.
2004-08-12 17:02:24 +00:00
// Distributed under the Boost Software License, Version 1.0. (See
// accompanying file LICENSE_1_0.txt or copy at
// http://www.boost.org/LICENSE_1_0.txt)
2003-07-07 14:20:34 +00:00
// no include guard multiple inclusion intended
//
// This is a temporary workaround until the bulk of this is
// available in boost config.
// 23/02/03 thw
//
#include <boost/config.hpp> // for prior
#include <boost/detail/workaround.hpp>
#ifdef BOOST_ITERATOR_CONFIG_DEF
# error you have nested config_def #inclusion.
2022-01-13 17:32:11 +03:00
#else
# define BOOST_ITERATOR_CONFIG_DEF
2022-01-13 17:32:11 +03:00
#endif
2004-12-03 09:55:30 +00:00
// We enable this always now. Otherwise, the simple case in
// libs/iterator/test/constant_iterator_arrow.cpp fails to compile
// because the operator-> return is improperly deduced as a non-const
// pointer.
2025-01-26 15:17:36 +03:00
#if 1
// Recall that in general, compilers without partial specialization
// can't strip constness. Consider counting_iterator, which normally
// passes a const Value to iterator_facade. As a result, any code
// which makes a std::vector of the iterator's value_type will fail
// when its allocator declares functions overloaded on reference and
// const_reference (the same type).
//
// Furthermore, Borland 5.5.1 drops constness in enough ways that we
// end up using a proxy for operator[] when we otherwise shouldn't.
// Using reference constness gives it an extra hint that it can
// return the value_type from operator[] directly, but is not
2005-02-27 17:28:24 +00:00
// strictly necessary. Not sure how best to resolve this one.
# define BOOST_ITERATOR_REF_CONSTNESS_KILLS_WRITABILITY 1
#endif
2004-01-24 17:39:45 +00:00
// no include guard; multiple inclusion intended