- Boost - lists.boost.org

Testing macros..
by Rene Rivera 24 May '10

24 May '10

Once upon a time I did a bunch of work towards a Boost Predef library. The goal was to have a consistent set of version and feature definitions as could be determined from the predefined macros of toolsets <https://svn.boost.org/svn/boost/sandbox/predef/>. But the work stalled for one basic reason.. How do I write tests for such a library? The only other library that approaches the domain of this one is Boost Config and, AFAICT, it doesn't test the macros themselves. As I'm looking to finish of this lib for eventual submission I'm looking for ideas on this. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 2

Is there a plan to provide a C++0x std library repository in Boost?
by vicente.botet 24 May '10

24 May '10

Hi, Boost provides a lot of C++0x accepted libraries that could be in the std namespace. As it was done for std::tr1, is there a plan to provide these libraries on namespace std? Best, Vicente

4 5

[challenge!] find a common domain
by Eric Niebler 23 May '10

23 May '10

I recently solved a devilish C++ coding problem related to the new sub-domain feature of Proto. I don't care for my solution, so I thought I'd throw it out there and see if some smart person could do better. I'm sending along the skeleton of the solution and some tests that it needs to satisfy. The rest is up to you. The problem goes like this. Every Proto expression has a "domain", which is a type defined something like this: struct my_domain : domain<> {}; A domain can be a sub-domain of another domain, defined like this: struct my_sub_domain : domain<my_domain> {}; When combining sub-expressions into larger expressions, the new expression has some domain that depends on the domains of its children. This domain is calculated according to some rules. - Domains that share no common super-domain are incompatible with each other. The result should be not_a_domain. - A sub-domain is "stronger" than its super-domain. - For a set of domains, the common domain is the strongest domain that is a super-domain of every domain in the set. - default_domain is special; it is compatible with (and dominated by) all other domains. - A sub-domain of default_domain is stronger than default_domain and still compatible with and dominated by all other domains. Your job: implement the deduce_domain3 template that finds the common domain of 3 domains. You're allowed to use decltype, but you get bonus points for a solution that doesn't. Bonus also for instantiating fewest templates. The challenge is for the ternary case, but your solution should scale to N domains. If your solution is better than mine, I'll use it in Proto and credit you! Good luck. P.S. I haven't checked my solution in yet, so you can't look in trunk and cheat. ;-) -- Eric Niebler BoostPro Computing http://www.boostpro.com

8 24

Proposal regarding "boost::add_const".
by Michael Soliman. 23 May '10

23 May '10

Moin Moin. First of all, this is my first boost posting, and as all I could find on "http://lists.boost.org/mailman/listinfo.cgi/boost" told my to post my proposal to this address, I did so (despite of being astonished, that there does not seem to be a directory of subgroups to browse.). However, at least on MSVC 9 as well as on ICL 11 there exists the problem, that the "BOOST_MPL_ASSERT" terms in the attached "consten.rar\consten\consten.cpp" do fail for "boost::add_const" but not for "consten", meaning, that "boost::add_const" was not capable to add constness to reference-types, which "consten" is. Hence my proposal is, to create a service-pack to "boost::add_const" based on "consten" and similarly to all other affected traits, such as "boost::add_volatile" and the like. With kind regards, Michael. P.S.: Is there a web-based, thematically browsable discussion-list (I know it to be sounding typical for windows-users, but these types of lists do save time.). -- __________________________________________ Michael Soliman. Web: http://soliman.de Email: mailto:michel@soliman.de Adresse: Dresdener Strasse 6 64839 Muenster GERMANY Telephon: +(49)6071420815 Handy: +(49)1705605430 Skype: skypeto:michel_soliman_de Oeffentlicher PGP-Schluessel: http://soliman.de/pgp.asc __________________________________________ Alopex GbR (Inhaber.: Michael Soliman & Henning Voß) Gross-Bieberauer Strasse 4, 64354 Reinheim. __________________________________________ Alopex-IT GmbH&Co KG, Eingetragener Name: "Alopex Informationstechnologie GmbH & Co. KG (pers. haft. Gesell.: Alopex Verwaltungsgesellschaft mbH ) ", Ort und Nr. des Registereintrages: Darmstadt, HR A 32356/Darmstadt, HR B 33834, Alopex-Patente GmbH&Co KG, Eingetragener Name: "Alopex Patentverwertungsgesellschaft mbH & Co. KG (pers. haft. Gesell.: Alopex Verwaltungsgesellschaft mbH ) ", Ort und Nr. des Registereintrages: Darmstadt, HR A 32357/Darmstadt, HR B 33834, Sitze: Gross-Bieberauer Strasse 4, 64354 Reinheim, Rechtsformen: GmbH&Co KG, Geschaeftsfuehrer: Voss, Henning und Soliman, Michael. ------------------------------ Zeitweise auch taetig fuer: NETWORK PEOPLE AG Alsfelder Straße 11, 64289 Darmstadt, Germany fon: + 49 . 6151 . 35076-0 fax: + 49 . 6151 . 35076-10 eMail: m.soliman(a)networkpeople.de visit: www.networkpeople.de Vorsitzender des Vorstands: Dipl.-Ing. Siamak Mashayekhi Aufsichtsrat: Dipl.-Chem. Michael Schnieder (Vors.) Sitz: 64283 Darmstadt Amtsgericht Darmstadt HRB 7604 Umsatzsteuer ID: DE204157624 Steuer-Nr.: 007 240 00336 ------------------------------ Diese Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This eMail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this eMail in error) please notify the sender immediately and destroy this eMail. Any unauthorised copying, disclosure or distribution of the material in this eMail is strictly forbidden.

2 1

[test] broken on trunk under cygwin
by Eric Niebler 23 May '10

23 May '10

Eric@AERIX ~/boost/org/trunk/libs/proto/test $ bjam toolset=gcc-4.5 ...patience... ...patience... ...found 1435 targets... ...updating 71 targets... gcc.compile.c++ ../../../bin.v2/libs/proto/test/noinvoke.test/gcc-4.5/debug/link-static/noinvoke.o noinvoke.cpp: In function ‘void test_noinvoke()’: noinvoke.cpp:67:36: warning: unused variable ‘t2’ gcc.compile.c++ ../../../bin.v2/libs/test/build/gcc-4.5/debug/link-static/compiler_log_formatter.o In file included from ../../../boost/config.hpp:57:0, from ../../../boost/detail/workaround.hpp:41, from ../../../boost/test/utils/basic_cstring/basic_cstring_fwd.hpp:19, from ../../../boost/test/utils/basic_cstring/basic_cstring.hpp:20, from ../../../boost/test/detail/global_typedef.hpp:18, from ../../../boost/test/output/compiler_log_formatter.hpp:19, from ../../../boost/test/impl/compiler_log_formatter.ipp:19, from C:\cygwin\home\Eric\boost\org\trunk\libs\test\src\compiler_log_formatter.cpp:1 6: ../../../boost/config/suffix.hpp:484:18: warning: ISO C++ 1998 does not support ‘long long’ ../../../boost/config/suffix.hpp:485:18: warning: ISO C++ 1998 does not support ‘long long’ In file included from ../../../boost/test/unit_test_log_formatter.hpp:23:0, from ../../../boost/test/output/compiler_log_formatter.hpp:20, from ../../../boost/test/impl/compiler_log_formatter.ipp:19, from C:\cygwin\home\Eric\boost\org\trunk\libs\test\src\compiler_log_formatter.cpp:1 6: ../../../boost/test/execution_monitor.hpp:366:5: error: expected ‘}’ before ‘BOOST_FPE_INV’ ../../../boost/test/execution_monitor.hpp:366:41: error: invalid conversion from ‘int’ to ‘boost::fp e::masks’ ../../../boost/test/execution_monitor.hpp:367:1: error: expected ‘,’ or ‘;’ before ‘}’ token ../../../boost/test/execution_monitor.hpp:367:2: warning: extra ‘;’ ../../../boost/test/execution_monitor.hpp:375:1: error: expected declaration before ‘}’ token "/usr/local/gcc-4.5/bin/g++.exe" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -DBOO ST_ALL_NO_LIB=1 -I"../../.." -c -o "C:\cygwin\home\Eric\boost\org\trunk\bin.v2\libs\test\build\gcc- 4.5\debug\link-static\compiler_log_formatter.o" "C:\cygwin\home\Eric\boost\org\trunk\libs\test\src\c ompiler_log_formatter.cpp" ...failed gcc.compile.c++ ../../../bin.v2/libs/test/build/gcc-4.5/debug/link-static/compiler_log_for matter.o... -- Eric Niebler BoostPro Computing http://www.boostpro.com

2 1

[nt2] Code from Boostcon 2010
by Ravi 23 May '10

23 May '10

Hi, Is the code for NT2 (presented at BoostCon 2010) publicly available? There is an empty repository on gitorious and another seemingly inactively-developed version on sourceforge. My google-fu fails me in finding a more up-to-date copy. Regards, Ravi

3 4

[castor] Interest in Logic Paradigm for C++ ?
by Roshan Naik 23 May '10

23 May '10

Based on suggestions from some Boost community experts, I would like to gauge interest to see if there is broader interest for including the Castor library into Boost. In short, Castor's aim is to foster multiparadigm programming in C++ by supporting techniques from the Logic Paradigm. See below for a longer description. ============== Description: ============== Logic Paradigm (LP) is a general purpose declarative programming paradigm. It focuses on "what" to compute and not "how" to compute. Although LP has been well explored in Computer Science as a fundamental computational model, it remains unavailable for main stream software development due to lack of support in popular programming languages. Prolog is perhaps the most commonly known language among those that support LP. Castor takes a pure library approach (i.e. without language extensions) for introducing LP to C++. Instead of providing a Logic interpreter or evaluation engine in library form, Castor provides a few simple library primitives on which LP techniques can be supported. This approach allows a natural and deep integration of declarative code into the language and also provides the flexibility of freely combining Logic with the other paradigms such as OO, generics, functional etc. STL concepts like iterators, containers and streams can also be used in declarative code. For an introductory tutorial on LP in C++ and Castor please refer to http://mpprogramming.com/downloads/betaTutorial.pdf. Castor is intended to be a free standing library that depends only on the standard C++ library. It does not depend on Boost or other libraries. It is a pure header library. ============== Current State: ============== A stable 1.0 version has been available since 2008 on www.mpprogramming.com/cpp under the MIT license. Work on version 1.1 is in progress and an early beta is now available. Current efforts are directed largely towards making Castor a richer "standard library" for working with LP in C++. Castor was not originally targeted for Boost but more recently I have been giving it more serious consideration regarding inclusion into Boost. At the upcoming BoostCon 2010 I will be presenting 'Logic Paradigm for C++'. If there is interest, my thought is that feedback from the Boost review/submission process and modifications to satisfy other Boost requirements/guidelines will perhaps yield a 1.2 version that will become the real Boost candidate. Any help in this space will be much appreciated. ================== Links for Castor - v1.1 beta (ported to Gcc 4.4.1 and VC++ 2008) : ================== Library+docs: http://mpprogramming.com/downloads/prebeta-1.1.zip Individually downloadable documentation: Tutorial: http://mpprogramming.com/downloads/betaTutorial.pdf Reference Manual: http://mpprogramming.com/downloads/betaRefManual.pdf Design doc: http://mpprogramming.com/downloads/betaDesignDoc.pdf - Roshan Naik

16 52

[config] GCC symbol visibility across shared libraries
by Beman Dawes 22 May '10

22 May '10

There are several outstanding tickets (2114, 2309, 3697) dealing with GCC symbol visibility across shared libraries (DSO's on UNIX-like systems, DLL's on Windows-like systems). A particular problem that is affecting several Boost libraries (system, filesystem, threads, etc) is that with compiler switch -fvisibility=hidden an exception thrown in one library cannot be caught in another library or in the main program. For more background, see http://gcc.gnu.org/wiki/Visibility Ticket 2114 provided patches to fix the problem, and work started on getting them ready for trunk. But that work seems to have stalled. See http://svn.boost.org/trac/boost/ticket/2114 What needs to be done to restart this effort? It would be better is discussion could occur on this list, rather than as comments attached to the ticket. That will ensure more eyeballs look at this. --Beman

8 33

boost:: program_options
by Vijay Samuel 22 May '10

22 May '10

Hi, I have a query regarding boost:: program_options. Is it possible for multiple programs to use a single configuration file? If so, then how? I have two programs which have to use a single configuration file. Both programs have both similar and unique options but have different default values. Thanks in advance. Cheers, -Vijay Samuel

2 2

Clang Builds Boost
by Doug Gregor 22 May '10

22 May '10

Hi all, Well, we didn't make it before the end of BoostCon, but now we have: Clang successfully builds all of Boost's regression tests on the release branch. More information available at http://blog.llvm.org/2010/05/clang-builds-boost.html . - Doug

17 25