- Boost - lists.preview.boost.org

[unordered] patch to remove warning on Visual C++
by Christopher Lux 16 Nov '08

16 Nov '08

Hi, appended is a small patch to fix some annoying warnings using Visual C++ 8.0 and 9.0. It would be nice if this could be looked at and applied to the trunk. The warnings were: 1>brick_pool.cpp 1>E:\devel\working_copies\schism_x64_vc90_sp1\externals\inc\boost\boost/unordered/unordered_map.hpp(388) : warning C4396: 'boost::operator ==' : the inline specifier cannot be used when a friend declaration refers to a specialization of a function template 1>E:\devel\working_copies\schism_x64_vc90_sp1\externals\inc\boost\boost/unordered/unordered_map.hpp(389) : warning C4396: 'boost::operator !=' : the inline specifier cannot be used when a friend declaration refers to a specialization of a function template Regards -chris -- Christopher Lux | | Bauhaus-Universität Weimar | faculty of media - virtual reality systems group

2 4

[Multiarray] & [Range] MSVC/gcc warning: returning address of local variable or temporary
by John Reid 15 Nov '08

15 Nov '08

The following code generates a worrying warning under MSVC: #include <boost/range/iterator_range.hpp> #include <boost/multi_array.hpp> typedef boost::multi_array< double, 1 > my_array; typedef my_array::const_iterator it; void test(const my_array & a) { boost::iterator_range< it > it_range(a.begin(), a.begin() + 1); it_range[0]; } C:\Dev\ThirdParty\boost\boost_1_37_0\boost/range/iterator_range.hpp(356) : warning C4172: returning address of local variable or temporary C:\Dev\ThirdParty\boost\boost_1_37_0\boost/range/iterator_range.hpp(354) : while compiling class template member function 'const double &boost::iterator_range<IteratorT>::operator [](__w64 int) const' with [ IteratorT=it ] iterator_range.cpp(8) : see reference to class template instantiation 'boost::iterator_range<IteratorT>' being compiled with [ IteratorT=it ] I'm using msvc 8.0 express and boost 1.37.0 release. I've seen similar warnings from gcc 4.3 on similar code. Is this a problem with boost.Multiarray, boost.range or the compiler? My guess is that Multiarray has defined its iterators incorrectly. Can anyone confirm this/provide a fix? Thanks, John.

6 11

Boost conformance to standard c++0x libraries statement
by vicente.botet 15 Nov '08

15 Nov '08

Hi, There are a lot of Boost libraries already included in the C++ Standards Committee's Library Technical Report (TR1). More Boost libraries are proposed for the upcoming TR2. As all these libraries do not conform completly to the standard for different raisons: the compliler do not support some feautres of the C++0x, the emulation seems to complex or any other justification. I think that it will help the users to have a clear statement, library by library, of which features the library conform to or not. This statement should contain the library feature(class, typedef, constants, functions, ...), dependencies on other C++0x features, whether it conforms on C++0x compilers supporting the needed compiler features, if it use some workaround on other compilers and finaly for the non conformant features why the library do not conforms. It will be also useful to state which features on the library are not on the standard. I have prepared as an example a table for the Boost.Thread library (limited tothread and this thread API). Anthony the informations on these tables could be wrong. Attached boost_thread_conformance.qbk and boost_thread_conformance.html Any comments and ideas are welcome. HTH, Vicente

1 0

[thread] sleep() with time_duration?
by Boris 15 Nov '08

15 Nov '08

If I want a thread to sleep for five seconds the shortest code I could come up with is: boost::system_time time = boost::get_system_time(); time += boost::posix_time::seconds(5); boost::thread::sleep(time); It would be nice if it was possible to pass a time_duration object to sleep() directly: boost::thread::sleep(boost::posix_time::seconds(5)); This would also be consistent with the deadline_timer in Boost.Asio whose constructor accepts both a time and a time_duration. Boris

4 7

[Random] design of the random library
by Ares Lagae 15 Nov '08

15 Nov '08

I have some questions regarding the design of the C++/TR1 and Boost.Random library. What are the requirements on the UniformRandomNumberGenerator argument of operator() of random distribution class templates? It seems that the only requirement is uniform distribution, and both range and type (integer / floating point) are not specified. Does this mean that the random distribution class templates work with any kind of UniformRandomNumberGenerator? Does the normal_distribution work as expected with a linear congruential uniform random number generator? Or does the normal distribution assume a continuous distribution in [0,1[? Are these requirements documented? I could not immediately find them in the documentation. It seems operator() of most random distributions will first have to construct a uniform_01 random distribution from the UniformRandomNumberGenerator argument and then transform that distribution to the required distribution (e.g. the normal_distribution would construct a uniform_01 distribution from the UniformRandomNumberGenerator argument of operator() and then use the Box-Muller transformation). I would appreciate it if someone could clarify these issues. -- Ares Lagae, Ph.D. Computer Graphics Research Group, Katholieke Universiteit Leuven http://www.cs.kuleuven.be/~ares/

2 3

default value for a variable using template argument
by Chris 15 Nov '08

15 Nov '08

Hi, did anyone ever suggest a template class which initializes a variable to a certain value? (see example) Is this too trivial? This is useful to prevent uninitialized values in objects. class A { defaulted<int, 1280> _width; defaulted<int, 1024 > _height; defaulted<int, 0> _depth; }; template <typename TYPE, TYPE value> class defaulted { public: defaulted() : _t(value) { } defaulted(const TYPE & value2) : _t(value2) { } operator TYPE & () { return _t; } TYPE * operator & () { return &_t; } const TYPE * operator & () const { return &_t; } operator const TYPE & () const { return _t; } TYPE & operator =(const TYPE & other) { _t = other; return _t; } private: TYPE _t; };

4 4

[thread] other thread_group functions
by vicente.botet 14 Nov '08

14 Nov '08

Hi, I would like to know which of the following thread functions have a sens for thread_group? bool joinable() const; bool timed_join(const system_time& wait_until); template<typename TimeDuration> bool timed_join(TimeDuration const& rel_time); void detach(); I have another sugestion related to the _all suffix of the thread_group functions join_all and interrupt_all. Could you add the synonyms join and interrupt? In this way a thread_group can be seen as a compound object sharing the same interface as the element thread. ______________________ Vicente Juan Botet Escribá

1 0

[thread] getting boost::thread* form boost::thread::id
by vicente.botet 14 Nov '08

14 Nov '08

Hi Anthony, I'm working with a keep_alive mechanism. I need to interrupt threads that are considered 'dead'. I have access to the thread specific context using a map : boost::thread::id -> context. This mapping is modified by self registration from the thread. On the other side I need a boost::thread pointer to interrupt the thread. With the current Boost.Thread interface, I don't see how I can get it either from the current thread or from the thread::id. Can I? Currently only the thread creator wrapper can add this information. I think that I could add a thread creator wrapper that add this as a thread specific pointer, but I will be able to get only the thread* for the threads created with this wrapper, which is not completly satisfactory. Do you think that at least one of these functions could be of general use: one for getting a boost::thread* form a boost::thread::id and one for getting the boost::thread* of the current thread? namespace boost { class thread { // ... static thread* get_thread_ptr(id); }; namespace this thread { thread* get_thread_ptr(); } } To implement this in Boost.Thread it will be need to store the thread* on the detail::thread_data_ptr. Do you think that this could be a possible addition on the Boost.Thread library? Thanks, Vicente

3 2

[numeric_cast] request for boost::numeric_downcast
by Thorsten Ottosen 14 Nov '08

14 Nov '08

Hi Fernando, Amoung our utilities we have boost::polymorphic_cast boost::polymorphic_downcast The latter only performs a check in debug builds, and can then be used whenever the cast must succeed. boost::numeric_cast has no such alternative. Therefore I wuold like to see one. To keep in the naming convention from above, I think it could be reasonable to call this boost::numeric_downcast Furthermore, this should if possible be implemented in a seperate header (which is included in the main header) that can be compiled without exception-support. I think there are still platforms where they need this functionality, but don't want to sue exceptions. Any comments -Thorsten

6 14

[thread] Conformance with N2497 move semantics
by vicente.botet 14 Nov '08

14 Nov '08

Hi Anthony, N2497 includes the following thread constructor overloadings template <class F> explicit thread(F f); template <class F, class ...Args> thread(F&& f, Args&&... args); void swap(thread&&); Boost.Threads try to conforms to N2497 as muh as possible. Boost.Threads defines already #ifdef BOOST_HAS_RVALUE_REFS template <class F> thread(F&& f); #else #ifdef BOOST_NO_SFINAE template <class F> explicit thread(F f); #else template <class F>explicit thread(F f, typename disable_if< boost::is_convertible<F&, detail::thread_move_t<F> >, dummy* >::type=0); #endif template <class F>explicit thread(detail::thread_move_t<F> f); template <class F,class ...Args> thread(F f, Args... args) I have some questions. Is there any deep raison for which template <class F> explicit thread(F f); should not always be defined? Is there any deep raison to emulate template <class F,class ...Args> thread(F f, Args... args) instead of template <class F,class ...Args> thread(F&& f, Args... args) Could template <class F, class ...Args> thread(F&& f, Args&&... args); rally be emulated? You provide 'void swap(thread&)'. Could 'void swap(thread&&)' be emulated? Do you know if the following overloadings are taken in account by the boost::swap utility? void swap(thread& x, thread& y); void swap(thread&& x, thread& y); void swap(thread& x, thread&& y); Thanks in advance, Vicente

2 2

Re: [boost] Compiling 64bit regex 1.37.0 with VS2005
by Gary Mann 14 Nov '08

14 Nov '08

I also see the same problem compiling with 32 bit MSVC 7.1 SP1 (13.10.6030). I don't experience the issue when using STLport - only when using the native Dinkumware STL implementation (not surprising given the preprocessor directives in the file). src\usinstances.cpp(47) : error C2910: 'std::char_traits<wchar_t>::length' : cannot be explicitly specialized I tried grabbing the latest copy of the source file from SVN, but it appears identical to that included in the 1.37.0 distribution. I haven't tried updating all the source and headers for the entire regex component yet... Gary -- View this message in context: http://www.nabble.com/Compiling-64bit-regex-1.37.0-with-VS2005-tp20493076p2… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 4

Re: [boost] [utility/swap] Internal compiler error Siliconman borland-6.10.0 (CodeGear?)
by Niels Dekker - mail address until 2010-10-10 14 Nov '08

14 Nov '08

>> But unfortunately, the rather simple specialized_in_std.cpp test >> gets an internal compiler error (Fatal F1004) from borland-6.10.0. I >> guess this is a CodeGear issue, right? David (siliconman) wrote: > Yes, this looks like a compiler bug. I'll submit it to the bug > tracking system. Thanks! So did you report the bug to http://qc.codegear.com ? If so, can you please give me the report number? Kind regards, Niels

1 0

[unordered] patch to remove warning on Visual C++
by Christopher Lux 14 Nov '08

14 Nov '08

Hi, appended is a small patch to fix some annoying warnings using Visual C++ 8.0 and 9.0. It would be nice if this could be looked at and applied to the trunk. The warnings were: 1>brick_pool.cpp 1>E:\devel\working_copies\schism_x64_vc90_sp1\externals\inc\boost\boost/unordered/unordered_map.hpp(388) : warning C4396: 'boost::operator ==' : the inline specifier cannot be used when a friend declaration refers to a specialization of a function template 1>E:\devel\working_copies\schism_x64_vc90_sp1\externals\inc\boost\boost/unordered/unordered_map.hpp(389) : warning C4396: 'boost::operator !=' : the inline specifier cannot be used when a friend declaration refers to a specialization of a function template Regards -chris -- Christopher Lux | | Bauhaus-Universität Weimar | faculty of media - virtual reality systems group Index: boost/unordered/unordered_map.hpp =================================================================== --- boost/unordered/unordered_map.hpp (revision 49734) +++ boost/unordered/unordered_map.hpp (working copy) @@ -385,8 +385,8 @@ friend bool operator==(unordered_map const&, unordered_map const&); friend bool operator!=(unordered_map const&, unordered_map const&); #else - friend bool operator==<>(unordered_map const&, unordered_map const&); - friend bool operator!=<>(unordered_map const&, unordered_map const&); + friend bool operator==<unordered_map>(unordered_map const&, unordered_map const&); + friend bool operator!=<unordered_map>(unordered_map const&, unordered_map const&); #endif }; // class template unordered_map

1 0

Compiling 64bit regex 1.37.0 with VS2005
by Foster Brereton 14 Nov '08

14 Nov '08

Hi, I've been looking around for potential issues I may have missed but have found none, so I thought I'd ask the list. I am trying to compile the regex library from 1.37.0 using MSVC2005. This used to work for boost 1.36.0, but does not anymore. The extended error set I have pasted here for email brevity: http://pastebin.com/md368403 The start of the errors I'm seeing are: usinstances.cpp C:\boost_libraries\libs\regex\src\usinstances.cpp(47) : error C2910: 'std::char_traits<wchar_t>::length' : cannot be explicitly specialized ... wc_regex_traits.cpp C:\boost_libraries\libs\regex\src\wc_regex_traits.cpp(48) : error C2910: 'std::char_traits<wchar_t>::length' : cannot be explicitly specialized ... ... the really strange thing is, those lines read as follows: template<> BOOST_REGEX_STDLIB_DECL std::size_t __cdecl char_traits<unsigned short>::length(unsigned short const*); ...and... template<> BOOST_REGEX_STDLIB_DECL std::size_t __cdecl char_traits<unsigned short>::length(unsigned short const*); ... respectively, and make no mention of wchar_t. My project settings are as follows: /Od /I "." /I "." /D "DVA_COCOA_UI=0" /D "BOOST_ALL_DYN_LINK" /D "BOOST_ALL_NO_LIB" /D "_WINDOWS" /D "MSWindows" /D "_CRT_SECURE_NO_DEPRECATE" /D "_SCL_SECURE_NO_DEPRECATE" /D "BOOST_THREAD_BUILD_DLL" /D "BOOST_REGEX_USE_CPP_LOCALE" /D "BOOST_NO_WREGEX" /D "BOOST_REGEX_RECURSIVE" /D "BOOST_REGEX_NO_LIB" /D "DEBUG=1" /D "_DEBUG" /D "_WINDLL" /D "_UNICODE" /D "UNICODE" /GF /FD /EHsc /RTC1 /MDd /Zp8 /Gy /Zc:wchar_t- /Fo"..\..\obj\win\debug\64/" /Fd"..\..\lib\win\debug\64/boost_regex.pdb" /W3 /nologo /c /Zi /TP /wd4355 /errorReport:prompt I'm compiling with wchar_t support turned off, and am defining BOOST_NO_WREGEX in an attempt to state as much explicitly for the library. (I couldn't find much documentation about disabling wchar_t support for the regex library explicitly). Does anyone have any pointers to guide me in the direction I should go to get this building again under a 64-bit environment? Thanks in advance for the help, Blessings, Foster -- Foster T. Brereton Adobe Systems Incorporated fbrereto(a)adobe.com

2 1

Boost, preprocessing, computed #includes, and distcc
by David Abrahams 14 Nov '08

14 Nov '08

One of the few options Boost users have for speeding up long compiles is to throw more machines at the problem, as with distcc (http://code.google.com/p/distcc/) I was just wondering why I couldn't get distcc's incredible "pump" mode to work as well as it should, and discovered this text: "In distcc-pump mode, the include server is unable to handle certain very complicated computed includes as found in parts of the Boost library. The include server will time out and distcc will revert to plain mode." (http://distcc.googlecode.com/svn/trunk/doc/web/man/distcc_1.html#TOC_22) It's nice that they consider it a bug, but it doesn't sound they're going to go out of their way to fix it. Just another lovely trade-off to keep in mind when making design decisions... ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 3

[MPL.Math] ratio
by Cromwell Enage 14 Nov '08

14 Nov '08

Hi, all! Sorry I've been out for so long. I've been reading N2691 for the past couple of days. I just noticed section 20.3, called "compile-time rational arithmetic", and I'm wondering how stable that specification is. I'm also wondering whether or not anyone else has been working on an implementation. A Google search turned up a "Summer of Code" project labeled 'ontl', but the ratio source code is not part of the download or its SVN distribution. In the meantime, my questions are: * Should I resume work on MPL.Math? Should I make a different branch, still part of MPL? Or should I fork a separate Boost project altogether? * If I resume work, should I make the implementation more standards-conformant? Cheers, Cromwell D. Enage

4 9

[MPL.Math] linear solver
by Cromwell Enage 14 Nov '08

14 Nov '08

Hi, Matthias. We were talking about Steven Watanabe's compile-time linear solver, currently part of Boost.Units. Can you point me in the right direction as to where the implementation is? (My initial guess is <boost/units/detail/linear_algebra.hpp>.) Documentation would be a big plus, but at least I can read source code. Cheers, Cromwell D. Enage

3 2

Re: [boost] Fwd: [signals2][review] little REVIEW
by vicente.botet 14 Nov '08

14 Nov '08

> ----- Original Message ----- > From: "Frank Mori Hess" <fmhess(a)speakeasy.net> > To: <boost(a)lists.boost.org> > Sent: Wednesday, November 12, 2008 4:01 AM > Subject: Re: [boost] Fwd: [signals2][review] little REVIEW > > > On Tuesday 11 November 2008 11:23, Stjepan Rajko wrote: >> ---------- Forwarded message ---------- >> From: <Jean-Christophe.BENOIST(a)fr.thalesgroup.com> >> * On test suite / test cases : >> >> - I cannot see any MT test case (from the documentation, in >> "acceptance tests" section at least). It's rather surprising. I cannot >> imagine there is no test case for MT (calling a signal while >> disconnecting slot etc..). In particular, I'd whish to see if this >> library is robust in a multi-core environment and run test cases in >> this environment (I know cases where a library is perfectly thread >> safe on mono-core, even hyperthreading, but fails on multi-core). At >> least, there should be a rationale explaining why this library should >> be robust in a multi-core environment (especially with a proprietary >> signals2::mutex). > > It's not obvious to me how to write a test for the library's > thread-safeness that is any more focused than "we did some signals stuff > in multiple threads and the program didn't crash". It's sort of like > writing a test for memory leaks. What you need is a debugging tool, like > what valgrind's helgrind tries to be. Then you can have your > multi-threaded test program, and the test is whether or not the debugging > tool detected any funny business (like multiple threads messing with the > same variable without locking). Yes I know that doing test on a multi-threading environement is not eassy, but we can not deliver a thread safe library without the minimal unit testing coverage on all the functionalities concerned by the multi-threading. Please could you take a look on hwo the tests of the Boost.Thread library are done. Regards, Vicente

2 1

[signals2] extended_slot_type bug with preferred syntax
by Frank Mori Hess 13 Nov '08

13 Nov '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In case anyone is trying to use extended_slot_type/connect_extended with the "preferred syntax" signal for the review, there is a bug with the default ExtendedSlotFunction template type parameter. Fix is in svn revision 49593: https://svn.boost.org/trac/boost/changeset?new=49593%40sandbox%2Fthread_saf… The "portable syntax" signals are not affected. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJELwa5vihyNWuA4URAueDAJ9V/2Bdpf2N6VWaUrjgWpyIvyH1mgCgrOP0 mJzCelYUnWTmNsoHzMPfKdY= =8bRd -----END PGP SIGNATURE-----

3 10

[c++-sig] A question regarding arguments bindings
by Sandeep Gupta 13 Nov '08

13 Nov '08

Hi, My question is regarding the default behavior of the compiler when there is mismatch in the argument type between binding declaration and function declaration. By default no warning is generated. Consider following example: class A{ public: A(const B&); }; In wrapper, if by mistake (which I made in my code), i write class_<A>("A", init<B>) ; The compiler does not complain about no constructor found. Instead for reasons, beyond my understanding of boost.python, B get passed by value. My question why doesn't compiler issue at least a warning. Needless to say i am new to boost.python. My apologies if this is something trivial or well known. Thanks sandeep

2 2

[flyweight] key value with objects not constructible from a key
by Michael Marcin 13 Nov '08

13 Nov '08

The flyweight factory concept seems to be missing a key part of the GoF Flyweight pattern's FlyweightFactory participant. The GoF factory supplies the flyweight if one exists. This is what the current boost flyweight Factory concept does. If no flyweight exists the GoF flyweight factory creates one. In the boost flyweight library this functionality is somewhere else that doesn't seem to be described in the documentation. The name factory for what is currently in place is misleading. Isn't it really just an associative container? I'm trying to use flyweight to represent texture objects right now. These are surely a good candidate for use with flyweight as they are one of the examples given. My textures are fairly simple objects, with low coupling. Creating a texture is however expensive and has a lot of dependencies (libjpeg,libpng,etc). I typically have a TextureFactory which decouples the construction of a texture from the actual texture object and allows the work required to setup the various libraries to read images to be reused by all textures constructed from the same TextureFactory instance. It doesn't seem possible to have this decoupling with flyweight. Am I missing something? -- Michael Marcin

5 20

[Chrono] Boost.Chrono added to sandbox
by Beman Dawes 13 Nov '08

13 Nov '08

Work-in-progress for the Boost.Chrono library has been added to the sandbox. See http://svn.boost.org/svn/boost/sandbox/chrono This work is in a very preliminary state. The only testing has been with VC++ 9.0 on XP-64 and a tiny bit on Ubuntu 8.04 Linux. There has been no work done yet on C++0x headers. The Jamfiles are there, but haven't been tested; I've been developing using the provided VC++ solution. The implementation of the clocks is going to be very system specific. If anyone would like to try .../libs/chrono/example/await_keystroke.cpp and report whether or not it compiles and works on their system, it would be appreciated. Patches to make .../libs/chrono/src/chrono.cpp work for various operating systems would be even more appreciated! I'm still unsure about even some of the basics, such as how to partition the three parts for boost. Are the time utilities, the compile-time rational arithmetic, and the type trait common_type three boost libraries, one boost library, or three parts of a larger boost library? There was some discussion of this in a prior thread, but I thought having the actual code available might move the discussion forward. There is a tiny bit of documentation; see .../libs/chrono/doc/index.html. Comments welcome! --Beman

4 6

[TR1] Sun problems (again)
by Ling Li 13 Nov '08

13 Nov '08

(The related thread is http://lists.boost.org/Archives/boost/2006/08/109450.php) Sun CC seems to have #include guards automatically for standard headers like <memory>. This somehow causes problems to Boost::TR1. Here is a simple example (call it sun-test.cpp) that doesn't compile with Sun's compiler: #include <string> #include <memory> void f() { std::tr1::shared_ptr<int> p(new int()); } The command line is: CC -c -library=stlport4 -I<BOOST_TOP>/boost/tr1/tr1/sun -I<BOOST_TOP>/boost/tr1/tr1 -I<BOOST_TOP> sun-test.cpp And the error msgs: "sun-test.cpp", line 5: Error: tr1 is not a member of std. "sun-test.cpp", line 5: Error: shared_ptr is not defined. "sun-test.cpp", line 5: Error: Badly formed expression. The reason is that the 2nd include, "#include <memory>," is not honored since Sun's <string> (included from Boost::TR1's string) somehow loads <memory> inside it. Although the <memory> header it loads is the Boost::TR1 version, Boost is smart enough not to include the TR1 extension part. That is actually the correct thing to do, and other compilers (VS and GCC) will get the TR1 extension via the 2nd include. But for Sun's CC, since the 2nd include is not honored, std::tr1 is missing. Sun CC doesn't do that auto #include guards for user headers. I am wondering if there is a way to turn off that auto guards for Sun CC (I haven't found a way yet). Or is there some way to change Boost::TR1 to accommodate this special behavior?

3 6

Re: [boost] llvm anyone?
by Giovanni Piero Deretta 13 Nov '08

13 Nov '08

On Wed, Nov 12, 2008 at 4:34 PM, Marshall Clow <marshall(a)idio.com> wrote: > At 10:29 AM -0500 11/12/08, Neal Becker wrote: >> >> Anyone testing on llvm compiler? (I'm trying it now on linux F9 x86_64 >> llvm-2.4) > > I believe that the llvm support for C++ is best described as "currently > quite limited". > I expect this to change over the next year or so, though. The clang front end is certainly only in an experimental stage, but LLVM also support the gcc front end (LLVM-gcc) which means that its C++ support should be about as good as native GCC. As the backend is quite different and there might be some small differences in the front end, it might still make sense to test on it. -- gpd

6 5

[OT] Contact with Jeff Garland
by Robert Kawulak 13 Nov '08

13 Nov '08

Hi Jeff, I was not able to contact you via e-mail -- could you please write to me how can I reach you? Best regards, Robert

1 0