- Boost - lists.boost.org

Problem with the Color Map for DFS visit algorithm
by Manas Singh 27 Oct '04

27 Oct '04

I am having problem with passing a color map to depth_first_visit algorithm. I have defined my graph as follows: typedef adjacency_list < vecS, vecS, directedS, property<vertex_color_t, default_color_type, property<vertex_count_t, int> > > graph_t; I have defined a vector of default_color_type as follows: std::vector<default_color_type> colors(num_vertices(g)); I am calling dfs visit as follows: depth_first_visit(graph, start_vertex, visitor(vis_count), colors.begin( )); But while compiling I am getting error. Is there any easy way of passing color maps to depth_first_visit ? Regards, Manas.

2 1

[serialization] Loading objects of classes with customized operator new
by Andreas Huber 27 Oct '04

27 Oct '04

Hi Robert Under release.html#todo you say that it is currently not possible to use serialization with types that define their own new/delete operators. In serialialization.html#constructors you describe a technique how types that do not possess a default constructor can be serialized. Given the design of load_object_ptr and load_construct_data it seems that this is easily possible, namely by overloading load_object_ptr. I'm therefore wondering whether the remark under release.html#todo is outdated or whether I'm missing something. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2

[assign] initializing nested data structures
by Jonathan Turkanis 27 Oct '04

27 Oct '04

Hi, I'm trying to use Boost.Assign to test an output formatting facility, but I'm having trouble translating pseudocode with brace-initializers into working C++. E.g., how to you translate this: vector< list< pair<string, string> > > v = { { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") }, { make_pair("hello", "goodbye"), make_pair("morning", "evening"), make_pair("cold", "hot") } }; The following works on VC7.1, but not on como or gcc 3.4.1: vector< list< pair<string, string> > > v = list_of( list_of( make_pair("hello", "goodbye") ) ( make_pair("morning", "evening") ) ( make_pair("cold", "hot") ) ) ( list_of( make_pair("hello", "goodbye") ) ( make_pair("morning", "evening") ) ( make_pair("cold", "hot") ) ); What am I doing wrong? Best Regards, Jonathan

2 2

Any interest in adding unicode support to boost?
by Erik Wien 26 Oct '04

26 Oct '04

Hi. I am in the process of planning a library for handling unicode strings in C++, and would like to probe the interest in the boost community for something like that. I read through the unicode dicussion that was up back in april, and from what I could gather there was some amount of interest, but no one felt comfortable taking on the task as of yet. I am hoping to be able to run this project as my Bachelor's Thesis in Computer Engineering (Not sure if that is the correct translation from Norwegian.) and if it gets approved by my college, myself and two other programmers will spend one semester working exclusively on this. (of course in collaboration with the boost community) At the end of that semester I hope the library (Or at least parts of it) will be in such a state it can submitted for review by boost. The library should ultimately have suppport for at least basic handling of unicode strings (in all encodings), collation of strings and other locale specific operations. The library should also be (to the extent that is possible) integrated with the standard C++ library (and boost) to get as much functionality as possible "for free". I'm here thinking of, among other things, the std::locale class and compabillity with iostreams. How these requirements are fulfilled will be determined as the project (hopefully) moves forward. I really feel the C++ language needs some form of standardized unicode support, and developing such a library within the boost community would be a very good way to ensure it fits everybody's needs the best possible way. If you have any, and I do mean ANY, thoughts on this, please do not hesitate to reply to this mail and let me know. I'm looking forward to your responses. Best regards Erik Wien - Gjøvik College (Høyskolen i Gjøvik), Norway.

22 149

[serialization] binary archives and text/binary streams
by Russell Hind 26 Oct '04

26 Oct '04

There seems to be a problem on win32 where if you use a stream opened in text mode for a binary archive, you get errors. The following code asserts because 'd' appears to have a random value on the way back in. If you open both streams in binary mode then the code runs fine. XML archives don't have the same problem. I realise you shouldn't use a binary archive with a text stream, but is there anyway to catch this at compile or run time? Otherwise you just end up with a corrupted archive? Thanks Russell double d = -6.7; { ofstream ofs("C:\\test.dat"); archive::binary_oarchive oa(ofs); oa & d; } d = 0.0; { ifstream ifs("C:\\test.dat"); archive::binary_iarchive ia(ifs); ia & d; } assert(std::abs(d + 6.7) < 0.0001);

3 3

MSVC 6 usage of typename keyword
by christoph＠familie-koegl.de 26 Oct '04

26 Oct '04

Hi, sorry if this is a stupid question but I haven't found an answer in the mail archive. I can hardly believe that it hasn't been asked before. Everywhere in the boost libs I see code like namespace boost { // Just a simple "envelope" for non-type template parameters. Useful // to work around some MSVC deficiencies. template <typename T, T n> struct non_type { }; } The problem is the "typename T" part. MSVC 6 does not compile this, it wants "class T". How do I get around this MSVC deficiency (I have SP 5 installed, at least my admin says so)? Isn't there something like BOOST_TEMPLPAR_TYPENAME_KEYWORD that is defined to be equal to class for MSVC <= 6 (and maybe others) an equal to typename for able compilers? Cheers, Christoph

2 1

[variant] regressions in GCC 2.95 --seemingly an MPL-related problem
by Joaquín Mª López Muñoz 26 Oct '04

26 Oct '04

I think I've reduced the problem Boost.Variant is having with GCC 2.95 (see for instance http://tinyurl.com/4sd7u and http://tinyurl.com/4dqqd) The attached snippet works OK for GCC 3.2 and other compilers, but ICEs on GCC 2.95, with the same problem shown in Boost.Variant. The culprit has to do with transform (and other MPL algoritmhs) dealing with expressions of the form: apply1<lambda<sizeof_<_1> >::type,_1> wich AFAIK are correct (otherwise somebody please correct me.) In case it is not possible to fix this in the MPL, I think I can hack a specific workaround for GCC 2.95 into the code of Boost.Variant, but I guess trying to fix MPL first is more sensible. HTH Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 5

Thoughts on Unicode strings
by Daryle Walker 26 Oct '04

26 Oct '04

I think that there should be at most two _external_ Unicode string types: 1. vector of Unicode code-points externally each element is like a int32_t 2. vector of abstract Unicode characters externally each element is a group of Unicode code-points (a primary or starting code point, followed by combiner codes) Option [2] is what we ultimately want, so [1] should be included only if really needed. Internally, such strings could use UTF-8, UTF-16, etc., but most users don't care about that from an outside perspective. Some users do care about the outside appearance. (I think some guy here wanted UTF-8 XML.) In those cases we have a specific input or output routine that uses an appropriate encoding object, to hide whether or not the Unicode string internally uses the same encoding as the final source/sink. The internals of the Unicode string could use the cluster concept, like in Mac OS X's Cocoa. Here we would make concrete classes for UTF-8, UTF-16, UTF-32, etc. strings. (We could include normalization and other factors in combinations too.) The external class would keep a union (or something) that uses one of the concrete classes. Iterators probably should be made for code points and/or abstract characters. Bidirectional travel would be easiest. Such iterators should be configured (at compile- and/or run-time) for various normalization schemes. Input needs special handling, since we shouldn't allow ultimately invalid byte/code-point combinations into Unicode strings. We need something that can enumerate over a byte stream for a particular encoding and spit out whole code-points (or queue the code-points and spit out abstract characters). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

2 1

[serialization] and list<shared_ptr<const T> >
by Russell Hind 26 Oct '04

26 Oct '04

If I try and write a list<shared_ptr<const T> > to an archive, I get a compilation error. I'm guessing this is because the objects in the list are shared_ptr<const T> The documentation for const members says to use const_cast<T&>(t) but when you want to try and write a list, you can't do this unless you write all the objects manually. Is there a way for serialization to be able to handle the const implicitly (for containers at least)? Otherwise the only solutions I can see are - Don't use const objects - Write all elements of the list ourselves. Thanks Russell

2 2

[cvs] waiting for agurtovoy's lock in /cvsroot/boost/boost/boost/spirit/tree/impl
by Andreas Huber 26 Oct '04

26 Oct '04

I'm a bit of a CVS dummy so I can't tell whether the message in the subject is to be expected. Should I notify the sourceforge folks about a stale lock? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

2 2