- Boost - lists.boost.org

[docs] Who's Using Boost link goes nowhere.
by Rene Rivera 28 Jul '05

28 Jul '05

Just tried looking up that page. And the link on <http://boost-consulting.com/boost/more/background.html> goes to <http://boost-sandbox.sourceforge.net/doc/html/who_s_using_boost_.html>. First the page doesn't exist. Second I don't think pointing it to the sandbox is the right thing to do. -- -- 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

5 16

[1.33.0] Code is frozen
by Douglas Gregor 28 Jul '05

28 Jul '05

The source code for Boost 1.33.0 is now frozen. Please do not check in any changes to the Boost source code without my explicit permission. You may still update parts of Boost that do not affect the regression tests in any way, until we have our final freeze of the entire tree at 11PM EST on Wednesday. Doug Gregor 1.33.0 Release Manager

16 37

MPL:Possible Placeholder problem with transform & if_ (?)
by Brian Braatz 28 Jul '05

28 Jul '05

Either something strange is happening with arg<> and transform or I did not write this code correctly. ( :) ) Any help pointing me to either conclusion appreciated. The next step is to try the same algorithm with transform_view. I really don't want a lazy sequence (how could mother be proud?), but sometimes life is disappointing. Thanks Guys. CODE: struct print_type { std::ostream & m_os; print_type(std::ostream & os = std::cout) : m_os(os) {} template <typename T> void operator()(T const& v) const { m_os << "[ " << typeid(v).name() << " ] "; } }; template <class seq_t> void _print_types(const char * pHeading) { std::cout << "** " << pHeading << std::endl; mpl::for_each<seq_t>(print_type()); std::cout << std::endl; } #define print_types(seq) _print_types<seq>(#sew); template <class T> struct YES { typedef YES type; }; template <class T> struct NO { typedef NO type; }; struct A{}; typedef mpl::vector<A> vec_t; typedef mpl::transform < vec_t, mpl::if_ < boost::is_same<mpl::_1, A >, YES< mpl::_1 >::type, NO< mpl::_1 >::type >::type >::type result; void test() { print_types (result); /* ////////////////////////// PRINTS: ** result [ struct NO<struct A> ] SHOULD PRINT: ** result [ struct YES<struct A> ] //////////////////////////// */ }

2 1

Re: [boost] Interest in an ODBC library?
by Brian Braatz 28 Jul '05

28 Jul '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Hajo Kirchhoff > Hi, > > > What I don't like in your approach is that you require that there is a > > type (my_table above) for each different rowset traversal "profile" - > > I don't. This is not required, this is merely an example. For small > tables and simple queries its the fastest way. But not the only way. > > > interested in only some of the columns - from 2 to 5, typically. Do you > > require that the application always retrieves all columns? > > Absolutely not. > > odbc::statement s("SELECT column1,column2,etc... FROM ..."); > > is supported of course. > > > Just imagine a single table with 4 columns - there are 15 different > > subsets of columns there (not counting the queries with no columns). > > Also there does not have to be a 1:1 relationship between the members in > my_table and the columns of the table. Subsets are fine. In fact, if you > have a table with 150 columns and want to select only a subset of > columns, you have a couple of options with my approach. > > a) write a struct ... containing only a few member variables for those > columns you want to select. > > b) use individual variables to bind them. > > c) all of the above > > Another example: > odbc::statement s("SELECT one([bindto]a), two([bindto b), sixteen, > seventeen, eighteen FROM huge_table"); > long a, b; > struct some_struct; // has members m_sixteen, ... > some_struct data; > > s.bind(a, "a"); // bind variable a to column one > s.bind(b, "b"); // bind variable b to column b > // bind all member variables of 'data' to columns > // of the same name ... if they exist > s.bind(data); > > > You does your approach scale in this aspect? > > It does. I do not see that it does. At a minimum, you need to support working like a dynamic ADO recordset does. that being, I can issue a call, and retrieve back the data, but I do NOT have priori knowledge of the types that is going to contain. I offer the following high level design thoughts- you split the lib into a few pieces: 1- Get the data from the data base and stream it into X 2- a stock form of "X" (like the table you described) 3- Helpers for binding if you built the thing that way, then it will be usable by those of us out there who have large bodies of code relying on things like ADO recordsets. I would love to replace the recordsets, but I need to be able to selectively use pieces of your library and I need to have a usage model that is similar. Thanks, Brian

2 1

Re: [boost] Call for interest for native unicode character and string support in boost
by Graham 28 Jul '05

28 Jul '05

Dear Doug, Thank you for your positive mail. >You seem to have a lot of valuable experience with Unicode. >I feel that the interface is the more urgent matter for now. The >implementation of the tables can always be changed as long as the >interface remains stable. Let me rephrase that: I think the issues of >programmer's interface and data tables are orthogonal, and programmers >will care most about the interface, and then about performance. This >is not to say you don't give a whole lot of important and difficult >issues that must be solved at some point. I agree that there is a large degree of orthogonally between the character and properties vs string handling, but there is also a fundamental and strong link. Until you have access to the character properties, or have at least defined what methods to access those properties will be available, you cannot support Unicode strings. A classic example of this is the fact that the lower case version of a single Unicode character may be series of Unicode characters - without understanding this and coding a method to handle this, the string handling cannot be written. I believe that we should agree a Unicode character data specification that will supply Unicode data so that we can then independently look at the string interface. In my experience the string part can then be split off and handled completely independently as you have correctly stated. Should these be character properties be supplied using an interface, published method calls, etc etc. ? What calls should there be? If we can agree the interface/ separation/ of Unicode character data from string interfaces then I believe that we will move forward quickly from there as we are then 'just' taking about algorithm optimisation on a known data set to create the best possible string implementation. >> How have you hooked in dictionary word break support for languages like >> Thai >IMO that would be beyond the scope of a general Unicode library. It is both outside the scope but also fundamental to the approach as this case must be handled/ provided for. In my experience this is handled by the dictionary pass [outside the scope of this support] adding special break markers into the text [which need to be supported transparently as Unicode characters that happen to be in the private use range at this level] so that the text and string iterators can then be handled normally. The fact that the break markers are special characters in the private use range should not be relevant or special at this level. >> How far have you gone? Do you have support for going from logical to >> display on combined ltor and rtol ? Customised glyph conversion for >> Indic Urdu? >Correct me if I'm wrong, but I think these issues become important >only when rendering Unicode strings. Aren't they thus better handled >by Uniscribe, Pango, or similar OS-specific libraries? I think a Boost >Unicode library should focus on processing symbolic Unicode strings >and keep away from what happens when they are displayed, just like >std::basic_string does. Unfortunately I believe that there may be serious limitations in this approach. I strongly believe that even if we do not actually write all the code we must not be in a position where, for example, you have to use a Uniscribe library based on Unicode 4 and a Boost library based on Unicode 4.1. [This is even ignoring UniScribe's 'custom' handling]. We must provide a Unicode character system on which all libraries can operate consistently. Even working out a grapheme break may require different sets of compromises that must work consistently for any set of inter-related libraries to be successful. As another example where display controls data organisation, what happens if you want to have a page of text display the same on several machines? This is actually a very difficult thing to do due to limitations in the Windows GDI scaling [which is not floating point but 'rounds' scaling calculations, and which can result in as much as a +/-10% difference in simple string lengths on different machines, unless handled specifically e.g. IIIIIIIIIIIIIIII can be the same length as WXWXWX on one machine but there can be a 20% difference on another machine] and requires access to the data conversion mechanisms and requires that you know how you are going to perform the rendering. >Why would you want to do canonical decomposition explicitly in a >regular expression? Let me give two examples: First why? If you use a regular expression to search for <e acute> - [I use angle brackets <> to describe a single character for this e-mail] then logically you should find text containing: <e><acute> and <e acute> as these are both visually the same when displayed to the user. Second why do we need to know? If we decompose arbitrarily then we can cover over syntax errors and act unexpectedly: e.g. If we type [\x1<e acute>] then we decompose it outside the syntactic context of the regular expression engine and we would get: [\x1e<acute>] This is NOT what we expect and is therefore an error as we are now looking only for an acute and the actual syntax error [incomplete hex number] is not reported. >> We will need to create a utility to take the 'raw'/ published unicode >> data files along with user defined private characters to make these >> tables which would then be used by the set of functions that we will >> agree such as isnumeric, ishangul, isstrongrtol, isrtol etc. > >I find the idea of users embedding private character properties >_within_ the standard Unicode tables, and building their own slightly >different version of the Unicode library, scary. Why is this needed? It is important that the private use range, which is part of the Unicode spec, be handled consistently with the other Unicode ranges otherwise we end up having to write everything twice ! The private use range is in the Unicode spec specifically as it has been recognised that any complex Unicode system will need private use characters. Classic examples are implementations that move special display characters into portions of the private use ranges to allow for optimal display of visible tabs, visible cr, special characters like Thai word breaks, and of course completely non-standard characters like a button that can be embedded in text and would be entirely implementation specific. Having the breaking characteristics of these characters be handled consistently with all Unicode characters is a massive simplification for coding. I strongly believe that we must therefore allow each developer who wants to use the Unicode system the ability to add these private use character properties into their own personal main character tables so they are handled consistently with all other characters, but acknowledge that these are implementation specific. This private use character data would NOT be published or distributed - the facility to merge them in during usage allows each developer the access to add their own private use data for their own system only. Yours, Graham Barnett BEng, MCSD/ MCAD .Net, MCSE/ MCSA 2003, CompTIA Sec+

2 1

Re: [boost] token_iterator flaw, format and date_time shadowing, regex gcc.mak problem, and Boost.Format suggestion
by Stephan T. Lavavej 28 Jul '05

28 Jul '05

[STL] > I have noted the following about Boost 1.32.0. > 1. boost/token_iterator.hpp is very broken on line 34. > > template <class TokenizerFunc, class Iterator, class Type> > class token_iterator > : public iterator_facade< > token_iterator<TokenizerFunc, Iterator, Type> > , Type // ********** SHOULD READ: const Type > , typename detail::minimum_category< > forward_traversal_tag > , typename iterator_traversal<Iterator>::type > >::type > , const Type& > > > > GCC 3.4.2 refuses to compile this when broken. [Dave Abrahams] > Why do you think so? I'm sorry, I misremembered it as a hard error. Actually, it produces a nontrivial warning under -Wcast-qual: C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/iter ator/iterator_facade.hpp: In static member f unction `static typename boost::mpl::if_<boost::is_reference<Reference>, Pointer, boost::detail::operator_arrow_proxy<Va lueType> >::type boost::detail::operator_arrow_result<ValueType, Reference, Pointer>::make(Reference) [with ValueType = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Reference = const std::basic_string<char, std::c har_traits<char>, std::allocator<char> >&, Pointer = std::basic_string<char, std::char_traits<char>, std::allocator<char > >*]': C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/iter ator/iterator_facade.hpp:644: instantiated from `typename boost::detail::operator_arrow_result<typename boost::detail::iterator_facade_types<Value, CategoryOrTrav ersal, Reference, Difference>::value_type, Reference, typename boost::detail::iterator_facade_types<Value, CategoryOrTra versal, Reference, Difference>::pointer>::type boost::iterator_facade<I, V, TC, R, D>::operator->() const [with Derived = boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<const char*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::basic_string<char, std::char_traits<char> , std::allocator<char> > >, Value = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, CategoryOrTr aversal = boost::forward_traversal_tag, Reference = const std::basic_string<char, std::char_traits<char>, std::allocator <char> >&, Difference = ptrdiff_t]' C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/date _time/time_parsing.hpp:81: instantiated fr om `time_duration boost::date_time::parse_delimited_time_duration(const std::string&) [with time_duration = boost::posix _time::time_duration]' C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/date _time/posix_time/time_parsers.hpp:27: inst antiated from here C:/MinGW/bin/../lib/gcc/i686-pc-mingw32/3.4.2/../../../../include/boost/iter ator/iterator_facade.hpp:325: warning: cast from `const std::basic_string<char, std::char_traits<char>, std::allocator<char> >*' to `std::basic_string<char, std::ch ar_traits<char>, std::allocator<char> >*' discards qualifiers from pointer target type Stephan T. Lavavej

1 0

[iostreams] [1.33.0] Please give me a couple of extra minutes
by Jonathan Turkanis 28 Jul '05

28 Jul '05

Hi, I need a few more minutes to fix some broken links. Sorry for the inconvenience. Jonathan

2 3

Interest in an ODBC library?
by Hajo Kirchhoff 28 Jul '05

28 Jul '05

Hi all, I'd like to gauge interest in an odbc wrapper library. I am currently writing one and the most important difference to other libraries I've seen is the ease with which my library allows binding variables to odbc columns and parameters. Given a table in the database named 'my_table' and a struct my_table, this would be the shortest code to retrieve all rows of that table and do something with them: odbc::table t; my_table data; t.bind(data); //!!! This does all the binding! t.open(); while (t.fetch().ok()) { } Note that this is the full, actual working code, not pseudo code. I have *not* omitted any function arguments. The only thing thats missing is setting the DSN and credentials for the default connection (see below). 'bind' makes use of another library 'data adapters', which allow writing runtime generic methods. I hope to make a separate announcement shortly, once I get my sourceforge CVS connection going agan. In the meantime, have a look at http://tinyurl.com/8ctju to get an idea of it. Other features: + ANSI SQL-92 "schema" support + uses DBMS strategy objects that handle DBMS specific functions such as creating a database, creating users and groups etc... + unit tests currently run with MS-Jet, MS-SQL Server 2000, postgres + has a macro 'preprocessor' for SQL statements built in that hides some of the differences between DBMS system. Example: CREATE TABLE abc(id $$SERIAL primary key not null) will expand to INT AUTOINCREMENT with MS-JET but to SERIAL on postgres. That way you can have one script that works with different databases. + always tries to fail gracefully if a feature is not supported by a specific DBMS Any interest? Best regards Hajo Two examples: Example ONE: Given this struct definition, which mirrors the table definition struct my_table { int m_id; char m_name[51]; string m_long_textfield; }; LWL_BEGIN_ADAPTER(my_table) PROP(m_id) PROP(m_name) PROP(m_long_textfield) LWL_END_ADAPTER() This is how you'd use the library In your main(), set the login data // set the credentials for the default 'unnamed' connection // all table/statement etc... will use this connection unless // specified otherwise odbc::connection::pool().set("MyDSN", "MyUserName", "MyPassword"); Anywhere use // instantiate my_table struct my_table data; // table uses the unnamed default connection odbc::table t; // bind does the magic. it automatically binds // all my_table member variables to the columns t.bind(data); // open the table t.open(); // fetch the rows while (t.fetch().ok()) { // do something cout << data.m_long_textfield; } // check for errors if (t.last_error().no_error()==false) { cerr << "ODBC error: " << t.last_error().as_string() << endl; } Example TWO: // create a statement with parameter marker statement s("SELECT * FROM my_table WHERE id=?([in]p_id)"); // bind the data to the columns my_table data; s.bind(data); // bind the WHERE parameter long parameter; s.bind(parameter, "p_id"); parameter=5; if (s.execute().ok() && s.fetch().ok()) { // data contains the row WHERE id = 5 cout << data.m_long_textfield; } else cerr << s.last_error().as_string() << endl; -- -------------------------------------------- Lit Window Library - Speed up GUI coding 10x http://www.litwindow.com/library?src=ml wxVisualSetup - integrate wxWidgets into Visual Studio .NET http://www.litwindow.com/Products/products.html?src=ml BugLister - Defect Tracker http://www.litwindow.com/buglister?src=ml Tips & Tricks for wxWidgets & MS Visual Studio http://www.litwindow.com/Knowhow/knowhow.html?src=ml

3 3

Release scripts for 1.33.0
by Misha Bergal 27 Jul '05

27 Jul '05

I've updated tarball/zipball making script (tools/release/make_tarballs.py). It has proven to be quite useful for 1.32.0 release. Basically it automates getting sources from CVS (with windows and unix newlines), building documentation, setting necessary Unix permission, cleaning up the intermediary results and making tarballs. There are some caveats though: 1. It runs on Windows and requires cygwin. 2. There might have been some changes in build procedure between 1.32.0 and 1.33.0, so the resulting tarballs need to be checked by a more knowledgable person. I will run the comparison between 1.32.0 and 1.33.0 tomorrow to check for obvious problems. 3. It doesn't have any documentation yet. 4. Release Manager's Checklist (http://www.boost.org/more/release_mgr_checklist.html) Distribution section has not been updated to include the reference to make_tarballs.py documentation. 5. Standard distrubitution of xsltproc has a show-stopper bug (http://tinyurl.com/bcp93) so the patched one needs to be obtained from our web site (http://engineering.meta-comm.com/boost/xsltproc-win32.zip) -- Misha Bergal MetaCommunications Engineering

4 5

singleton: zombie_call
by Jason Hise 27 Jul '05

27 Jul '05

I am trying to come up with a mechanism which allows member functions of the singleton to be called if the instance exists, and which do nothing if the instance does not exist (no creation is attempted, the operation is simply skipped). My current idea is a member function of the singleton pointer named zombie_call, which would be used something like: ptr.zombie_call ( &MySingletonType::SomeFunc, param1, param2, ... ); The only problem I have is what to do if the instance does not exist and the member function has a return value. Should I just return a default-constructed object in these cases? (And what should happen if the return type does not have a constructor taking no arguments?) Should I append a parameter to the end of zombie_call which is returned if the instance does not exist, and have it default to a default-constructed object? Should I append a parameter that is a reference to the return type, and just assign the return value to it if the operation is successful? (And what happens if the return type is already a reference?) Should I just enforce that member functions called with zombie_call return void? Also, is there any way to make the syntax of the call a bit nicer? I was originally hoping to have a separate pointer type called zombie_ptr, which just behaved in this manner when functions were accessed via operator->, but I couldn't think of a non-intrusive way to pull it off... Any and all thoughts are appreciated. -Jason

4 7