November 2004 - Boost - lists.boost.org

[serialization] problem with Microsoft VC 7.1 and ADL
by Vyacheslav E. Andrejev 09 Nov '04

09 Nov '04

Hello All, Seriaization library relies on argument dependent lookup (ADL) in calling load and save functions in boost::serialization::free_loader::invoke and boost::serialization::free_saver::invoke accordingly. Library supposes that this feature works well in VC 7.1 (that is macro BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is undefined). But as I see, first, this supposition is implemented with error, and, second, ADL not always works very well in VC 7.1. Let's look to file /boost/serialization/split_free.hpp: namespace serialization { #if ! BOOST_WORKAROUND(BOOST_MSVC, <= 1300) template<class Archive, class T> void save(Archive &ar, const T & t, const unsigned int); template<class Archive, class T> void load(Archive &ar, T & t, const unsigned int); #endif ... Pay attention to "!" sign before BOOST_WORKAROUND. So, if VC version is 7.1 or higher, compiler expects that save and load would be defined in serialization namespace, if VC version is 7.0 or lower, compiler will search those namespaces from which Archive or T are originated. Very well. But let's take a look now to /boost/serialization/set.hpp for example: #ifdef BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP namespace boost { namespace serialization { #else namespace STD { #endif template<class Archive, class Key, class Compare, class Allocator > inline void save( Archive & ar, const STD::set<Key, Compare, Allocator> &t, const unsigned int /* file_version */ ){ ... } template<class Archive, class Key, class Compare, class Allocator > inline void load( Archive & ar, STD::set<Key, Compare, Allocator> &t, const unsigned int /* file_version */ ){ ... } In this file if BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is defined save and load will be defined in serialization namespace, otherwise in the std namespace. But BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is undefined for VC 7.1 (see /boost/config/compiler/visualc.hpp)! So in VC 7.1, accordingly to split_free.hpp, compiler expects save and load from serialization workspace, but they are defind in std accordingly to set.hpp (and all others stanard containers serialization files). By happy concourse of circumstances, this error is bypassed by errors in compiler and in most casses VC 7.1 compiles serialization library very well. But sometimes it accedentally rembers what ADL is and emits error during link stage that serialization::save and serialization::load are undefined. I suggest: 1) define BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP for VC 7.1 since as I can see Koening search technique implementation is unstable; 2) change "#if ! BOOST_WORKAROUND(BOOST_MSVC, <= 1300)" in split_free.hpp to "#if defined(BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP)". -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC

2 1

[filesystem]1.32/vc7.1: unresolved reference when building a user dll
by Francis ANDRE 09 Nov '04

09 Nov '04

Hi Developpers When using the dll version of the boost::filesystem library to build a user's dll library, one get the followin link error: (Note that no error is produced at link time when building a static non dll user's library with the boost::filesystem dll library) SYSOUT.obj : error LNK2019: unresolved external symbol "private: void __thiscall boost::filesystem::path::iterator::increment(void)" (?increment@iterator@path@filesystem@boost@@AAEXXZ) referenced in function "public: static void __cdecl boost::iterator_core_access::increment<class boost::filesystem::path::iterator>(class boost::filesystem::path::iterator &)" (??$increment@Viterator@path@filesystem@boost@@@iterator_core_access@boost@@ SAXAAViterator@path@filesystem@1@@Z) Any idea how to solve this unresolved reference?? The code involved in this build is: class __declspec(dllexport) SYSOUT : public OSDDIR { void makedir(const DATASET::VOLUME& volume, const std::string& file); }; void SYSOUT::makedir(const VOLUME& volume, const std::string& file) { path rel(file); path vol(volume); for (path::iterator i = rel.begin(); i != rel.end(); i++) { path dir = vol / *i; if (!boost::filesystem::exists(dir)) { create_directory(dir); } vol = vol / *i; } } Regards Francis ANDRE

2 1

Problem to use boost
by Daniel Lidström 09 Nov '04

09 Nov '04

Hi, this is what I've done: compiled with commandline of bjam "-sVC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7" "--prefix=C:\projects\boost" install Within my project, I've set an additional include path of C:\projects\boost\include\boost-1_31. Now when I compile my project with one source file containing the line #include <boost/shared_ptr.hpp> I get this error: c:\projects\boost\include\boost-1_31\boost\config\compiler\borland.hpp(1 3) : fatal error C1017: invalid integer constant expression What have I missed? -- Daniel

2 1

RE: [boost] Problem to use boost
by Michiel Salters 09 Nov '04

09 Nov '04

Are you really compiling with VC7.1, perhaps another MSVC version or are you using the borland compiler? I admit C1017 sounds like MSVC. Michiel Salters > -----Original Message----- > From: boost-bounces(a)lists.boost.org > [mailto:boost-bounces@lists.boost.org]On Behalf Of Daniel Lidström > Sent: dinsdag 9 november 2004 14:33 > To: 'boost(a)lists.boost.org' > Subject: [boost] Problem to use boost > > > Hi, > > this is what I've done: > compiled with commandline of > bjam "-sVC71_ROOT=C:\Program Files\Microsoft Visual Studio .NET > 2003\Vc7" > "--prefix=C:\projects\boost" install > > Within my project, I've set an additional include path of > C:\projects\boost\include\boost-1_31. Now when I compile my > project with > > one source file containing the line > > #include <boost/shared_ptr.hpp> > > I get this error: > > c:\projects\boost\include\boost-1_31\boost\config\compiler\bor > land.hpp(1 > 3) > : fatal error C1017: invalid integer constant expression > > What have I missed? > > -- > Daniel > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

1 0

Re: Re[4]: [boost] Re: Re: GUI Library Proposal for a Proposal
by Reece Dunn 09 Nov '04

09 Nov '04

Michael Walter wrote: >On Sat, 6 Nov 2004 13:12:14 +0000, Val Samko <boost(a)digiways.com> wrote: > > MW> On Fri, 5 Nov 2004 23:54:30 +0000, Val Samko <boost(a)digiways.com> >wrote: > > >> Once again, in geometry, vector and point are practically the same >thing. > > MW> Not really - you can only represent a point by its radius/position > > MW> vector wrt a given coordinate system. > > > > I thought we are only talking about Cartesian coordinates? Does anyone > > really need a gui library for radial coordinate system? :) >Apologies - I was apparently using the wrong term (not a native >English speaker), and was just seeing "the vector r from the origin to >the current position" on Mathworld. Googling a bit more it appears >that it is such a vector in a polar/spherical coordinate system only. > >The word I was looking for is "Ortsvektor" in German, the vector from >the origin to a certain point. What would be the proper word for that >in English (tried googling, failed :)? "Ort" means place, so it would be "place vector", or more likely "position vector". Is this what you mean? Using http://dictionary.reference.com/translate/text.html produces "radius vector". Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

3 2

RE: [boost] Re: logging lib, v1.3
by Kevin Cousins 09 Nov '04

09 Nov '04

Markus Schöpflin wrote" > John Torjo wrote: >> Finally, have had some time to update the logging lib. Get it from: >> http://www.torjo.com/ (of course, it comes packed with docs) > > Just a quick thought that came to my mind... > > Did you consider using the syntax 'BOOST_LOG(dbg, "message" << foobar);' > instead of 'BOOST_LOG(dbg) << "message" << foobar;'? > > While I think the syntax you use looks far nicer, we ususally need the > ability to be able to compile away the logging calls completely and this > only can be done with the first form. ...which introduces the potential for a problem with unintended multiple parameters to the macro function, a la: #define BOOST_LOG(x,y) ... BOOST_LOG(dbg, "message" << templated<1,2>::type() << foobar); // ^BANG! BOOST_LOG(dbg, "message" << ( templated<1,2>::type() ) << foobar); --Kevin. kevin.cousins(a)ir.com _____________________________________________________________________ This email is intended only for the use of the individual or entity named above and may contain information that is confidential and/or privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 9966 1066 and destroy the original message. Thank You _______________________________________________________________________

1 0

library-based property implementation
by Reece Dunn 09 Nov '04

09 Nov '04

Hi All, I have been working on an implementation of a library that allows you to define properties, based on the wg21 N1615 paper by Lois Goldthwaite. The code is committed to the sandbox (under the property directory) with tests and preliminary documentation. I have seperated the properties into two. The boilerplate code for operator overloads, organised by rank, where rank is the number of indices (the term is borrowed from Tensor algebra) provides one group. The other group is the property storage that implements the get and set functions that the boilerplate classes use to implement the operator overloads. : Scalar Properties A scalar property is a single-element property. You can have simple properties that either store their values internally or reference an external data member: class object { int val; public: scalar_property< aliased_property< int > > Val; object(): Val( val ){} }; int main() { scalar_property< value_property< int > > ival( 0 ); ival = 7; ival += 3; int j; scalar_property< aliased_property< int > > jval( j ); jval = 2; assert( j == 2 ); } You can also define more complex properties that use class methods to control them: class object { int val; public: int get_Val() const{ return val; } void set_Val( const int & v ){ val = v; } scalar_property< object_property < int, object, &object::get_Val, &object::set_Val > > Val; object(): Val( this ){} }; : Rank 1 Properties A rank 1 property is a 1-dimensional property. For example: class result_set { public: // property record index[]; record get_record( int i ) const; void set_record( int i, record r ); boost::rank1_property< boost::rank1_object_property < record, int, result_set, &result_set::get_record, &result_set::set_record > > record; public: result_set(): record( this ) { } }; Regards, Reece

2 2

[1.32] [function] documentation missing
by Caleb Epstein 08 Nov '04

08 Nov '04

In the release candidate tarballs, the documentation for the "function" library is redirecting to http://www.boost.org/regression-logs/cs-win32_metacomm/doc/html/function.ht… It looks like the Boost.Book documentation isn't being generated for this library. Is this expected? -- Caleb Epstein caleb.epstein(a)gmail.com

2 1

Re: [boost] GUI Library Proposal for a Proposal
by George van den Driessche 08 Nov '04

08 Nov '04

> Message: 2 > Date: Mon, 08 Nov 2004 10:42:21 -0500 > From: Beman Dawes <bdawes(a)acm.org> > Subject: Re: [boost] GUI Library Proposal for a Proposal) > To: boost(a)lists.boost.org, boost(a)lists.boost.org > Message-ID: <6.0.3.0.2.20041108102747.0272bec0(a)mailhost.esva.net> > Content-Type: text/plain; charset="us-ascii"; format=flowed > > At 07:38 PM 11/7/2004, George van den Driessche wrote: [snip] > >So what do you stand to gain, other than being able to write GUIs in > >your favourite language, as opposed to your second-favourite language? > >The only thing I can think of is that you don't have to worry about any > >bridge between languages. > > What you say makes a lot of sense if just you is involved. Or perhaps a > small enough group that they can all agree on the second-favorite language. > > But in larger organizations that approach results in a proliferation of > languages. I know of a company that has let programmers write code in any > language they like. The result is a nightmare. Over a dozen languages are > in common use. The toolchains on some projects are so convoluted that the > projects cannot be moved between the several operating systems in use at > the company. Programmers cannot freely move to another project because they > often don't know all the languages that are required. It is a serious mess. > > Thus the use of C++ as a GUI language may be sub-optimal as far as the > small picture goes, but could be a really smart move in terms of the big > picture. That's a convincing point. I'm glad it's a convincing point, because I like C++ :) Only, sometimes I wonder whether we're all so obsessed with the language that we can't stand back and realise that some other language is appropriate for a given task. Makes me think: if there was some language that easily spanned the range from static to dynamic code, then everyone could learn that and that only. Never mind... > Because what we are talking about is a library, rather than something in > the core language, non-users of the library don't pay for something they > don't use. As long as a C++ GUI library is useful to a significant number > of people it doesn't matter if lots of others choose a dual language > approach. True. Personally, I quite like the thinking behind Win32GUI, and I've been wondering about the viability of porting it to run on top of Carbon on OSX. I just needed a bit of persuasion that it's worth pursuing at all. I'm not sure how far the event handling systems can be aligned, but I'm certainly going to look into it. If it works, it'll need a different name :) George

2 1

const_string + recursive_variant = boom
by Caleb Epstein 08 Nov '04

08 Nov '04

I've been trying to build a generic "message" type class using boost.variant and have just run across a problem when trying to convert it from using std::string to using the proposed boost::const_string. Attached is a small test case and the output from gcc 3.3.2 (the latter gzipped due to its hugeness). All is well if the mystring type is std::string. Any thoughts on how to fix this? -- Caleb Epstein caleb.epstein(a)gmail.com

6 9