- Boost - lists.boost.org

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

intrusive_ptr explicit constructor
by Colin Rafferty 25 Oct '04

25 Oct '04

Hi- Shouldn't the constructor in intrusive_ptr be explicit? explicit intrusive_ptr(T * p, bool add_ref = true): p_(p) { if(p_ != 0 && add_ref) intrusive_ptr_add_ref(p_); } I don't have cvs access. -- Colin

4 7

[assign] typo
by Jonathan Turkanis 25 Oct '04

25 Oct '04

Dear Thorsten, It was good to meet you finally last week. I'm reading through the assign docs and there seem to be some misplaced parentheses in the definition of names2 in the preformatted section following the heading "Function list_of()". I think it should say const stack<string> names2 = list_of( "Mr. Foo", "Mr. Bar", "Mrs. FooBar" ).to_adapter(); Best Regards, Jonathan

2 2

[contacting Jeremy B. Maitin-Shepard]
by Thorsten Ottosen 25 Oct '04

25 Oct '04

Dear All, I have troubles getting in contact with Jeremy and I want to discuss some hash-table stuff with him. Does anyone know his email? br Thorsten

1 0

[serialize] xml archives and base 64 encoded binary data
by Russell Hind 25 Oct '04

25 Oct '04

Hi, I'm writing some binary data to an xml_oarchive (a vector of floats). I'm then giving the xml files to some python uses we have here so they can read them in. They had trouble with the base64 encoding of the binary data. One has mentioned that base64 spec says an '=' must be appended to the data to indicate the padding up to the next 4-byte multiple. When they added an '=' to the data between the tags in the resultant xml file, they could decode it successfully. If it is in the spec (am trying to find a link to check this), can the the base64 encoding in serialize be modified to do this before the 1.32.0 release, so it conforms to the standard? Thanks Russell

4 14

[patch] [filesystem] Get rid of a 'uninitialized' warning
by larsbj＠gullik.net 25 Oct '04

25 Oct '04

This patch make a warning on gcc about uninitialized variable go away. Please apply to branch and main trunk. -- Lgb

2 1