- Boost - lists.boost.org

Compiling Boost 1.36.0 for Itanium - Bug
by Amit Sonawane 08 Dec '08

08 Dec '08

>Environment: >WinXP SP2/Visual Studio Team System 2005/Itanium cross compiler tools >1 . Generate boost libs using Itanium cross compiler command prompt with these options bjam -a --build-type=complete --toolset=msvc >architecture=ia64 --stagedir=Winia64 stage >2. Compiling under Itanium configuration in VS2005 generates several linker errors: >error LNK2019: unresolved external symbol ._interlockedbittestandset referenced in function "[Entry] bool __cdecl >boost::detail::win32::interlocked_bit_test_and_set(long *,long)" (.?interlocked_bit_test_and_set@win32@detail@boost@@YA_NPEAJJ@Z) >error LNK2001: unresolved external symbol ._interlockedbittestandset >libboost_thread-vc80-mt-1_36.lib(thread.obj) : error LNK2001: unresolved external symbol ._interlockedbittestandset >3.The projects compile fine under x86 and x64. _interlockbittestandset is not intrinsic on Itanium platform This sounds like an issue with Boost code itself. Your might want to either post to boost-devel, or file a bug at svn.boost.org - Volodya Esta mensagem pode conter informação confidencial e/ou privilegiada. Se você não for o destinatário ou a pessoa autorizada a receber esta mensagem, não deverá utilizar, copiar, alterar, divulgar a informação nela contida ou tomar qualquer ação baseada nessas informações. Se você recebeu esta mensagem por engano, por favor avise imediatamente o remetente, respondendo o e-mail e em seguida apague-o. Agradecemos sua cooperação. This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, change, take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation.

1 0

Excellent factory style design pattern implementation
by Michael Goldshteyn 07 Dec '08

07 Dec '08

I thought that everyone might be interested in the following which basically creates a Boost-Centric Factory-Pattern Implementation, including: Factory Abstract Factory Prototype Here is a link to the article and the actual code: http://arcticinteractive.com/2008/10/06/boost-centric-factory-pattern-imple… I was very impressed with the work and am almost wondering if this is ready for a review and inclusion into Boost proper. Thanks, Michael Goldshteyn

6 7

a invites you to join Zorpia
by a 07 Dec '08

07 Dec '08

Hi boost! Your friend a from , just invited you to his online photo albums and journals at Zorpia.com. So what is Zorpia? It is an online community that allows you to upload unlimited amount of photos, write journals and make friends. We also have a variety of skins in store for you so that you can customize your homepage freely. Join now for free! Please click the following link to join Zorpia: http://me.signup.zorpia.com/signup?invitation_key=20081054ec30c646c05fcf5cc… This message was delivered with the a's initiation. If you wish to discontinue receiving invitations from us, please click the following link: http://me.signup.zorpia.com/email/optout/boost@lists.boost.org

1 0

Boost-docs moderation
by Vladimir Prus 07 Dec '08

07 Dec '08

Who's in charge of moderating boost-docs mailing list? I've posted a few messages already that are reported to be sent to moderation queue, and did not appear yet. Direct mail to boost-docs-owner(a)lists.boost.org appear to have no effect either. Thanks, Volodya

2 2

[constrained_value] default initialization
by Jeff Flinn 07 Dec '08

07 Dec '08

I couldn't find mention of what is the initial value of bounded_int<int, 123, 456>::type some_var; I assume it follows the rules for an int? The Simple constrained objects examples says the following is legal: even_int a; What about: odd_int b; Thanks, Jeff

2 1

Re: [boost] [Boost-users] [review][constrained_value] Review of ConstrainedValue Library begins today
by Robert Kawulak 07 Dec '08

07 Dec '08

> From: Neal Becker > There is confusion over bounded vs. bounded_int. Maybe > rename bounded_int to compile_time_bounded, or static_bounded. I'm not against changing the name if something better than bounded_int is proposed. However, compile_time_bounded is longish and may be interpreted as checking the bounds at compile time, while static_bounded may suggest that some static members are involved. What do others think?

1 0

[Serialize] error 'unable to start program' with demo.cpp compiled in debug mode under msvc7.1
by David Körner 07 Dec '08

07 Dec '08

Hi, when I compile the demo.cpp from the boost.serialize tutorial in release mode everything works fine. But when I compile it in debug mode the application wont start and the error 'unable to start program' is displayed. It further says that the application has failed to start because the configuration is incorrect. When I change something and do a recompile - the compiler fails: 'unable to update manifest. wrong parameter'. I then have to do a clean+rebuild and it compiles again but wont run until I comment out every boost.serialize code. I use MSVC7.1 (VS2005). I already have used the serialize library with boost version 1.34 successfully. Can someone help me with that issue? Has anybody experienced similar problems? Any help or hint would be appreciated. Thank you very much in advance. David _________________________________________________________________ Wer erfand den Glückskeks? Kleiner Tipp: Die Chinesen waren es nicht! - Mehr auf msn.de http://redirect.gimas.net/?n=M0812xMSNDE

3 3

Re: [boost] [UUID] Code for UUIDs as PODs and other changes
by Vladimir Batov 07 Dec '08

07 Dec '08

Scott, Many thanks for your crash-course on aggregates and your patence with me. Much and truly appreciated. I had to dig the Standard up for a "refreshment". It's embarassing but I admit I all forgot about that "C" stuff tucked away in a corner of C++. I never thought I'd come across it ever again. Kudos to you for your effort. I am coming to appreciate your implementation. It's very impressive how efficiently you managed to cut off "all the excess" and how far you've got without C++ "perks and whistles". I am sure it had its uses. That said, I feel aggregates' limitations are far too restrictive for a full-fledged implementation (and especially the interface). Best, Vladimir. > ... > It comes from making it a POD, as all PODs are also aggregates. > > 8.5.1 Aggregates [dcl.init.aggr] > > An aggregate is an array or a class (clause 9) with no user-declared > constructors (12.1), no private or protected non-static data members > (clause 11), no base classes (clause 10), and no virtual functions > (10.3). When an aggregate is initialized the initializer can contain > an initializer-clause consisting of a brace-enclosed, comma-separated > list of initializer-clauses for the members of the aggregate, written > in increasing subscript or member order. If the aggregate contains > subaggregates, this rule applies recursively to the members of the > subaggregate.

1 0

Re: [boost] [UUID] Code for UUIDs as PODs and other changes
by Vladimir Batov 07 Dec '08

07 Dec '08

... > >> uuid u = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */ > >> 0x6b, 0xa7, 0xb8, 0x14, > >> 0x9d, 0xad, > >> 0x11, 0xd1, > >> 0x80, 0xb4, > >> 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 > >> }; > > > > I am not sure as a user I'd be interested in doing that kind of low-level stuff and in fact I am doubtful it'll even compile. > > > > It does work, actually. I use it to implement > uuids::namespaces::dns() and friends. It compiles indeed! Tried MSVC++9 and even ol' gcc 3.4.4. C++0X talks about initialization of that kind but for standard containers. To me it feels like very non-standard behavior. What am I missing? Someone help me out here. > 4.1.7. Nil UUID > > The nil UUID is special form of UUID that is specified to have all > 128 bits set to zero. > > I'm not particularly attached to nil(), but at the same time, I don't > have any better name. I dislike null(), when people are used to > treating NULL as pointer (even when it actually isn't). C# uses > Empty, but that's also not great, since empty is strongly entrenched > through its use in the Container concept. Fair enough. The standard expicitly mentioning uuid::nil() sounds like a good reason. > Really, I'd be plenty happy to get rid of it entirely, since value > initialization provides the same functionality: uuid id = uuid(); Have to disagree as to me the above is unclear as I am not sure if it means "create a new uuid" or "create an invalid uuid". I prefer saying clearly what I mean, i.e. uuid id(uuid::nil()); Best, Vladimir.

2 1

Re: [boost] [UUID] Code for UUIDs as PODs and other changes
by Vladimir Batov 07 Dec '08

07 Dec '08

> PODness: I am personally far from thrilled and fail to see benefits of that move. > As a POD, all the constructors are of course gone. Well, "constructors are of course *not* gone" as the default and copy constructors will be generated for you. The auto-generated default constructor does not seem to initialize the underlying boost::array to anything. Therefore, I suspect "uuid id;" will be left uninitialized. > ... > I don't think that serialization to and from strings > belongs in the type, and it seems like using a lexical_cast is > perfectly reasonable: Yes, taking out the conversions to/from string certainly make the UUID-related code/interface cleaner. More so, IMHO lexical_cast has become somewhat idiomatic for that kind of tasks and provides the well-defined and well-known path to enable the functionality. Much preferred. > ... > I don't know if it's useful, but aggregate syntax also opens > possibilities: > > uuid u = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */ > 0x6b, 0xa7, 0xb8, 0x14, > 0x9d, 0xad, > 0x11, 0xd1, > 0x80, 0xb4, > 0x00, 0xc0, 0x4f, 0xd4, 0x30, 0xc8 > }; I am not sure as a user I'd be interested in doing that kind of low-level stuff and in fact I am doubtful it'll even compile. I see nil() introduced in the code with "As named in RFC 4112, 4.1.7" comment. I tried googling for "RFC 4112" and it gave me "RFC4112 - Electronic Commerce Modeling Language (ECML) Version" with no "nil" mentioned. I have no issues with "nil" pre se as it's well-entrenched in other languages. However, I feel that C/C++ settled on "null" (and C++ 0x introduces nullptr). So, I fail to see any reasons to deviate from that. >> ... the rest snipped. I see a lot of code cleanup, reorganization and reshuffling. Everything has its place and time. Even though I agree that at some point it needs to be done, I do not feel we've reached that point. I'd much prefer to focus on providing well-thought-through interface. Without having agreed on the interface and settling on what and how certain functionality is delivered to the user I feel that "implementation-detail" discussions seem premature and in fact distracting at this point. Best, Vladimir.

2 1