December 2005 - Boost-users

Re: [Boost-users] crc.hpp and visual studio run time checking
by Clarke, Trevor 16 Dec '05

16 Dec '05

The problem is that the code does not state that it doesn't care if those bits disappear (via masking) so a warning is thrown stating that you are loosing data. Similar to compiler warnings if you do this: int foo(123456789); char bar = foo; // instead of bar = static_cast<char>(foo); The difference is, the masking warning is a run time check which pops up a dialog every time the code executes and is thus not as easy to ignore as the compile warning. ------------------------------ Trevor R.H. Clarke tclarke at ball com Ball Aerospace & Technologies Corp -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Daryle Walker Sent: Friday, December 16, 2005 12:38 PM To: Boost Users mailing list Subject: Re: [Boost-users] crc.hpp and visual studio run time checking On 12/14/05 2:32 PM, "Clarke, Trevor" <tclarke(a)ball.com> wrote: > There are a few places in crc.hpp where the following happens: > static value_type shift( value_type rem ) > { return rem << CHAR_BIT; } > > The problem is, if run time checking is active in VS2003 (I assume 2005 has > the same issue), a pop-up warning is issued during every call to the function > as data is lost. (that¹s the intent in fact). The fix is to mask (rem << > CHAR_BIT) & 0xffff (or whatever the appropriate mask value is for > value_type). Is this a known issue? It¹s technically not a bug but could cause > some annoyances for anybody using rtc. Should this be changed? What's the point of the mask? The affected bits have already gone to oblivion at that point. Maybe RTC has a bug? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

crc.hpp and visual studio run time checking
by Clarke, Trevor 16 Dec '05

16 Dec '05

There are a few places in crc.hpp where the following happens: static value_type shift( value_type rem ) { return rem << CHAR_BIT; } The problem is, if run time checking is active in VS2003 (I assume 2005 has the same issue), a pop-up warning is issued during every call to the function as data is lost. (that's the intent in fact). The fix is to mask (rem << CHAR_BIT) & 0xffff (or whatever the appropriate mask value is for value_type). Is this a known issue? It's technically not a bug but could cause some annoyances for anybody using rtc. Should this be changed? ------------------------------ Trevor R.H. Clarke tclarke at ball com <mailto:tclarke@ball.com> Ball Aerospace & Technologies Corp

2 1

Re: [Boost-users] Boost binary serialization & AMD64
by Robert Ramey 16 Dec '05

16 Dec '05

There might be differences in size of certain types like std::size_t or others. Robert Ramey Leon Mergen wrote: > Hello, > > I'm currently having problems using serializations that were stored > binary on an x86 and loading them on an amd64. Anyone knows whether > there are any compatibility issues between those architectures and > storing things binary ? > > Thanks in advance. > > Regards, > > Leon Mergen

4 4

Re: [Boost-users] Boost binary serialization & AMD64
by Robert Ramey 16 Dec '05

16 Dec '05

The system includes text and xml archives which are portable. Also included are native binary archives which are not portable accross platforms. There is an example of a portable binary archive. It is incomplete in that doesn't include code for floating point number. Another difficulty in making a good implementation of this is the lack of portable method of detecting and re-creating different kinds of nan's So you're in new territory here. Good Luck Robert Ramey Leon Mergen wrote: > On Thu, 2005-12-15 at 18:12 -0800, Robert Ramey wrote: >> There might be differences in size of certain types like std::size_t >> or others. > > Ok, and I assume if I would want to make the x86 data files readable > on an amd64 architecture, I would have to write my own conversion > utility, or simply start switching over to textual storage ? > > As in, there's no such thing provided by Boost.org ? > > Regards, > > Leon Mergen

1 0

[serialization] Transactional persistence ?
by Buster 16 Dec '05

16 Dec '05

I'm looking for an STL-like library that would let me do something like the following: tp::database data; tp::map<int, string> map1(data); tp::list<float> list1(data); ... tp::transaction t; map1.start_transaction(t); list1.start_transaction(t); map1[5] = "hello"; // does NOT commit to container or database list1.push_back(1.0); // does NOT commit either t.commit(); // Finally commits to container and database. // Without this call, t would call rollback // in destructor. Does anyone know of such a library ? If not, I guess I'll have to do some writing. If I do write it, it seems that using boost serialization would save a lot of the work. But I've looked at it and it seems to be missing a couple things I need. For one, it seems to require that you serialize the entire container each time you change one element. Perhaps I'm wrong ? The other problem is that I don't see anything related to transactions within the library. This may even prevent me from using the library to implement the actual serialization of each element, as I wouldn't be able to gurantee that the data was NOT written. Unless one can hook up transactional archives to boost serialization ? Any advice or pointers would be greatly appreciated.

4 4

Pb. dynamic_bitset under xlC v6 (Aix)
by thierry.lartigue＠bnf.fr 16 Dec '05

16 Dec '05

C for AIX Compiler, Version 6 I compile example1.cpp (/usr/local/boost/boost_1_33_0/libs/dynamic_bitset/example) and I have errors : xlC -o example1 example1.cpp -I/usr/local/boost/boost_1_33_0 -L /usr/local/boost/boost_1_33_0/lib -lboost_regex-xlc-1_33 ld : 0711-317 ERREUR : Symbole non défini : boost::dynamic_bitset<unsigned long,std::allocator<unsigned long> >::ulong_width ld : 0711-317 ERREUR : Symbole non défini : boost::dynamic_bitset<unsigned long,std::allocator<unsigned long> >::bits_per_block ld : 0711-345 Pour plus de détails, utilisez l'option -bloadmap ou -bnoquiet. Why? Thierry L.

2 2

Re: [Boost-users] Compiling Archive Output Code
by Merrill Cornish 16 Dec '05

16 Dec '05

Robert, Thanks for the pointer. I finally got it working--after a couple of false starts, whic bring me to the subject of this message. :-) I don't know if you've noticed, but those deceptively simple macros can cause problems in applications that use their own namespace. For example, BOOST_IS_ABSTRACT(<class_name>) expands into two nested namespace declarations enclosing the code that gets expanded. So, if this macro is placed inside of the application's declared namespace block, then the application's namespace gets prepended to the boost namespace, making the code fail. If you then move BOOST_IS_ABSTRACT() out of the application's namespace block, the expanded code works, but now it claims it never heard of <class_name>, since its no longer automatically picking up the application's namespace. The documentation for BOOST_IS_ABSTRACT() needs to be changed to warn that it must be used ONLY at the global, default namespace level and that the <class_name> needs to include any application namespace. On the other hand... The BOOST_SERIALIZATION_BASE_OBJECT_NVP(<name>) macro expands into a single function call with the boost namespaces prepended to the function name. This means that this macro can be used anywhere regardless of any enclosing application namespace block--but now the class name has the wrong namespace. Even if the macro were used inside the application's namespace block, the class name argument is quietly put in the boost namespace, where it isn't known. So, again, the class name must have the application's namespace explicitly prepended--even though it's inside the application's namespace block. It would be nice if these macro all behaved the same in the presence of an application namespace. And, you should warn to always explictly state the applicaiton namespace, if any, on class name arguments--but not method names. Merrill

1 0

[BGL] Visitor in dijkstra_shortest_paths
by Johan Oudinet 16 Dec '05

16 Dec '05

Hi, I want to modify the dijkstra behavior such as it doesn't consider special vertices. I think to create a visitor so when the examine_edge(u,v) method is called, I check if the vertex v can be considered (i.e, its property "trust" is true), if not, I want to skip the examination (and so the relaxation too). But, I don't know how to do this "skip". example: -=-=-=-=-=-=-=-=-=-=-=- DIJKSTRA (G, s, w) // initialization ... INSERT(Q, s) discover_vertex(s) while (Q != 0) u <- EXTRACT-MIN (Q) S <- S U {u} for each v in Adj[u] examine_edge(u,v) // what I would like to do: // if (not G[v].trust) continue; // thus, the next operations are skipped. if (w(u,v) + d[u] < d[v]) // edge (u,v) is relaxated ... end for finish_vertex(u) end while -=-=-=-=-=-=-=-=-=-=-=- Have you got an idea how I can do this ? Regards, -- Johan

1 1

boost::filesystem::copy_file hate '#'?
by LI Daobing 16 Dec '05

16 Dec '05

Hello, I use Debian/Linux and libboost-filesystem-dev(1.33.0-5), and I meet the following problem, I want to know whether it is bug or my mistake, please help me, thanks. See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343491 $ cat copy_file.cpp #include <boost/filesystem/operations.hpp> using namespace boost::filesystem; int main() { copy_file("bad", "#"); return 0; } $ g++ -o copy_file copy_file.cpp -lboost_filesystem $ touch bad $ ls -l bad -rw-r--r-- 1 nichloas nichloas 0 2005-12-16 00:33 bad $ ./copy_file terminate called after throwing an instance of 'boost::filesystem::filesystem_error' what(): boost::filesystem::path: invalid name "#" in path: "#" Aborted $ g++ -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5) $ -- LI Daobing

2 1

Documentation Typo
by Merrill Cornish 16 Dec '05

16 Dec '05

On page http://www.boost.org/libs/serialization/doc/index.html, a bullet under "polymorphic Archives"/"Motovation" starts: * If seriaiization code is placed in a library,... Note the ii. Merrill

1 0