- Boost - lists.boost.org

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 02 May '05

02 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

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

02 May '05

In-Reply-To: <4276462D.1020501(a)boost-consulting.com> eric(a)boost-consulting.com (Eric Niebler) wrote (abridged): > It injects 5 local variables. I haven't checked, but I suspect that > some can be optimized away sometimes. I doubt they will be in debug mode, which is when I need to look at them. > I'm not sure why users will need to understand how FOREACH uses > its hidden variables. Can you explain? When I am debugging, I need to understand what the code is doing else how I can I understand what it is doing wrong? For example, from looking at the implementation it seems that the macro caches the end() value in a variable called _foreach_end. This means that if some random memory corruption changes that variable the loop may never terminate. I need to know. Incidently, if it is caching then code like: BOOST_FOREACH( int i, vec ) if (condition(i)) vec.push_back( filter(i) ); will not work the same as: for (iterator i = vec.begin(); i != vec.end(); ++i) if (condition(*i)) vec.push_back( filter(*i) ); Which at least needs to be documented. Again the implementation is complex enough that I can't tell at a glance whether these are the same, so I may have this wrong, but I strongly suspect they are different. -- Dave Harris, Nottingham, UK.

4 9

Re: xpressive as scanner generator [was: new version of xpressive]
by Andreas Pokorny 02 May '05

02 May '05

Resending that message, accidently sent it to eric directly, so again: On Mon, May 02, 2005 at 09:50:37AM -0700, Eric Niebler <eric(a)boost-consulting.com> wrote: > About a year ago, Hartmut Kaiser wrote an xpressive_p() parser for > Spirit which wrapped an xpressive regex. It worked a bit like the > current regex_p parser. Would that meet your needs? I don't know what > became of it. Perhaps Hartmut knows. Thats also an interesting usage of xpressive. I dont have an acute need for scanners, my parsing needs are currently focused on biological formats which are just database dumps most of the time. So I have to work on character level most of the time. But provided that I work on parsing a scripting language, or rather a language which is intended for parsing by software, I would try to implement a lexer first. And use that lexer as scanner object in spirit. I think it is a bit strangely that there are several generic C++ replacements for yacc/bison, but nothing similar to lex/flex, that can be intergrated into spirit (integrated as scanner that is). Andreas Pokorny

2 1

RE: [boost] lambda bind breaks VC 7.1
by Brian Braatz 02 May '05

02 May '05

Try turning off the automatic auto completion functionality in the IDE I have seen this, not repeatable though. In one case, I re-formatted the call and by doing this I got it to not crash anymore. I have also run into problems with conflicts with the win32 bind() call. (but that is a whole different ball of wax) > -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of Jason Hise > Sent: Sunday, May 01, 2005 12:22 PM > To: boost(a)lists.boost.org > Subject: [boost] lambda bind breaks VC 7.1 > > For some reason, it seems that whenever I type '(' after > boost::lambda::bind (which would normally cause the intellisence list to > pop up with the arguments the function takes), visual studio completely > locks up. Does anyone else have this problem? Are there known fixes or > work-arounds? > > -Jason > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[ptr_container] metrowerks problems
by Thorsten Ottosen 02 May '05

02 May '05

Hi All, I haven't got a metrowerks compiler and can't fix the problems easily; so I *need* somebody to help me. The alterantive is that I will have to mark them as unusable. Please contact me if you would like to help and need directions. Thanks -Thorsten -- Thorsten Ottosen ---------------------------- www.dezide.com http://www.cs.aau.dk/index2.php?content=Research/mi www.boost.org www.open-std.org/JTC1/SC22/WG21/

3 18

libs/libraries.htm
by Stefan Strasser 02 May '05

02 May '05

I'm reading about the libs that got accepted into 1.33 and noticed that ptr_container is missing from libs/libraries.htm -- Stefan Strasser

1 0

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

02 May '05

In-Reply-To: <d55ii6$74o$1(a)sea.gmane.org> gennadiy.rozental(a)thomson.com (Gennadiy Rozental) wrote (abridged): > 1. Not to mention the collection type > As Eric pointed out - you may not know one. But even if you do writing > std::vector<mytypes<my_param> > several types for every loop I need is > tidies. I generally solve that problem with a typedef. Most of the time the collection is a class, the typedef is a member of that class, and the iterating code is a member function of that class. So the word "iterator" is all I need. If your loops are so complex you would benefit from BOOST_FOREACH, I think you'd also benefit from simplifying them, separating concerns a bit more, etc. > Since you agree that looping is quite basic need - simplifying it is a > worthy task. I agree it's a worthy ambition, but this doesn't simplify them. It makes them much more complex and then tries to hide the complexity behind a macro. > As for the complexity it's required to support some corner > cases situation. You could always disable it with defines (that what I > am going to do). Adding #defines is adding complexity. -- Dave Harris, Nottingham, UK.

2 1

RE: [boost] Boost Logging Library ( + Mini Update on proposed boost.profile )
by Brian Braatz 02 May '05

02 May '05

> -----Original Message----- > From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] > On Behalf Of James Fowler > Maksym Motornyy wrote: > > > During development of last product I was missing good C++ logging > > library like one available in Java. I had to write it myself. Does > > somebody think that it will be useful to have it in Boost? Or there is > > such one in development? > > Several projects related to logging have been mentioned recently (see > message below). I'm about to throw another in the ring which could be > used for primitive logging, although it's primary focus lies elsewhere. > [James Fowler Writes:] > The basic concept of logging is simple enough, but the wide range of > useful implementation variations makes it really hard to envision a > solid "one-size-fits-all" system. It may make sense to start working on > a common set of patterns for a logging system interface, which could be > used to consistently encapsulate many different implementations. This > same issue came up in a discussion with Brian Baatz on profiling. > Developing such an interface should be challenging enough, even without > specifying implementation, but it's a more manageable first step. It > also seems like a good way to foster cooperation among the various > projects while allowing a healthy level of diversity, ideally > improving the consistency over time for "early-adopters" of specific > projects. [Brian Braatz Writes:] (Thank you James for remembering I was working on this :) ) Sorry guys, have been OFF LIST for awhile here. Was busy integrating profiling into a very large application. I am working towards getting a status report out to this list here (hopefully) within this week. This will include What I added to the profiler What production tests we did What was learned by doing that Next steps for proposed boost.profile What I have learned in this process: Profiling EVENTS and LOGGING those events together is what is necessary to get the whole picture "Programmer" level logging is different from profile event logging What I see the Logging Library doing is connecting the dots with programmer supplied information Logging events and connecting them (mentally) with the profile report fills in the missing blanks for the developer for performance centered thinking Logging programmer detailed messages is more for finding bugs Logging events relative to the profiler, is more for performance related analysis What is also interesting, while I have not done a detailed review of the logging library, we seem to have done some things similarly. (there is about 5-10% overlap) Again, what profiling \ event tracing is trying to do is different I think than what the Logging Library is trying to do, there is some overlap. My State: I have integrated the profiler and things I have added to the profiler into our application In doing so, the library on top of that is using our internal (not boost) libraries for support My next step here is to take what I learned from doing this and combine them into one library that is boostified Additionally, I need to (this week) keep everyone in the loop by submitting a report.

1 0