April 2005 - Boost - lists.boost.org

tuple patch (constructing from a pair)
by John Maddock 29 Apr '05

29 Apr '05

The following simple patch to tuple_basic.hpp allows tuples to be constructed from std::pairs (there is already an assignment operator, but the copy constructor is missing for some reason, and is required for TR1 conformity). RCS file: /cvsroot/boost/boost/boost/tuple/detail/tuple_basic.hpp,v retrieving revision 1.28 diff -r1.28 tuple_basic.hpp 627a628,636 > template <class T, class U> > tuple(const std::pair<T, U>& p) > : inherited(p.first, p.second, detail::cnull(), detail::cnull(), > detail::cnull(), detail::cnull(), detail::cnull(), > detail::cnull(), detail::cnull(), detail::cnull()) > { > BOOST_STATIC_ASSERT(length<tuple>::value == 2);// check_length = 2 > } > Is it acceptable to add this? Many thanks, John Maddock.

10 49

TEST
by jeff＠crystalclearsoftware.com 29 Apr '05

29 Apr '05

p� /K$�﹖�a�2�[S�sq��v��p��y;W8�f-��D�_Ok�UJ\b�È9��ͤ��6�gPD��,d�.�Z˶��^��s��\�3�ʕ�,k �f�dHZ�,��Nuƭ��d�w�6�%3��p` �0e�M�JÃ:��[��FR��%H �ӮP��Ƨ��S�C�rQ��Idmī�`2i��< Q��"�ח2�RJ�-n��*�o��{kR�ΰ��mk��"�"��e��E%�4��ٔi�4n�ڔ��l'�Ѧ)��3��O��f��TzX��G֬ŷ�"/,Y�r��C�!��]��J9Y��ߪkQ�(�r1�{�l��A ��~��tHJ��Yb��)��8py�K��W�& e҃z��sǚC��F7g`g�.��-��ϖq:�ch��r�$��Տ��Mm�tl� 7Z�2.�H��M�7��7j�؋_Tά�!u�N�K�L��0��!� ��%ҋ��VL� ��ӴZc�Iԕx��Bc��z%:�!U,B4ϩ��K�8WY&�J��ض-䭆�> t��a�Lӡˠ%��b:��F��\�5�HH��1�6�]?N��Д}oZ��*>; !��,��'��s��{��^V %�X��P�P͉y�m:��r��F��{�UULQc��8-��bqZwJO|��xiZ�b�r�L}�V�m%Yܨ�ֿ��%��bq^��W�5л��7��Z3MJf� �ܪ �2{��Q�fd��.�g��u��a�Я��Y �g� ��e{lk��W�]4�AGmΤ�Q�|��T��V��"ZP��Y��t��In�3<�A��_�51y_2�ӷ�۝�Az��y� �.㧞��wK�<ĉ�]�tr��K񏯅��_"��4�'��Z�!��ID�|��'�}o�c�� N�x��FHi��H^W�17��'qJD��I��;i��ߺ'ۺ�P��K��-mvM,7��ѥo�؄�0��A�`�ؾۄ�g�>FRGf��V�_�%C��(��؞�|G��t��o/��Ւ]/�v`��^v��FͶ�4��}��È�D�P,{��m�tsҐ�T��wf�_T\��<S�M�s*׸H�ȽA�s�1)�/ѳ�%;G�<p�a��H�3<�w��S݆} ��4pS�&�s5Ê5�ao-�;��n_��ڍk�a#LM��]G>$��/t5`�Djx�-�� ƭ��u� :��fyy螏��c�~Z�L��u�͔/��-Na�� :�wfxܸ��_rY��9?��ʃ�`�z(��d��z�J��R�#Ȫf�Zk5;"��$N�mӐPa�-O��\��e��mZP��XG�-$Xu�D�2�G��;�V�'��fb�&�Z�^Xv2e��s>.v>Ԍ�"4(��)��Q�G�\�5��۹ �mƟ~c|a��H��݊-I`fO�\�0 s�� GU:'��Vv�AS��^R��X�Dp%�i�.�X��9��gg�Z��#E �7mԧZtv ��ȁ��i �1�"�X��Κ��m;�ݪ��&�Eq��ZV�k�� HT�H�}��ԼƔ��!'Mr��q�.��s��$T��t�p�ͅ�u�� Ƈá�I~��iM�3D�u��5�m�a��S��dx֔��OW�c��X��Dx9$�Hd�ȝ��0*��v�8��Zn�S��[;�(� {0$�`�8�K��Ѿ��9��7��.�8�_�p�Dy��y��2��'��ߦ�:s8RyB��N��J։]X75�jؑV �{1��6��,0��{z��00�Ԛ��:�^�kq��x��g�Z�� o�$V^��R�� &a�R6�Xq�9ܻ�|�b/U�UAD�>hi�w"��1��aHY4�-j� S�p#��x�Wt��iZ�k��!]/�Ƒ�I�O%�� '!!V�R:�0��&�V�4}�{�wQ��GBy��:�<�]��|��~׸5߇B�h� �wE]Ey:�뺎$��_��W��F%��;UJ��ڷ�l�8��",�n�d|� ��dA��3�Hs��K�A��O��V|��{)m�aĸ��74UO��YT�ƨdSpt��MI��k'�c�cKn��o��;| ��JEv��jMF��Z"�D)n�[�C&�2vG�S��'��I�*��a��A�*�/�V��.�n%��h��\ٱ�K�3h`�IHB��g`��h.��Q6{��,�� $��7G��xv��(�o��C�7�w��;�r�.��}�l�5�<f �I�u�]E��v\�Ijz�[ű(^:�sVZ�K��OpTZ9?�U� �f��n:�F�H0O�-��e8/Ӷ\��Y ��K��T��9�1Q� pt��:��ͪ��nK�N�(tgd�Ya��ެ�Q}��C�9JN��Ke�N�?}��E�!˒n��j�\�_% �1��.eo�˛� $~5*��k9�!��E\~E�a��q�T�0MTd�SȦ��$wh^!`�p�L�֚�_�_�?ӵ*�� >F?��p<-*N��p��f��2��T-v��N�9t��-��,� b4�)��AX]��9�9��k[��G7MB�p!��5�� W�D�ֱ '�c��/>�>.ZE&T��b7��E�f�?Ї��R��a,g�"n��{�d��(eH`��O��eF��h�QZ��5��a�ĳ&α�V�`Ե3��ڿO�ɒu~˷f��(}�r�GB�9ҩ�:l^��[� ��&Oz��諤��O��Y�v�a��ی��C&l�?r��>C��`�2�f`�r0�3�t��R�'�J�7b3�جs�O�7T6V�&W>H�4µ��x��kO(�n�u�~U&7�p�B�Ah��g��[��o u��w�sz'�347��y�,�̻�"n�3��~D��䖈D�t�;�&��RLJBE��$��E�kZ}fG�mgLȈo Q��DT��A�;�� N��N�4$�Z�k`�G%��g \�W�D�%��{�[��h��RS��D��!� �\��/��F��s��Ћ��큓B�� ɷ�q�vX�{�\�?&��zx�w�ì�DT[��r��Ɏ�J�& %c�WXXށ6��2��L��ao��щ�p�

1 0

[1.33] bind_rel_test fails on g++ 2.95.3
by Peter Dimov 29 Apr '05

29 Apr '05

I have one unexpected failure in bind: bind_rel_test on g++ 2.9x. It's caused by the overeager relops operators and the lack of std:: by default. I think I know how this can be fixed, but this will trigger a recompilation of everything that includes bind.hpp. OK to proceed with the fix? On a related note, when are expected failures going to turn gray? :-) -- Peter Dimov http://www.pdimov.com

3 2

Re: [boost] Big integer continued
by brangdon＠cix.compulink.co.uk 29 Apr '05

29 Apr '05

In-Reply-To: <d4rdqo$vhr$1(a)sea.gmane.org> kalita(a)poczta.onet.pl (Marcin Kaliciñski) wrote (abridged): > There's an issue with some of the bitwise operations, as they are only > well defined for integers of fixed size. What should for example > ~boost::integer(0) return? Ideally an infinitely long integer filled > with binary 1s. Some of the functions in n1744 look like they would be most useful when using an integer as a kind of vector<bool>. Is that intended as a reasonable use? It could be convenient if there were some way to specify a mask of arbitrarily many 1s. In effect, a left-shift with 1-fill. Given that, don't see a need for ~boost::integer(0) and I'd rather it didn't compile. > boost::rational does not have a conversion operator to integer type, > which is good as most of rationals are not integers. Should > boost::integer have such an operator, with runtime range checking? The conversion should be explicit in my view, perhaps via boost::numeric_cast<>. > 2. Implementation Initially I'd be happy if you just provided one portable implementation and an efficient one for your favourite platform. Lack of an efficient implementation for any given platform should not be a reason to reject the library. -- Dave Harris, Nottingham, UK.

1 0

Re: [boost] Re: Boost to the rescue
by JOAQUIN LOPEZ MU?Z 29 Apr '05

29 Apr '05

----- Mensaje original ----- De: Robert Ramey <ramey(a)rrsd.com> Fecha: Viernes, Abril 15, 2005 6:05 pm Asunto: [boost] Re: Boost to the rescue > > I'm amazed to discover that in only ONE single case have any of the > programmers, managers, etc ever even heard of boost. This group even > includes an ex head of the computer science department at a top tier > university !!! > Speaking of which, I've got the nasty feeling that a good portion of the C++ programming community have heard of Boost but don't use it because: 1. It's too big. 2. It's too hard to install. 3. The docs are too technical. 4. They fear it's too "advanced" for them to understand it. I've actually read comments on programmer sites touching on every one of these issues. My opinion is that: * #1 is not that much of an issue in a world where people are happy to install a multimegabyte IDE and don't complain about it. When it comes to installing a library, somehow they measure size by a different standard. * #2 is certainly a point, specially for Windows folks used to doubleclick on everything. Maybe it'd be a good idea to produce some graphical wizards (not necessarily as an official part of Boost) that automate the installation for at least the most commonly used platforms (read MS.) IMHO this would lower the entry barrier a lot. * As for #3 and #4, I've got this idea round my head that Boost would benefit of a "community site" where people of various expertise levels could mingle together, post Boost-related articles, etc. Something like CodeProject or Gamedev, which have a less intimidating appearance than www.boost.org. Some months ago I asked for a Boost-related forum in CodeProject, to no avail :( Well, just some random ideas. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

20 45

Re: [Boost-testing] Re: [thread] test_read_write_mutex breaksregressiontesting
by Caleb Epstein 29 Apr '05

29 Apr '05

On 4/28/05, Michael Glassford <glassfordm(a)hotmail.com> wrote: > <quote> > patching file util.inl > Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 350 > > This application has requested the Runtime to terminate it in an unusual > way. Please contact the application's support team for more information. > </quote> > > Any ideas why? In case it's a problem with the command line I'm > entering, what should it be? As with a compiler, this sort of tool just shouldn't crash. In the interests of expediency, I'm attaching the complete files (libs/thread/test/util.inl and test_read_write_mutex.cpp) with my changes applied. Here's the standard way I apply patches, in case this helps for the future: cd /path/to/boost/root # Test that the patch applies cleanly - if you see any "FAILED" messages, it doesn't :) patch -p0 --dry-run < patchfile # OK? Do it for real patch -p0 < patchfile -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

RE: [boost] Re: [website] Oh the fun..
by Martin Bonner 29 Apr '05

29 Apr '05

----Original Message---- From: Rene Rivera [mailto:grafik.list@redshift-software.com] Sent: 28 April 2005 16:28 To: boost(a)lists.boost.org Subject: Re: [boost] Re: [website] Oh the fun.. > Martin Bonner wrote: >> ----Original Message---- >> From: Rene Rivera [mailto:grafik.list@redshift-software.com] >> Sent: 28 April 2005 03:37 >> To: boost(a)lists.boost.org >> Subject: Re: [boost] Re: [website] Oh the fun.. > > Please change your posting program so that it doesn't include this > superfluous information. > >>> 2. I think just about all web designers agree that 800x600 is the >>> minimum one should design for at this time. >> >> Hmm. How about all (boost) USERS? > > You should already know that it's impossible to satisfy all users. Sure. But my point was that it is users, not web-designers that matter. > And the various *_ptr discussions should serve as an example. NOOO! This way madness lies :-) [snip] >> So why do you need to specify the background colour? I haven't >> looked at the source, but it looks white on my machine which is the >> default for my browser. > > What makes you assume that everyone has a default background color of > white? I certainly don't assume that, nor have my default as white. OK. I have now checked the source. The styles explicitly specify a background of white. I changed my background colour, and the design does NOT respect that. I think it should. > What you are saying is to abandon design and leave it entirely to the > browser defaults and user settings. Yes, I realize that means abandoning ANY control of colour - I don't think that is a bad thing. You can still control layout (and I would like to congratulate you on using %ages and em/pt measurements rather than px measurements). > And please don't assume that the browser developers made perfect, or > even good, choices about how to present a web page. That is depressingly true :-( > Like I just said above.. You can turn the CSS *off* and have your > browser+user settings prevail. For example with Firefox you can choose > the View/Page Style/No Style menu and voila you have your defaults. Ah! THAT was something I didn't know. Cool! That enormously weakens my argument (particulaly given that you have carefully avoided putting style information into the basic HTML). I think colour control probably /does/ make sense here (it allows the inverse banner, and the neat bullets (which are images, not characters). Having said all that: - I would prefer a more conventional appearence for the links (different colour, more striking underline - and I'm not keen on hover highlights [but that's just personal prejudice]). - I agree with the observation that Google has trained me to ignore boxes on the right Joel wrote: > IMO, Rene's work is superb. Good point Joel. I forgot to mention that didn't I? Sorry Rene - this is all carping at the edges. The overall effect is a big improvement on the main Boost website (which itself is by no means bad). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434

1 0

Review Managers Needed
by Tom Brinkman 29 Apr '05

29 Apr '05

The Typeof, "Function Types" and "Logging libraries" still need review manager volunteers. Contact me again at reportbase(a)google.com to volunteer. Review Queue as of April 28, 2005 1) FOREACH Macro (Starts: 25-Apr-2005; Ends: 1-May-2005) 2) Typeof (Review Manager Needed) 3) Singleton 4) Function Types (Review Manager Needed) 5) Logging (Review Manager Needed) 6) Policy Pointer 1) FOREACH Macro Author: Eric Niebler eric(a)boost-consulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: http://boost-sandbox.sourceforge.net/vault/index.php?directory=eric_niebler, foreach.zip BOOST_FOREACH is a macro that makes it simple to iterate over STL containers, ranges, arrays and null-terminated strings. Its performance approaches that of the hand-coded equivalent loop. BOOST_FOREACH uses Boost.Range can be extended to iterating user-defined collections by extending Boost.Range. Documentation is at http://boost-sandbox.sourceforge.net/libs/foreach 2) Typeof Author: Arkadiy Vertleyb Arkadiy Vertleyb, Peder Holt vertleyb(a)hotmail.com Review Manager: Needed Available: http://boost-sandbox.sourceforge.net/vault/ (typeof.zip) The proposed Typeof library implements the functionality of the non-standard typeof() operator. Depending on the compiler, it utilizes one of the following three methods: 1) Forwards to the non-standard typeof extension, usually called __typeof__, on the compilers where such extension is available; 2) Utilises a loophole, available on the Microsoft vc6.5, vc7.0, and vc7.1; 3) Emulates typeof by the means of template and preprocessor metaprogramming for the compilers that do not fall into above two categories, such as vc8.0 beta, etc. This method is rather portable, and can also be used on the compilers that implement the __typeof__ as a language extension, when compiling with language extensions switched off. The emulation mode is currently working with vc7.1, vc8.0 beta, and gcc 3.3/3.4; The MS-specific trick is working with vc6.5, 7.0, and 7.1. The __typeof__ extension forwarding is working with gcc 3.3/3.4 and Metrowerks. 3) Singleton Author: Jason Hise chaos(a)ezequal.com Review Manager: Pavel Vozenilek pavel_vozenilek(a)hotmail.com Availabe At: http://tinyurl.com/6qvrd The singleton library provides multiple powerful methods of controlling the lifetimes of global resources. Client code can choose among the many provided methods of creation, or can easily write new creators for specialized initialization needs. Client code can additionally control precisely when a singleton instance is automatically created and destroyed, can create and destroy singleton instances explicitly any number of times, and can set up dependencies between singletons in an easy and natural way. 4) Function Types Author: Tobias Schwinger tschwinger(a)neoscientists.org Review Manager: Needed Available at: http://tinyurl.com/4oe7q This library provides a metaprogramming facility to classify, decompose and synthesize function-, function pointer-, function reference- and member function pointer types. For the purpose of this documentation, these types are collectively referred to as function types (this differs from the standard definition and redefines the term from a programmer's perspective to refer to the most common types that involve functions). The classes introduced by this library shall conform to the concepts of the Boost Metaprogramming library (MPL). The Function Types library enables the user to: * test an arbitrary type for being a function type of specified kind, * inspect properties of function types, * view and modify sub types of an encapsulated function type with MPL Sequence operations, and * synthesize function types. This library supports variadic functions and can be configured to support non-default calling conventions. 5) Logging LIbrary Author: John Torjo <john.lists(a)torjo.com> Review Manaer: Needed Available at: http://torjo.com/code/logging-v132.zip The Boost Log Library is a small library, who: * makes it very easy to declare/define new logs * allows you very simple access to logs * allows for log hierarchies, and for modifying log hierarchies * allows for easy and efficient enabling/disabling of logs/log hierarchies * allows for easy manipulation of log behaviors (the log's destination(s) and/or adjusting the original message) * is thread-safe Using the library in code is easy and straightforward: int i = 1, j = 2, k = 3; BOOST_LOG(app) << "testing " << i << '-' << j << '-' << k << std::endl; BOOST_LOG(dbg) << "this is a debug message, i=" << i << std::endl; BOOST_LOG(info) << "I just wanted to tell you something...."; Additions to v1.3.2 - can be compiled as a static/dynamic runtime (works as a DLL as well) - removed dependency on boost_thread Note: I did not test this on Unix, but it should work. If anybody can take a look at detail/ts_posix.hpp, I'd appreciate it. - solved other small issues, based on feedback - slightly improved documentation 6. Policy Pointer Author: David B. Held dheld(a)codelogicconsulting.com Review Manager: Gennadiy gennadiy.rozental(a)thomson.com Available At: Boost Sandbox under policy_ptr Smart pointers are used to automate memory management by handling the deletion of dynamically allcoated objects (and other resources). They assist in ensuring program correctness, exception safety, and memory integrity. Policy Pointer is a policy-based smart pointer framework designed to accomodate the large number of smart pointer designs. Through the use of policy classes, virtually any smart pointer type can be constructed within this framework. This library is a Boostification of the original Loki::SmartPtr type with significant modifications.

3 2

[pool] Making it honour BOOST_HAS_THREADS
by Markus Schöpflin 29 Apr '05

29 Apr '05

Hello, attached is a patch which makes the pool library honour the general boost threading support flag. As a side effect, it also makes the pool library usable on Tru64 because on that platform you can only include <pthread.h> if you're actually compiling with -pthread. Any objections to applying this patch, anyone? Markus Index: mutex.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/pool/detail/mutex.hpp,v retrieving revision 1.6 diff -u -r1.6 mutex.hpp --- mutex.hpp 28 Sep 2004 12:55:44 -0000 1.6 +++ mutex.hpp 28 Apr 2005 11:41:20 -0000 @@ -19,6 +19,10 @@ #define BOOST_MUTEX_HELPER_WIN32 1 #define BOOST_MUTEX_HELPER_PTHREAD 2 +#if !defined(BOOST_HAS_THREADS) && !defined(BOOST_NO_MT) +# define BOOST_NO_MT +#endif + #ifdef BOOST_NO_MT // No multithreading -> make locks into no-ops #define BOOST_MUTEX_HELPER BOOST_MUTEX_HELPER_NONE @@ -37,12 +41,13 @@ #error Unable to determine platform mutex type; define BOOST_NO_MT to assume single-threaded #endif - -#ifdef BOOST_WINDOWS - #include <windows.h> -#endif -#ifdef _POSIX_THREADS - #include <pthread.h> +#ifndef BOOST_NO_MT +# ifdef BOOST_WINDOWS +# include <windows.h> +# endif +# ifdef _POSIX_THREADS +# include <pthread.h> +# endif #endif namespace boost { @@ -50,6 +55,8 @@ namespace details { namespace pool { +#ifndef BOOST_NO_MT + #ifdef BOOST_WINDOWS class win32_mutex @@ -102,6 +109,8 @@ #endif // defined(_POSIX_THREADS) +#endif // !defined(BOOST_NO_MT) + class null_mutex { private:

2 2

RE: [boost] Re: Steps before moving to Subversion
by Schrom, Brian T 29 Apr '05

29 Apr '05

Do you have a test case that we can reproduce your missing line merge and post back to Subversion? -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rene Rivera Sent: Thursday, April 28, 2005 7:32 AM To: boost(a)lists.boost.org Subject: [boost] Re: Steps before moving to Subversion David Abrahams wrote: > Rene Rivera <grafik.list(a)redshift-software.com> writes: >>Never mind.. just found the documentation of svnmerge. And hence have >>some answers. > > What are they, please? I don't know them. http://www.dellroad.org/svnmerge/index >>But here's the thing, it solves the book keeping aspect of the svn >>merge. But it doesn't solve the problem I had. It's not like I did not >>follow the procedure of marking the comments with merge points and >>using "-r N:M" to only merge the un-merged changes. My problem was >>that the svn merge operation lost a line, literally. Which means that >>the conflict resolution algorithm has a problem. So unless there's a >>solution out there that doesn't use "svn merge" we might get bitten. > > Oh. Well it's not nice to have a bug, but you have to check your > merge results by hand anyway, don't you? Of course you should check the merge results.. And I did in this case. But what I did was open the source file, which has the usual "<<<" and ">>>" conflict markers, and edit to make sure all the changes where in there. But that conflict result was missing a line. When I did a diff from what I had to the repository version on my branch, the other check I go through when merging, the missing line obviously didn't show either. What I failed to do was do a manual diff between the two other original source files, the head revision and the branch revision, which svn creates when it finds a conflict. I don't consider what I did as unusual, as I was expecting the conflict resolution of a merge to *never* loose information, under any circumstances. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

3 2