- Boost-users - lists.preview.boost.org

Re: [Boost-users] boost::serialisation -Non-default Constructors
by Merrill Cornish 28 Jan '06

28 Jan '06

Yes. Each class you want to serialize needs a default constructor in addition to whatever other constructors your application needs. Merrill

2 1

::spirit, token_node_d
by elviin 28 Jan '06

28 Jan '06

Before I'll investigate more I'd like to know if anybody knows why it is not allowed a rule object inside this directive: token_node_d.

2 2

[statechart] Ready for addition to main CVS
by Andreas Huber 28 Jan '06

28 Jan '06

Dear Boosters I believe I have addressed all the important issues that were reported during formal review of the Boost.Statechart library (then proposed as boost::fsm). Although there's still a lot to do, I think that the current version is stable enough to be added to the main CVS. All reviewers (and anyone else interested) are invited to verify that the issues that have been put forth have been taken care of appropriately: http://boost-sandbox.sf.net/libs/statechart Given Thomas Witt's cutoff date for additions of new libraries (February 8th) and the roughly one week needed to move the statechart directories from the sandbox CVS to the main CVS (can only be done by source forge staff), I must ask people to come forward with their questions/concerns before February 1st. Should anyone need more time, please let me know immediately by following up to this post. Thanks & Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

[graph] non-contiguous edges?
by Roman Schindlauer 28 Jan '06

28 Jan '06

Hello, Warning ahead - this is a newbie question. I need to find weak and strong components of a graph. So far, my code is as simple as it could be (edges being a std::vector of std::pair<unsigned,unsigned>): typedef adjacency_list <vecS, vecS, undirectedS> Graph; Graph G; for (Edges::const_iterator ei = edges.begin(); ei != edges.end();++ei) add_edge((*ei).first, (*ei).second, G); std::vector<int> component(num_vertices(G)); int num = connected_components(G, &component[0]); However, my vertices are not contiguously numbered. Hence, the following edges (8, 9) (9, 10) (12, 13) result in these connected components: 0: 0 1: 1 2: 2 3: 3 4: 4 5: 5 6: 6 7: 7 8: 8, 9, 10 9: 11 10: 12, 13 which is not what I want (just two wcc: 8, 9, 10 and 12, 13). I was reading into the property_map stuff, but as far as i understand, that would not help here. Do I have to remap the indices beforehand or is there a way to convince Boost that there are no other nodes than those in the edges? Best regards, Roman

1 0

Warnings and boost
by gast128 27 Jan '06

27 Jan '06

Dear all, Our company makes heavy use of boost libraries. But unfornately some libraries trigger warnings. This is hard to circumvent since we both have level 4 and warnings as error option enabled in Visual Studio 2003. An example is the counting iterator: const std::vector<int> values1(boost::make_counting_iterator(1), boost::make_counting_iterator(10)); gives C4244. This is even harder to supress since the STL is included in the precompiled header. Is it an option to have a good look at this issue for the next release? Note that it is also possible that Plauger's STL is not conforming. Wkr, me

5 5

Spawning a thread on a member function
by Sliwa, Przemyslaw (London) 27 Jan '06

27 Jan '06

All, Does anyone know how to spawn a thread on member function of an existing object in its constructor. Clearly simple boost::bind does not work. I do not know how to tell the compiler it must take the member function. Thanks for help, Pshemek Kind regards Pshemek Przemyslaw Sliwa Global Foreign Exchange FX Risk Engine Development Merrill Lynch ( +44 (0)20 7995 4182 ) +44 (0)79 6325 2319 * Email: przemyslaw_sliwa(a)ml.com -------------------------------------------------------- If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/ --------------------------------------------------------

4 5

Declaration Terminated Incorrectly
by Deepak Singh 27 Jan '06

27 Jan '06

Hello; I am using Borland C++ 6 Evaluaion Version for making dll. Can You help me out from this error. /*Voice.h*/ //#include "CFeatureMatrix.h" //#include "CVoiceInterface.h" //#include "CVoicePrint.h" BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fwdreason, LPVOID lpvReserved) { return 1; } When I compile to make dll I get "stddef.h:Declaration terminated incorrectly" error and second line shows "stddef.h:Qualifier 'std' is not a class or namespace name". If I remove Comment for including the header file I get "Voice.h:Declaration terminated incorrectly" /*Voice.h*/ #include "CFeatureMatrix.h" #include "CVoiceInterface.h" #include "CVoicePrint.h" BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fwdreason, LPVOID lpvReserved) { return 1; } Regards Deepak ********************************************************* Disclaimer: The contents of this E-mail (including the contents of the enclosure(s) or attachment(s) if any) are privileged and confidential material of MBT and should not be disclosed to, used by or copied in any manner by anyone other than the intended addressee(s). In case you are not the desired addressee, you should delete this message and/or re-direct it to the sender. The views expressed in this E-mail message (including the enclosure(s) or attachment(s) if any) are those of the individual sender, except where the sender expressly, and with authority, states them to be the views of MBT. This e-mail message including attachment/(s), if any, is believed to be free of any virus. However, it is the responsibility of the recipient to ensure that it is virus free and MBT is not responsible for any loss or damage arising in any way from its use ********************************************************

2 1

[lambda] Nesting and temporaries
by EMalenfant＠interstarinc.com 27 Jan '06

27 Jan '06

Hello, Given the following: std::string Cat(const std::string& First, const std::string& Second) { return First + Second; } void Print(const char* S) { std::cout << S << std::endl; } std::string foo("foo"); std::string bar("bar"); The novice Lambda user that I am would have thought that this: using namespace boost::lambda; bind(Print, bind(&std::string::c_str, bind(Cat, _1, _2) ) )(foo, bar); would be roughly equivalent to: Print(Cat(foo, bar).c_str()); But it seems to behave more like: const char* ptr_to_temp = Cat(foo, bar).c_str(); Print(ptr_to_temp); and invokes undefined behavior. This workaround seems to work: var_type<std::string>::type temp(var(std::string())); ( temp = bind(Cat, _1, _2), bind(Print, bind(&std::string::c_str, temp)) ) (foo, bar); this one too: var_type<std::string>::type temp(var(std::string())); bind(Print, bind(&std::string::c_str, (temp = bind(Cat, _1, _2)) ) ) (foo, bar); Could someone comment on this? Are these workarounds correct? Is one better than the other? Is there another solution? Thanks, ----------------------------- Éric Malenfant A conclusion is the place where you got tired of thinking

1 0

boost::iostream - returning EOF in device::write and set failbit
by Oliver.Kowalke＠infineon.com 27 Jan '06

27 Jan '06

Hello, would the eofbit be set if I return EOF in device::write? How can I set failbit from device? Regards, Oliver

2 1

Re: [Boost-users] Version Mgmt classes/algorithms
by Rich Johnson 27 Jan '06

27 Jan '06

On Jan 26, 2006, at 11:58 AM, Noel Yap wrote: > Hmm, I've been thinking about this problem but from a different > perspective. > > First, some definitions: > - patch release: the new component is link and load compatible with > the old one; clients might need to relink or reload > - minor release: the new component is compile compatible with the old > one; clients might need to recompile > - major release: the new component isn't compatible with the old one; > clients might need to modify code > > Given the above, a mapping can be made of changes to source to one of > the above. I suppose if a component developer follows the above, one > could write a class that could easily figure out whether or not a > certain M.m.p update is backwards compatible with another. > > Also, what really counts are changes to header files. More > specifically, changes to published header files (ie header files that > are installed so as to be usable by other components). I LIKE the crispness of your functional definitions. They suggest that there may exist an algorithm determining the ''order'' of a change: - Any change in the interface base class is _at least_ a minor release. - Any change in an implementation derived class is _at most_ a patch release. - Any change in the semantics of the base class interface is _at least_ a major release. - Version stamp can probably be generated by configuration control (i.e. CVS); - Version stamp can probably be used as a _signature_ of the module's interface. FWIW, a "compiler compatibility" is probably required when dealing with separately compiled modules. Applying the definitions to dynamically loaded libraries where we're _always_ relinking; we come up with: - if patch release; accept - if minor release; reject (you _might_ scoot by with some changes; but why risk it?) - if major release; reject - if compiler incompatible; reject (of course). Dynamically loaded modules could supply a ''well known'' C function to access their version stamp (or otherwise determine compatibility) prior to instantiating any dynamically allocated objects. Now you've got me thinking.... --rich

3 3