January 2009 - Boost - lists.preview.boost.org

[future] review starts today?
by k-oli＠gmx.de 05 Jan '09

05 Jan '09

Does the review start officialy today (5. January)? Between the announcement and the 5. January a lot of posts arrived the mailing list. Oliver

1 0

Re: [boost] [crypto] Finalisation
by Kasra 05 Jan '09

05 Jan '09

Dear Kevin, I didn't know you were working on your library I thought you have coded one and decided it was enough for your needs and had stopped developing. So if we are both developing I personally think it is more than silly to code two separate libraries instead of focusing on one. If you are interested we could merge the current progress into 1 library. In regards to your comment about the amount of code, I have the following algorithms fully functioning (some need little attention): BlockCiphers: Blowfish, Cast-256, Khazad, Mars, Rijndael, RC2, RC5, RC6, Serpent, Twofish All of the above implementations are generic, for example rc6 is defined as follows: template < size_t R, // # of rounds typename W // word size {uint8_t,uint16_t,uint32_t,uint64_t} > class rc6_cipher; // the recommended rc6, although completely generic // but the following typedef could gain performance of // 26 Clocks Per Byte (CPB) which is _almost_ as fast as it gets typedef rc6_cipher<20,32> rc6; StreamCiphers: RC4, HC-128/256, Rabbit, Salsa, Sosemanuk Hash Functions: MD4, MD5, SHA-1, SHA-244, SHA-256, SHA-384, SHA-512, Whirlpool, (ifdef BOOST_CRYPTO_EXPERIMENTAL) { MD6, Sekin } Padding: One-zero, ISO-10126, PKCS-7. Mode Of operation: ECB, CBC, OFB, CFB, CTR-E, CTR-D, LRW, XTS mode of operations is something like: template < BlockCipher BlockCipherT, PaddingAlgorithm PaddingAlgorithmT > class XTS; Also endian class which is designed to read/write correct endian values from/to memory. I haven't implemented Public key cryptography because of not having a clear answer to what library to use for large number operations, or for example implement internal library for it. With Best Regards Kasra

2 1

[Reviews] Futures - packaged_task and shared_future
by vicente.botet 05 Jan '09

05 Jan '09

Hi, can you consider the ability of a shared_packaged_task to return a shared_future? This is a temporary use case until we have implementation of containers allowing movable_only object. unique_future<T> is movable_only and can not be stored on current containers as for example fusion::tuple. Best, Vicenre _____________________ Vicente Juan Botet Escribá

2 2

[date_time] SIGSEGV in multithreaded code on Solaris Sparc
by Roberto Gimenez 05 Jan '09

05 Jan '09

The following multithreaded code causes SIGSEGV in Solaris Sparc 10: #include <boost/thread.hpp> #include <sstream> #include <boost/date_time/posix_time/posix_time.hpp> using namespace std; using namespace boost; void fun(); int main(int argc, char** argv) { thread t1(fun); thread t2(fun); pause(); return (EXIT_SUCCESS); } void fun() { while(true) { stringstream str; str << posix_time::microsec_clock::local_time().time_of_day(); } } The stackstrace from the core dump is the following: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ead3c50 _pause (ffffffff7ffff4e0, ffffffff7ee00200, 0, ffffffff7ef08ba4, ffffffff7e300140, 0) + 8 0000000100015ea0 main (1, ffffffff7ffff5f8, ffffffff7ffff608, ffffffff7ea4aedc, ffffffff7e3000c0, ffffffff7ee00200) + 58 000000010001589c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7ea3b670 strlen (ffffffff7e0fba38, 1001377c0, 1, ffffffff7f510d00, c, ffffffff7f51d608) + 50 0000000100017c60 std::locale::locale<boost::date_time::time_facet<boost::posix_time::ptime,char, std::ostreambuf_iterator<char,std::char_traits<char>> > >#Nvariant 1(const std::locale&,__type_0*) (ffffffff7e0fba38, ffffffff7e0fba30, 1001362a0, 1061b4, ffffffff7f00ef70, 1) + 68 000000010001728c std::basic_ostream<__type_0,__type_1>&boost::posix_time::operator<<< char,std::char_traits<char>>(std::basic_ostream<__type_0,__type_1>&,const boost::posix_time::time_duration&) (ffffffff7e0fbbb0, ffffffff7e0fbb90, ffffffff7e0fbbb8, ffffffff7e0fbd08, ffffffff7f51a160, ffffffff7f510d00) + 22c 0000000100015f84 void fun() (ffffffff7f915528, 10012f920, 3, ffffffff7ee00b58, 18, 3) + 5c 0000000100020940 void boost::detail::thread_data<void(*)()>::run() (10012f920, 0, 158, 10af4c, 0, 0) + 10 ffffffff7f8095b4 thread_proxy (10012f920, 2, 10012de88, 10012f920, 3, 48) + 94 ffffffff7ead2e7c _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- ffffffff7f3d3130 std::locale::~locale #Nvariant 1() (ffffffff7f915528, 1001311f0, 3, ffffffff7ee01358, 18, 3) + 8 0000000100020940 void boost::detail::thread_data<void(*)()>::run() (1001311f0, 0, 158, 10af4c, 0, 0) + 10 ffffffff7f8095b4 thread_proxy (1001311f0, 2, 10012df30, 1001311f0, 3, 5d) + 94 ffffffff7ead2e7c _lwp_start (0, 0, 0, 0, 0, 0) When running with just one thread, it works fine. So it's a race condition aparently. The stacktrace varies. This is another one: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ead3c50 _pause (ffffffff7ffff4e0, ffffffff7ee00200, 0, ffffffff7ef08ba4, ffffffff7e300140, 0) + 8 0000000100015ea0 main (1, ffffffff7ffff5f8, ffffffff7ffff608, ffffffff7ea4aedc, ffffffff7e3000c0, ffffffff7ee00200) + 58 000000010001589c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7f3d3130 std::locale::~locale #Nvariant 1() (ffffffff7f915528, 10012f920, 3, ffffffff7ee00b58, 18, 3) + 8 0000000100020940 void boost::detail::thread_data<void(*)()>::run() (10012f920, 0, 158, 10af4c, 0, 0) + 10 ffffffff7f8095b4 thread_proxy (10012f920, 2, 10012de88, 10012f920, 3, 48) + 94 ffffffff7ead2e7c _lwp_start (0, 0, 0, 0, 0, 0) ----------------- lwp# 3 / thread# 3 -------------------- 000000010001e090 unsigned long boost::date_time::gregorian_calendar_base< boost::date_time::year_month_day_base<boost::gregorian::greg_year, boost::gregorian::greg_month,boost::gregorian::greg_day>, unsigned long>::day_number(const boost::date_time:: year_month_day_base<boost::gregorian::greg_year,boost::gregorian:: greg_month,boost::gregorian::greg_day>&) (ffffffff7defb7c4, 7d9000000000000, 1000000000000, 5000000000000, 4, 7d9) + 1b8 000000010001b078 boost::date_time::date<boost::gregorian::date, boost::gregorian::gregorian_calendar,boost::date_time::date_duration< boost::date_time::duration_traits_adapted> >::date #Nvariant 1( boost::gregorian::greg_year,boost::gregorian::greg_month, boost::gregorian::greg_day) (ffffffff7defb9b0, 7d9000000000000, 1000000000000, 5000000000000, ffffffff7ebf6c38, ffffffff7defb9c0) + 98 000000010001a3a0 boost::gregorian::date::date #Nvariant 1(boost::gregorian:: greg_year,boost::gregorian::greg_month,boost::gregorian::greg_day) (ffffffff7defb9b0, 7d9000000000000, 1000000000000, 5000000000000, 400, ffffffff7defb9f0) + 90 0000000100017a20 boost::posix_time::ptime boost::date_time::microsec_clock< boost::posix_time::ptime>::create_time(boost::date_time:: microsec_clock<boost::posix_time::ptime>::TZ_FOR_CREATE) (0, 1000, 6, 0, 198704, 18) + 128 000000010001749c boost::posix_time::ptime boost::date_time::microsec_clock< boost::posix_time::ptime>::local_time() (ffffffff7defbba0, 18, ffffffff7defbbb8, ffffffff7defbd08, ffffffff7f51a160, ffffffff7f510d00) + c 0000000100015f40 void fun() (ffffffff7f915528, 1001311f0, 3, ffffffff7ee01358, 18, 3) + 18 0000000100020940 void boost::detail::thread_data<void(*)()>::run() (1001311f0, 0, 158, 10af4c, 0, 0) + 10 ffffffff7f8095b4 thread_proxy (1001311f0, 2, 10012df30, 1001311f0, 3, 5d) + 94 ffffffff7ead2e7c _lwp_start (0, 0, 0, 0, 0, 0) The only constant thing is the deletion of the locale: std::locale::~locale Compiler is: CC: Sun C++ 5.9 SunOS_sparc Patch 124863-07 2008/08/22 Any clues?

1 0

boost.org: Minor nitpick
by dhruva 05 Jan '09

05 Jan '09

Hi, The following link is supposed to list the header-only packages first (more intuitive) but lists the auto-link packages first. http://www.boost.org/doc/libs/1_37_0?sort=header-only -dhruva -- Contents reflect my personal views only!

3 2

[thread] thread_proxy's catch(...) destroys my stack info for unhandled exceptions
by Roberto Gimenez 05 Jan '09

05 Jan '09

When some unhandled exception is thrown inside my function, it would be good that is isn't actually handled, so I could collect the stack info from the core-dump. For example: #include <boost/thread.hpp> using namespace std; using namespace boost; void f1() { throw 1; } void f2() { throw 1; } void f() { f1(); f2(); } int main(int argc, char** argv) { thread t(f); t.join(); return (EXIT_SUCCESS); } Whe run it, the core-dump's stack info is: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ecd2f20 __lwp_park (100108658, 100108640, ... ffffffff7eccc748 cond_wait_queue (100108658, 100108640, ... ffffffff7ecccca8 cond_wait (100108658, 100108640, ... ffffffff7ecccce4 pthread_cond_wait (100108658, 100108640,... ffffffff7f809ff4 void boost::thread::join() (ffffffff7ffff518, ... 0000000100004168 main (1, ffffffff7ffff608, ffffffff7ffff618, ... 0000000100003a7c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7ecd40a4 _lwp_kill (6, 0, ffffffff7edf7338, ... ffffffff7ec4a68c abort (1, 1b8, ffffffff7f106f10, ... ffffffff7f106a04 void __Cimpl::default_terminate() (0, 0, ... ffffffff7f809770 thread_proxy (100108610, 1001086dd, 2c, ... ffffffff7ecd2e7c _lwp_start (0, 0, 0, 0, 0, 0) With this information I cannot know where the exception was thrown. So I commented the catch(...) part in libs/thread/src/pthread/thread.cpp: extern "C" { void* thread_proxy(void* param) { boost::detail::thread_data_ptr thread_info = static_cast<boost::detail::thread_data_base*>(param)->self; thread_info->self.reset(); detail::set_current_thread_data(thread_info.get()); try { thread_info->run(); } catch(thread_interrupted const&) { } //catch(...) //{ // std::terminate(); //} detail::tls_destructor(thread_info.get()); detail::set_current_thread_data(0); boost::lock_guard<boost::mutex> lock(thread_info->data_mutex); thread_info->done=true; thread_info->done_condition.notify_all(); return 0; } } And recompiled boost, now the core dump's stack info is the desired one: ----------------- lwp# 1 / thread# 1 -------------------- ffffffff7ecd2f20 __lwp_park (100108658, 100108640, 0, 4, 11fb1c, ... ffffffff7eccc748 cond_wait_queue (100108658, 100108640, 0, 0, ... ffffffff7ecccca8 cond_wait (100108658, 100108640, ffffffff7ed00358,... ffffffff7ecccce4 pthread_cond_wait (100108658, 100108640, ... ffffffff7f809f54 void boost::thread::join() (ffffffff7ffff518, ... 0000000100004168 main (1, ffffffff7ffff608, ffffffff7ffff618, ... 0000000100003a7c _start (0, 0, 0, 0, 0, 0) + 17c ----------------- lwp# 2 / thread# 2 -------------------- ffffffff7ecd40a4 _lwp_kill (6, 0, ffffffff7edf7338, ... ffffffff7ec4a68c abort (1, 1b8, ffffffff7f106f10, ... ffffffff7f106a04 void __Cimpl::default_terminate() (ffffffff7f214718, ... ffffffff7f1067f4 void __Cimpl::ex_terminate() (ffffffff7f2106c0, 0, 0, ... ffffffff7f1074c8 _ex_throw_body (ffffffff7f2106c0, 0, ffffffff7e2fbf50, ... ffffffff7f10740c void __Crun::ex_throw(void*,... 0000000100004064 void f1() (0, 0, ffffffff7edf7f80, ... 00000001000040fc void f() (ffffffff7f915528, 100108610, ... 00000001000053c0 void boost::detail::thread_data<void(*)()>::run() (... ffffffff7f8095b4 thread_proxy (100108610, 3, 100106bd8, 100108610... ffffffff7ecd2e7c _lwp_start (0, 0, 0, 0, 0, 0) I can know now where the unexpected/unhandled exception was thrown. I could solve my problem partially, puting throw() exception specs everywhere, so when some unexpected exception is thrown, the throw() will stop it. Unfortunatelly, it whould stop at the calling function, and the stack will tell me that some unexpected exception was thrown by any of the functions inside the caller. This is worse than having a stack info like the above one because in this case I wouldn't know who raised the unexpected exception. In the above stack info I can know who did it. So why is: catch(...) { std::terminate(); } there? It looks unnecesary.

5 9

How to access COM ports
by master master 05 Jan '09

05 Jan '09

How to access COM port using BOOST library. I want to access COM3 port using boost. For socket port the below line works .... ........ boost::asio::ip::tcp::resolver::query query("localhost", "9999"); .......... ..... but how to do it for COM port I tried this .... ....... boost::asio::ip::tcp::resolver::query query("localhost", "COM3"); ......... ....... but it didn't worked. Another problem I am facing is that the network client should be platform-independent but if I use socket.h then it will not work on windows and if I use winsock then it will not run on linux/unix variants. Same for other header files like inet.h etc Rahul To create something exceptional ________________________________ -Master4Master "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, re-transmission, conversion to hard copy, copying, circulation or other use of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email, and delete this message and any attachments from your system. Virus Warning: Although I have taken reasonable precautions to ensure no viruses are present in this email, I cannot accept responsibility for any loss or damage arising from the use of this email or attachment." Speak out for justice and peace, even if your voice trembles. Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

3 4

BoostCon 2009: Call for participation
by Hartmut Kaiser 04 Jan '09

04 Jan '09

Hi all, Please find below the call for participation for the 3rd annual Boost Conference in Aspen. There are only a couple of days left to submit any proposals. I'm sorry for any duplicates you might receive. Please forward this mail to any related mailing list or any person you think might be interested. Regards Hartmut ---------------------------------------------------------------------------- 3rd annual Boost Conference 2009 Aspen CO, USA, May 3-9, 2009, www.boostcon.com ---------------------------------------------------------------------------- Call for participation ---------------------- Promising to be the main face-to-face event for all things Boost (www.boost.org) BoostCon'09 opens the door to your C++ future. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and from TR1 to TR2 and the new C++0x Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- * Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * TR1 and TR2 * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and Developers. Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations ............. Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels ...... Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials ......... Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops ......... Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations ............................. These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems boost libraries. Tool Vendors Presentations .......................... We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other * A paragraph or two describing the topic covered, suitable for the conference web site * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half-day, full day * Alternate lengths, if you are willing to make adjustments: 10-20 minute lightning-talks, 45 minutes, 90 minutes, half-day, full day * Audience: users, developers, both * Level: basic, intermediate, advanced * A biography, suitable for the conference web site * Your contact information (will not be made public) Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon09. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted papers will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon CD handed out to attendees. For general information on the BoostCon 2009 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon09(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Important dates --------------- Proposals for submissions due: January 10th 2009. Proposals acceptances sent (tentative program available): February 10th, 2009 Fully scheduled program available: March 1st, 2009 Session materials due: April 1st 2009. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

Re: [boost] [logging] Interest check on logging library.
by Jason Wagner 04 Jan '09

04 Jan '09

Andrey Semashev wrote: > Sorry, couldn't resist. I think, my library fits these requirements > quite well. Why would you start your own implementation from scratch? Is > there something that doesn't suit you in my implementation? It started because I thought yours was no longer in development. I have no idea why I thought that, since looking at your cvs logs you have been consistently working on it. It was largely a mistake. I'm writing a internet spaceship game. There's a client and a cluster of servers with different types. The protocol is simple message passing, with the serialization code shared between client and server. This leads to a very simple example like: if(message.size > packet.size) { log << severity::warn() << "Packet was larger than the buffer that contains it!" << build_target::server() << " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); // error handling } On the client side, we note that the packet was too big and move on. On the server side, we actually log the packet since evil hackers are always trying to steal my space bucks. Since the template generates empty code at compile time, both gcc and msvc are smart enough to remove the " Packet source=" and ", account= " strings from the binary, providing less clue in the client as to what the server is watching for. On the server side, I probably want this record to go into a database, so having the entire thing as a single record is very important. That precludes items of the form: log << severity::warn() << "..."; if(server) // or #ifdef log << "Packet source = "; //... I also really don't like having the conditional in the logging. Looking at the serialization code, one shouldn't have to wade through the logic of logging. I think I could add this to your library using features. That's not a light weight thing to add, based upon what I see features need to be instantiated. In my scheme, since the if() test is built into the log record instantiation there's single point to change to affect all appropriate loggers. With your scheme I'd have to change the logger type, the if()s that wrap them or the macros that contain the ifs, and possibly client code as well. Switching to a different scheme, I could do: log << severity::warn() << "Packet was larger than the buffer that contains it!" << auditing::full() << " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); Now, on the client side I can turn off full auditing at compile time and on the server time I can turn off packet logging at run time and have a condition that turns it on when I suspect a problem. There is a separation of concerns between what audit level and severity of the record. The whole thing could be rewritten with scope variables for connection and user that would allow them to be first class denizens of the database or fed into an event processing system without having to do entity extraction on the record. In addition, immediately insertable variables prevent the overhead of setting scope variables if not needed: log << severity::warn() << "Packet was larger than the buffer that contains it!" << auditing::full() << << set("User", user) << set("connection",connection) " Packet source= " << connection << ", account = " << user << "\n" << dump_hex(packet); --- Jason Wagner jason(a)nialscorva.net

4 8

[exception]throw_exceptions concerns
by Gennadiy Rozental 04 Jan '09

04 Jan '09

Hi, I am trying to look closely on to the warnings emitted during Boost.Test compilation and I've noticed couple that makes me a bit concerned (these are from msvc-7.1 toolset): ..\..\..\boost\throw_exception.hpp(58) : warning C4673: throwing 'boost::exception_detail::clone_impl<T>' the following types will not be considered at the catch site with [ T=boost::exception_detail::enable_error_info_return_type<boost::bad_weak_ptr>::type ] ..\..\..\boost\detail\shared_count.hpp(407) : see reference to function template instantiation 'void boost::throw_exception<boost::bad_weak_ptr>(const E &)' being compiled with [ E=boost::bad_weak_ptr ] ..\..\..\boost\throw_exception.hpp(58) : warning C4671: 'exception' : the copy constructor is inaccessible Here is the list of my concerns: 1. What does the first one means and should we worry? 2. Does the second means that std::exception is not copy constructible? If yes can we disable it inside the header? 3. These warnings seems to be originated from the lines related to the Boost.Exception. in this regard I've got following concerns: a) Was it agreed that practically all Boost users are now exposed to the Boost.Exceptions library by default whether they are willing or not b) throw_exception documentation is now incorrect and misleading, since it does not mention this 4. If let's say I would like to disable Boost.Exceptions exposure during Boost.Test compilation, will it lead to the ODR violations? Thanks, Gennadiy

3 5