January 2005 - Boost - lists.boost.org

RE: [boost] Call for Volunteers: the Synopsis project
by Stefan Seefeld 30 Mar '05

30 Mar '05

Hi Volodya, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > Sent: September 30, 2004 03:04 > Count me as interested. Are you going to base that parser on > OpenC++, which, > IIRC, was used by Synopsis some time ago? Last time a looked > at OpenC++, it > did not even distinguish between ordinary names and > typenames, which makes me > wonder if it's a good parser. You are right, there remains a lot of work to be done. The C++ parser backend of synopsis which we are talking about here is indeed based on OpenC++, but has already undergone lots of improvements. In its original design the parser didn't contain any form of semantic analysis such as symbol lookup to disambiguate certain expressions. For what it had been used so far it was good enough. I'm now working on the features that allow it to get closer to the standard, i.e. constant expression evaluation, symbol (type) lookup, etc. As I said, any help would be very appreciated ! Regards, Stefan

2 2

Warnings in Boost.Thread
by Janusz Piwowarski 29 Mar '05

29 Mar '05

Hi all, When Boost.Thread is compiled in release mode, there are a lot of warnings about unused variable 'int loop_count' in read_write_mutex.cpp. They comes from code like: int loop_count = 0; while (m_state == -1) { BOOST_ASSERT(++loop_count == 1); ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; } If loop is for second evaluation of condition only, i think it would be better to write: if (m_state == -1) { ++m_num_waiting_readers; m_waiting_readers.wait(l); --m_num_waiting_readers; BOOST_ASSERT(m_state != -1); } Regards, Janusz

2 1

Re: [boost] shared_ptr doubts
by Don G 20 Mar '05

20 Mar '05

It is likely that we will simply just disagree on this, but I will at make a stab at responding to your points. > For some specific smart pointer applications, it is possible to > design a smart pointer that is more optimal than shared_ptr. > That's what a policy-based smart pointer is all about, and > hopefully we will soon have one in Boost. In the meantime, look > at the Loki policy-based smart pointer. I'm familiar with Alexandresu's book (even if I can't always remember how to spell his name<g>), but... > But sometimes a single general-purpose smart pointer is needed. Yes! Although I am focused purely on reference counting smart pointers. But... > For example, as a standard type to communicate between libraries, > including third-party libraries. Or to recommend generally to a > wide-range of programmers, including those who might be confused > by a plethora of choices. Exactly. > Or in cases where various efficiency concerns are nowhere near as > important as using a well-known, well-understood, and soon > standardized smart pointer. Why can't we have both? I would suggest that a major reason STL is so popular is that it paid careful attention to efficiency from its inception. If std::vector had allocated several or nearly a dozen extra machine words per object as shared_ptr does at times, I believe things would have turned out differently. The std containers offer what is needed to accomplish a well focused task, allocating only the data necessary for that job and no more. For example std::list need only allocate 2 pointers per object. If Stepanov had gone on to add feature after feature that made this number on par with shared_ptr, again, it likely would not have been well received. > The Colvin-Dimov shared_ptr design solves a far-broader range of > smart pointer problems than any other proposed design. That's > why it is the most commonly recommenced C++ smart pointer type > in the world. That's why the C++ committee is standardizing it. Please don't take my doubts the wrong way; I am not trying to "dis" their fine work. If folks want to use it, that's fine. They should be warned, but caveat emptor. I am focused on the last statement above. As it sits, shared_ptr simply goes too far and in so doing one must always ask "is shared_ptr suitable in this case?" As a library author, this is often an impossible question to answer, because it could depend on the use to which the library is put. In other words, by adding all the frills, shared_ptr actually reduces its scope of applicability. > It isn't intended to replace all other smart pointers. No single > smart pointer type can do that. So appreciate it for the many > problems it solves, rather than worrying about the problems > where another smart point would be more optimal. Where is the standard smart pointer to which you refer? I can keep writing my own (have been for many years, and kinda like it<g>), but what I would really love to see is a pair of simple ones provided by the standard library that accomplish just two jobs: delete it; and delete it when the count drops to 0 (with some means for the count to be internal to the object). If more smart pointers are added beyond that, that would be great. So far, both auto_ptr and soon shared_ptr fail at the K.I.S.S. test. They set out to solve these two "simple" problems and got lost along the way. A standard facility should not offer such surprises to unsuspecting users. With auto_ptr we got "surprise! you thought I was the owner, but it was that other guy that just left scope". With shared_ptr we will have "surprise! here's that bad_alloc you've always wanted". If the current design is the way it will be (probably), can't we at least have a warning label: "WARNING: shared_ptr may allocate 40+ bytes per object (fine print: depending on platform and multithread considerations, your mileage may vary, etc.)" Well, I'm no lawyer I guess... <g> > All IMO, of course! Likewise! Best, Don ===== __________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250

5 13

Re: Boost.Threads Bug (recursive_try_mutex)
by Jonathan Biggar 17 Mar '05

17 Mar '05

Mark Rodgers wrote: > Bill, > > recursive_try_mutex::do_trylock() (BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE > implementation) contains the following: > > assert(res == 0); > > Surely that should be > > assert(res == 0 || res == EBUSY); This bug still exists in 1.32! -- Jon Biggar Levanta jon(a)levanta.com

2 1

format lib patch
by François Dumont 23 Feb '05

23 Feb '05

Here is a small typo fix for the BOOST_NO_LOCALE_ISDIGIT macro that is sometimes spell with an additional I (ISIDIGIT). It is even spell correctly only once!

2 1

format lib patch
by François Dumont 23 Feb '05

23 Feb '05

Config: STLport 5.0 beta and MSVC 8 (but also reported with 7.1) It looks like this compiler has a problem with the relation between the basic_string::size_type and basic_format::size_type as soon as the library is not the native one. Here is a patch proposition that return a basic_string::size_type rather than the basic_format::size_type. I think it is quite a secure patch as the method is already using a static_cast<typename string_type::size_type> to return its result and not a simple static_cast<size_type>. Bests

2 1

BOOST_NO_RTTI?
by Douglas Gregor 20 Feb '05

20 Feb '05

We've now had a user request that could be solved by adding a BOOST_NO_RTTI macro, that (when set) would disable Boost's use of constructs that use run-time type information (dynamic_cast, typeid, etc.), similar to our BOOST_NO_EXCEPTIONS. http://lists.boost.org/MailArchives/boost-users/msg09240.php I'll plan to add it unless there is violent disagreement. Doug

6 10

void * with boost::python
by Preston A. Elder 16 Feb '05

16 Feb '05

I have some functions in C++ that take a void *, for example hexdump(). The main use of this, obviously, is to pass a buffer and get the hex dump as a return value - without having to worry about the type passed, eg: std::string str("This is a test"); hexdump(str.data(), str.length()); std::wstring wstr(L"This is a test") hexdump(str.data(), str.length() * sizeof(wchar_t)); I want to know the best way of exposing such a function to python without being too 'string specific' (theres no reason I couldn't do hexdump(&some_int, sizeof(int)) in C++, so I want something similar in python, if I can get it). Now hexdump is only an example, I have a few other functions that do the same (for example, recv() and send() in a socket class). Any ideas would be appreciated. Right now, the best thing I can think of is to create a wrapper function (for use in the python interface only) that accepts a std::string/std::wstring and calls hexdump, however this hamstrings me when I want to do things like integers, or complex structures. Also, on another note, is there somewhere that has all of boost already pythonized? I manually converted boost::date_time (at least all the gregorian and posix_time stuff) myself, however I would have expected most of boost to have been converted to python already ;) -- PreZ :) Founder. The Neuromancy Society (http://www.neuromancy.net)

3 8

[filesystem] Major changes before standardization
by Beman Dawes 13 Feb '05

13 Feb '05

I'm currently working on a major revision of the Boost filesystem library aimed at getting it ready to be proposed to the C++ committee for the next Library TR. The critical technical change required is internationalization. The plan is to provide a templated basic_path class, with typedefs for path and wpath. In other words, an approach very similar to the current std::basic_string, std::string, and std::wstring. Doing this adds a certain amount of complexity compared to the current path class. For example, a path_traits class has to be introduced to give basic_paths on user defined types a way to import the conversions, delimiters, and other traits. To offset the added complexity, I'd like to reduce some of the complexities in the current design: * Eliminate the distinction between native and generic grammars; either would be permitted in all contexts. As well as simplifying the class interface a bit, this will also eliminate a source of user confusion. * Move the name error checking from the basic_path class into stand alone functions. Although the current error checking could be further improved by Peter Dimov's suggested change allowing failure to be treated as either a warning or a hard error, moving it out of the class simplifies the interface, allows full path (rather than name-by-name) error checks, and eases internationalization. The primary downside of these changes will be that users who want path portability checks will have to code calls to checking functions that are currently being called automatically. The internationalization of the library is a big enough change that we will probably want to have at least a mini-review once the changes are complete. Comments? --Beman

12 55

[mpl] vector_c with enumerators?
by Larry Evans 11 Feb '05

11 Feb '05

Is the following supposed to compile: enum visitor_numerals { visitor_n0 , visitor_n1 }; typedef mpl::vector_c<visitor_numerals,visitor_n0> vec_viz_type; typedef mpl::at_c<vec_viz_type,0>::type vec_viz0_type; it does with intel but with gcc, I get: bjam --v2 toolset=gcc vector_enum_test ...patience... ...found 751 targets... ...updating 4 targets... gcc.compile.c++ ../../../../bin.v2/lje/libs/fields_visitor/test/vector_enum_test.test/gcc/debug/vector_enum_test.o /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/preprocessed/gcc/vector_c.hpp: In instantiation of `boost::mpl::vector_c<visitor_numerals, 0l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l, 2147483647l>': /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/has_tag.hpp:20: instantiated from `boost::mpl::aux::has_tag<test()::vec_viz_type, mpl_::bool_< false> >' /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/sequence_tag.hpp:115: instantiated from `boost::mpl::sequence_tag<test()::vec_viz_type>' /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/at.hpp:45: instantiated from `boost::mpl::at_c<test()::vec_viz_type, 0l>' vector_enum_test.cpp:11: instantiated from here /home/evansl/prog_dev/boost-release/boost_1_32_0/boost/mpl/aux_/preprocessed/gcc/vector_c.hpp:47: error: invalid conversion from `long int' to `visitor_numerals'

3 8