[boost] Re: the boost::signal sample crashes
Bohdan wrote: E. Gladyshev [EMAIL PROTECTED] wrote in message Do you mean link of incompatible library problems ? If so ... as mentioned this is problem of boost build system and it will be finally solved. Look at boost::regex, it doesn't have such problems for compilers supporting #pragma comment. It means that correct library is linked automatically. Does regex address the issue of alignment and calling convention etc and other options (in BCB, treat enums as ints is a good one to screw up libraries) by wrapping the headers in push/pop option statements? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
This is just what I would like to see in boost. I have created a duplicate set of headers for boost (same names, same structure but in boost_wrappers which do this and include the original header between the push and pop). We had a discussion about this a while back and I am all for it, but people seemed against it. I'll try and find a link to the discussion. Thanks Russell John Maddock wrote: Does regex address the issue of alignment and calling convention etc and other options (in BCB, treat enums as ints is a good one to screw up libraries) by wrapping the headers in push/pop option statements? Yes: #ifdef __BORLANDC__ # pragma option push -a8 -b -Vx -Ve -pc -w-8027 #endif // code here #ifdef __BORLANDC__ # pragma option pop #endif We should standardize this boost-wide really in some kind of prefix/suffix header. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
Beman Dawes wrote: I'd like to be sure that some Booster signs up for this beta and starts running the Boost regression tests against it. And then follows up with bug reports to Borland as needed. Any bugs fixed in the compiler before it ships are bugs Boosters don't have to cope with later. Any volunteers:-? I've signed up, but don't know when we will here if we've been accepted or not. If I am, I'd be happy to take on the regression test role for BCB (and submit bugs etc) Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
Beman Dawes wrote: At 12:53 PM 8/6/2003, Russell Hind wrote: Perhaps coordinate with John Maddock? He is really our config header expert. So John, would you be interested in trying to get this sorted out for the next release? As I have said, I currenly only use BCB, and so can't offer much help for other compilers. Would it be best to have something like a boost/config/preinclude.hpp file which includes a compiler specific pre-include and then a boost/config/postinclude.hpp for afters? I've created ones for BCB which I use here, that simply do #praga nopushoptwarn #pragma option push -a8 -b -Vx -Ve -pc -w-8027 for pre and #pragma nopushoptwarn #pragma option pop for post (probably don't need the nopushoptwarn in postinclude though). These options are from regex. I may be a better idea not to include disabling warnings in the default boost options? And also, It might be worth adding -Vg- to disable codeguard for boost, unless the new build system will build CodeGuard libraries as well as non-cg enabled libraries. These options also should be the same as the default jam options for the compiler also. What do you think? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
Peter Dimov wrote: To make out-of-line libraries plug and play we may have to prefix/suffix all* inline libraries as well, making their users pay for something they do not need. * Under the assumption that they are potential future dependencies. I understand this (and it was because signals relies on shared_ptr that I was bitten by it), but by default the libraries are all built using the default compiler option for the tool. The inlined (header-only) library are only tested against that default set, so why not enforce that default set for all boost libraries? If an individual library author then wants to enforce another set (different alignment or something) for optimisation purposes, then let then over-ride the defaults, but at least everywhere that library is used, it will use the same compiler options and stop the problems of hangs/crashes at runtime due to mis-matched settings. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] anonymous lock in boost/libs/random/build
This lock has been there since I tried updating boost last night (about 8 hours ago). Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: anonymous lock in boost/libs/random/build
Thanks, its gone now (I managed an update an hour or so ago). Cheers Russell Beman Dawes wrote: At 02:48 AM 8/13/2003, Russell Hind wrote: This lock has been there since I tried updating boost last night (about 8 hours ago). Please report stale locks to SourceForge support. They are the only folks who can fix the problem. Thanks, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
Beman Dawes wrote: In the meantime, you might want to try running the regression tests using any compiler you have at hand. While we are doing much better with docs, etc., running the tests still take a bit of getting used to. I plan to do that, I'm currently using BCB6 so it would be a good starting point. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
John Maddock wrote: #ifdef __BORLANDC__ # pragma option push -a8 -b -Vx -Ve -pc -w-8027 #endif // code here #ifdef __BORLANDC__ # pragma option pop #endif We should standardize this boost-wide really in some kind of prefix/suffix header. Here is the discussion (it cropped up with signals library there too) http://tinyurl.com/j5xi Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
# if BOOST_WORKAROUND( __BORLANDC__, = 0x0560 ) I would just like to point out that if _USE_OLD_RW_STL is defined, BCB6 uses the roguewave STL from BCB5 and so doesn't have this _STL/std:: conflict. So it may be worth introducing that into the #if somehow. (I don't define this because I prefer STLPort to RW STL but it is a fix) Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
Peter Dimov wrote: The main problem with shared_ptr 1.30.x and below is that the single- and multithreaded versions are incompatible. The CVS version is now binary compatible on Windows, so 1.31 will work across different threading models; still, the correct default for Borland should probably be to do a multithreaded build. By the way, this can't be fixed with prefix/suffix headers. No, you still need single/multi-threaded builds, but with out headers, I then need to add in 4-byte alignment builds, 8-byte alignment builds, different builds for different calling conventions etc. It doesn't get easy, especially for existing projects. We either end up making a custom build of the boost libs for each project? That would become a maintanence nightmare. How would you feel if you had to re-build your compiler's RTL just so you could change some project options? But I don't want to enforce a set. I want (for example) shared_ptr to use whatever set the user has specified and not to override his settings. Then we put options in to ignore the pre-post config headers so users can user there own settings if they wish, but it appears to me that most people don't care what options are set, they would just rather have it work, and currently, its very easy to break things as soon as you use a compiled lib. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: Have you built the signals library multi-threaded or single threaded and Whatever the default build is. Single threaded. The application is set to use multi-thread run-time libraries and MFC.DLL. Not seen this specific one, the most common problem I saw was a hang so it may well not be your problem, but worth looking into. It may well be the problem. I didn't see crashes, just hangs. You have objects created inside the signals lib (non-multi-threaded) so it doesn't create/initialise the lock member variables. There is then header code which is compiled directly in your application (multi-threaded even though you only use 1 thread) and so it tries to access these non-existent locks in the objects created in single threaded signals lib. If you are going to use a multi-threaded application/run-time, you must build/link the multi-threaded version of the boost libs also. Because of the crash, you may still have another problem, but I would solve this one first, then look for the next. I saw the hangs under Borland C++ Builder, the bug may present itself in a different way under VC++. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: Thanks for taking a look at the problem. IMO, distributing objects between inlines and DLL functions is not a very good idea. The classic example is: It can cause problems but if you are aware of it, then you can work around it quite easily. Part of the reason in speed. Some code can be inlined to optimise things for release builds. This is a good thing IMHO. Also, some libraries are wholly or partly template based so they can't go completely in a .lib yet. I'm sure there are other reasons that other people could fill you in on. IMHO, boost needs to get rid of any possibility of this to happen. Why does boost::signal() need a DLL/LIB in the first place? Would not be just the .h file enough? It could be put in a .h, but there is a lot of code in the library and it makes sense to have it built as a .lib. Perhaps another solution would be for all the inlined code in the header to be moved into the .lib at a loss of performance. I would just prefer a solution mentioned above where the libs built by boost have different name endings for debug/release multi/single threaded. But this isn't the whole problem. The other problem is compiler options and such for the structures in the header files. For example, data alignment. boost builds with alignment of 8 for Borland by default. If your app uses another alignment option (we used to use 4 for historic reasons) then when you accessed objects returned from the dll, you would access the wrong offsets for the members because the boost headers don't force options such as this around there structures. I have created a duplicate set of headers for the parts of boost that I use that force compiler options using a #pragma push, then include the boost header, then pop those compiler options. I only ever include my wrappers so that I don't get caught by this and am free to use whatever compiler options I wish for the rest of the project. Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: IMO, I should be able to just use the library w/o this kind of workarounds. It is hard to debug these .lib/.h conflict issues. Why build the .lib at all? Why not just add the signals source file to your project? I did this for a while with thread and signals. I've since now got my own build system working with name .libs and generated headers to make sure project options are the same for the .lib and where I include the headers. I've made it easier by only using the multi-threaded libraries in boost and therefore never create the single threaded libraries. Also, boost releases don't come out that often that it is a PITA to keep up to date, although I am just about to go through it with 1.30.1 Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: Anybody had problems with boost::signal? The following sample code crashes on my Win2k/VC++6 system. Have you built the signals library multi-threaded or single threaded and are you building an application of the same sort? This seems to be a common source of problems with the signal library. The default library build is single-threaded but most people appear to generate multi-threaded apps on win32 and run into problems. Not seen this specific one, the most common problem I saw was a hang so it may well not be your problem, but worth looking into. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [boost::thread] locks, exceptions and assertions
David Abrahams wrote: That sounds like what I remember Bill telling me. but scoped locks don't tend to be shared. The mutex is, but the actual lock isn't intended to be. Certainly not accross threads, so there shouldn't be race conditions in scoped_lock. Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [boost::thread] locks, exceptions and assertions
Peter Dimov wrote: This looks like a motivating example for scoped_unlock. :-) That would definitely be useful. In places I have made my own scoped_unlock (well, just called unlocker) but I haven't re-used it everywhere yet!. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [boost::thread] locks, exceptions and assertions
Jon Biggar wrote: Russell Hind wrote: Ok, but what happens if locking an already locked mutex where undefined behaviour? This isn't this the same as the smart_ptr case? Who knows how the actual implementation is on all the platforms, or future platforms? Um, wasn't the question throw vs assert? In either case we would detect the attempt to relock the lock and not do that. Yes it was, you wrote that smart_ptr asserted because that was better than dereferencing a null ptr so my question/point is why throw rather than assert because locking an already locked mutex (as Peter pointed out) is undefined behaviour. Similar results in the end so why assert in one and throw in the other? Why not throw in shared_ptr then? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
Beman Dawes wrote: Seems like we are very close to being ready to do a 1.31.0 release. One new library has been added since 1.30.0, at least two libraries have had interface upgrades, and a large number of bugs have been fixed in numerous libraries. How about 1 or maybe more betas of 1.31.0 (like we had for 1.30.0) so that hopefully some problems can be found before the final release? Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: How to achieve this goal using boost::tokenizer?
You need to pass a separator into the tokenizer that only separates on ',' (i'm not sure if this code compiles, but you get the idea std::string Pages(2,3,5-7); char_separatorchar CommaSep(,); tokenizerchar_separatorchar Tokenizer(Pages,CommaSep); This will split it up into 2 3 5-7 You will then need to do a bit of extra passing on each token to see if it is a range (contains a '-') using either just a find, or create another tokenizer for '-' Cheers Russell lattice wrote: If we print some pages ,we can select pages in a range to print. for example,if we enter 2,3,5-7 in Ms-word print dialog,then page 2,3,5,6,7 is printed. Now questions is : if we get a string like this 2,3,5-7,if we use boost::tokenizer, we can only get 2,3,5,7. eventually some information is lost. How can we get the desired result2,3,5,6,7 using boost::tokenizer? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: string conversion methods
Jeff Garland wrote: In date-time there are several 'to_string' functions that provide different ouput formats so a single 'str()' method isn't going to be enough. As for c_str(), you can use this once you have std::string. From my view there is no point in trying to force fit this functionality into an inadequate interface. Finally, by keeping these as free functions dates and times can be used without including I/O headers which the 'to_string' functions use. I'm not saying replace all the _string methods with a str() but jshould we have str() native_file_str() to_simple_str() or string() native_file_string() to_simple_string() just to commonise things. Filesystem has a string() method. stringstreams use str(). I also agree that boost libraries don't need a c_str() method since this can come from the string() (or str()) method. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: thread::current() ?
Philippe A. Bouchard wrote:
lock()...
if (thread() == f1 || thread() == f2)
{
thread()..(whatever casts)...m_list;
}
unlock()...
// I think the only way to do this is by mapping the thread's id
// with the object's address (mapkey, functor1 *) but there is
// no standard key publicly accessible and map creates overhead.
Do you mean which thread is currently executing? Both threads are
effectively executing and you code here is inside a third thread and
that is what thread() would actually return, not either thread1 or
thread2. Maybe I'm missing something.
More information about what you are trying to do would be helpful
because currently I don't get it.
Cheers
Russell
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] string conversion methods
It's only minor: But boost::filesystem and boost::date_time have string conversion methods such as string() native_file_string() to_simple_string() where as boost::format (and also stringstreams in the STL) have str() I don't know about the other libraries? Is there a standard for this in boost or is it up to the libraries? Should they be commonised? Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem::path bug?
Tim Russell wrote: boost::filesystem::path p; p = boost::filesystem::path( .txt); .// Three spaces Have you tried p = boost::filesystem::path( .txt, boost::filesystem::native); as this is how I have to construct paths on Windows because of the \ separater. Maybe this will work for you also. Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost::thread feature request: thread priority
Look at the thread_dev branch of boost::thread in the CVS. There are many changes (including priority) that haven't been finalised yet. Hopefully they will make it into 1.31.0 whenever that will be released. Cheers Russell Maxim Egorushkin wrote: Hello, I've been missing a feature in the thread library: managing a thread priority. And, BTW, the class encapsulating stopwatch functionality with a millisecond precision would be very useful. It would help writing more portable programs (as boost::thread is portable). ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compose_f_gxy_hxy
Daniel Frey wrote: Sure. But still compose.hpp is in itself incomplete. And it completes the standard's parts on function objects so I think it might be desirable to supply compose_f_gxy_hxy. If we take bind into account here, we could just as well remove compose.hpp completly, couldn't we? Or was this your suggestion? I thought bind was the preferred method over compose now. This lead me to believe that compose was left in for backwards compatibility. I haven't actually used compose, so don't know if there are things it can do that bind doesn't, mind you. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: tokenizer comments
Vladimir Prus wrote: I have a few comments regarding the tokenizer library. 1. The documentation says that char_delimiters_separator is default parameter to 'tokenizer' template, and at the same time says that 'char_delimiters_separator' is deprecated. I think that's confusing and default parameter should be changed to 'char-separator'. char_delimiters_separator has been deprecated since before 1.29.0 (IIRC, that is when I started using boost). Should it not now be removed from the library completely if it is superceeded by char_separator and has been for quite a while? Then there wouldn't be this confusion. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: shared_ptr/weak_ptr and thread-safety
Trevor Taylor wrote: Who? Me? I think Peter meant Alexander Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Borland C++ Builder 6 SP4 and release 1.30
AFAICT, there are places this needs changing so as you come accross them, I would just post to this group so someone with access can change it in the CVS for the next release. Maybe a __BORLANDC__LATEST could be defined in the compiler config headers rather than embedding version numbers all over the place (I don't know how many places 0x56x is used explicitly, so this may not be necessary) Cheers Russell Edward Diener wrote: I have noticed that the 1.30 release does not seem to be aware of the SP4 update to BCB6 and am wondering if anybody has tracked changes that need to be made to 1.30 because of this release. In particular the __BORLANDC__ number for the SP4 release is 0x564 and I have noticed a number of files where tests were being made against __BORLANDC__ numbers of 0x560 ( the original BCB6 release ), 0x561 ( BCB6 SP1 I believe ), and even 0x562 ( BCB6 SP2 I believe ). Of course a number of these tests were =, , =, or comparisons and I am wondering if I have to change any of these in my own private copy of Boost 1.30 in order to work correctly with BCB6 SP4, and what changes need to be made. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: smart assert (was: ENFORCE/ better assertion technique)
Darren Cook wrote:
In my own assert library I added options for logging, but in the end
never used that and always had it throw an exception. This is nice for
two reasons:
1. MFC debugger catches it and allows me to go back up the call stack
to where the assert happened. (I'm still struggling with gdb but I think
it can be set to do the same?)
Under win32, my assert method uses
if (IsDebuggerPresent())
{
DebugBreak(); // ammounts to int 3 on intel
}
(IsDebuggerPresent() is a win32 method to see if a debugger is attached
to the process)
which I find better than the debugger catching an exception. At my last
work place, we made asserts through exceptions but ended up with
exceptions being thrown in destructors and such which wasn't very nice,
especially if the destructor was being called during clean up because of
a previous exception.
But I don't know if this can be applied to all platforms.
Russell
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: an xml-binary persistence library
Vladimir Prus wrote: b) versioning at the class level I implemented a binary serialisation library at my previous work place that was very similar to what has been described here. As for versioning, we left it up to the class. But implemented it in all classes. All classes stored a version number as the first item they wrote to the archive and then read it back in to know how to load them selves. Not sure if it is the ideal way, but it worked. It would be nice not to have to handle this in every class, though. I suppose it could be handled by the class registration. Give the registration info a version number. The in the reading method, the version number is passed in by the archive which the archive reads from the file. The other issue we hit was that class names took up a lot of space in a binary archive so we went for type number (which was generated during class registration for each class). The problem here is that the order of registration is then important to preserve the numbers so that subsequent builds of the software can load up the old files. We handled this by storing the type map in the file at the end (i.e. a list of type names/type numbers). This was read in and another map created that mapped the numbers in the file to the current class registration numbers. This is done as soon as the archive is opened for reading. It allows you to re-order the class registrations without worrying about not being able to open old files. Another way to do it, rather than have a list in the file is to store the type name only when the first object of that type is saved. Subsequent saves of that object will only store the type number. When reading, the map is built up as objects of the various types are read back in. A suggestion for being able to use the same code for loading/storing objects: I'm quite happy for the binary archive to just ignore the first parameter and write the value out, but as others aren't, then maybe a duplicate set of methods in the binary archive which don't take that parameter. This would allow you to write the same code for reading and writing xml/binary, but if you really didn't want the performance hit on your object in binary mode, then you could use the other methods and would have to have 2 lots of code. I suppose the xml version could support the methods without comments as well, and just write the type e.g. int10/int stringHello/string and this then leaves it up to the users of the library to how they wish to serialise. Another difference we had, was that we had a base interface called Persistent which all objects stored polymorphically through the archive used. I like the idea of making the storing/loading method template based, so you don't need an interface class to store objects. Maybe you could customise the method that is called during the class registration process also? (with defaults). People may then be able to specify the same method for xml and binary or different ones, which means they wouldn't have to find out at run time in the serialise method as to whether it was XML or binary. I don't know if this could be done with templates, though. We also used a static Create method that was stored during the registration process which meant we could make the default constructor protected or private to stop people calling it accidently if it was only there for the persistent archive. Another way to do this is to make a constructor that takes the archive so the object could serialize itself at construction time as well as later on during its life. Just some thoughs, but I really would like to see a library like this added to boost at some point. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Johan Nilsson wrote: Yes, but why not have both on all platforms? It would make using it cross-platform easier, but you aren't actually getting microsecond information under windows, so if your program relies on that detail, it won't work correctly under windows anyway, so you must make your program work with millisecond times and you could then just use your millisec_clock on both platforms. Basically, I both agree and disagree. I agree from the point of view of using the library cross-platform, but disagree on the principle that your using something that promises microsecond detail, but in fact is only returning millisecond. (in my example anyway, if you could make the microsecond stuff work from QPC then that would be fine) Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Johan Nilsson wrote: Yes, but why not have both on all platforms? I suppose another solution is to have secs_clock, millisecs_clock on windows, all three on another platform that supports microseconds, and then a typedef of something like highprescision_clock which on windows will be a millisecs_clock, and on other platforms will be microsecs_clock, but you won't need to know, you just get the highest precision available. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Johan Nilsson wrote: Perhaps, but one should consider that GetSystemTime promises 1ms resolution and delivers 10-15ms (and, IIRC, that GetSystemTimeAsFileTime promises 250ns resolution). The Platform SDK states that the tickcount (GetTickCount) is updated every 10ms on NT3.51 and hight so I guess that GetSystemTime is updated at this interval also. FileTimes are measured in 100 nanosecond intervals since 1 January, 1601, but are you sure that GetSystemTimeAsFileTime will return a value that is updated at 250ns intervals? I can't find anything in the SDK to say what the update interval is for the SystemTime, I'm just guessing that it is updated when the tick count is. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread Lib and DLL
I'd been wondering this, and heard about TLS issues. The issues are only on Windows it appears. Search for the thread Fwd: Thread-Local Storage (TLS) and templates by Greg Colvin on 18/02/2003 Specifically, the many posts by William Kempf and Edward Diener discuss the problems on windows with TLS cleanup. I do have a question on this issue: If this problem is only to do with TLS cleanup when a thread exits, then if all threads are created when the program starts and only destroyed when the program exited, then, in practice, could this really be an issue? I.e. if we only work like this, could building thread as a static lib cause problems providing that we don't let threads exit in the middle of the program? We're currently really trying to stay clear of any DLLs. Cheers Russell David Brownell wrote: I am curious as to why the new version of the Thread library does not provide a static library in the 1.30 version of boost. After reading some initial posts, I have seen references to thread local storage, but haven't seen anything that documents why this makes a static library impossible. All thing considered, I find a static library is much more desirable than a dll. Thanks! David Brownell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread Lib and DLL
William E. Kempf wrote: Theoretically at least, I don't see why this would cause a problem. You intentionally leak, but the leak is benign since it occurs only right before the application exits. But most users won't code this way, nor do I want to have to deal with the support requests/questions this would cause. So, unless you have some suggestion as to how I can enable this usage with out causing confusion, I'm not sure I'd care to re-enable static builds. But you could probably fairly easily hack things to build that way yourself. No, I wasn't going to ask you to re-enable static linking because of this. As you rightly pointed out in the other thread, you have to make the library safe for all possible cases which is what you are doing. If we did decide to go this route, then we would certainly handle building the lib ourselves. Our problem with DLLs is this: We work on many projects. Some are in maintenance only mode, so don't get many updates. The next project may use boost-1.30.0 and then go into maintenance. I may then be working on a project which uses boost-1.32.0 and would like to keep both dlls available on the system. Current idea for doing this is re-naming the boost dlls to boost_thread-1.30.0.dll etc so that I can have 1 bin directory with all the dlls in, and each project would link and use the correct dll. I wonder if support for this could be built into the builds? Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Thread Lib and DLL
William E. Kempf wrote: You can do this simply by placing the applications in seperate directories and keeping the proper DLL version alongside the executable. Not necessarily the ideal solution, but it's the easiest way to solve DLL Hell. The reason I've not done this (and want to go to the 'version number in name' if we're forced to use dlls) is that I can have all dlls sitting in one place on the system, and to create a quick project, I can already use the boost libs without having to copy/move any lib/dll files. I use #pragma link statements (like regex does) in code to link with the boost dlls so all I need on my libs path is C:\BOOST\1.30.0\bin and change this depending on which version. The version is also just a project wide #define so it can easily be changed on a project by project basis (need to change 3 things: include directory lib directory version #define (so the pre-processor can make up the .lib name) and I can then easily switch between versions and have all versions existing on the same machine. I'm trying to make boost as easy to use as the STL, i.e. always available without havig to do anything bar include a header file in 1 or more CPP files that contains the #pragma link statements. I've also currently done it by adding a d to the debug version and mt to the threaded version (of signals etc) so I can easily switch between the debug and release version of a lib if I want to step through the code. The multi-threaded version is automatically used if __MT__ is defined etc. Current idea for doing this is re-naming the boost dlls to boost_thread-1.30.0.dll etc so that I can have 1 bin directory with all the dlls in, and each project would link and use the correct dll. I wonder if support for this could be built into the builds? Absolutely! I'm hoping we address these kind of concerns with a full installation solution sometime soon. In the mean time, the stage rule in the Jamfile should be able to handle this. You can hardcode the release number in today... but I believe there's a variable available which I could use to do this with out hardcoding. I'll see if I can track this down and make the patch. That would be good. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Mark Blewett wrote: I was surprised at the difference too, so tested here with a Dual 800Mhz PIII (Dell Precision 220) running Windows 2000 Advanced Server (SP2). Cutting and pasting into a default Win32 console project in VC6 (SP4 I think) gives a result of ~0.72 on an idle machine. FYI: From Microsofts Platform SDK docs on QueryPerformanceCounter On a multiprocessor machine, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the BIOS or the HAL. To specify processor affinity for a thread, use the SetThreadAffinityMask function. Not sure if this effected your results or not. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [date_time] enabling microsec_clock under C++Builder
C++Builder doesn't currently support the microsec_clock of date_time
because of its standard library. Would it be possible to add code to
get the time using Win32 methods as this gives millisecond times?
Something like this in microsec_time_clock.hpp seems to work
static time_type local_time()
{
#ifdef __BORLANDC__
SYSTEMTIME lt;
GetLocalTime(lt);
date_type d = date_type(lt.wYear,
lt.wMonth,
lt.wDay);
int adjust = resolution_traits_type::res_adjust() / 1000;
time_duration_type td = time_duration_type(lt.wHour,
lt.wMinute,
lt.wSecond,
lt.wMilliseconds * adjust);
return time_type(d, td);
#else
#endif
}
Is this Ok, and would it be of interest to anyone? It could be used for
all Win32 compilers (if the adjust statement is correct) or are there
reasons why platform specific code wouldn't be wanted in the library?
We currently log a lot of error information to text files, but
sub-second times are useful. date_time currently doesn't offer this for
C++Builder, so that is why we would like something like this added.
Cheers
Russell
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Jeff Garland wrote: C++Builder doesn't currently support the microsec_clock of date_time because of its standard library. Would it be possible to add code to get the time using Win32 methods as this gives millisecond times? I think this is a good addition, but we should probably make the addition for all Win32 compilers since I think this is actually part of the Win32 api. I agree with that. Would it be better to make it a millisec_clock, or just use the microsec_clock but the resolution is only milliseconds? Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Alisdair Meredith wrote: Russell Hind wrote: I agree with that. Would it be better to make it a millisec_clock, or just use the microsec_clock but the resolution is only milliseconds? WinAPI Note: we can get a higher resolution using the QueryPerformanceCounter API (and QueryPerformanceFrequency if resolution info is required) Can these be used to get an actual date/time though? Or just for high resolution timing? I've only had a brief look at them, so will read a bit more. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Un-named unions and Borland Internal Compiler Error
Line 56 of optional.hpp states that Borland ICEs if the union is un-named. This is correct for C++Builder 5 (0x551), but C++Builder 6 Update 4 (0x564) doesn't have this problem. Not worth removing it but just thought I'd point it out incase anyone is interested. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Beman Dawes wrote:
Be careful. At least with some older versions of Windows, the execution
time for some of the Windows time related API's was so large that the
useful resolution was nowhere near the apparent claimed resolution.
If a function that is supposed to measure time in microseconds takes
several milliseconds to execute, it seems to me the useful resolution is
really milliseconds rather than microseconds.
It might be interesting to write a little test program and run it on
modern versions of Windows to see it this problem still exists.
Does this help?
I've just run this quickly on my PIII 800 running Win2K SP3 and worse
case for 1,000,000 calls to QueryPerformanceCounter was 1.92seconds,
usually between 1.55 and 1.65 seconds (10 runs).
LARGE_INTEGER Start, End, Temp;
QueryPerformanceCounter(Start);
for (unsigned int i = 0; i 100; ++i)
{
QueryPerformanceCounter(Temp);
}
QueryPerformanceCounter(End);
LARGE_INTEGER Frequency;
QueryPerformanceFrequency(Frequency);
double Time = (static_castdouble(End.QuadPart) - Start.QuadPart) /
Frequency.QuadPart;
Doesn't seem to bad to me. Can't test on any more OSes as this is all
we have installed.
Cheers
Russell
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock underC++Builder
Do you want the C++Builder project as well, or is this enough?
Cheers
Russell
Beman Dawes wrote:
Interesting. Could you please post the entire program as an attachment,
so I can just compile and run it without any cut-and-paste?
Thanks,
--Beman
#include windows.h
#include iostream
int main(int argc, char* argv[])
{
LARGE_INTEGER Start, End, Temp;
QueryPerformanceCounter(Start);
for (unsigned int i = 0; i 100; ++i)
{
QueryPerformanceCounter(Temp);
}
QueryPerformanceCounter(End);
LARGE_INTEGER Frequency;
QueryPerformanceFrequency(Frequency);
double Time = (static_castdouble(End.QuadPart) - Start.QuadPart) /
Frequency.QuadPart;
std::cout Time std::endl;
return 0;
}
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.0 release postmortem
Beman Dawes wrote: What systems work for others in an Internet environment like Boost? Who could act as host? I see the GCC folks are migrating from GNATS to Bugzilla. Another group in our company uses BugZilla for an internal project, and I helped them out on it for a few months, and so had access to it. I liked it. Specifically: All the comments are kept with the bug It is easy to refer (and hyperlink) to other bugs in comments revision history of a bug attachments for bugs Mark bugs as duplicates I've not had any experience administering a bugzilla implementation though so can't really help there. The only point they said about it was that it isn't very secure. Any one can create an account on it and start submitting bugs (AFAICR) but that isn't a problem with a project such as boost, IMHO. Which I guess its why it never bothered the Mozilla lot. HTH Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.0 - problem with filesystem lib
Alisdair Meredith wrote: Russell Hind wrote: I had the same problem with C++Builder 6 when first using the filesystem library. The default builds for filesystem are single threaded. If your application is multi-threaded, then you need to re-build the filesystem library with multi-threading (it uses mutexes somewhere (I think from smart_ptr but can't remember)). That is certainly a poor default choice for the borland compiler. The 'typical' borland user will be using the shipped VCL class library, and this is requires MT builds. Single-threaded is an exceptional condition, rather than the norm, on this platform. If MT builds are not to be global defaults, could we at least patch the jam files to use multithreading on Borland? I would like both single and multi-threaded to be built for all libraries by default. But at minimum, would like an easy way to find out which libraries are affected my multi-threading. These are: signals filesystem thread (obviously) The only library I've used that isn't is date_time Not sure on regex, but I think its makefiles build all the possible versions so it isn't so much of an issue. Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
Trevor Taylor wrote: As a software user I am frequently frustrated by an error occurred like failure messages. As a developer I know that the software *knows* exactly what failed, why, and exactly what it was doing at the time, but doesn't pass any of this information on. Recently I developed some C++ where for the first time I was happy with the information reported in error cases. The key to happiness, it turned out, was to collect context with exceptions as they propogated (back) up the call chain. I would love boost to provide an exception class/framework/something with this capability to encourage collection of context information, which would make problem diagnosis so much easier. IIRC, there was discussion of a library to help getting callstact info etc a few months back, but can't quite remember what the result was. I have basic info on doing this in C++Builder on Windows (and use it in our software) and it could esaily be applied to VC++, but as for other platforms, I'm affraid I can't help. For BCB, have a look at http://www.wischik.com/lu/programmer/index.html and look at the debugging aids section. This could also easily be applied to VC++ as well, but I haven't tried it under that. We use it to generate a callstack in an assert which can be very useful. You could also use it to look up the method name during an access violation or some other exception that can get thrown. I have also had some success using a try...__except block to get the CONTEXT as you mentioned and produce a callstack from that, but usually the last few entries are missing. You can always fill in the last entry for the exception address, but I don't know how much you can trust the stack at that point because, as far as I know, it has started unwinding. I don't think windows keeps a copy of it with the exception record so you can walk it once the exception has been thrown. Cheers Russell Perhaps I could relate some of my experience and put some ideas up for discussion? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::format 1.30.0-b1 (again)
Samuel Krempp wrote: Le mer 19/03/2003 à 14:27, Russell Hind a écrit : and this _USE_OLD_RW_STL macro is then an adequate mean to detect such cases ? if so, I could disable the workaround, depending to this macro. but not right before the release. My take on this is: BCB5 (0x550 to 0x551) doesn't have this problem as it uses RogueWaves STL BCB6 (0x560 to 0x564) only has this problem if using STLPort (default) (i.e. no _USE_OLD_RW_STL defined) But if in BCB6, you define _USE_OLD_RW_STL then BCB6 uses RogueWave STL as shipped with BCB5 so doesn't have the problem. So the test may be #if (__BORLANDC__ = 0x560) (__BORLANDC__ = 0x564) !defined(_USE_OLD_RW_STL) #define BOOST_BAD_ISDIGIT #endif (Sorry, not up on the BOOST_WORKAROUND syntax yet, so that is the best I can provide). I'm not sure about kylix (0x570 and above) and whether it comes with the old RW STL or just the STLPort version, hopefully someone else on the list can help with this, as Alisdair has already asked. It really is an insignificant detail, as using locale's isdigit rather cctype's only matters if the given locale has more digit characters than the good old '0'-'9' (and even then, it matters only if someone is bold enough to use those locale's extra digit characters as number parameters in a format string..) Probably not worth the effort then given that even if _USE_OLD_RW_STL is defined, it still works whether BOOST_BAD_ISDIGIT is defined or not Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Latest borland patch - compiler version 0x564
Alisdair Meredith wrote: Beman Dawes wrote: There just isn't any time left. See OK to tag for release? message just posted. Sorry, The line has to be drawn somewhere, and it is human nature to wish we were the other side g I will be able to test properly with the new BCB patch myself next week. My worry is that the MPL is worming itself into more libraries as an implementation detail now. If it turns out there are any knock-on dependencies (such as we discovered with lexical_cast this week) would it be possible to distribute a separate borland 'patch' through SourceForge, that updated just the affected files? [I suspect I can produce such a thing if necessary, it need merely overwrite 20-30 files which can be provided in a .zip] Alternatively, is there a convenient place to publish advisories for special-interest communities (such as letting borland users know they may need to update files that check against older compiler version.) I suspect the latter will be simpler, and may well apply to a broader range of compilers through the duration of a release cycle. Perhaps something else for the Wiki? Could a 1.30.1 be released in 3 or 4 weeks time when these changes had have time to be tried? I don't know if it is boost policy to release updated releases like this, (only been using it since 1.29.0) but it would be nice, as mentioned by Alisdair before, to use a boost release 'out of the box'. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Regex and STLPMT.LIB
John Maddock wrote: It looks more likely that you actually compiled with Builder 6, as that ships with (and uses) that lib. I ran into this problem. Builder 6 puts itself at the head of the path, so when you run make (for building regex), I ended up building with BCB6 make, and then tried linking it with a BCB5 project and hit this exact problem. Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::format 1.30.0-b1 (again)
Does anybody know if this needs fixing, or is it my mistake. If it needs fixing, is someone able to do it before 1.30.0 is released? Thanks Russell Russell Hind wrote: Sorry about last post, Mozilla decided to send when I tried to paste stuff into the message (?). Strange, but probably finger trouble. Here goes again: I have just tried boost::format with C++Builder 6 Update 4 and works fine (simple test), but have to #define BOOST_BAD_ISDIGIT Looking in format.hpp (line 43) there is #if defined(BOOST_NO_STD_LOCALE) || ( BOOST_WORKAROUND(__BORLANDC__, = 0x561) \ BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT( 0x570 ) ) ) #define BOOST_BAD_ISDIGIT #endif __BORLANDC__ is now 0x564 after update 4, and still has the problem. Should this be updated to reflect this? Also, BCB5 doesn't have the problem (0x551) and neither does BCB6 if you use the rogue wave STL (_USE_OLD_RW_STL) so could these be taken into account? (or doesn't it really matter, don't currently use locals, so don't know how much enabling this would impact formats use) Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::format 1.30.0-b1
I have just tried boost::format with C++Builder 6 Update 4, and have to either #define BOOST_BAD_ISDIGIT or #define _USE_OLD_RW_STL Looking in format.hpp (line 43) there is ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::format 1.30.0-b1 (again)
Sorry about last post, Mozilla decided to send when I tried to paste stuff into the message (?). Strange, but probably finger trouble. Here goes again: I have just tried boost::format with C++Builder 6 Update 4 and works fine (simple test), but have to #define BOOST_BAD_ISDIGIT Looking in format.hpp (line 43) there is #if defined(BOOST_NO_STD_LOCALE) || ( BOOST_WORKAROUND(__BORLANDC__, = 0x561) \ BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT( 0x570 ) ) ) #define BOOST_BAD_ISDIGIT #endif __BORLANDC__ is now 0x564 after update 4, and still has the problem. Should this be updated to reflect this? Also, BCB5 doesn't have the problem (0x551) and neither does BCB6 if you use the rogue wave STL (_USE_OLD_RW_STL) so could these be taken into account? (or doesn't it really matter, don't currently use locals, so don't know how much enabling this would impact formats use) Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::threads and lib vs dll
I see that boost::thread has moved to a dll implementation (win32) in 1.30.0-b1. I have modified the JamFile for boost:thread so it builds the lib as well as the dll. Default build be made to do both, rather than just the dll? Or is boost moving to dll implementation only for all libraries? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::threads thread_dev
Just a quick question: Are the changes made on the thread_dev branch for the thread library going to make it into the 1.30.0 release or are they being held back for a future release? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Borland C++ Builder patch 4 released
Paul Mensonides wrote: Beman Dawes wrote: #define A() 1 #define B(m) m 2 B(A) I've run the above through the preprocessor and heres the output /* Unit1.cpp 1: */ /* Unit1.cpp 2: */ /* Unit1.cpp 3: */ /* Unit1.cpp 4: */A 2 Tested using the preprocess option with BCB6Pro Update 4. This looks like what you were hoping for. If you'd like me to test anything else then just let me know. HTH Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Borland C++ Builder patch 4 released
FYI I've submitted it as QC#3629
Russell
Paul Mensonides wrote:
Russell Hind wrote:
Sorry to say that the output is now incorrect. A2 instead of A 2.
Checking the preprocessor output for this gives
/* Unit1.cpp 9: */int main() {
/* Unit1.cpp 10: */std::cout A 2 std::endl;
/* Unit1.cpp 11: */return 0;
which is again correct. This is strange since I thought that bcc32
was
just supposed to call cpp32 for the pre-processing. I can submit this
as a bug to Borlands QualityCentral if you like (but don't hold your
breath).
:(
I'm not surprised, but I was hoping If they fixed this bug, Borland would
be able to use the strict configuration of the pp-lib. I'd still need the
same hacked configuration for Sun and IBM (they have similar bugs), but at least
Borland's wouldn't need it.
Please do submit a bug report. I think they've already gotten this one before
though, so I'm not holding my breath. ;)
Thanks again for the help,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Question about boost::thread::yield for Win32
Is yield intended to always yield to another thread if one can run?
Because the code for yield is
void thread::yield()
{
#if defined(BOOST_HAS_WINTHREADS)
Sleep(0);
#elif defined(BOOST_HAS_PTHREADS)
# if defined(BOOST_HAS_SCHED_YIELD)
int res = 0;
res = sched_yield();
assert(res == 0);
# elif defined(BOOST_HAS_PTHREAD_YIELD)
int res = 0;
res = pthread_yield();
assert(res == 0);
# else
xtime xt;
xtime_get(xt, TIME_UTC);
sleep(xt);
# endif
#elif defined(BOOST_HAS_MPTASKS)
MPYield();
#endif
}
Taken from the main CVS.
Sleep(0) on Win32 will only yield to another thread of equal or higher
priority, not to lower priority threads.
In boost::detail::lightweight_mutex::scoped_lock, it is mentioned that
Sleep(1) will get around. Is the behaviour of Sleep(0) the intended use
of yield?
explicit scoped_lock(lightweight_mutex m): m_(m)
{
while( InterlockedExchange(m_.l_, 1) )
{
// Note: changed to Sleep(1) from Sleep(0).
// According to MSDN, Sleep(0) will never yield
// to a lower-priority thread, whereas Sleep(1)
// will. Performance seems not to be affected.
Sleep(1);
}
}
(I don't actually use yield yet, so currently have no preference for
either, but just wondered what the intended use of yield was)
Thanks
Russell
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
