- Boost-users - lists.preview.boost.org

[general] Speeding up compilation?
by Lynn Allan 14 Apr '06

14 Apr '06

<alert comment="stl newbie"> vc7.1 Visual C++ user: Sorry if this has been asked before. My impression is that this is the nature of templates, since code is being generated as objects are instantiated. Are there guidelines for speeding up compilation/linkage of code that moderately/heavily uses templates? It seems to take a looooong time, even on a relatively modern development computer. Precompiled headers don't seem to help .... perhaps it is counter-productive to use precompiled headers with stl/boost? Or I'm ignorant about proper usage? Are there vc7.1 / vc8 settings to speed up development? GCC? Is this #define applicable (and/or perhaps others): BOOST_MPL_USE_PREPROCESSED_HEADERS </alert>

5 6

utf8_codecvt_facet linking problem with VC 7.1
by Raider 14 Apr '06

14 Apr '06

I'm trying to compile simple code using utf8_codecvt_facet: // ---- UTF8.cpp starts ------------------------------ #include <iostream> #include <fstream> #include <string> #include <locale> #include <boost/program_options/detail/utf8_codecvt_facet.hpp> using namespace std; int main() { locale loc; locale utf8loc(loc, new boost::program_options::detail::utf8_codecvt_facet()); wifstream f; f.imbue(utf8loc); f.open("UTF8.txt", ios::binary); wstring s; f >> s; f.close(); return 0; } // ---- UTF8.cpp ends ------------------------------ It works OK with VC 8.0 (both building Boost and this code with VC 8.0). But I get linker errors with VC 7.1 (both building Boost and this code with VC 7.1): UFT8.obj : error LNK2001: unresolved external symbol "protected: virtual int __thiscall boost::program_options::detail::utf8_codecvt_facet::do_out(int &,unsigned short const *,unsigned short const *,unsigned short const * &,char *,char *,char * &)const " (?do_out@utf8_codecvt_facet@detail@program_options@boost@@MBEHAAHPBG1AAPBGPAD3AAPAD@Z) UFT8.obj : error LNK2001: unresolved external symbol "protected: virtual int __thiscall boost::program_options::detail::utf8_codecvt_facet::do_in(int &,char const *,char const *,char const * &,unsigned short *,unsigned short *,unsigned short * &)const " (?do_in@utf8_codecvt_facet@detail@program_options@boost@@MBEHAAHPBD1AAPBDPAG3AAPAG@Z) As a linker tells me the reference is: ?do_in@utf8_codecvt_facet@detail@program_options@boost@@MBEHAAHPBD1AAPBDPAG3AAPAG@Z But library (auto-linked libboost_program_options-vc71-sgd-1_33_1.lib) contains: ?do_in@utf8_codecvt_facet@detail@program_options@boost@@MBEHAAHPBD1AAPBDPA_W3AAPA_W@Z When I add Boost/libs/program_options/src/utf8_codecvt_facet.cpp to my VC 7.1 project, the sample code builds fine. The question is how to build this code under VC 7.1? Is it needed to rebuild Boost's libboost_program_options-vc71-*-1_33_1.lib with some compiler options to get ?do_in@utf8_codecvt_facet@detail@program_options@boost@@MBEHAAHPBD1AAPBDPAG3AAPAG@Z export or to build code above with some options to get ?do_in@utf8_codecvt_facet@detail@program_options@boost@@MBEHAAHPBD1AAPBDPA_W3AAPA_W@Z reference?

1 0

[spirit] thread safety / lock freedom
by Tim Blechmann 13 Apr '06

13 Apr '06

hi all, i'm currently looking into the spirit library to create a parser ... it seems to be threadsafe, but it's using thread locks. is it possible to use the library in a lockfree manner? can i be sure, that there will be no lock misses, when i'm not sharing parsers between the threads? thanks in advance ... tim -- TimBlechmann(a)gmx.de ICQ: 96771783 http://www.mokabar.tk All we composers really have to work with is time and sound - and sometimes I'm not even sure about sound. Morton Feldman

2 1

[Xpressive] Baffled about results of search
by Lynn Allan 13 Apr '06

13 Apr '06

<alert comment="xpressive newbie"> vc7.1 xpressive from "vault" as of today (April 11) With the statements below (more or less based on Example 1 and Example 2 in the sample code provided with xpressive), I'm attempting to detect which "group" of subexpressions matched, and getting results that I don't understand (not unexpected for a newbie <g>). std::string altDow( "Alternate days of the week are Tue and Thursday and Sat and Monday." ); sregex rex = sregex::compile( "((Sunday|Sun)" "|(Monday|Mon)" "|(Tuesday|Tue)" "|(Wednesday|Wed)" "|(Thursday|Thu)" "|(Friday|Fri)" "|(Saturday|Sat))" ); The first regex_search sort of works, but I'm unclear what field in the smatch:what variable to use to tell what matched, and some oddities are happening. regex_search( altDow, what, rex ) Length(0): 3 Position(0): 31 what[0]: Tue what[1]: Tue what[2]: what[3]: what[4]: Tue The subsequent searches give valid information about the length and position, but other fields in the smatch:what variable seem invalid. regex_search( altDow.substr(32), what, rex) regex_search( altDow.substr(45), what, rex) Regardless, I'm unclear how to tell which of the "groups" of subexpressions was "hit". With boost::regex there was a way to loop thru the boolean field: what[i].matched and see what "hit", but I am not seeing a comparable accessor. Am I doing something wrong, leaving something out, completely clueless on using xpressive, or is xpressive not intended for this kind of usage? (and if xpressive is appropriate, what statements will provide the intended information?) The intention is to be able to to replace/encode the altDay string to be: Alternate days of the week are <dow=2>Tue</dow> and <dow=4>Thursday</dow> and <dow=6>Sat</dow> and <dow=1>Monday</dow>." ); If it will help, here is a link to the vc7.1 project. http://cleanspeech.sf.net/misc/DayOfWeekTest.zip </alert>

4 10

catch(...) in thread_proxy
by Jeremy Stanley 13 Apr '06

13 Apr '06

I find the catch(...) in thread_proxy to be a real nuisance. The only thing I can do to prevent threads from silently slipping away is to put a catch(...) inside my thread procedure, but when this is hit I have no idea what the exception is or where it was thrown. I could configure the debugger (msvc71) to break whenever an exception is thrown, but then I have to wade through handled exceptions in order to find the real error. There was a discussion on this subject about eight months ago where the consensus seemed to be get rid of the catch(...)--any progress on this since then? I notice the catch(...) is still present in CVS, which isn't encouraging. As a refresher, this approach won't help... try { thread_proc(); } catch(...) { exception_filter(); // ... because I don't have a stack trace here. } This sort of approach could be okay though: if ( swallow_exceptions ) { try { thread_proc(); } catch(...) { whatever(); } } else { thread_proc(); } If swallow_exceptions were on by default, it wouldn't change behavior unless the programmer asked for it, perhaps using an optional parameter in the thread and thread_group constructors.

2 1

High memory requirement of adjacency_list
by Pratyush 13 Apr '06

13 Apr '06

Hi, It seems that adjacency list takes up lot of memory than what I was expecting. Below is the code that I used for testing. int main() { typedef boost::adjacency_list<> graph_t; graph_t g(6045064); } The graph populated is taking about 190MB of memory, i.e., 32 bytes/vertex approx. I was expecting it to take 4 bytes/vertex. Am I doing something wrong? My intent is to use "vec_adj_list_impl" having no properties at all. Thanks & regards, Pratyush

5 8

Release Candiate Download Location?
by Olaf van der Spek 13 Apr '06

13 Apr '06

Hi, What is the location where the current release candidate can be downloaded?

1 0

[format] %d, %u etc. with (unsigned) char types
by Luke Elliott 13 Apr '06

13 Apr '06

I couldn't find anything on this in the list archives or the format docs, but it seems likely to have been asked before so apologies if that is the case. I would expect something like: boost::format fmt("%d"); fmt % char(0); std::cout << fmt; to output "0" given that %d is explicitly specified. This isn't the case (with VC++ 7.1 and GCC 3.4 at least, and presumably all others given this is normal stream behaviour). Obviously it can be worked around by casting to a non-char type, but that seems a shame given the nature of the library and not having to worry about type-safety too much. So, is this by design or accident? If not by design, would it be possible to change the behaviour (specialisation somewhere for (unsigned) char types or something??)? Thanks in advance Luke Elliott.

1 0

Validating file names using regex
by Jean-Sebastien Vachon 13 Apr '06

13 Apr '06

Hi there, I am sure what I am looking for exist somewhere but I haven't been able to find anything that works in boost::regex. What I am looking for is a regular expression that will validate a filename according to the specification of the OS (UNIX systems and Windows). I would be very grateful if someone could provide me with these two expressions (one for Linux and one for Windows). Later,

4 7

[xpressive] Installation prepares .lib files?
by Lynn Allan 13 Apr '06

13 Apr '06

WinXp-SP2 vc7.1 Would it be feasible/advantageous for xpressive to have an installation procedure a'la regex to build a whole series of .lib libraries? That seems to speed up builds quite a bit.

2 1