May 2005 - Boost - lists.boost.org

request: CVS commit access
by Caleb Epstein 03 May '05

03 May '05

I'm not sure what it takes to get commit access to the Boost CVS repository on sourceforge, but I'd like the ability to fix the occasional bug, etc. that I find in my testing on SunOS without having to beg some other Booster to apply a patch by sending to the list. Is this available with "Tester" access or only "Developer"? I'm a member of the project (cepstein) but not given any role: http://sourceforge.net/project/memberlist.php?group_id=7586 -- Caleb Epstein caleb dot epstein at gmail dot com

2 1

Re: [boost] Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 03 May '05

03 May '05

In-Reply-To: <d55q7o$4g5$1(a)sea.gmane.org> SeeWebsiteForEmail(a)moderncppdesign.com (Andrei Alexandrescu (See Website For Email)) wrote (abridged): > > Comparing: > > > > BOOST_FOREACH( int i, vec ) > > cout << i; > > > > with: > > > > for (iterator i = vec.begin(); i != vec.end(); ++i) > > cout << *i; > > > > the macro just doesn't seem worth it. > > In fairness, it's > > for (vector<ArbitrarilyComplexType>::iterator i = vec.begin(); i != > vec.end(); ++i) > cout << *i; No, I meant what I wrote. I usually have a suitable iterator typedef in scope. In the worst case it is more like: typedef vector<ArbitrarilyComplexType> MyVec; for (MyVec::iterator i = vec.begin(); i != vec.end(); ++i) cout << *i; where "MyVec" is some meaningful name (and is probably itself worth putting at some larger scope - after all, where did the vec come from?). And I see adding a typedef as clearer, transparent even, compared to the BOOST_FOREACH macro. > I think the part of the discussion that focuses on arguments for or > against macros is misplaced. Agreed. As I said earlier, I am not absolutely against macros; I won't automatically vote against any proposal that uses them. I am also objecting to BOOST_FOREACH because it is taking something simple and making it complicated. -- Dave Harris, Nottingham, UK.

2 1

[wave] Compilation hangs on Tru64
by Markus Schöpflin 03 May '05

03 May '05

Hello, after recent fixes to the pool library the wave tests passed on Tru64/cxx. But currently the compiler chokes when compiling instantiate_cpp_grammar.cpp. It just sits there for hours consuming all available CPU resources without making any visible progress. This behaviour seems to be related to changes checked in over the weekend. Does that ring a bell with anyone? Markus

2 2

DLL/SO loading library.
by Vladislav Lazarenko 03 May '05

03 May '05

Greetings, dear developers. I have some simple idea to write platform independed library to provide users with ability to load DLL/SO files (i.e. to develop plugin system etc.). Is there any library in boost? I've found nothing. Maybe we need it? Let's discuss, I am interested in your comments. Thank you very much in advance.

14 32

GCC 4.0 Compiler Review \ Performance Tests
by Brian Braatz 03 May '05

03 May '05

http://www.coyotegulch.com/reviews/gcc4/index.html The review is interesting, but of most relevant interest to boosters would be the following: "The C++ compiler is now faster, particularly on code heavy with templates; the Standard C++ library has improved stream and strings classes, and it includes preliminary new classes from the recent C++ Technical Report 1 (an update to Standard C++)." The review is interesting. For those who don't wish to read through it, basically 4.0 is more of an incremental version, no real performance leaps in compilation or performance.

3 2

Re: [boost] Re: Re: Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 03 May '05

03 May '05

In-Reply-To: <d55r5q$9h2$1(a)sea.gmane.org> gennadiy.rozental(a)thomson.com (Gennadiy Rozental) wrote (abridged): > > Adding #defines is adding complexity. > > I think it's a kinda an attitude issue: you see all macros as enemies. No. Adding almost anything is adding complexity. It's another layer. And of course a rather powerful layer - a macro can do almost anything. Also you snipped the context. Your proposal here was, if I understand correctly, to use conditional compilation to switch off FOREACH's support for corner cases. So we are adding more options and configurability, and the potential for my corner cases not to work because support for them has somehow been switched off (where - in the makefile?). Even if I know how FOREACH works in my project, it might work differently on my colleague's project. And I have yet more code to read when I look at the header. It's as if we were trying to build the most complex thing that could possibly work. > I see some of them as friends. Macros in general (and FOREACH in > particular) are in most cases only usability helpers (there is also > configuration switched domain, but it's beside the point). And until > language provide as-convenient alternatives I am ready to accept the > macro nature of these tools. I'm ready to accept them too, when they do something worth while. This one doesn't. -- Dave Harris, Nottingham, UK.

2 1

The View concept
by Maciej Sobczak 03 May '05

03 May '05

Hi, There is a thread on comp.lang.c++.moderated where the problem of manipulating with "heavy" data in STL containers was raised. The name of the thread is "Messign with expensive objects in containers". I have posted a solution with the help of a simple view adaptor class that I wrote a while ago. The code with examples and documentation is here: http://www.msobczak.com/prog/bin/view.zip (11kB) Alberto Barbati suggested to post it here for review. It is different from boost::multi_index in that view operates on already existing objects or sequences. Note: the view class itself is very simple and as a concept is only a fraction of what is available in the View Template Library: http://www.zib.de/weiser/vtl/ I would like to know your opinion about the view as a concept, and its simple implementation that I referenced above. It might fit into the Containers category of Boost libraries. Regards, -- Maciej Sobczak http://www.msobczak.com

2 1

why the demo.cpp in serialization can't be built?
by Jun Lu 03 May '05

03 May '05

Lots of link errors (VC7.1). One of them: Test error LNK2019: unresolved external symbol "public: __thiscall boost::archive::basic_text_oprimitive<class std::basic_ostream<char,struct std::char_traits<char> > >::~basic_text_oprimitive<class std::basic_ostream<char,struct std::char_traits<char> > >(void)" (??1?$basic_text_oprimitive@V?$basic_ostream@DU?$char_traits@D@std@@@std@@@archive@boost@@QAE@XZ) referenced in function "public: virtual __thiscall boost::archive::text_oarchive_impl<class boost::archive::text_oarchive>::~text_oarchive_impl<class boost::archive::text_oarchive>(void)" (??1?$text_oarchive_impl@Vtext_oarchive@archive@boost@@@archive@boost@@UAE@XZ)

2 1

Re: [boost] Re: Formal Review: FOREACH macro
by brangdon＠cix.compulink.co.uk 03 May '05

03 May '05

In-Reply-To: <4276723A.5020107(a)boost-consulting.com> eric(a)boost-consulting.com (Eric Niebler) wrote (abridged): > OK, that's true. But the same can be said of any third-party library. Quite. There seems to be a general view in Boost that users don't care about the complexity of the implementation. It is with the general view that I disagree. It is also a problem with shared_ptr, for example. However, the complexity can be justified if the library delivers enough bang for the buck. In my view this one doesn't. > I guess the only problem is that most debuggers don't let you step > into a macro. Yes, that's a problem specific to macros :-) > Neither of these loops "work" -- they are both broken in the same way. As others have pointed out, the first one works with reserve(). Or they might work with other containers than std::vector - let's not get hung up on details. I'm sure you are as capable as I at manufacturing examples which do work and which demonstrate the problem. > I don't think it's reasonable to assume rational behavior when you > are altering the sequence while you are iterating it. Do you see how the proposed library is making life more complicated? It is adding unobvious restrictions and rules. > But perhaps it should be worth noting in the docs that FOREACH > doesn't perform any heroics to make this work. Definitely. Especially as others have suggested non-caching implementations. The only way to know whether FOREACH caches is to consult the documentation, or look at its implementation. And again I see this as adding a little bit of complexity. -- Dave Harris, Nottingham, UK.

1 0

[Filesystem] i18n
by Martin 03 May '05

03 May '05

Didn't find any comments on the new filesystem implementation so here are mine - Would it be possible to store the new files in the vault? I find it inconvenient to check out a special branch just to read the documentation. - I haven't compiled the new files but I have had a good look at the documentation and the source. My impression is that it is a very nice implementation. (All the #ifdefs make the source hard to follow but I'm not the maintainer) - Specially I like the switch from default portable syntax to default native syntax. It means that I no longer need to change the default name checker in each application and that the "native_" prefix from the access functions are gone. (Maybe the name checker could be a template parameter (with default "none") for those who still want to use it. Would complicate implementation of operations.) The comments I have on the new implementation is: - Operations are limited to std::string (and std::wstring on win32) as external type. Why not allow any range of characters? Current implementation will not work with const_string, flex_string and a basic_string with a custom allocator. - Why not have a static locale member in the class instead of using the utf-8 facet. The locale could then be used both for internal/external conversion via the codecvt facet and get operator< to work with a custom locale. (for posix the locale would default to locale::global() with the utf-8 facet added) I also had hopes for some new things that didn't appear in the new implementation. - non-throwing is_* functions. I find it very inconvenient and error prune to put try/catch around each is_directory call. Calling is_accessible before every other is_* function is an option but not much easier and still leaves a risk for an exception if another process is accessing the file. The throwing is_* functions also makes it impossible(?) to use the directory iterator with algorithms like remove_copy_if(directory_iterator(path), directory_iterator(), back_inserter(filelist), is_directory) My suggestion is to add non-throwing overloads where a second parameter tells what the function should return in case of error. e.g. is_directory(path, true). - The directory iterator is still very limited since you can't specify a filter (e.g. "*.txt"). If used on a win32 system with a mounted posix disk or a posix system with a CD problems might arise. (There is no portable way to tell if "FILE.TXT" matches "*.txt"). - Why doesn't last_write_time return a boost::ptime

7 38