- Boost-users - lists.boost.org

time_duration compile warning
by Leon Mergen 22 Oct '06

22 Oct '06

Hello, I'm using GCC 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9), and the time_duration class was generating the following warning for me: /usr/local/include/boost/boost/date_time/time_duration.hpp:58: warning: control may reach end of non-void function I've heard that I wasn't the first person with this problem, and well, since I like my code to compile clean (treat warnings as errors), this was preventing me to do so. Apparently GCC had some troubles with seeing that the static tick_type to_tick_count () function defined at time_resolution_traits.hpp was always returning something. Simply moving the code inside the else {} block to the end of the function made GCC confident that the function was indeed always returning something. Looks more like a GCC bug, but here's the patch: root@solatis1:/usr/local/include/boost/boost/date_time# diff time_resolution_traits.hpp time_resolution_traits.hpp~ 123,125c123,127 < return (((fractional_seconds_type(hours)*3600) < + (fractional_seconds_type(minutes)*60) < + seconds)*res_adjust()) + fs; --- > else{ > return (((fractional_seconds_type(hours)*3600) > + (fractional_seconds_type(minutes)*60) > + seconds)*res_adjust()) + fs; > } root@solatis1:/usr/local/include/boost/boost/date_time# This is for boost 1.33.1 Regards, Leon Mergen http://www.solatis.com

2 2

shmem - Allocating enough space. open and allocate.
by Andrea Carbone 22 Oct '06

22 Oct '06

Hello dear boost users, I am trying to use the shmem library for the first time. The domain of the application is centered on the passing of image frames from process that acquires the images to the client process via a local shared memory segment. In short, nothing really complicated. A synchronized writer/reader process. I started from looking at processA/processB example in the example directory. I am using boost 1.33.1 and shmem 0.93 (the latest available from boost vault). If I open the segment with the exact number of bytes needed: > const int memsize = 320*240; > //Create shared memory > if(!segment.open_or_create(shMemName, memsize)){ > std::cout << "error creating shared memory\n"; > return -1; > }; Then I cannot use: > unsigned char* uchar_ptr = (unsigned char*)segment.allocate(num_elements); with num_elements equal to the memsize. I see that there is need for an extra memory space to pass as second argument to the open() function... (for example 320*240+1024) ... How can I know in advance how many bytes are necessary to allocate the space actually needed? For instance, what is the difference between the size in open(..) and allocate(..)? In this case I just need a raw_memory segment .... In more complex cases? Is there some rule of thumb? Andrea Carbone

3 6

[iterators] Do I need and how to use a custom difference type
by Markus Bernhardt 20 Oct '06

20 Oct '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a custom vector-like template class for scalar types which compresses the contents similar to the infamous vector<bool> template. If for example all stored values are in the range from 0 to 1023 then only 10 bits will be used to store each value. If you insert the value 1024 to the sequence the bitcount will be increased to 11 and the whole sequence get rewritten. Now I want to use boost::iterator to create a "random access traversal iterator". I think I have to provide a custom Difference parameter, because std::ptrdiff_t will not work (right?). I have simply no idea how to do that. Any comments are welcome. Thank you, Markus -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFNLIUdnooMonJSYkRAi3dAJ91CwtdgBRdjDnt0gFKxvh0Hq7WVwCfUST/ kpFy9EA5MGZvU1cF7RKnjZw= =c53t -----END PGP SIGNATURE-----

2 1

Re: [Boost-users] Support for VS 2005 C++/CLI
by John Dunn 20 Oct '06

20 Oct '06

From: Peter Dimov > > Well... the download page for the beta SP > > https://connect.microsoft.com/visualstudio > > has a Feedback link > > http://connect.microsoft.com/feedback/default.aspx?SiteID=210 > > Since the SP is a beta, they probably pay attention to > feedback from beta testers. :-) I've posted feedback regarding the issue. If anyone is feeling bored feel free to vote for my issue ( #230171 ) - perhaps they use the voting to determine priority in some fashion. https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba ckID=230171

1 0

Re: [Boost-users] Support for VS 2005 C++/CLI offtopic: why C++/C LI?
by John Dunn 20 Oct '06

20 Oct '06

> From: Andre Krause > > just a beginners question, not want to start any flames: > why are you using C++/CLI mode, if you are using portable > libraries like boost anyway? why not build a native C++ > application? what are pro's and con's? i must admit that i > never got my head up into .net stuff, because i thought: "no > way, i completely will loose cross platform." but now with > mono, thats not true that much anymore. i heard that bytecode > might be even faster than native code, because these bytecode > JIT compilers can "magically" optimise speed at runtime!! ( > see http://psyco.sourceforge.net/, > http://www.kano.net/javabench/ , > http://www.idiom.com/~zilla/Computer/javaCbenchmark.html ) > Valid question. I'm using C++/CLI because I want to use the new Windows Presentation Foundation ( WPF ) libries which only have a managed API. So my choices are C++/CLI, C#, VB or XAML. Using these libraries are the only way to get 'next-gen' hardware accelerated GUI applications as far as I know. Compared to the Win32 API, WPF is a huge win - it's saved me months since I didn't have to write my own windowing framework. If our application was Windows only I'd probably not be using boost but we also have a bunch of shared portable code that needs to run on Windows, x86 Linux and PPC Linux, so I need to figure out how to integrate boost properly into a C++/CLI application.

1 0

Re: [Boost-users] Support for VS 2005 C++/CLI
by Nat Goodspeed 20 Oct '06

20 Oct '06

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of John Dunn > Sent: Thursday, October 19, 2006 3:23 PM > To: 'boost-users(a)lists.boost.org' > Subject: Re: [Boost-users] Support for VS 2005 C++/CLI (Peter Dimov) > > Peter Dimov wrote : > > Did you rebuild the Boost.Thread library with the new SP? You probably > > still have a dependency on the old VC runtime in it if you didn't, > > whereas the application now depends on the new runtime. > > Yes, I did rebuild boost after installing the new SP. [Nat] I've just run into a very strange behavior when loading DLLs in VS 2005, and I wonder whether your problem might be related. Our app dynamically loads certain DLLs. I coded a static object in the DLL whose constructor performs some initialization. The app loads the DLL and the OS returns control to the requesting app. Surprise! Control hasn't yet reached the static object's constructor! I'm floored by this behavior, which seems to me to violate one of the fundamental promises of the C++ language. It appears that because this particular DLL contains both unmanaged (native) and managed (CLR) code, somehow the compiler decided that it would be okay to defer initializing this static native class object until CLR initialization -- which only happens the first time control passes into any managed code in the DLL! Before that time, we've already called lots of native code in the DLL with this object sitting there uninitialized. One is tempted to invoke some managed code from DllMain() to force CLR initialization as soon as the DLL is loaded -- except that it's flatly forbidden. The MS runtime throws an exception with a stderr message to the effect that you may NOT invoke managed code during DllMain(). (I don't know the technical reason for that restriction. Probably that's why Microsoft implemented this highly dubious "lazy initialization" strategy in the first place.) So far I've thought of no better workaround than to introduce a function with a canonical name (e.g. "initManaged()") in each such DLL. Our routine that dynamically loads a DLL will test for the existence of such a function, and if found, will call it. But I haven't yet implemented this workaround. The chilling fact is that it's possible to begin actively using a newly-loaded VS 2005 DLL containing unconstructed static objects. Will such a system run any given third-party library? Flip a coin. I have no idea whether this has any bearing on your problem -- but to me, it seems to call into question the robustness of the whole VS 2005 C++ implementation.

1 0

[Summer of Code] An overview of Boost participation in GSoC 2006
by Joaquín Mª López Muñoz 20 Oct '06

20 Oct '06

Hello, A report of our experience in GSoC 2006 has been uploaded at http://boost.org/more/boost_soc_06_overview.html The report includes an analysis of the areas of improvement we found and a list of action proposals aimed at doing it better next year. I hope you find it an instructive and entertaining read. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Support for VS 2005 C++/CLI
by John Dunn 20 Oct '06

20 Oct '06

I'm curious if boost currently ( or plans to ) support C++/CLI. For the past couple of months I've been using boost in a managed C++ application without any issues ( but with quite a few scary warnings ). I've recently installed the beta VS2005 SP and now my applicaiton crashes with the following error if I link with the boost::thread library. The application failed to initialize properly (0xc000007b). Click on OK to terminate the application. Is this something that should work? I seem to remeber when I initially downloaded boost some mention of it not supporting C++/CLI but I couldn't find that reference again. Since it worked pre service pack should I complain to MS? Is my best bet putting all my boost code inside of a DLL? Here's a simple program which will crash if compiled with /clr. Note that no managed C++ objects are used/created and I haven't instantiated a thread object either. #include <iostream> #include <boost/thread/thread.hpp> #include <boost/thread/xtime.hpp> static void thread_func() { int count = 5; while( count ) { std::cout << "thread func..." << std::endl; boost::xtime xt; boost::xtime_get( &xt, boost::TIME_UTC ); xt.sec += 1; boost::thread::sleep( xt ); count--; } } int main( int argc, const char* * argv ) { std::cout << "running" << std::endl; return 1; } Any pointers would be appreciated. Thanks- John Dunn QSC Audio Products, Inc.

4 3

Re: [Boost-users] Memory problem using shared_ptr w/ STL-containers, gcc
by Wu Yinghui, Freddie 20 Oct '06

20 Oct '06

> And thus spake "Baranowski, Daniel" <dbaranowski(a)LSIJAX.COM> > Thu, 19 Oct 2006 14:25:46 -0400: > >> You'll see that the objects are or are not getting destroyed (they are >> on my comp). I played around with this in VC 8 and the memory usage >> didn't go up like yours. Here's how it looks on my system: > > Well, I have to apologise in one respect, the memory definitely gets > re-used, which is a relief. What remains is the impossibly-large memory > footprint of >10kb per object, which I have to investigate further. At the > moment it is such that a list of a little over 5000 (small) POD objects > eats well over 100MB of memory, and that just can't be right... however I > will check if this is really caused by the shared_ptr... > > Anyway, thank you all for your suggestions and your time. You have been a > great help. > > Regards, > Robert Hi, As what Andrew has already mentioned, using shared_ptr for simple POD is way too heavy in terms of memory overhead. I'd suggest you try two alternatives and see which one fits you more: 1) Store the POD directly in your container. AFAIK, copying 2 integers in and out of the container is not heavy at all in most cases. So that might help remove the trouble of using shared_ptr all together. 2) If you insist on storing pointer to the POD in the container, why not take a look at Boost.Pointer_Container library? The library provides the whole range of containers for pointer types. Better still, memory management on destruction is automatic in the pointer containers. Hope this helps... Cheers, Freddie -- Wu Yinghui, Freddie Research & Development Senior Software Engineer Volume Interactions Pte Ltd 1 Kim Seng Promenade, #12-01 Great World City East Tower Singapore 237994 Tel: +65 62226962 (Ext 216) Fax: +65 62226215 Email: yhwu(a)volumeinteractions.com URL: http://www.volumeinteractions.com Important: This message is intended for the recipient(s) addressed above. It contains privileged and confidential information. If you are not the intended recipient, please notify the sender immediately by replying to this message and then delete it from your system. You must not read, copy, use, or disseminate this communication in any form. Thank you.

2 1

Memory problem using shared_ptr w/ STL-containers, gcc
by Robert Fendt 20 Oct '06

20 Oct '06

Hi, I have a somewhat peculiar problem concerning the shared_ptr template. I use an STL container to hold several shared_ptr values. When the container is destroyed, all the destructors are called correctly, but the memory is not freed. Furthermore, shared_ptr usage introduces a 100x memory overhead (or more) in my case. Compiler system is GCC. Consider the following short example: #include <iostream> #include <string> #include <deque> #include <boost/shared_ptr.hpp> class A { public: int a; int b; }; int main() { std::string tmp; std::cout << "Enter something to continue" << std::endl; std::cin >> tmp; { std::deque<boost::shared_ptr<A> > list; for (int i = 0; i < 10; i++) { boost::shared_ptr<A> ptr(new A()); list.push_back(ptr); } std::cout << "Enter something to continue" << std::endl; std::cin >> tmp; } std::cout << "Enter something to continue" << std::endl; std::cin >> tmp; } Between the first and the second stop, the program size in memory grows by about 150k... and that's for 10 objects which are <20 bytes large, individually. And to top it off, it leaks memory. Between stops two and three the memory *should* be freed since the scope is left. I can include a destructor doing debug output in the class which shows that the objects are indeed destroyed. But the memory stays allocated. I suspect this is a GCC problem, but I have actually no clue... I tested it on a recent Debian "Unstable" and an Ubuntu "Breezy". GCC versions varying from 3.2 to 4.1. Or do I use the template in a wrong way? Suggestions would be very welcome... and if this is a known bug in GCC, a feasible work-around would be great. Thanks in advance, Robert

4 5