/*=============================================================================
    Copyright (c) 2011 Matt Calabrese

    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)
==============================================================================*/
 
#include <boost/config.hpp>
 
// ToDo: Add check for relaxed typename rule

#include <boost/type_traits/is_arithmetic.hpp>
#include <boost/type_traits/is_pointer.hpp>
#include <boost/utility/enable_if.hpp>
 
namespace boost {
 
// Never defined
extern void* enabler;
 
}

using namespace boost::generic::std_concept;
 
struct input_iterator_overload {};
struct bidirectional_iterator_overload {};
struct random_access_iterator_overload {};
 
#define STATIC_ASSERT_IS_SAME( left, right )                                   \
BOOST_STATIC_ASSERT                                                            \
( ( ::boost::is_same                                                           \
    < BOOST_GENERIC_DETAIL_REMOVE_PAREN( left )                                \

#include <boost/auto_function/auto_function.hpp>
#include <boost/generic/std_concept/iterator.hpp>
#include <boost/generic/type_traits/concept_is_modeled_by.hpp>
#include <cassert>
#include <forward_list>
#include <iterator>
#include <list>
#include <vector>
 
// Just for simplicity of the example, pull in the full namespace

// Standard reference 24.2.2
// The following code defines the concept "Iterator"
// The concept is uaary with a single type parameter called "X"
// The "using" argument here specifies that "Iterator" is a refinement of the
// previously defined concepts "CopyAssignable", "CopyConstructible",
// "Destructible", and "Swappable".
// The "for typedef" argument is a convenience argument that lets the programmer
// create a simple alias for a more complicated type name. This alias is only for
// use when calling the macro to simplify the specification of further
// requirements.

/*==============================================================================
    Copyright (c) 2010 Matthew Calabrese

    Use, modification and distribution is subject to 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)
==============================================================================*/
 
// Note: Currently only tested on GCC 4.5.1

// Note: The compiler does not need "requires" or concepts for this to work
//       Also notice that here the predicate is a type
template< class L, class R >
BOOST_AUTO_FUNCTION( add( L left, R right ) )
  ( requires boost::is_pointer< L > )
(
  return left + right // no semicolon, must be an expression
) // Note these are parentheses
 
// Same as above only the predicate is a value

#include <new>
#include <utility>
 
// This macro is variadic in order to directly support operator,
#define BOOST_AUTO_FUNCTION( ... ) auto __VA_ARGS__ -> BOOST_AUTO_FUNCTION_IMPL
 
#define BOOST_AUTO_VOID_FUNCTION( ... )                                        \
auto __VA_ARGS__ -> BOOST_AUTO_VOID_FUNCTION_IMPL
 
// Variadic to support expressions with commas not between parentheses

#include <boost/preprocessor/control/iif.hpp>
#include <boost/preprocessor/facilities/empty.hpp>
#include <boost/preprocessor/facilities/identity.hpp>
#include <boost/ptr_container/clone_allocator.hpp>
#include <boost/type_traits/is_convertible.hpp>
#include <boost/utility/enable_if.hpp>
#include <utility>
 
#define AUTO_FUN_IMPL( ... ) decltype( __VA_ARGS__ ) { return __VA_ARGS__; }

#include <utility>
 
// Note: I've revised my implementation of AUTO_FUN here
// to make its use look more like a function definition
 
#define AUTO_FUN_IMPL( ... ) decltype( __VA_ARGS__ ) { return __VA_ARGS__; }
 
#define AUTO_FUN( name_and_param_list ) auto name_and_param_list-> AUTO_FUN_IMPL
 
template< typename SourceType >

#include <nds.h>
 
// Explanation:
// The following code shows the problem. There are two allocations each yielding
// different adresses. One memory location is filled with red pixels, the other
// is filled with blue pixels. They are then rendered, however you will see two
// red sprites instead of a red and a blue. The reason is that the second
// allocation is not aligned to the boundaries implied by
// SpriteMapping_Bmp_1d_128 meaning that when the oam stores the memory adresses
// as an offset based on the boundary size, both offsets are truncated to the

#include <nds.h>
 
#include <boost/cstdint.hpp>
#include <boost/gil/algorithm.hpp>
#include <boost/gil/image_view.hpp>
#include <boost/gil/packed_pixel.hpp>
#include <boost/gil/rgba.hpp>
#include <boost/gil/virtual_locator.hpp>
#include <boost/mpl/vector.hpp>
#include <boost/utility/binary.hpp>