Posts tagged ‘boost’

Konwencja dostępu do iteratorów STL’u to para metod begin i end, gdzie pierwsza zwraca nam iterator początkowy, natomiast end zwraca iterator końca – dokładniej standard przewiduje, że end będzie określał element „za” ostatnim, ale teraz to nie jest najważniejsze. Myślę, że poniższa pętelka, to chleb powszedni czytelnika:

for( std::map<std::string,std::string>::iterator it = myMap.begin(); it != myMap.end(); it++){
// do some fancy stuff
}

Żeby jak najmniej zaskakiwać użytkownika naszego kodu, postanowiliśmy powielać tę konwencję i dostęp do naszych iteratorów także odbywa sie poprzez pary begin/end. Jednak wyobraźmy sobie sytuacje w której chcemy zwracać różne iteratory, np. mamy vector int’ow i chcemy przy pomocy jednego iteratora przejść przez liczby parzyste, inny umożliwia nam dostęp do nieparzystych, a trzeci do liczb podzielnych przez 5. Chwila zastanowienia i wygląda to na typowe zastosowanie faktorii, gdzie metoda fabrykująca dostaje parametr informujący o tym jaki typ iteratora interesuje użytkownika kodu zadeklarowany jako poniższy enum:

enum ITER{ODD,EVEN,DIV5};

Teraz tylko trzeba to dołączyć do naszego interfejsu i żeby elegancko schować całe to ustrojstwo trzeba dodać dodatkową metodę begin z parametrem, np:

class MyClass {
public:
public MyIterator begin( ITER type ) {}
}

Wszystko ładnie i pięknie, przyszedł moment eksportu api do pythona i jest problem, gdyż boost::python obsługuje jedynie standardowe pary begin/end. Eksport enum’a przy pomocy enum’a boost’owego to bułka z masłem, ale dalej nie da sie dobrać do iteratora innego niż domyślny, chwila 🙂 grzebaniny w źródłach samej bibliteki i mamy obsługę begin z parametrem przy pomocy kodu poniżej:


// Copyright David Abrahams 2002.
// 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)
#ifndef ITERATOR_DWA2002512_HPP
# define ITERATOR_DWA2002512_HPP

# include <boost/python/detail/prefix.hpp>

# include <boost/python/detail/target.hpp>
# include <boost/python/object/iterator.hpp>
# include <boost/python/object_core.hpp>

# include <boost/type_traits/cv_traits.hpp>
# include <boost/type_traits/transform_traits.hpp>

# if defined(BOOST_MSVC) && (BOOST_MSVC == 1400) /*
> warning C4180: qualifier applied to function type has no meaning; ignored
Peter Dimov wrote:
This warning is caused by an overload resolution bug in VC8 that cannot be
worked around and will probably not be fixed by MS in the VC8 line. The
problematic overload is only instantiated and never called, and the code
works correctly. */
#  pragma warning(disable: 4180)
# endif

# include <boost/bind.hpp>
# include <boost/bind/protect.hpp>

namespace boost { namespace python {

namespace detail
{
  // Adds an additional layer of binding to
  // objects::make_iterator(...), which allows us to pass member
  // function and member data pointers.
  template <class Target, class Accessor1, class Accessor2, class NextPolicies>
  inline object make_iterator(
      Accessor1 get_start
    , Accessor2 get_finish
    , NextPolicies next_policies
    , Target&(*)()
  )
  {
      return objects::make_iterator_function<Target>(
          boost::protect(boost::bind(get_start, _1))
        , boost::protect(boost::bind(get_finish, _1))
        , next_policies
      );
  }

  template <class Arg, class Target, class Accessor1, class Accessor2, class NextPolicies>
  inline object make_iterator(
     Arg& arg
    , Accessor1 get_start
    , Accessor2 get_finish
    , NextPolicies next_policies
    , Target&(*)()
  )
  {
      return objects::make_iterator_function<Target, Arg>(
        boost::protect(boost::bind(get_start, _1, _2))
        , boost::protect(boost::bind(get_finish, _1))
        , next_policies
    	, arg
      );
  }

  // Guts of template class iterators<>, below.
  template <bool const_ = false>
  struct iterators_impl
  {
      template <class T>
      struct apply
      {
          typedef typename T::iterator iterator;
          static iterator begin(T& x) { return x.begin(); }
          static iterator end(T& x) { return x.end(); }
      };
  };

  template <>
  struct iterators_impl<true>
  {
      template <class T>
      struct apply
      {
          typedef typename T::const_iterator iterator;
          static iterator begin(T& x) { return x.begin(); }
          static iterator end(T& x) { return x.end(); }
      };
  };


  // guts of template class iterators<>, below.
  template <bool const_ = false>
  struct iterators_impl1
  {
      template <class t, class arg>
      struct apply
      {
          typedef typename t::iterator iterator;
          static iterator begin(t& x, arg y) { return x.begin(y); }
          static iterator end(t& x) { return x.end(); }
      };
  };

  template <>
  struct iterators_impl1<true>
  {
      template <class t, class arg>
      struct apply
      {
          typedef typename t::const_iterator iterator;
          static iterator begin(t& x, arg y) { return x.begin(y); }
          static iterator end(t& x) { return x.end(); }
      };
  };
}

// An "ordinary function generator" which contains static begin(x) and
// end(x) functions that invoke T::begin() and T::end(), respectively.
template <class T>
struct iterators
    : detail::iterators_impl<
        boost::is_const<T>::value
      >::template apply<T>
{
};

// An "ordinary function generator" which contains static begin(x, y) and
// end(x) functions that invoke T::begin(y) and T::end(), respectively.
// where y is extra argument when creating start iterator
template <class T, class Arg>
struct iterators1
    : detail::iterators_impl1<
        boost::is_const<T>::value
      >::template apply<T, Arg>
{
};

// Create an iterator-building function which uses the given
// accessors. Deduce the Target type from the accessors. The iterator
// returns copies of the inderlying elements.
template <class Accessor1, class Accessor2>
object range(Accessor1 start, Accessor2 finish)
{
    return detail::make_iterator(
        start, finish
      , objects::default_iterator_call_policies()
      , detail::target(start)
    );
}

// Create an iterator-building function which uses the given accessors
// and next() policies. Deduce the Target type.
template <class NextPolicies, class Accessor1, class Accessor2>
object range(Accessor1 start, Accessor2 finish, NextPolicies* = 0)
{
    return detail::make_iterator(start, finish, NextPolicies(), detail::target(start));
}

// Create an iterator-building function which uses the given accessors
// and next() policies, operating on the given Target type
template <class NextPolicies, class Target, class Accessor1, class Accessor2>
object range(Accessor1 start, Accessor2 finish, NextPolicies* = 0, boost::type<Target>* = 0)
{
    // typedef typename add_reference<Target>::type target;
    return detail::make_iterator(start, finish, NextPolicies(), (Target&(*)())0);
}

// Create an iterator-building function which uses the given accessors
// and next() policies. Deduce the Target type and Arg type.
template <class NextPolicies, class Accessor1, class Accessor2, class Arg>
object range(Accessor1 start, Accessor2 finish, Arg arg, NextPolicies* = 0)
{
    return detail::make_iterator(arg, start, finish, NextPolicies(), detail::target(start));
}

// A Python callable object which produces an iterator traversing
// [x.begin(), x.end()), where x is an instance of the Container
// type. NextPolicies are used as the CallPolicies for the iterator's
// next() function.
template <class Container
          , class NextPolicies = objects::default_iterator_call_policies>
struct iterator : object
{
    iterator()
        : object(
            python::range<NextPolicies>(
                &iterators<Container>::begin, &iterators<Container>::end
                ))
    {
    }
};

// A Python callable object which produces an iterator traversing
// [x.begin(y), x.end()), where x is an instance of the Container
// type and y is extra parameter that begin accepts when crating start
// iterator. NextPolicies are used as the CallPolicies for the iterator's
// next() function.
template <class Container, typename Arg
          , class NextPolicies = objects::default_iterator_call_policies>
struct iterator1 : object
{
	Arg arg;
    iterator1()
        : object(
            python::range<NextPolicies>(
                &iterators1<Container, Arg>::begin, &iterators<Container>::end, arg
                ))
    {
    }
};

}} // namespace boost::python

#endif // ITERATOR_DWA2002512_HPP


Teraz już możemy sobie bez większych problemów wyeksportować nasz iterator korzystając z konstrukcji:

.def("ints", bp::iterator1<IntWrapper,IntWrapperUtils::IteratorType>() );

Gdzie drugi argument to typ naszego iteratora.

Jeszcze tylko eksport enum’a, ale jak pisałem wyżej to prościzna 🙂

bp::enum_<IntWrapperUtils::IteratorType>("IteratorType")
.value( "ODD", IntWrapperUtils::ODD )
.value( "EVEN", IntWrapperUtils::EVEN )
.export_values()

I w skrypcie możemy już sobie wywoływać

for x in b.ints(IteratorType.EVEN):
print x

Voila 🙂

Tak jak zapowiadałem w moim poprzednim wpisie, rvalue_converter operujący na streamach jest też, a jakże. Krótkie wprowadzenie: mamy sobie wyeksportowane api, które m.in. prowadzi zapis danych do pliku, ale aby odciążyć sama metodę od żmudnych operacji na strumieniach, a jednocześnie dać jej dużą elastyczność dot. zapisu danych, dostaje ona gotową referencję do strumienia jako parametr, przykładowy kod może wyglądać tak:

class MyClass {
public:
writeToStream( std::ifstream& out ){}
}

No i teraz, fajnie by było mieć możliwość otwarcia pliku po stronie pythona i tylko przesłania samego uchwytu do naszej metody c++’owej. Otóż Ci którzy czytali poprzedni wpis o konwersji stringów już pewnie wiedzą, że to jest możliwe, może troche karkołomne, bo synchronizacja streamów to sprawa niebalna, no ale w moich testach wszystko działa poprawnie.

A oto i kod:

namespace tulips { 
namespace converters { 
namespace fstream {

  class custom_fstream
  {
    public:
		custom_fstream(
			const char* path,
			FILE* file,
			std::ios_base::openmode mode = std::ios_base::in | std::ios_base::out
		) :
			m_fstream(path,mode),
			m_file(file)
		{
			fflush(m_file);
			m_fstream.seekg(ftell(m_file));
		}
		std::fstream& get_stream() { return m_fstream; }
		~custom_fstream(){ fseek( m_file, m_fstream.tellg(), SEEK_SET );}
    private:
      std::fstream m_fstream;
      FILE* m_file;
  };

  struct custom_fstream_from_python_file
  {
	custom_fstream_from_python_file()
	{
		bp::converter::registry::push_back(
			&convertible,
			&construct,
			bp::type_id<custom_fstream>());
	}

	static void* convertible(PyObject* obj_ptr)
	{
		if (!PyFile_Check(obj_ptr) || obj_ptr == Py_None) return 0;
		return obj_ptr;
	}

	static void construct(PyObject* obj_ptr, bp::converter::rvalue_from_python_stage1_data* data)
	{
		FILE* file = PyFile_AsFile(obj_ptr);
		void* storage = ((bp::converter::rvalue_from_python_storage<custom_fstream>*)data)->storage.bytes;
		new (storage) custom_fstream(PyString_AsString(PyFile_Name(obj_ptr)), file, std::ios::in|std::ios::out);
		data->convertible = storage;
	}
  };

  void init_converter()
  {
    custom_fstream_from_python_file();
  }

}}} // namespace tulips::converters::stream

No i teraz już możemy sobie przesyłać uchwyt do strumienia otwarty po stronie pythona 🙂

Przypuśćmy, że mamy gotowy program w c++, który sobie wczytuje pewne dane, operuje na nich i wypluwa wynik, nic wielkiego, przykładów można znaleźć tysiące. Jednak nasz program, żeby być w miarę elastycznym obsługuje pluginy w formie plików bibliotecznych (dll/so), ładowanych na żądanie, ale chcielibyśmy skorzystać z elastyczności jaką daje język skryptowy, np. python a jednocześnie cały czas mieć możliwość optymalizacji kodu po stronie c++.

Rozwiązaniem jest biblioteka boost::python, ale podobnie jak w przypadku boost::shared_ptr dokumentacje mają niezłą, więc wprowadzenia robić nie będę.

Chciałbym się skupić na konwesji typów pomiędzy c++ a python’em i odwrotnie a konkretnie przedstawić konwerter pomiędzy std::basic_string<unsgned char>, który jest wykorzystywany do przechowywania danych wewnątrz elementu (np. Field) z i do pythonowego stringa, mamy już wyeksportowane api, które może mieć postać:

class SampleObject {
public:
void setValue( std::basic_string v& ) {
// do some important stuff
}
}

Jednak po wyeksportowaniu takiej metody okazuje się, że wołając z pythona:sampleObject.setValue( ‚sample value’ )Dostajemy błąd o niezgodności typów i pozostaje nam tylko przyglądać sie komunikatowi błędu.

Rozwiązaniem jest napisanie własnego konwertera, który weźmie stringa pythonowego, zamieni go na unsigned char* i przekaże dalej gdzie trzeba. Oczywiście nie jest to jedyne rozwiązanie, bo równie dobrze można sobie przeciążyć dana metode we wrapperze do api pythonowym, i w niej zrobić całe czary-mary, ale to takie szablonowe…

No więc nasz konwerter, wie że dostanie PyString albo std::basic_string<unsigned char> i ma wyprodukować to co trzeba, oto i on:

typedef std::basic_string ustring;
namespace bp = boost::python;
namespace tulips{
namespace converters {
namespace ustr {
// definiujemy zawijacza na ustring
class custom_string {
public:
custom_string() {}
custom_string(const ustring& value) :
 	m_string(value) {
}
const ustring& value() const {
return m_string;
}
private:
ustring m_string;
};
struct custom_string_to_python_str {
static PyObject* convert(const custom_string& s) {
return bp::incref(bp::object(s.value()).ptr());
}
};
struct custom_string_from_python_str {
custom_string_from_python_str() {
bp::converter::registry::push_back(&convertible, &construct, bp::type_id());
}// sprawdz czy konwersja jest mozliwa
static void* convertible(PyObject* obj_ptr) {
if (!PyString_Check(obj_ptr))
return 0; //zero 🙂
return obj_ptr;
}// no i przekonwertuj
static void construct(PyObject* obj_ptr, bp::converter::rvalue_from_python_stage1_data* data) {

// pobierze stringa z obiektu PyObject
const char* str = PyString_AsString(obj_ptr);
const unsigned char* value = (const unsigned char*) str; // cast na unsigned char*
if (value == 0) // sprawdz czy napewno sie udał
bp::throw_error_already_set();
void* storage = ((bp::converter::rvalue_from_python_storage*) data)->storage.bytes; // pobierz pamiec zalakowana w storage'u
new (storage) custom_string(value); // przypisz custom_string'a do pamieci
data->convertible = storage; // zapisz przekonwertowany typ
}
};
// jeszcze tylko pobierzemy sobie rozmiar to tak zeby len() tez zadzialalo
std::size_t size(const custom_string& s) {
return s.value().size();
}
// no i trzeba powiadomic pythona jak ma przeprowadzic konwersje
void init_converter() {
bp::to_python_converter();

custom_string_from_python_str();

bp::def("size", size);
}}
}
} // namespace tulips::converters::ustring

Voila, to nie było aż takie trudne!

Wszyscy programujący w c/c++ wiedzą, że zarządzanie pamięcią to nie jest sprawa prosta. Załóżmy, że mamy sobie obiekt grupujący jakies pola, powiedzmy, że będzie to klasa Header, i ma mapę Fieldów  (std::map<std::string,Field>) identyfikowanych po nazwie. No i chcemy, żeby Field’y można było modyfikować poza Header’em, czyli mapa musi być dostępna przez publiczne api. Możnaby coprawda udostępnić tylko kopię referencji w mapie, ale tracimy cała elastyczność związaną z bezpośrednimi modyfikacjami Fieldów. No tak, tylko teraz mamy iterację po wskaźnikach na obiekty Field, przykładowy kod może wyglądać tak:

for( FieldMap::iterator it = fieldMap.iterator(); it != fieldMap.end(); it++ ) {

Field* f = *it;

}

Wygląda prosto, ale co jeżeli ktoś zechce nam taki wskaźnik usunąć, albo zastąpić go innym wskaźnikiem? To tylko 2 przykładowe problemy z jakimi sie można napotkać stosując powyższe rozwiązanie. Pewnie zaraz puryści dodadzą, żeby powstawiać całą masę const‚ów, które owszem rozwiążą część problemów, ale same stworzą kolejne.

Zamiast żonglować const’ami, można zastosować smart pointer’y. Czymże one sie charakteryzują – otóż w swej najprostszej postaci, przewowuja nam wskaźnik i udostepniają na żądanie, usuwając go w momencie usunięcia samego siebie (std::auto_ptr) + przechowują prawo własności do wskaźnika. W bardziej skomplikowanej postaci, posiadają wewnętrzny licznik referencji, dzięki któremu mogą stwierdzić czy dany obiekt nadaje sie do usunięcia czy nie (boost::shared_ptr). Żeby jeszcze sobie uprościć życie, można zezwolić na konstrukcję „pustych” obiektów shared_ptr i wypełniać je wskaźnikami dopiero na żadanie.

To w sumie tyle wprowadzenia, po więcej odsyłam do dokumentacji boost’a – nie będe jej tutaj powielał, natomiast moim celem jest przekazanie paru problemów, z którymi sie napotkałem podczas pracy z boost::shared_ptr.

1. Konstruktor kopiujący a nieusuwalny boost::shared_ptr.

W manualu boost’owym podają, że jeżeli potrzebujemy stworzyć inteligentny wskaźnik, który nie będzie usuwany, bo np zarządzamy nim gdzie indziej, a referencji z jakiegoś względu nie możemy przekazać – można do konstruktora przesłać jako dodatkowy argument funktor, który zapewni nam, że podczas dojścia licznika referencji do 0, nic się nie stanie.

Uzbrojeni w taka broń smiało przekazywaliśmy nasz obiekt to tu to tam, aż w pewnym momencie ni z gruchy ni z pietruchy pokazał sie  seg fault. Otóż okazało się, że nasz konstruktor kopiujący owszem kopiował wskaźnik, zwiększał licznik referencji, ale o zgrozo, NIE KOPIOWAŁ funktora, przez co nasz nieusuwalny wskaźnik stawał sie zwykłym shared_ptr’em i w momencie dojścia licznika do 0, został skasowany.

2. Nasza przykładowa aplikacja udostępnia swoją mapę, światowi zewnętrznemu, ale tenże swiat ingerując w stan jej elementów, może nam popsuć sporo i aby temu zaradzić można wprowadzić obserwatora, w momencie dodania fielda, kontener (w tym przypadku Header) rejestruje sie jako obserwator fieldów, a one wysyłają notyfikację, jak ktoś lub coś je zmienia.

Problem jaki się pojawił był związany właśnie z obserwatorem. Otóż w pewnym momencie pochodne Headera służyły jednynie za twórcę mapy, która miała być przekazana dalej, jednak rejestrowały sie jako obserwatory, a w momencie usunięcia nie wyrejestrowywały się, więc mapa lądowała w innej strukturze, ze wskaźnikiem na zwolniony obszar w pamięci.

Dodanie autousuwania obserwatora ze wszystkich fieldów w destruktorze naprawiło sytuację.

Ten krótki artykuł nie jest próbą dyskredytacji smart pointerów a jedynie, formą dzielenia się wiedzą, bo skoro zdażyło sie to raz, to pewnie komuś sie zdarzy drugi raz.

Pozdrawiam