Re: [boost] Re: Boost preprocessor library
- Original Message - From: "Pavel Vozenilek" <[EMAIL PROTECTED]> > > I see many pre-processor macros in the reference section of the > > documentation but I don't see any good overview explaining the various > > macros or groups of macros and the ideas behind them. > [snip] > > The "Topics" section gives the overview, just follow the individual pages in > their order. The docs is IMHO very well written. Thanks for your opinion, Pavel. I have far more difficulty writing legible, well-structured documentation that I have writing the code. There is still much room for improvement though Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost preprocessor library
- Original Message - From: "Edward Diener" <[EMAIL PROTECTED]> > I see many pre-processor macros in the reference section of the > documentation but I don't see any good overview explaining the various > macros or groups of macros and the ideas behind them. The directory groupings of the library's headers are a pretty obvious clue for most of the preprocessor library (e.g. directory names such as "arithmetic" and "repetition"). While there is no "general overview" for the time being, you can look at the directory structure (which is included in the documentation) and get a pretty good idea of what is in the library. The library includes facilities for arithmetic, logical, and comparison operations, repetition constructs (horizontal and vertical), control structures (such as "if" and "while"), manipulation of several data types with unique properties, and a myriad of miscellaneous tools and facilities to help with using the afore mentioned groups. > What I am looking for > is a good overview of what macros are in the library. One section shows > examples, but they seem very random and don't seem to explain functionality > or ideas very well. Nearly every reference document for a particular macro includes a simple example. The examples in those parts don't usually do anything incredibly useful. They just exist to show how the respective macro *can* be used. There is no set group of domains to which the pp-lib caters. You use it to do whatever it is that you want to do. (The pp-lib does, however, excel at repetition.) Many of the facilities in the library are similar to the low-level capabilities of a regular old "if" or "while". Discussing at length what constructs like this are good for would only complicate the documentation even more than it already is. The documentation provides a reference of all macros (etc.) in the library and shows how to use them. How you use them and what you use them for is up to you. If you have a specific question or a general idea of what you want to accomplish, you can always ask me. I can point you in the right direction, give you advice, and tell you if it can or cannot be done. Dealing with the preprocessor as a programming environment is like learning a whole new language--one that doesn't even have many language features that are taken for granted (i.e. arithmetic, looping, flow control, etc.), so you have to expect that it takes some experimentation and experience to understand it. I will help you in every way that I can. > The preprocessor library would be much more understandable if the ideas > behind the macros were discussed and if an overview allowed end users to > understand what is in the library. The fundamental reason that the library is inaccessable and has such a step learning curve is that the library is not written in C++ (or even C). It is written in Cpp. Furthermore, it is like any other library written to be used by a specific language. You must have a reasonable understanding of the language in order to use the library. This requires more than a minimal conceptual understanding of Cpp, but a nitty-gritty "what-happens-when-and-what-doesn't-happen-and-why". That is what makes it steep. I agree that the documentation can be improved considerably, but that is also a massive undertaking. Consider the available documentation on C++ idioms. The literature is spread over thousands of books, articles, and decades of algorithmic lore. The available literature for programming in Cpp is largely confined to one place (that I know of), and that is the documentation for Boost's pp-lib. I am certainly not saying that Cpp is on par with a general purpose programming language (such as C++) as far as the raw number of unique idioms, but it has great many nonetheless, and the primary purpose of the documentation is to describe the library, not the language. > I have a feeling there are some valuable > techniques there, as the library has been muched praised, but I can't > discern how they macros are organized to provide functionality. I'm not sure what you mean here. Are you saying that the docs should discuss the implementation of the library as well as what the library can do? The internal implementation of the library uses some fairly advanced techniques, and it is hacked into incomprehensibility to support extremely buggy preprocessors (such as Metrowerks and Microsoft). The high-precision arithmetic support, which I have working on everything but Metrowerks, uses more advanced techniques than the entire rest of the library combined (which is what makes Metrowerks such a pain in the ***), not to mention the amount of tricks involving C99's variadic macros and placeholder arguments that I have up my sleve. (BTW, Dave, any word on the "work" Metrowerks is supposedly doing on their preprocessor?) The documentation does have some significant articles on the library facilities that require the user to use more advanced techniques,
RE: [boost] Re: Re: Re: Re: [multiarray] compiling problem
> From: Thorsten Ottosen [mailto:[EMAIL PROTECTED]] > > >Additionally, creating > > patches using the latest files from CVS makes them very > easy to apply. > if one have cvs access, I pressume :-) > No, there's anonymous read access to CVS - see http://www.boost.org/more/download.html and http://sourceforge.net/cvs/?group_id=7586. Of course, when applying the patches, write access helps ;-). Bjorn ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost preprocessor library
- Original Message - From: "Edward Diener" <[EMAIL PROTECTED]> Newsgroups: gmane.comp.lib.boost.devel Sent: Monday, January 13, 2003 6:43 PM Subject: Re: Boost preprocessor library [snip] > I see many pre-processor macros in the reference section of the > documentation but I don't see any good overview explaining the various > macros or groups of macros and the ideas behind them. [snip] The "Topics" section gives the overview, just follow the individual pages in their order. The docs is IMHO very well written. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: sockets library question
>> Sockets seems to be actively under development at the moment. Most of >> the activity seems to be on the Wiki at the moment though: >> >> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket > >Ah! > >Yes, that looks more promising. > >Thanks for the redirect! And more than that, there is a recent implementation based on the Wiki web pages in the boost-sandbox. Sockets is a library that has had a number of false starts. Hugo Duncan has been the key driver of this new effort, but I know he would love to have help. I believe we have gradually built enough base that if we could find a few volunteers with a some time to invest we could finally get a kernal of the library available for review. You can browse the boost sandbox socket stuff at: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost- sandbox/libs/socket/ or find out more about download access to the sandbox from http://sourceforge.net/projects/boost-sandbox/ Anyway, download it, compile it, update the Wiki -- give us feedback... Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost preprocessor library
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "Edward Diener" <[EMAIL PROTECTED]> writes: > > > I don't see any organizational principle in the documentation for explaining > > the various macros in the Boost preprocessing library. Would someone please > > point me in the right direction ? > > I think you will have to ask more-specific questions. I see many pre-processor macros in the reference section of the documentation but I don't see any good overview explaining the various macros or groups of macros and the ideas behind them. What I am looking for is a good overview of what macros are in the library. One section shows examples, but they seem very random and don't seem to explain functionality or ideas very well. The preprocessor library would be much more understandable if the ideas behind the macros were discussed and if an overview allowed end users to understand what is in the library. I have a feeling there are some valuable techniques there, as the library has been muched praised, but I can't discern how they macros are organized to provide functionality. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost preprocessor library
- Original Message - From: "Edward Diener" <[EMAIL PROTECTED]> > I don't see any organizational principle in the documentation for explaining > the various macros in the Boost preprocessing library. Would someone please > point me in the right direction ? I'm not sure what you mean. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost preprocessor library
"Edward Diener" <[EMAIL PROTECTED]> writes: > I don't see any organizational principle in the documentation for explaining > the various macros in the Boost preprocessing library. Would someone please > point me in the right direction ? I think you will have to ask more-specific questions. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] A little problem with unit-test
Guillaume Melquiond <[EMAIL PROTECTED]> writes: > Hi, > > I'm quite annoyed with 'unit-test' in a Jamfile. I don't know if it's my > fault or not, but I hope somebody can help me with this problem. > 'unit-test' doesn't seem to work anymore. Indeed, some times ago, when I > was launching 'bjam ...', test programs were compiled, linked, chmod'd and > finally run. > > Now test programs are still compiled, linked and chmod'd, but they are not > run anymore. So the whole test-suite of the interval lib has lost its > meaning. Did I overlook something? Or maybe I should use something else? > > My CVS is up to date. I did rebuild bjam. And, of course, test programs > don't fail to compile (it goes till the chmod). Fixed in CVS. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: sockets library question
"Alisdair Meredith" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > "Blue, Reginald V" wrote: > > Sockets seems to be actively under development at the moment. Most of > the activity seems to be on the Wiki at the moment though: > > http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket Ah! Yes, that looks more promising. Thanks for the redirect! ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun, only handled by vc6/7! - iter_adapt_patch (1/1)
On Mon, 13 Jan 2003 15:30:36 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >David Abrahams <[EMAIL PROTECTED]> writes: > >> Heck, you're right! The parser just gives a misleading error >> message. I found a much cleaner fix along these lines; testing now >> and will check in shortly. Thanks for the hint! >> >> Gennaro Prota <[EMAIL PROTECTED]> writes: >> > >Done now. Seen :-) Yes, this way it's much cleaner. Incidentally, the problem of base class forwarding you had here is common but I didn't notice it was that problem when seeing bjam's output, I just saw that there were errors in files other than the one I modified and thought to ask you before trying further modifications and/or beginning speculating. Also, guessing in advance that it wasn't really a parsing problem would have been difficult, because Borland does have parsing problems (a simple example is in dynamic_bitset's constructor from basic_string, as you may see from the comments) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: sockets library question
"Blue, Reginald V" wrote: > The question I have is: Is it likely for any of them to make it into the > main CVS stream? I'm quite the lurker too Sockets seems to be actively under development at the moment. Most of the activity seems to be on the Wiki at the moment though: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket I'm also lurking there. Hoping to find time to get involved, but there's never enough hours in the day :¬ ( -- AlisdairM Team Thai Kingdom ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] sockets library question
On Monday 13 January 2003 04:58 pm, Blue, Reginald V wrote: > I've recently joined this list, and I've lurked for a bit (trying to get > the feel of the group), but I'm still not sure if this is on topic or not. > If I need to be redirected elsewhere, please let me know. Welcome! This is perfectly on-topic for this list. > I noticed in the Sandbox CVS there are several socket implementations and, > presumably, they're all based on streams. > > The question I have is: Is it likely for any of them to make it into the > main CVS stream? > > Personally, I think it's a good idea that one of them does make it into the > main CVS stream (as TCP/IP is quite ubiquitous these days...perhaps more so > than threads.) I agree. I believe that we need networking support in Boost (and in the C++ standard), but I do not know the status of any of the existing socket implementations. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost preprocessor library
I don't see any organizational principle in the documentation for explaining the various macros in the Boost preprocessing library. Would someone please point me in the right direction ? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] sockets library question
I've recently joined this list, and I've lurked for a bit (trying to get the feel of the group), but I'm still not sure if this is on topic or not. If I need to be redirected elsewhere, please let me know. I noticed in the Sandbox CVS there are several socket implementations and, presumably, they're all based on streams. The question I have is: Is it likely for any of them to make it into the main CVS stream? Personally, I think it's a good idea that one of them does make it into the main CVS stream (as TCP/IP is quite ubiquitous these days...perhaps more so than threads.) Thanks for your time. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: some thoughts about serialisation
Dave Harris wrote: > How do you see archive versioning being done? For example, suppose field > TOTAL is a double in version 1 and a fixed-point user-defined type in > version 2. The easy way would be to let a class have multiple class descriptors (one for each version) and add the version number to the archive. I havent figured out a hard war yet :) best regards, Ares Lagae ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] A little problem with unit-test
Hi, I'm quite annoyed with 'unit-test' in a Jamfile. I don't know if it's my fault or not, but I hope somebody can help me with this problem. 'unit-test' doesn't seem to work anymore. Indeed, some times ago, when I was launching 'bjam ...', test programs were compiled, linked, chmod'd and finally run. Now test programs are still compiled, linked and chmod'd, but they are not run anymore. So the whole test-suite of the interval lib has lost its meaning. Did I overlook something? Or maybe I should use something else? My CVS is up to date. I did rebuild bjam. And, of course, test programs don't fail to compile (it goes till the chmod). Thanks, Guillaume ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread &amp; OSerror code.
"William E. Kempf" <[EMAIL PROTECTED]> writes: > David Abrahams said: >> "William E. Kempf" <[EMAIL PROTECTED]> writes: >> >>> David Abrahams said: "William E. Kempf" <[EMAIL PROTECTED]> writes: >> People said they wanted it, and the cost is low (one int). I think >> Greg is right that they wanted to attempt system-dependent >> recovery. > > Well, I can agree that the cost is low... so I won't argue too much > about including it. I just want to feel comfortable with the > rationale. I think a rationale goes like this: suppose the platform gives you a function for converting an error code into an error message (realistic, I think). How much code do you have to write in order to take advantage of it? >>> >>> Contrasted with, "If a platform has the ability, the error is >>> translated into a message that's returned as part of what()." That's >>> where I feel uncomfortable with the reationale. >> >> Remember that it's a bad idea to carry dynamically-allocated state in an >> exception object. Translating to readable strings at the throw point is >> ill-advised. > > Agreed, but that's an implementation detail. IOW, the exception should > carry the error code, but what purpose is there in having the interface > expose this detail? > > BTW: The filesystem_error carries a lot of dynamically-allocated state > (as in 1/2 of the member data is, at least potentially, allocated). Lots of platforms have callback interfaces where if the callback fails it may need to pass an error code back to the caller. If you couldn't easily get the original error code back this could be a serious pain. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread &amp;OS error code.
David Abrahams said: > "William E. Kempf" <[EMAIL PROTECTED]> writes: > >> David Abrahams said: >>> "William E. Kempf" <[EMAIL PROTECTED]> writes: >>> > People said they wanted it, and the cost is low (one int). I think > Greg is right that they wanted to attempt system-dependent > recovery. Well, I can agree that the cost is low... so I won't argue too much about including it. I just want to feel comfortable with the rationale. >>> >>> I think a rationale goes like this: >>> >>> suppose the platform gives you a function for converting an error >>> code into an error message (realistic, I think). How much code do >>> you have to write in order to take advantage of it? >> >> Contrasted with, "If a platform has the ability, the error is >> translated into a message that's returned as part of what()." That's >> where I feel uncomfortable with the reationale. > > Remember that it's a bad idea to carry dynamically-allocated state in an > exception object. Translating to readable strings at the throw point is > ill-advised. Agreed, but that's an implementation detail. IOW, the exception should carry the error code, but what purpose is there in having the interface expose this detail? BTW: The filesystem_error carries a lot of dynamically-allocated state (as in 1/2 of the member data is, at least potentially, allocated). William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] some thoughts about serialisation
In-Reply-To: <[EMAIL PROTECTED]> On Sun, 12 Jan 2003 14:21:49 +0100 Ares Lagae ([EMAIL PROTECTED]) wrote: > 3) reflection is the difficult part, serialisation is the easy part. How do you see archive versioning being done? For example, suppose field TOTAL is a double in version 1 and a fixed-point user-defined type in version 2. -- Dave Harris ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread &amp; OS error code.
At 03:11 AM 1/14/2003, William E. Kempf wrote: >Stefano Delli Ponti said: >> From: "William E. Kempf" <[EMAIL PROTECTED]> >>> David Abrahams said: >>> > "William E. Kempf" <[EMAIL PROTECTED]> writes: >>> > >>> >>> People said they wanted it, and the cost is low (one int). I think >>> Greg is right that they wanted to attempt system-dependent >>> recovery. >>> >> >>> >> Well, I can agree that the cost is low... so I won't argue too much >>> about including it. I just want to feel comfortable with the >>> rationale. >>> > >>> > I think a rationale goes like this: >>> > >>> > suppose the platform gives you a function for converting an error >>> code into an error message (realistic, I think). How much code do >>> you have to write in order to take advantage of it? >>> >>> Contrasted with, "If a platform has the ability, the error is >>> translated into a message that's returned as part of what()." That's >>> where I feel uncomfortable with the reationale. >> >> The rationale may include the possibility, in certain circumstances, to >> catch a single root exception with a way to discern and react to the >> effecive os error (without the need for string comparisons). > >If the exception type doesn't fold multiple errors into a single unit, >there's no need for the error code in this situation. RTTI will provide >the same capabilities, even if you don't want to have seperate catch >clauses. Yes, but that assumes a different exception class for every error code, including codes on systems that we may not have thought about yet, or have not even been invented yet. So an optional system-defined code of a system-defined type seems like a good insurance policy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fun, only handled by vc6/7! - iter_adapt_patch(1/1)
David Abrahams <[EMAIL PROTECTED]> writes: > Heck, you're right! The parser just gives a misleading error > message. I found a much cleaner fix along these lines; testing now > and will check in shortly. Thanks for the hint! > > Gennaro Prota <[EMAIL PROTECTED]> writes: > Done now. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread & OS error code.
"William E. Kempf" <[EMAIL PROTECTED]> writes: > David Abrahams said: >> "William E. Kempf" <[EMAIL PROTECTED]> writes: >> People said they wanted it, and the cost is low (one int). I think Greg is right that they wanted to attempt system-dependent recovery. >>> >>> Well, I can agree that the cost is low... so I won't argue too much >>> about including it. I just want to feel comfortable with the >>> rationale. >> >> I think a rationale goes like this: >> >> suppose the platform gives you a function for converting an error code >> into an error message (realistic, I think). How much code do you have >> to write in order to take advantage of it? > > Contrasted with, "If a platform has the ability, the error is translated > into a message that's returned as part of what()." That's where I feel > uncomfortable with the reationale. Remember that it's a bad idea to carry dynamically-allocated state in an exception object. Translating to readable strings at the throw point is ill-advised. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread &amp;OS error code.
From: "William E. Kempf" <[EMAIL PROTECTED]> > > If the exception type doesn't fold multiple errors into a single unit, > there's no need for the error code in this situation. RTTI will provide > the same capabilities, even if you don't want to have seperate catch > clauses. It won't, unless you are willing to create a dedicated exception class for each and every potential OS error code. :-) The idea is that at the throw point, you are converting an OS error code to a portable error identification token (exception type, portable error code, string identifier, whatever) and this conversion is, in general, lossy. So it might make sense to preserve the original. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread &amp;OS error code.
Stefano Delli Ponti said: > From: "William E. Kempf" <[EMAIL PROTECTED]> >> David Abrahams said: >> > "William E. Kempf" <[EMAIL PROTECTED]> writes: >> > >> >>> People said they wanted it, and the cost is low (one int). I think >> Greg is right that they wanted to attempt system-dependent >> recovery. >> >> >> >> Well, I can agree that the cost is low... so I won't argue too much >> about including it. I just want to feel comfortable with the >> rationale. >> > >> > I think a rationale goes like this: >> > >> > suppose the platform gives you a function for converting an error >> code into an error message (realistic, I think). How much code do >> you have to write in order to take advantage of it? >> >> Contrasted with, "If a platform has the ability, the error is >> translated into a message that's returned as part of what()." That's >> where I feel uncomfortable with the reationale. > > The rationale may include the possibility, in certain circumstances, to > catch a single root exception with a way to discern and react to the > effecive os error (without the need for string comparisons). If the exception type doesn't fold multiple errors into a single unit, there's no need for the error code in this situation. RTTI will provide the same capabilities, even if you don't want to have seperate catch clauses. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun, only handled by vc6/7! - iter_adapt_patch (1/1)
On Mon, 13 Jan 2003 14:36:22 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: > >Heck, you're right! The parser just gives a misleading error >message. I found a much cleaner fix along these lines; testing now >and will check in shortly. Thanks for the hint! You're welcome :-) Sorry for screwing up the subject line once again, I guess I don't understand how attachments work with my news reader Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread &OS error code.
From: "William E. Kempf" <[EMAIL PROTECTED]> > David Abrahams said: > > "William E. Kempf" <[EMAIL PROTECTED]> writes: > > > >>> People said they wanted it, and the cost is low (one int). I think > >>> Greg is right that they wanted to attempt system-dependent recovery. > >> > >> Well, I can agree that the cost is low... so I won't argue too much > >> about including it. I just want to feel comfortable with the > >> rationale. > > > > I think a rationale goes like this: > > > > suppose the platform gives you a function for converting an error code > > into an error message (realistic, I think). How much code do you have > > to write in order to take advantage of it? > > Contrasted with, "If a platform has the ability, the error is translated > into a message that's returned as part of what()." That's where I feel > uncomfortable with the reationale. The rationale may include the possibility, in certain circumstances, to catch a single root exception with a way to discern and react to the effecive os error (without the need for string comparisons). Sted ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun, only handled by vc6/7!
On Mon, 13 Jan 2003 07:48:24 +0100, Terje Slettebø <[EMAIL PROTECTED]> wrote: >No, I don't think so. The previous sentence says: "The parameter list (void) >is equivalent to the empty parameter list." Then it follows with what is the >rule, except for this special case. The problem is the expression "except for this special case". The above is not a special case of parameter with void type. > IOW, it's not a parameter type in the >special case, and it's not otherwise, either. Exactly. >How would you propose to clarify it? Since you asked, I would have added the special case to the grammar, where one can unambiguously specify whether void is intended literally or not. Example: parameter-declaration-clause: parameter-declaration-listopt ...opt parameter-declaration-list , ... empty-parameter-list-specifier empty-parameter-list-specifier: void Then, since I care clarity (:-)) I would have written: A parameter-declaration-clause consisting of the empty-parameter-list-specifier is equivalent to the empty parameter list. [Note: by grammar, the empty-parameter-list-specifier can only be (at translation phase 7) the keyword "void" and not e.g. a type-id of type void] [...] >> template >> int f(T1 t1, T2 t2, T3 t3); >> >> >>becomes a generator of variadic functions with a fixed maximum number >>of arguments. > >Really? How would you impleent that? Yup. Forget it, this was just a result of somnolence. In practice, while sleeping at the keyboard, it occurred to me the wonderful idea that if you allow f (T); with T=void than you have a variadic function with zero or one arguments. Hence the "generalization"... Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread &OS error code.
David Abrahams said: > "William E. Kempf" <[EMAIL PROTECTED]> writes: > >>> People said they wanted it, and the cost is low (one int). I think >>> Greg is right that they wanted to attempt system-dependent recovery. >> >> Well, I can agree that the cost is low... so I won't argue too much >> about including it. I just want to feel comfortable with the >> rationale. > > I think a rationale goes like this: > > suppose the platform gives you a function for converting an error code > into an error message (realistic, I think). How much code do you have > to write in order to take advantage of it? Contrasted with, "If a platform has the ability, the error is translated into a message that's returned as part of what()." That's where I feel uncomfortable with the reationale. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fun, only handled by vc6/7! - iter_adapt_patch(1/1)
Heck, you're right! The parser just gives a misleading error message. I found a much cleaner fix along these lines; testing now and will check in shortly. Thanks for the hint! Gennaro Prota <[EMAIL PROTECTED]> writes: -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread
> Beman Dawes said: [...] > > The idea of mandatory "options" is new to me. Wonders never cease. Actually the idea isn't that new. An example of a mandatory C++ option is, for example, function template partial ordering. The compilers have to support it in theory, but in practice some don't, and BOOST_NO_FUNCTION_TEMPLATE_ORDERING is the macro that indicates (absence of) support. I guess the POSIX mandatory options are similar in spirit, i.e. something expected to go away as implementations catch up. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread & OS error code.
"William E. Kempf" <[EMAIL PROTECTED]> writes: >> People said they wanted it, and the cost is low (one int). I think Greg >> is right that they wanted to attempt system-dependent recovery. > > Well, I can agree that the cost is low... so I won't argue too much about > including it. I just want to feel comfortable with the rationale. I think a rationale goes like this: suppose the platform gives you a function for converting an error code into an error message (realistic, I think). How much code do you have to write in order to take advantage of it? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun, only handled by vc6/7! - iter_adapt_patch (1/1)
begin 644 iter_adapt_patch
M*BHJ(&ET97)A=&]R7V%D87!T;W)S+FAP<"YO"!N965D960@9F]R(&5N86)L95]I9B!I;B!C;VYS=')U
M8W1O6YT87@@;F5E9&5D(&9O7!E;F%M92!4,CX-"BL@("`@('-TPT**R`@("`@("`@('1Y<&5D968@='EP96YA;64@96YA8FQE7VEF
M7V-O;G9E7!E;F%M92!B;W)L86YD
M7W!A7!E
M*B`](#`-"BL@(V5L7!E;F%M92!E
M;F%B;&5?:69?8V]N=F5R=&EB;&4\3W1H97))=&5R871O7!E*B`](#`-"B$@(R!E;F1I9B`-"B`@("`@("`@("`I#0H@("`@("`@
M(#H@WT-"B`@#0HM+2T@-C@V+#8Y-"`M+2TM
M"B`@("`@('1E;7!L871E/&-L87-S($]T:&5R271E49U
M;F-T:6]N+"!/=&AE7!E;F%M92!E;F%B;&5?:69?8V]N=F5R=&EB;&4\3W1H97))=&5R871O7!E*B`](#`-"B$@(R!E;F1I9B`-"B`@("`@("`@("`I
M#0H@("`@("`@(#H@WT-"B`@#0HM+2T@-S0W+#WT-"BHJ*BHJ
M*BHJ*BHJ*BHJ*@HJ*BH@.3(X+#DS-B`J*BHJ"B`@("`@("`@=&5M<&QA=&4\
M8VQAhttp://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Next revision of boost::thread
Beman Dawes said: > At 11:52 AM 1/11/2003, Alexander Terekhov wrote: > > > >"William E. Kempf" wrote: > >[...] > >> > There is some chance you might talk me into accepting two flavors > of threading for the Standard - full threads and threads-lite in > effect. But picking and choosing between four or five optional > thread > features > >> > leaves me cold. > >> > >> I can understand that, but my hands are somewhat tied by POSIX, > whose standards bodies took the opposite stance on this issue. > > > >It seems to me that you're missing the purpose/role of The Single UNIX > Specification and various "Product Standards" within the UNIX > branding/ certification program of The Open Group consortium: e.g. > UNIX 95, UNIX 98 Workstation, UNIX 98 Server, etc.]. > > > >Well, < note that this is rather old SUSv2-stuff. The current version > is SUSv3[/TC1](*) > > > > >http://www.unix-systems.org/version2/whatsnew/threadspaper.pdf > >(Threads and the Single UNIX(R) Specification, Version 2) > > > > > > > >For conformance to the Single UNIX Specification, Version 2, the > threads options are split so that non-realtime functionality is > >mandatory, and realtime functionality is grouped into a single > >option: the Realtime Threads Feature Group. > > > > It seems I'm only slightly misunderstanding. There aren't "four or five" optional groups, but only two (assuming UNIX specification conformance instead of just POSIX... is that a reasonable thing to do here?). But this still leaves me with optional functionality that may or may not be present. Which still leaves the question open about conditional compilation. But certainly thanks for the link. > Interesting. I spent about fifteen minutes with Google and The Open > Group's search feature and couldn't come up with a formal specification > for what threading "options" are mandatory for version 3. Was the same > division into just two flavors (first four "options" now mandatory, > last three "options" mandatory for realtime) carried forward into > version 3. Do you have a link? > > The idea of mandatory "options" is new to me. Wonders never cease. Yeah... and I have no problems eliminating "mandatory options". William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Fun, only handled by vc6/7! - iter_adapt_patch (0/1)
On Sun, 12 Jan 2003 21:30:45 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: >cd $BOOST_SANDBOX/libs/iterator/test >bjam -sTOOLS=borland test > >if you want to try it. Edit out the line which defines >BOOST_NO_ENABLE_IF_CONSTRUCTORS in >$BOOST_SANDBOX/boost/iterator/iterator_adaptors.hpp Sorry for the late reply: I was waiting to be at home to look at it with calm. Here's a first try. If you apply the patch there are still some errors but, since I'm not confident with the code, I'm not sure whether they depend on parser bugs too or are something that simply didn't show up before because the corresponding code never got compiled. Let me now. If they still depend on compiler bugs I can try other solutions. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread &OS error code.
Beman Dawes said: > At 05:15 PM 1/10/2003, William E. Kempf wrote: > > >>... what() // from std::runtime_error. Implementation > provides > >> // a very explicit message, including who(), > path1(), // path2(), and message reported by O/S > (which is // subject to locale on some O/S's. > >> > >>int native_error() const; > >>// a return of 0 implies a library (rather than system) error > >> > >>error_code error() const; // filesystem defined error code > >> > >>const std::string & who() const; // name of func throwing > >exception > >> > >>const path & path1() const; // argument 1 to func; may be > empty() > >>const path & path2() const; // argument 2 to func; may be > empty() > >> > >> That's pretty heavyweight, but each function has important uses. > > > >This description brings a better understanding than what I had > previously, > >but doesn't fill in all the gaps. > > > >What's the purpose of a non-native error code? > > It is useful for those who want a portable, more detailed breakdown of > what caused the error. The alternative was no non-native error code, > but instead providing one exception class for each of what are now > error codes. That's what I'm proposing. A seperate exception for each error condition. Under that scheme, I'm not sure I see any use for a code, native or not. > > For that matter, if what() > >includes a translated message for the error code, what purpose is > there > for > >the native error code? > > People said they wanted it, and the cost is low (one int). I think Greg > is right that they wanted to attempt system-dependent recovery. Well, I can agree that the cost is low... so I won't argue too much about including it. I just want to feel comfortable with the rationale. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] permutation_iterator and MSVC
Roland Richter <[EMAIL PROTECTED]> writes:
> Hi,
>
> as mentioned in the docs, it is necessary to tell MS VC++
> all template parameters of an iterator_adaptor *explicitly*.
No, not usually. If the docs say that, they should be fixed.
> Unfortunately, it seems one cannot do that for a permutation_iterator,
> since permutation_iterator_generator just takes ElementIterator
> and IndexIterator as its template parameters.
>
> I propose extending the code like this:
>
> template< typename ElementIterator, typename IndexIterator,
>// Reasonable default, but can be passed explicitly for MSVC:
>typename ValueType =
>boost::detail::iterator_traits::value_type
>// etc.
> >
> struct permutation_iterator_generator
> {
> typedef boost::iterator_adaptor
> < ElementIterator,
>permutation_iterator_policies< IndexIterator >,
>ValueType
>// etc.
> > type;
> };
>
> in order to write something like
>
> typedef permutation_iterator_generator<
> element_range_type::iterator,
> index_type::iterator,
> element_range_type::value_type // tells MSVC++ the value_type
>>::type
>
>
> to keep MSVC quiet.
>
> I'm not sure, but I think I saw the same trick for some other
> iterator adaptors. Comments?
IIRC, it doesn't work if ElementIterator happens to be a pointer,
because the default expression is evaluated even if you supply that
argument. On the other hand, the new strategy for pointer iterators
is to ask the user to specialize boost::detail::iterator_traits
manually. We supply boost::detail::ptr_iterator_traits to help with
that.
We are working on a redesign of the library, currently in
$BOOST_SANDBOX/boost/iterator/iterator_adaptors.hpp. We don't have a
permutation iterator in there yet.
HTH,
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: [multiarray] compiling problem
<[EMAIL PROTECTED]> wrote in message 3D8559AE95B4D611B02C0002557C6C8B3C459F@STH-EXCH">news:3D8559AE95B4D611B02C0002557C6C8B3C459F@STH-EXCH... > And when creating patches, it's always a good idea to check that one's > favorite editor hasn't inserted tabs or changed the line endings (the latter > is the case with the submitted multi_array files). sorry for that. >Additionally, creating > patches using the latest files from CVS makes them very easy to apply. if one have cvs access, I pressume :-) -Thorsten ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Date-Time Library...
Jeff Garland <[EMAIL PROTECTED]> writes: >>Btw, by recurring events I mean events which can be configured to > occur >>for example: every monday and thursday, last friday in month, >>every second tuesday, every friday the 13th, and so on... >>Much like crontab or MS-Outlook's recurrence appointments. >> >>Unfortunately, there is no such class in the Date-Time library. > I don't >>know, but maybe such a class doesn't fit in a library? > > I believe it would be a perfect fit with the library. > The only reason it isn't there is time. Oh, the irony of it all!! -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] permutation_iterator and MSVC
Hi,
as mentioned in the docs, it is necessary to tell MS VC++
all template parameters of an iterator_adaptor *explicitly*.
Unfortunately, it seems one cannot do that for a permutation_iterator,
since permutation_iterator_generator just takes ElementIterator
and IndexIterator as its template parameters.
I propose extending the code like this:
template< typename ElementIterator, typename IndexIterator,
// Reasonable default, but can be passed explicitly for MSVC:
typename ValueType = boost::detail::iterator_traits::value_type
// etc.
>
struct permutation_iterator_generator
{
typedef boost::iterator_adaptor
< ElementIterator,
permutation_iterator_policies< IndexIterator >,
ValueType
// etc.
> type;
};
in order to write something like
typedef permutation_iterator_generator<
element_range_type::iterator,
index_type::iterator,
element_range_type::value_type // tells MSVC++ the value_type
>::type
to keep MSVC quiet.
I'm not sure, but I think I saw the same trick for some other
iterator adaptors. Comments?
- Roland
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: Re: [boost] Re: Next revision of boost::thread & OS error code.
From: "Martin Brown" <[EMAIL PROTECTED]> > Hi, > > I would second the approach below. If I can get to > the native error code, then I can use FormatMessage() > or strerror() to get to the platform error message, > localised if necessary. I am not so interested in > the name of the function throwing the exception - I > tend to use a logger with a stack-trace built in. The purpose of the function name is to act as a portable unique identifier that answers the "what failed?" question; the error code answers the "why did it fail?" question. Both parts are needed, in general, to construct an error message. I.e. who() == "std::fopen" path1() == "foo.txt" error() == ENOENT (or "ENOENT") Sample message: "foo.txt": Open error: No such file or directory Depending on the situation, one of the "what"/"why" pieces can be encoded in the exception type (open_error or file_not_found for the above), but it's still useful to have a common mechanism to obtain them from a single catch clause. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Date-Time Library...
>Btw, by recurring events I mean events which can be configured to
occur
>for example: every monday and thursday, last friday in month,
>every second tuesday, every friday the 13th, and so on...
>Much like crontab or MS-Outlook's recurrence appointments.
>
>Unfortunately, there is no such class in the Date-Time library.
I don't
>know, but maybe such a class doesn't fit in a library?
I believe it would be a perfect fit with the library. The only
reason it isn't there is time. I would be happy to collaborate
with you on building such an extension :-)
>Anyhow, I think it would be really nice to say something like:
>recurring_event wakeMeUp("09:45");
>recurring_event trainingDays(monday,thursday);
>recurring_event cleaningDay(tuesday,every_2nd);
>recurring_event receiveSalary(friday,last_day_in_month);
>recurring_event santa(christmas_day);
In general, what you want to do here is very similar to the
generator concept. See
http://www.boost.org/libs/date_time/doc/date_algorithms.html
for some ideas. For example your receiveSalary on the last
friday of the month is very similar to the 'last_kday_of_month'
which performs the following calculation:
last_kday_of_month lkm(Friday,Jan);
date d = lkm.get_date(2002);//2002-Jan-28
date d2 = lkm.get_date(2003); //2003-Jan-31
>Does anyone have an idea or hint how to implement such a class (maybe
>out of different boost-classes)? Otherwise I know one way to go, based
>on the paper "Recurring Events" written by Martin Fowler and available
>on his site martinfowler.com.
I believe most of the tools you need are already in the library.
It is really a matter of putting them together in a way that is
useful to your application. For example
recurring_event wakeMeUp("09:45");
is easily specified as a time duration offset from midnight. That
is
using namespace boost::gregorian;
using namespace boost::posix_time;
//warning -- untested code!
class daily_event {
daily_event(time_duration td) :
offset_from_midnight(td)
{}
//use this to generate wakeup time for any date
ptime getWakeUpTime(date d)
{
return ptime(d, offset_from_midnight);
}
private:
time_duration offset_from_midnight;
};
Jeff
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Fun, only handled by vc6/7!
From: "David Abrahams" <[EMAIL PROTECTED]>
> "Paul Mensonides" <[EMAIL PROTECTED]> writes:
>
> >> template struct voidify { typedef void type; };
> >> template struct Y {};
> >> struct X
> >> {
> >> template
> >> operator Y (typename voidify::type) const { return Y(); }
> >> };
> >
> > Is this even legal? I.e. for a user-defined conversion operator to have
any
> > arguments at all?
>
> Look twice; the argument is void.
Doesn't matter. f(T) has one argument for any T. f(void) (void is a keyword
here, not a type expression) has zero arguments.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fun, only handled by vc6/7!
>From: "David Abrahams" <[EMAIL PROTECTED]> > Terje Slettebø <[EMAIL PROTECTED]> writes: > > > Why would we want that? What is this useful for? > > It would be useful for writing a templated implicit conversion > operator with restricted applicability via SFINAE. Right. I've read up properly on the thread, now. I see how this could be useful. Sorry for not having done that earlier. > SFINAE is a feature of the language which (coincidentally) allows a > technique for removing functions from the overload set based on some > compile-time computation. This technique relies on having a return > type or parameter type to play with. Unfortunately, implicit > conversion operators have neither. > > Read all about SFINAE in Jossutis & Vandevoorde. I've done it. Also, when the term first time was brought up here, it was pointed out that this technique has been used for quite a while, also before the book got published. However, now we have a name for it. :) Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Next revision of boost::thread
Beman Dawes wrote: [...] > Interesting. I spent about fifteen minutes with Google and The Open Group's > search feature and couldn't come up with a formal specification for what > threading "options" are mandatory for version 3. Was the same division > into just two flavors (first four "options" now mandatory, last three > "options" mandatory for realtime) carried forward into version 3. Do you > have a link? Well, at the moment, I have the following links [that perhaps might help]: http://www.opengroup.org/onlinepubs/007904975/xrat/xsh_chap02.html#tag_03_02_09_06 (XSI Supported Functions) http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap03.html#tag_01_03_00_65 (XSI) http://www.opengroup.org/onlinepubs/007904975/xrat/xbd_chap02.html (Conformance) http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html (Conformance) regards, alexander. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Date-Time Library...
Hi,
I need a library which allowes me to define and handle recurring events. Of course, I
thought that Boost would help me out by providing such a handy-dandy class out of the
box.
Btw, by recurring events I mean events which can be configured to occur for example:
every monday and thursday, last friday in month, every second tuesday, every friday
the 13th, and so on... Much like crontab or MS-Outlook's recurrence appointments.
Unfortunately, there is no such class in the Date-Time library. I don't know, but
maybe such a class doesn't fit in a library?
Anyhow, I think it would be really nice to say something like:
recurring_event wakeMeUp("09:45");
recurring_event trainingDays(monday,thursday);
recurring_event cleaningDay(tuesday,every_2nd);
recurring_event receiveSalary(friday,last_day_in_month);
recurring_event santa(christmas_day);
Does anyone have an idea or hint how to implement such a class (maybe out of different
boost-classes)? Otherwise I know one way to go, based on the paper "Recurring Events"
written by Martin Fowler and available on his site martinfowler.com.
Btw, when I searched the archive I saw that at least one other user (Dylan) had a
similar request/desire for such a utility.
/Tommy
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Re: [multiarray] compiling problem
> From: David Abrahams [mailto:[EMAIL PROTECTED]] > >> That's not a patch; those are the complete files. > However, I'm sure > >> Ron can work with those. If he doesn't respond in the next week, > >> Bjorn (the maintenance wizard) will get on his case. > > > > So what is a patch? > > It is a diff between the modified files and the originals, usually > unified I believe (diff -u). Actually, it seems we request context diffs (-c), presumably because they are easier to read [http://www.boost.org/more/bugs.htm]. And when creating patches, it's always a good idea to check that one's favorite editor hasn't inserted tabs or changed the line endings (the latter is the case with the submitted multi_array files). Additionally, creating patches using the latest files from CVS makes them very easy to apply. [This "What is a patch, anyway?" is a good question; I'll add some additional patch instructions to "Report Bugs" subsection.] Bjorn ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Function Type Typedefs in Classes, Etc.
"Paul Mensonides" <[EMAIL PROTECTED]> wrote in message
000701c2b9fd$f56ef7f0$9d00a8c0@c161550b">news:000701c2b9fd$f56ef7f0$9d00a8c0@c161550b...
> Is this well-formed:
>
> struct X {
> typedef void func_t(int);
> func_t member;
> };
>
> void X::member(int) {
> return;
> }
>
> What about:
>
> struct X {
> typedef void func_t(int) const;
> // ^
> func_t member;
> };
>
> void X::member(int) const {
> return;
> }
>
Both are well-formed. See 8.3.5/4,7
> This is the root of my question:
>
> template struct test;
>
> template struct test {
> typedef R type;
> };
>
> struct X { };
>
> test< void (X::*)(int) >::type // what type is this?
>
> Is it a function type, or is it a "member function type"?
>
Judging, again, by 8.3.5/4,7 it's a function type.
Rani
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Fwd: Final CFP for PSI'03]
There are not many conferences yet that support generic programming. Please consider a submission to PSI'03, which lists generic programming explicitly as one of its conference topics. Find below an excerpt of the Final Call for Papers. For more information see http://www.iis.nsk.su/PSI03. Sibylle ([EMAIL PROTECTED]) --Forwarded Message- From: Alexandre Zamulin <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Final CFP for PSI'03 Date: 13 Jan 2003 15:34:17 +0600 --- FINAL CALL FOR PAPERS Andrei Ershov Fifth International Conference PERSPECTIVES OF SYSTEM INFORMATICS 9 - 12 July 2003, Novosibirsk (Siberia), Russia PROCEEDINGS: full papers will appear in Springer LNCS series, extended abstracts will be published in a local book. SUBMISSION DEADLINE (extended abstracts, 10 pages): February 2, 2003. MAIN TOPICS: Semantics-Based Program Processing; Programming Methodology and Automated Software Engineering; Information Technologies. KEYNOTE SPEAKERS: Kim Bruce (Williams College, USA) David Harel (The Weizmann Institute of Science, Israel) Tony Hoare (Microsoft Research, Cambridge, UK) Max Kanovich (University of Pennsylvania, USA) and Jacqueline Vauzeilles (University Paris13, France) Bertrand Meyer (ETH Zurich, Switzerland) Joachim Schmidt (Technical University Hamburg-Harburg, Germany) CONFERENCE TOPICS Conference topics include: Semantics-Based Program Processing - program specification, transformation, and verification, - semantics, logic and formal models of programs, - partial evaluation, mixed computation, and abstract interpretation, - program analysis and synthesis, - model checking. Programming Methodology and Automated Software Engineering - object-oriented, aspect-oriented, component-based and generic programming, - program and system construction for parallel and distributed computing, - constraint programming, - multi-agent technology, - system re-engineering and reuse, - integrated programming environments, - software architectures, - software development and testing, - tools for software engineering, - Web services in software engineering, - program understanding and visualization. Information Technologies - database and information systems, - knowledge-based systems and knowledge engineering, - electronic commerce, - digital libraries and Web publishing, - natural language processing. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Fun, only handled by vc6/7!
Terje Slettebø <[EMAIL PROTECTED]> writes: > Why would we want that? What is this useful for? It would be useful for writing a templated implicit conversion operator with restricted applicability via SFINAE. SFINAE is a feature of the language which (coincidentally) allows a technique for removing functions from the overload set based on some compile-time computation. This technique relies on having a return type or parameter type to play with. Unfortunately, implicit conversion operators have neither. Read all about SFINAE in Jossutis & Vandevoorde. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: [multiarray] compiling problem
"Thorsten Ottosen" <[EMAIL PROTECTED]> writes: >> >> Why not do it and post a patch here? >> >> >> > >> > done. >> >> That's not a patch; those are the complete files. However, I'm sure >> Ron can work with those. If he doesn't respond in the next week, >> Bjorn (the maintenance wizard) will get on his case. > > So what is a patch? It is a diff between the modified files and the originals, usually unified I believe (diff -u). -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
