Re: [boost] Boost header and library dependency tables
I think it's a good idea. But I have a few comments. First, it only handles headers that are directly under 'boost/'. However some people have tried not to pollute the root directory and have put their libraries in sub-directories. For example, the Graph library, uBlas, the Interval library, the mathematical libraries, and so on. And your script is unfortunately forgetting them. I know, I just wasn't sure which needed including. Second, the links at the top of the pages don't work with all browsers since the anchors are defined in a non-standard way. It shouldn't be a name=#boostaligned_storagehpp but a name=boostaligned_storagehpp (no sharp sign). With some quotes, it would be even better, but it's another problem. OK, that's an error in the shell script I used, easy enough to hack around Finally, what are library dependencies? Sorry if it's a dumb question. But by looking at the results, I don't get the meaning of it. It's everything that's needed by the complete library - by it's test and example programs etc as well as the headers - for most libraries this means that the Boost.test source will be listed as a dependency for example. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] alternative configuration technique
I found that boost has very powerful configuration system (boost/config.hpp and around...) but why use macros? there is another solution described here, let discuss it... may be there are some troubles, invisible for me, that prevent from using this technique in libraries like boost? I think that there are two problems: 1) Your scheme requires that all possible implementations can be parsed by the compiler - that won't be true for macros describing defects. 2) Your scheme can't cope with optional features (long long or someheader.h). Oh, and macros are probably simpler, if ugly. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost header and library dependency tables
On Sun, 8 Jun 2003, John Maddock wrote: [snip] Finally, what are library dependencies? Sorry if it's a dumb question. But by looking at the results, I don't get the meaning of it. It's everything that's needed by the complete library - by it's test and example programs etc as well as the headers - for most libraries this means that the Boost.test source will be listed as a dependency for example. Yes, it's what I thought at first. But the results are strange: I'm really surprised the MultiArray library relies on the Interval library headers. Regards, Guillaume ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: no semaphores in boost::thread
William E. Kempf wrote: I haven't seen your code to say for sure, but from the limited description I believe there's a very high probability that this is the case. Hm... I'm ready to accept the argument that having two separate synchronization primitives to do logically one task can be error-prone in non-trivial schemes. However, from what I understand, Stefan uses his semas in roughly this way: // get single element from queue 1a. semaphore_acquire 2a. mutex_lock 3a. get_elem_from_queue (some equivalent of front+pop_front) 4a. mutex_unlock // put single element into queue 1b. mutex_lock 2b. put_elem_to_queue (some equivalent of push_back) 3b. mutex_unlock 4b. semaphore_release I understand that there is a period of time when the program is running (and therefore is subject to preemption) between 1a and 2a, and that similar period of time happens between 3b and 4b. But I do not see the problem -- in typical usage these two pseudocode sequences are *the only* places in the application where the queue is accessed. That means that the only effect of race condition (resulting from preemption between 1a and 2a or between 3b and 4b) is that at some times the queue will actually have more elements than the sema's counter value. It is *not* a danger in the sense that there is no possibility to pop from the empty queue (once you get green light in 1a, you are sure that 3a will succeed, you just do not care how many elements there are, there is at least one for sure). I think that the argument about race conditions is valid when there are other places in code where the queue is accessed in some way and I understand that two separate synchronization objects make it more probable to write flawed code. However, in this simple example, either: - the race condition does not matter, or - I miss something obvious On the other hand (and being frank, it has to be stated loudly), the above pseudocode does not show that semas should be preferred over condvars... I write it for the sake of argument and better understanding of the rationale. -- Maciej Sobczak http://www.maciejsobczak.com/ Distributed programming lib for C, C++, Python Tcl: http://www.maciejsobczak.com/prog/yami/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: alternative configuration technique
John Maddock [EMAIL PROTECTED] writes: I found that boost has very powerful configuration system (boost/config.hpp and around...) but why use macros? there is another solution described here, let discuss it... may be there are some troubles, invisible for me, that prevent from using this technique in libraries like boost? I think that there are two problems: 1) Your scheme requires that all possible implementations can be parsed by the compiler - that won't be true for macros describing defects. 2) Your scheme can't cope with optional features (long long or someheader.h). Oh, and macros are probably simpler, if ugly. Yeah, the effort it would take to implement and maintain a one-line workaround in a 20-line function for different compilers would go through the roof. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
Edward Diener [EMAIL PROTECTED] writes: How does one get the latest Boost CVS source ? I have WinCVS but have never been able to figure out how to use it to get CVS source on the Internet anywhere. Would anyone like to run me through it ? I know it has something to do with server access but I am dumbfounded by the WinCVS doc, The easiest and most reliable way to use CVS to get the Boost CVS sources is to use the cvs command-line tool (a cvs.exe is part of your WinCVS installation) and to simply follow verbatim the instructions for anonymous CVS access at: http://sourceforge.net/cvs/?group_id=7586 Using boost for the modulename. It's only two lines you need to type. I know WinCVS is supposed to make things easier, but for many jobs it really doesn't - you have to figure out how the instructions everyone else uses can be translated into equivalent checkboxes and menu items in WinCVS, and eventually you need to understand how the command-line works because the abstraction layer provided by WinCVS always leaks the underlying implementation details. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Inter-FSM protocol discussion
Hi Andreas, I've taken the liberty of starting a new thread to talk about these inter-FSM protocol issues as they don't related directly to your current FSM lib submission. For the benefit of people cruising the archives at a later date, this conversation derives from this exchange: http://news.gmane.org/onethread.php?group=gmane.comp.lib.boost.develroot=%3Cbbjf53%24448%241%40main.gmane.org%3E --- After posting http://article.gmane.org/gmane.comp.lib.boost.devel/20971 (suggests that inter-FSM protocols need some sort of semantic concept checking that depends on metadata that characterizes the FSM's between which the protocol is being established), it occurred to me that all but the simplest protocols themselves depend on a FSM mechanism... So let me take another shot at it: Related to concept checking (references: Category theory [1], and Morphisms [2]): A category is given by two pieces of data: a class of objects and, for any two objects X and Y, a set of morphisms from X to Y. What I was trying to suggest is that the objects in the category are FSM's, and the set of morphisms defined for any two FSM's X and Y is a concept that needs to be checked. Speaking as a layman, and not a discrete math theorist, at first glimpse it would seem reasonable to think that the various flavors of morphism might provide us with a nomenclature for describing the set(s) of inter-FSM event exchanges that a protocol could legally define without violating the semantics of any of the FSM objects in the category. After thinking about it a little more and realizing that all but the simplest protocols are themselves based on some sort of FSM mechanism, maybe what we need is boost::fsm + boost::morphism to deal formally with protocols at a high-level. Totally shooting from the hip, we might for example consider codifying a concept hierarchy for the various flavors of morphisms (see p.151 of the BGL book or http://www.boost.org/libs/graph/doc/graph_concepts.html for an inspirational example). Climbing further out on the limb, such a library might leverage boost::property_map to aggregate the FSM's in a category (value_type == event source/sink metadata), and the actual morphism concept would be defined as a set of references into the property_map that performs concept check via boost::concept_check, and perhaps (wild speculation alert) generation of the code to actually implement the morphism mapping (i.e. wiring FSM event sources/sinks) via boost::mpl? This would provide compile-time concept checking and theoretically make it possible to design protocols at a very high-level of abstraction and leave the messy wiring to the C++ compiler (starts to blur the line between functional and imperative which is a good thing). I'm certain I've overlooked some important considerations. Viscerally, it feels like the right light to stumble towards though. Comments? - Chris Category theory entry on Wikipedia [1] http://www.wikipedia.org/wiki/Category_theory Morphism entry on Wikipedia [2] http://www.wikipedia.org/wiki/Morphism Ok, I see that concept checking could be helpful... I've been staring at the Wikipedia sections on Morphisms [1] and Group Theory [2] looking for a suitable nomenclature for describing these protocol concepts. Basically my idea is that the actual protocol would formally specify what flavor of *morphism it's attempting to establish and use information from FSM's in the group to determine if such a mapping is possible (the concept check) and if so, affect the mapping generically somehow (i.e. the protocol itself doesn't get involved with event types and data semantics directly). Unclear to me if this is done at compile time, runtime, or gasp both... What do you guys think of these ideas? Errr, while I got what a group is I don't really get what a *morphism is. The description is too formal for me and the examples don't help either. Moreover, I also fail to see the connection between groups and FSMs. Have I been drinking too much lately ;o)? Regards, Andreas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Managing boost dependencies
John M. wrote: The bcp utility is a tool for extracting subsets of Boost, it's useful for Boost authors who want to distribute their library separately from Boost, and for Boost users who want to distribute a subset of Boost with their application. John - Many thx for doing this, I'm sure it will come in handy. I've tried this out for date_time and noticed a couple things: 1) date_time includes tokenizer.hpp which includes token_iterator.hpp which includes token_functions.hpp. Unfortunately, token_functions.hpp is not copied so my compile failed. 2) When I copied the 'build' library the boost-build.jam file and Jamrules files in boost root directory were not copied so bjam commands complained. Seems like these last 2 can't be determined because there isn't any direct include... Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Interest in library generating streambufs from objectswith socket-like interfaces?
Jonathon T. wrote: I have several class templates for producing standard streambufs based on classes with read, write and seek functions (or a suitable subset thereof.) I have used them successfully to access tcp connections, cryptographic routines, OLE compound documents, zip files, etc. There are templates istreambuf and ostreambuf which perform either input or output exclusively, a template double_streambuf which behaves like an istreambuf glued to an ostreambuf, and a template bidirectional_streambuf which performs input and output using a single shared buffer with a single repositionable file pointer. In addition, template parameters can be used to specify code conversion and to turn off buffering, and a contained error object can be used to customize exception throwing. I there is any interest, I will post them at the vault. Jonathan -- I have an interest in this (sorry for the slow response) for a couple reasons. 1) I'd be interested in how this fits with the Boost Socket initiative http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket 2) I've written something similar for zip files, but looks like you may have a more general solution -- a toolkit for creating new streambuf types. If this is the case, it would be very handy. Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Math Constants Formal Review - is extensible.
You can seen an example of extending to a 'new' constant 'gamma' in the examples testFunctionConstants/gamma_function_constants.hpp. The example by Michael Kenniston also show how complex items could also be added (but not normally to avoid every program dragging in complex). Macros could also facilitate the process of course, and it could start with a macro defining the constant as a 40 decimal digit string. If Boosters agree that this scheme is an acceptable way to go, the the example and guidance could be made more helpful to provide the encouragement you rightly say is needed. But first the overall strategy needs agreement. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria LA8 8AB UK | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey | Sent: 07 June 2003 00:20 | To: [EMAIL PROTECTED] | Subject: [boost] RE: Math Constants Formal Review | | Another point I am missing is a way to extend the constants | for user-defined types. Something like numeric_limits | comes to mind. I think that this is a must-have feature as | people that write applications that need lots of these | constants are likely also using types with higher precision | that the standard types provided by the language. Without a | way to teach the constants-framework the new types, they | will create wrappers and thus they won't use the intended | boost-/standard-way to access the variables. | | Regards, Daniel | | ___ | Unsubscribe other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
| Genny wrote | Paul What I would like to get is agreement on the presentation | of constants. | | You mean macros vs. constant variables vs. inline functions? | This is another thing I didn't understand by looking at the | documentation: the FAQ section seems sometimes to imply you | have already done a choice in this regard; In the previous review, Boosters suggested strongly different views on different ways of presenting constants. As I have tried to explain, there are pros and cons and valid reasons for wanting all of these. for instance: | | Q. Why not use floating-point hardware constants? | A. Because only a few are available, they are often not the right | size, are not available on all processors, and most important | are sometimes not accurate enough. | | but then, in another point: | | Q. Why are functions like double pi() which return constants | provided? | A. It provides a framework whereby users can plug in special | implementation and hardware-specific versions. Indeed - so the _user_ needs to be able to make the choice, and this implies that a single representation of constants won't do. | Because some compilers may be able to produce smaller | and/or faster code.(For example, note that MSVC 7 Standard | edition only inlines __inline, so this will produce slower | and longer code). | | Maybe you meant: because some compilers generate better | code with a manifest constant and others better code with a | function? You could also say that - I'm open to suggestions. Paul ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Math Constants Formal Review
If someone would like to do this, I'd be grateful. (Memories of how to use commandlines and CVS have decayed). Paul Paul A Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] On Behalf Of Daryle Walker | Sent: 06 June 2003 23:47 | To: Boost | Subject: [boost] Re: Math Constants Formal Review | | | On Friday, June 6, 2003, at 6:45 AM, Jaap Suter wrote: | | Today is the start of the formal review of the Math | Constants library | by Paul Bristow. The review will run until Sunday June | 15th. I will | be serving as review manager. | | [SNIP] | You can find the latest documentation, including a bigger | FAQ section, | at: | | http://groups.yahoo.com/group/boost/files/MathConstants/ | Math_Constants_doc_3.zip | | Some examples are available at: | | http://groups.yahoo.com/group/boost/files/MathConstants/ | Math_Constants3.zip | [TRUNCATE] | | In the previous review, copies of the code and documentation of the | Command Config Option library were copied to the web space | SourceForge reserved for the Boost-Sandbox. Maybe we could | do the same | for this review (and all later ones). | | Daryle | | ___ | Unsubscribe other changes: | http://lists.boost.org/mailman/listinfo.cgi/b| oost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
John Maddock [EMAIL PROTECTED] writes: Folks, I've put together a small tool for managing boost dependencies called bcp (for boost copy). The bcp utility is a tool for extracting subsets of Boost, it's useful for Boost authors who want to distribute their library separately from Boost, and for Boost users who want to distribute a subset of Boost with their application. ~ As usual comments etc are most welcome, All I can say is that this is totally awesome, and thank you. also should a utility/tool such as this go through the review process I don't think it needs to. We review libraries, but traditionally tools are just checked in if they seem useful or are known to be needed. This one is. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost header and library dependency tables
John Maddock [EMAIL PROTECTED] writes: A while ago Beman produced header dependency tables, unfortunately these began to get rather complicated and so were dropped, I've placed some alternative tables here: Boost header dependencies: http://www.regex.fsnet.co.uk/header_dependencies.html Boost library dependencies: http://www.regex.fsnet.co.uk/library_dependencies.html Whether these are actually any better than what we had before is questionable, but the information might prove useful to some. BTW these tables are produced using bcp in list mode (see separate thread). What I really want to see for something called library dependencies is the list of other libraries (not headers) that a library depends on. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
David Abrahams wrote: Edward Diener [EMAIL PROTECTED] writes: How does one get the latest Boost CVS source ? I have WinCVS but have never been able to figure out how to use it to get CVS source on the Internet anywhere. Would anyone like to run me through it ? I know it has something to do with server access but I am dumbfounded by the WinCVS doc, The easiest and most reliable way to use CVS to get the Boost CVS sources is to use the cvs command-line tool (a cvs.exe is part of your WinCVS installation) and to simply follow verbatim the instructions for anonymous CVS access at: http://sourceforge.net/cvs/?group_id=7586 Using boost for the modulename. It's only two lines you need to type. OK, thanks ! Those two lines should get me started. I know WinCVS is supposed to make things easier, but for many jobs it really doesn't - you have to figure out how the instructions everyone else uses can be translated into equivalent checkboxes and menu items in WinCVS, and eventually you need to understand how the command-line works because the abstraction layer provided by WinCVS always leaks the underlying implementation details. I will use the command lines above but I am still thinking that there must be a way to do things via WinCVS which allows me to access Boost CVS from within WinCVS's GUI environment. I will look at the WinCVS site to see if there are NGs or mailing lists that might help me out. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review
On Sun, 8 Jun 2003 15:56:53 +0100, Paul A Bristow [EMAIL PROTECTED] wrote: If someone would like to do this, I'd be grateful. (Memories of how to use commandlines and CVS have decayed). IIUC, the boost sandbox is, so to speak, a more precious resource than the Yahoo files section. So, unless there's a need to develop there (for instance because many people should simultaneously work at the files, or because it's appropriate to have a record of all the changes and who made them) the Yahoo section or any private web spaces should be preferred. It seems a waste to use a cvs repository just to provide a place to get things from. But, maybe, the policy is different and I don't know. It would be nice to have a confirmation. I'm sure Beman or Dave can give it. Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] WinCVS note
I also had problems getting WinCVS to work to taste. I was frustrating as I didn't need to go into the whole facility - I just wanted a sync'ed local copy. I bought a book on CVS but it started to consume a lot of time to use I finally got WinCVS to create a new local copy by using the command line functionality ( login, etc) included in WinCVS. From then on the sync stuff (update) worked fine (though I had to search around for an option in the update). I suspect that WinCVS is a little bit behind the complete CVS syntax. I suppose there might be a lesson here but I've move on. Robert Ramey Edward Diener [EMAIL PROTECTED] writes: How does one get the latest Boost CVS source ? I have WinCVS but have never been able to figure out how to use it to get CVS source on the Internet anywhere. Would anyone like to run me through it ? I know it has something to do with server access but I am dumbfounded by the WinCVS doc, The easiest and most reliable way to use CVS to get the Boost CVS sources is to use the cvs command-line tool (a cvs.exe is part of your WinCVS installation) and to simply follow verbatim the instructions for anonymous CVS access at: http://sourceforge.net/cvs/?group_id=7586 Using boost for the modulename. It's only two lines you need to type. I know WinCVS is supposed to make things easier, but for many jobs it really doesn't - you have to figure out how the instructions everyone else uses can be translated into equivalent checkboxes and menu items in WinCVS, and eventually you need to understand how the command-line works because the abstraction layer provided by WinCVS always leaks the underlying implementation details. Dave Abrahams ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost]Interest in library generating streambufs from objects
This a very ripe subject My interest stems from my efforts regarding a serialization library. I have had occasion to consider alternatives in this light. I have looked at Jeffs compression streambuf. I think its interesting, useful and nicely done. Given this, maybe you should set your sights even higher. I think it would be more interesting if the following were considered a) composability - suppose I have an encryption facility and a compression facility. I would like to be able to make a streambuf the compresses thhen encryrpts or vice versa. b) suppose I add other facilities such as escaping/unescaping ascii characters, convert to/from wide characters, etc. I should be able to compose these in an arbitray way. c) this suggests to me: i) a implemention set of composable iterator adaptors. ii) a streambuf that can filter input/output through an itererator adaptor. This MIGHT be implemented as a codecvt facet that takes an interator adaptor as an argument. d) This would have the advantage that the conversion facilities would be useful way beyond streambuf e) currently, the new iterator adaptor package doesn't include an example that is suitable for use as a basis for such conversion or transformational adaptors. But its not hard to make one. To summarize, I would like see the concept of adaptable sequence factored out of streambuf and a streambuf built that can use any adaptable sequence. Robert Ramey Jeff Garland wrote Jonathon T. wrote: I have several class templates for producing standard streambufs based on classes with read, write and seek functions (or a suitable subset thereof.) I have used them successfully to access tcp connections, cryptographic routines, OLE compound documents, zip files, etc. There are templates istreambuf and ostreambuf which perform either input or output exclusively, a template double_streambuf which behaves like an istreambuf glued to an ostreambuf, and a template bidirectional_streambuf which performs input and output using a single shared buffer with a single repositionable file pointer. In addition, template parameters can be used to specify code conversion and to turn off buffering, and a contained error object can be used to customize exception throwing. I there is any interest, I will post them at the vault. Jonathan -- I have an interest in this (sorry for the slow response) for a couple reasons. 1) I'd be interested in how this fits with the Boost Socket initiative http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket 2) I've written something similar for zip files, but looks like you may have a more general solution -- a toolkit for creating new streambuf types. If this is the case, it would be very handy. Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] random lib: Quasi-random generators
Hi, Have anyone involved in the random lib and its standardization considered a couple of quasi-random generators? I have recently heard of the fancy named quasi stuff which simply means that the numbers fill the range more uniformly than normal pseudo-random sequences. These sequences are important for Quasi Monte Carlo integration and for applications that need to destribute N samples uniformly in some way without knowing N in advance. regards Thorsten source: Numerical recipes in C++, second edition, p. 313ff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: no semaphores in boost::thread
well, unless (likely given this biz) the words have changed meaning again, naked semaphore was described by Dijkstra way back when (1964??) a mutex was a variant of a semaphore which restricted signalling (V()) to the task/process/thread/whatever that had successfully waited (P()) on it. often a mutex would allow the _same_ task/process/thread... to wait (P()) multiple times on the same mutex withOUT deadlock, but would have to signal (V()) the correct number of times before the mutex would be released. Now if the definitions have changed, I apologize for the mis-understanding. If you have some OTHER definition that discriminates between semaphore and mutex, I'd be happy to hear it. If not, why do we have two words for the same thing? btw, note that IF my definition is correct, then at a minimum a mutex must do more work than a semaphore (since it must establish ownership of the mutex). At Thursday 2003-06-05 09:48, you wrote: Victor A. Wagner, Jr. wrote: I'm baffled that they want to penalize (time and space) those for whom a naked semaphore works. Show me please an example illustrating naked semaphore in work. It's blatantly clear to anyone who's had to write a mutex that it's additional code on TOP of a semaphore. Optimization strategies aside for a moment (they are different for mutexes and semaphores) a binary semaphore can be used as normal POSIX mutex. ftp://gatekeeper.research.compaq.com/pub/DEC/SRC/research-reports/SRC-020.pdf Mutexes and semaphores A mutex is represented by a pair (Lock-bit, Queue). The Lock-bit is 1 if a thread is in a critical section protected by the mutex, and is 0 otherwise. In terms of the formal specification, the Lock-bit is 0 iff the mutex is NIL. The Queue contains the threads that are blocked in Acquire (awaiting its WHEN condition). The user code for Acquire and Release is designed for fast execution of a LOCK clause when there is no contention for its mutex. In this case an Acquire-Release pair executes a total of 5 instructions, taking 10 microseconds on a MicroVAX II. This code is compiled entirely in-line. Acquire consists of two sequential actions: test-and-set the Lock-bit (implemented atomically in the hardware); call a Nub subroutine if the bit was already set. The user code for Release is two sequential actions: clear the Lock-bit; call a Nub subroutine if the Queue is not empty. The Nub subroutine for Acquire (after acquiring the spin-lock) first adds the calling thread to the Queue. Then it tests the Lock-bit again. If it is still 1, this thread is de-scheduled and the general scheduling algorithm is invoked to determine what to do with this processor. On the other hand, if the Lock-bit is now 0, the thread is removed from the Queue, the spin-lock is released, and the entire Acquire operation (beginning at the test-and-set) is retried. The Nub subroutine for Release (after acquiring the spin-lock) checks to see if there are any threads in the Queue. If there are, it takes one, adds it to the ready pool, and invokes the general scheduling algorithm, which will assign the thread to a suitable processor if one is available. The implementation of semaphores is the same as mutexes: P is the same as Acquire and V is the same as Release. regards, alexander. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] patch for date_time library
Synge - I have applied a fix that is equivalent to your patch. Let me know if it works. Sorry to be so slow on this... Jeff -Original Message- [mailto:[EMAIL PROTECTED] Behalf Of Synge Todo Sent: Thursday, May 29, 2003 10:15 PM Subject: [boost] patch for date_time library Dear Boosters, SGI MIPSpro C++ can not compile programs, which use date_time library. The compiler complains as follows: cc-3354 CC: ERROR File = /home/i004/i00400/src/boost/boost/date_time/time_system_split.hpp, Line = 35 A non-integral operation is not allowed in a nontype template argument. typedef date_time::wrapping_intint_type, INT64_C(86400) * config::tick_per_second wrap_int_type; I attached a simple workaround to solve this problem. Could someone apply this patch? Thank you in advance. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: RE: Math Constants Formal Review - is extensible.
On Sun, 08 Jun 2003 16:56:53 +0200, Paul A Bristow wrote:
You can seen an example of extending to a 'new' constant 'gamma' in the
examples testFunctionConstants/gamma_function_constants.hpp.
Either I don't understand the example or we are talking past each other. I
don't meant to extend the framework with new constants, but with
definitions of existing constants for new types. Maybe the attached
example of a small experiment of mine clarifies what I was thinking about.
Look at the Roguewave-extension for pi. If I imagine to use
boost/math_constants.hpp in the company I work, it would be encapsulated
into another header base/math_constants.h and it would provide all
constants for Roguewawve's decimal type, too. I already used the
lambda-library and tought it about the decimal type, which worked very
smooth and I was really happy to see that the library designers didn't
limited it to build-in types. A key-feature for me!
defining the constant as a 40 decimal digit string.
Roguewave's types can be used with precisions up to 1024 bits - probably
more. I don't think that a one-size-fits-all approach can work in the area
of numeric computations.
If Boosters agree that this scheme is an acceptable way to go, the the
example and guidance could be made more helpful to provide the
encouragement you rightly say is needed.
But first the overall strategy needs agreement.
Indeed. So if I still missed that the constants can be provided by the
user for their types, please let me know. Otherwise, we should find a
consensus whether such a feature is needed. I personally think it is, but
if the majority thinks it's not that important... :)
Note that the attached file is not meant to offend you in any way. It way
just a toy example and maybe you can take some ideas out of it. It's not
meant to replace your code as I think you have put a lot of ideas in it
and provide features I don't even know of :)
Regards, Daniel
---
#include iostream
using namespace std;
namespace math
{
// Generic base class for all constants
template typename T, template class class F struct constant
{
// A cast-to-anything-operator :)
template typename U operator U() const { return F U ()(); }
#define ADD_OPERATOR( OP ) \
template typename U friend U operator OP( const T lhs, const U rhs ) \
{ U nrv( static_cast U ( lhs ) ); nrv OP##= rhs; return nrv; } \
template typename U friend U operator OP( const U lhs, const T rhs ) \
{ U nrv( lhs ); nrv OP##= static_cast U ( rhs ); return nrv; }
ADD_OPERATOR( + );
ADD_OPERATOR( - );
ADD_OPERATOR( * );
ADD_OPERATOR( / );
#undef ADD_OPERATOR
};
// Here's the definition for pi for all types (can be extended by UDTs):
template typename T struct pi_value;
template struct pi_value float { float operator()() const { return 3.14; } };
template struct pi_value double { double operator()() const { return 3.1416;
} };
template struct pi_value long double { long double operator()() const {
return 3.1415927; } };
/*
// For expensive constructions, maybe this is an option:
template struct pi_value RWDecimal RWMP3Int {
const RWDecimal RWMP3Int operator()() const {
static const RWDecimal RWMP3Int value( 3.1415926535897932384626433832
);
return value;
}
};
*/
// Here's the single line to create a useful interface
struct pi_t : constant pi_t, pi_value {} pi;
// Another one:
template typename T struct pi2_value;
template struct pi2_value float { float operator()() const { return 9.87; } };
template struct pi2_value double { double operator()() const { return 9.8696;
} };
template struct pi2_value long double { long double operator()() const {
return 9.8696044; } };
struct pi2_t : constant pi2_t, pi2_value {} pi2;
// And their relationship:
pi2_t operator*( const pi_t, const pi_t ) { return pi2_t(); }
// Some obvious (?) constants:
#define CONSTANT_VALUE( name, value ) \
template typename T struct name##_value { T operator()() const { return value;
} }; \
struct name##_t : constant name##_t, name##_value {} name;
CONSTANT_VALUE( minus_one, -1 );
CONSTANT_VALUE( zero, 0 );
CONSTANT_VALUE( one, 1 );
CONSTANT_VALUE( two, 2 );
CONSTANT_VALUE( three, 3 );
CONSTANT_VALUE( ten, 10 );
#undef CONSTANT_VALUE
minus_one_t operator-( const one_t ) { return minus_one_t(); }
one_t operator-( const minus_one_t ) { return one_t(); }
zero_t operator-( const zero_t ) { return zero_t(); }
// Another one:
template typename T struct half_pi_value;
template struct half_pi_value float { float operator()() const { return 1.57;
} };
template struct half_pi_value double { double operator()() const { return
1.5708; } };
template struct half_pi_value long double { long double operator()() const {
return 1.5707963; }
[boost] Re: Managing boost dependencies
Edward Diener [EMAIL PROTECTED] writes: David Abrahams wrote: Edward Diener [EMAIL PROTECTED] writes: How does one get the latest Boost CVS source ? I have WinCVS but have never been able to figure out how to use it to get CVS source on the Internet anywhere. Would anyone like to run me through it ? I know it has something to do with server access but I am dumbfounded by the WinCVS doc, The easiest and most reliable way to use CVS to get the Boost CVS sources is to use the cvs command-line tool (a cvs.exe is part of your WinCVS installation) and to simply follow verbatim the instructions for anonymous CVS access at: http://sourceforge.net/cvs/?group_id=7586 Using boost for the modulename. It's only two lines you need to type. OK, thanks ! Those two lines should get me started. I know WinCVS is supposed to make things easier, but for many jobs it really doesn't - you have to figure out how the instructions everyone else uses can be translated into equivalent checkboxes and menu items in WinCVS, and eventually you need to understand how the command-line works because the abstraction layer provided by WinCVS always leaks the underlying implementation details. I will use the command lines above but I am still thinking that there must be a way to do things via WinCVS which allows me to access Boost CVS from within WinCVS's GUI environment. Oh, there certainly is; I used to use it. I'm just telling you that in the end you will work harder, possibly much harder, to become effective with CVS if you try to do that. That's in part because WinCVS tries to hide CVS's model of operation a bit, even though it's just a CVS wrapper. If you learn the command-lines first, though, you'll immediately understand what all of the WinCVS operations do since the abstraction layer provided by WinCVS is actually fairly thin. I will look at the WinCVS site to see if there are NGs or mailing lists that might help me out. Suit yourself; I'm trying to suggest that you not waste your time, at least as first, and instead dig into http://cvsbook.red-bean.com/ -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
David Abrahams wrote: Edward Diener [EMAIL PROTECTED] writes: David Abrahams wrote: Edward Diener [EMAIL PROTECTED] writes: I will look at the WinCVS site to see if there are NGs or mailing lists that might help me out. Suit yourself; I'm trying to suggest that you not waste your time, at least as first, and instead dig into http://cvsbook.red-bean.com/ Thanks for the link. Do realize that people are different and that my programming preference is almost always to use a GUI interface over command lines as long as the GUI interface lets me do what I want to accomplish. Of course I write actual code in a fancy editor just like everyone else g. I will dig into the .pdf version of the link first, although my initial reaction to CVS was not joyful, but I am sure it can not be that arcane to use. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Managing boost dependencies
Edward Diener [EMAIL PROTECTED] writes: David Abrahams wrote: Edward Diener [EMAIL PROTECTED] writes: David Abrahams wrote: Edward Diener [EMAIL PROTECTED] writes: I will look at the WinCVS site to see if there are NGs or mailing lists that might help me out. Suit yourself; I'm trying to suggest that you not waste your time, at least as first, and instead dig into http://cvsbook.red-bean.com/ Thanks for the link. Do realize that people are different and that my programming preference is almost always to use a GUI interface over command lines as long as the GUI interface lets me do what I want to accomplish. I do realize that. I have the same preference, but I found WinCVS to be somewhat opaque and mysterious until I learned the command-line stuff. Of course I write actual code in a fancy editor just like everyone else g. I will dig into the .pdf version of the link first, although my initial reaction to CVS was not joyful, but I am sure it can not be that arcane to use. Maybe it is, but I think it's better than trying to learn CVS the other way. Once you understand CVS itself, there are any number of front-ends (WinCVS, emacs vc and pcl-cvs modes, something that integrates with the windows file browser - I forget the name) that you can use and will make total sense. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Command Line Config review results
At 09:12 AM 6/5/2003, Aleksey Gurtovoy wrote: Vladimir Prus wrote: There've been a fair amount of suggested changes, many of which are documented on Wiki [1], and since the author himself keeps track of the issues, I won't reiterate them here - except for stressing the need for a) extensively reworked and extended documentation, and Completely agree. b) resolving the 'wchar_t' support issue before the library makes into official Boost distribution. I'm actually not that happy about solving general issue alone... You don't have to. I am sure a lot of people on this list have dealt with the issue and would be happy to help you out. There may be a confusion here. Lots of people have experience with wchar_t and other non-char types in applications where the internal and external character set, type, size, and encoding are all the same. But I think command line arguments have to interoperate with the operating system. That means the internal and external character set, type, size, or encoding may be different. While some people have experience with character set conversions on specific operating systems, finding people who have solutions which work portably across multiple operating systems is much harder. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Command Line Config review results
At 10:48 AM 6/4/2003, Vladimir Prus wrote: Aleksey Gurtovoy wrote: b) resolving the 'wchar_t' support issue before the library makes into official Boost distribution. I'm actually not that happy about solving general issue alone... but let it be. I assume I've not asked to implement any specific approach, and can decide myself? I've just about finished an extensive analysis of the issues involved when wchar_t and other non-char types are used in filenames. Many of these issues, including the key interoperability requirements, will apply to command line arguments or any other communication where the character type, size, or encoding differs between internal use in a user program and external use by the operating system. It would be unwise and chaotic for the Boost filesystem and command line libraries to have different external to internal conversion behaviors. Also, those issues are fairly orthogonal to the other big picture aspects of a command line library design. All that argues for not trying to add wchar_t support to the command line library right away. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Math Constants Formal Review
At 01:57 PM 6/8/2003, Gennaro Prota wrote: On Sun, 8 Jun 2003 15:56:53 +0100, Paul A Bristow [EMAIL PROTECTED] wrote: If someone would like to do this, I'd be grateful. (Memories of how to use commandlines and CVS have decayed). IIUC, the boost sandbox is, so to speak, a more precious resource than the Yahoo files section. So, unless there's a need to develop there (for instance because many people should simultaneously work at the files, or because it's appropriate to have a record of all the changes and who made them) the Yahoo section or any private web spaces should be preferred. It seems a waste to use a cvs repository just to provide a place to get things from. But, maybe, the policy is different and I don't know. It would be nice to have a confirmation. I'm sure Beman or Dave can give it. What Daryle is talking about is not the sandbox CVS itself, but boost-sandbox project web space that you get from SourceForge, separate from the CVS. We use that space on the main boost SourceForge project for publishing daily regression tests, for example. Yes, it would definitely be a good idea. It means that those wishing to grab code for a review do not have to deal with yahoogroups. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Some questions on the FSM submission
Hi Jeff, for a telecom product. It was great if what you were doing fit well into SDL, but plugging in say an std::list was a nightmare -- basically undoable (C wrappers and such). He hated every minute. Me too :-))) 4) I think you are right that your submission can cover most of the ground of both. That said, I for one, think that coverage of UML is the more important of the two. A few developers I've met actually understand something about UML state diagrams. Barely any have any idea about SDL and I've worked on various telecom projects for at least 8 years... Agreed. Andreas has it covered. Perceived competition between UML and SDL is a bit of a fizzer in that they have the same roots and huge overlap in goals? Didnt see it like this myself until recent catch-up. UML wins on familiarity and comfort? Your point about few developers is spot-on. Consistent with a recent CUJ article that tried to sell the value of state-machines. Used the example of a VB implementation of calc.exe to highlight the fact that we (developers at large) tend to avoid proper handling of async events. Its everywhere (GUIs, devices, networks...) and yet a low percentage of software solutions are formalized with the likes of UML. Maybe boost::fsm is going to be sexy enough to lure a few more developers? PS: 8 years of telecoms without SDL? Almost jealous ;-) Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
