- Boost-users - lists.boost.org

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

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

27 Jan '06

> > For what it's worth, we use namespaces to do version management and > this works quite well for us. This technique may not work for you > but a brief description of it is in Stroustrup's D&E in section > 17.4.4 (Using Namespaces to Manage Releases). We've done a lot of > work in this area, just not sure if it's what you're interested in. Hmm...I'll have to take a look. Do you do use it with dynamically loaded modules--dlopen(), dlsym(), etc.?

2 1

boost::serialisation - portable_binary_oarchive not part of library
by Oliver.Kowalke＠infineon.com 27 Jan '06

27 Jan '06

Hallo, why is portable_binary_oarchive and portable_binary_iarchive only contained in the examples not part of the library interface? Regards, Oliver

2 1

Boost threads- how do I simultaneously check the lock on two or more mutexes?
by Terence Wilson 26 Jan '06

26 Jan '06

boost::try_mutex M1, M2; boost::try_mutex::scoped_try_lock lockx(M1, false); boost::try_mutex::scoped_try_lock locky(M2, false); I would like to be able to atomically check that at least one lock can be made: assert(lockx.try_lock() || locky.try_lock()); In Win32 I would use WaitForMultipleObjects. Thanks in advance.

1 0

Comments on the usability of program_options
by Steve Byan 26 Jan '06

26 Jan '06

First let me mention that I greatly appreciate all the work done by the contributors to Boost. The library has been extremely helpful to me both as a class and template library and as a learning tool for template meta-programming. In the spirit of constructive criticism, I'd like to offer a few usability observations arising from my first attempt to use program_options. I appreciate the flexibility, extensive feature set, and the extensibility of the library. I particularly like the unification of command-line options with configuration files; this is a very handy feature. However, I think the unification of program arguments with program options is less successful. I think the library would be better if arguments were a separate concept. Unifying program arguments with program options has these consequences: 1) The error message produced by an excessive number of arguments is opaque to most users. The error message produced is "Error: unknown option foo", which I think would be better phrased as something along the lines of "Error: too many arguments". Since program_options doesn't distinguish options from arguments, it can't easily produce a better diagnostic message. 2) The usage description by default describes command-line arguments as options. E.g. the usage message is something like this: Supported options: -h [ --help ] produce this help message --device-file arg scsi pass-thru device special file To hide the "argument options" in the help message, program_options supports multiple options_descriptions, but puts the responsibility for hiding the "argument options" on the user of the library, and, unlike normal options, does not automatically provide a description of the argument in the help message. If arguments were instead treated as first-class concept instead of a mutant form of an option, the library could automatically handle these issues. 3) Somewhat related to issue #2, program_options doesn't generate a concise usage description help-message from the grammar. For example, it would be nice if options_desciption could provide a string like this: Usage: scsi_tool [-h | --help] [-v | --verbose] <device-file> [<output-file>] Additionally, it would be nice if program_options handled more of the validation and error reporting. Currently the user is responsible for checking for required arguments and generating an error if they are not supplied, and for coding the generation of a usage message when the options and arguments don't conform to the specified grammar. An example of an alternative design which addresses these concerns (but which lacks many of the more sophisticated features of program_options) is Ole Laursen's commandoptions <http:// www.cs.aau.dk/~olau/commandoptions/> Regards, -Steve -------- Steve Byan <smb(a)egenera.com> Software Architect Egenera, Inc. 165 Forest Street Marlboro, MA 01752 (508) 858-3125

3 2

Re: [Boost-users] program_options requires non-const argv
by Merrill Cornish 26 Jan '06

26 Jan '06

Steve, I ran into the same problem. Once I thought about it, I realized I had _never_ seen a C or C++ main() function prototype defined with a const second argument. I think I remember that one of the traditional C getopt() function variants actually munges the argument list by removing that arguments it recognizes, leaving anything else for direct processing by the program. I'm guessing program_options is therefore tacitly assuming the second argument is non-const also. Merrill

4 3