Re: [boost] posix_time to timeval conversion
On Mon, Jun 23, 2003 at 06:53:28AM -0700, Jeff Garland wrote: > [snip] > Ok will do. I'll add some protections or rounding for when durations > support higher than microsecond resolution. I'll let you know when > this gets added. It seems that since 1) timeval is non-(C++) standard, and 2) it is used only by select, that this conversion is more appropriate in a Boost socket library, and even there only as an internal component. - Jeremy Maitin-Shepard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] WCHAR_MIN/MAX not defined for NetBSD in integer_traits.h
NetBSD does not have WCHAR_MIN/MAX using gcc3.3 basicaly the min/max for wchar_t is INT_MIN/MAX similarly to freeBSD I encountered this problem when trying to compile boost.python which failed because of this problem. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Math constants - efficiency
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Monday, June 23, 2003 7:44 PM | To: [EMAIL PROTECTED] | Subject: [boost] RE: Math constants - efficiency | | | On Mon, 23 Jun 2003 19:54:36 +0200, Paul A. Bristow wrote: | | > These are interesting results, but my enthusiasm is severely reduced by | > the fact that MSVC 7.1 (Standard) chokes terminally on both versions | > :-(( | > | > Compiling... | > Frey_bench_mark_gcc.cpp | > Frey_bench_mark_gcc.cpp(82) : warning C4305: 'return' : truncation from | > 'double' to 'float' | > Frey_bench_mark_gcc.cpp(108) : fatal error C1001: INTERNAL COMPILER | > ERROR | > (compiler file 'msc1.cpp', line 2701) | > Please choose the Technical Support command on the Visual C++ | > Help menu, or open the Technical Support help file for more | > information | | ??? Line 108 is the static_cast< double >( pi ) for me. How can it compile | the three lines before but choke on 108? I think I will still have to wait | for the day MS has no surprise for us a bit longer... :) Same line of code for me :-( And how can the compiler actually crash like this? | But the GCC 2.95.x ICEd on the F()() so the workaround for the MSVC may | be trivial and acceptable, too. And why do other very similar codes from Michael Kenniston and Terje work? Suggestions? | I know and in this toy code I don't really care :)) No problem. | > I hope this will produce a bit more sympathy for my attempts to provide | > a variety of solutions for a variety of compilers. If the result is such | > a big performance hit on widely used compilers, it is just too early for | > such an advanced solution. | | Hm, I'm not sure I agree. Whatever will be standardizes shouldn't prevent | good code, but it's not responsible for bad compilers. But there should - | as I already said - be only one interface. Don't disagree with that but I see a 'chicken and egg' problem : until there is a Boost library file, nobody will use it, and there will be no pressure on compiler people to get a 'final solution' to work, and to work well. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [mpl] workaround needed for Borland
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Eric Friedman <[EMAIL PROTECTED]> writes: >> > I'd apply the patch myself, but due to the heavy use of preprocessed >> > headers, I'm worried I won't get it completely right. So I'll leave >> > it up to Aleksey (or others) to fix. >> >> AFAICT, Aleksey is the only one who knows how to make modifications >> to MPL correctly in the context of its preprocessing system. Aleksey, >> a short README would totally solve this problem, wouldn't it? > > How about this one instead: > > f:\cvs\boost\libs\mpl\preprocessed> preprocess.py > > Usage: >preprocess.py [] > > Purpose: >updates preprocessed version(s) of the header(s) in > "boost\mpl\aux_\preprocessed" directory > > Example: >the following command will re-generate and update all 'apply.hpp' > headers: > >preprocess.py all f:\cvs\boost apply.cpp > Well it's called pp.py in the current CVS, and doesn't handle 3 args, but... You've actually got a Python-based C++ preprocessor, or what?? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Inter-FSM protocol discussion
Chris, Sorry for the long delay, I was swamped with other stuff. The longer I think about your suggestions about FSM protocols the more do I think that coded FSM protocol specifications are not worth the effort. Even worse, I believe they will inevitably lead to code duplication. However, since I don't understand all of what you said, I may well have overlooked some important points. Before I start, I'll try to define my understanding of a protocol: *When* (timing and/or state) and *how* (effects) a particular entity will react to what kind of input. Please note: - The general term "effects", which can be just about everything (modifying an internal counter, flushing a buffer, calling a callback object, returning a value, etc.). - Sender and receiver entities were deliberately left out of the definition because this would only complicate the matter without any benefit, IMO. - Even more deliberately, the terms FSM (replaced with "entity") and event (replaced with "input") were avoided. Replace "entity" with class or function and you'll see that both define what I believe a protocol is. The last note brings us to my point: The interface and the implementation of an entity (function, class, FSM, etc.) already define its protocol. There's no point in specifying the *whole* protocol once more with more code as this would inevitably duplicate some information, even if the specification is on a higher level. Granted, asserts sometimes partly do exactly that, but never fully. You mentioned concept checking between communicating state machines. IIUC, you would want to define some kind of a channel between the two machines. The channel would: 1. Anonymize, i.e ensure that there are no cyclic dependencies between the two machines. 2. Check the type and maybe even the contents of events going through the channel. That is, it checks that the channel protocol is not violated. - I realize that it could sometimes be desirable to have support for 1, especially if you want to have complete anonymization (the client does not know the server and vice versa). However, as handcrafting this amounts to only a couple of LOCs I doubt that it would be worth the effort. - Either explicitly or implicitly, the participating state machines must implement all of the checking done in the channel. Essentially the channel would duplicate most of these checks. The only difference is that state machines ignore "bad" events by default, while the channel would presumably throw after detecting such an error. In my last project we needed exactly such behavior (throwing of an exception if the receiving state machine fails to consume a particular event). boost::fsm does not currently support this, mainly because I'm still struggling to find a proper name for such an event. Regards, Andreas ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] Yet another patch for nonrecursive DFS
Hi Vladimir, Vladimir Prus wrote: > There's another question: why store "u" at all. I'm > guessing "source(*ei, g)" might be more efficient? That's a good thought, but there might be a problem trying to dereference a past-the-end iterator. I mentioned before that ei_end could always be generated from u instead of storing it, but it's just a question of trading cycles for bytes. Which resource is more critical? > I'm thinking we have some technical questions left to > apply your patch. > 1. It needs license from you. Can you copy the standard license in for me? // (C) Copyright Bruce Barr, 2003 // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. // This software is provided "as is" without express or implied // warranty, and with no claim as to its suitability for any purpose. > 2. Once you decide on 1) I'll commit your patch, > making nonrecursive dfs default. I plan to retain the > old version for a while, because it would be > desirable to compare performance. Cool. > 3. Maybe, the FAQ, either fully or partically, must > be added too. How about adding: // FAQ's can be found at: // http://lists.boost.org/MailArchives/boost/msg48752.php // or http://aspn.activestate.com/ASPN/Mail/Message/boost/1681625 // or http://article.gmane.org/gmane.comp.lib.boost.devel/21454 // or http://www.mail-archive.com/boost%40lists.boost.org/msg08752.html after // after all of its out-edges have been examined. If you happen to know that one of those links can be counted on to persist, then the other three aren't really needed. Thanks, Bruce __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Trouble building latest CVS (Intel 7.1 and VC7)
Hi there, I just checked out the latest CVS and I am having trouble building it. My environment is: - Windows XP - Intel Version 7.1, Build 20030402Z - Visual C++ 7.0 All my environment variables are setup correctly (INCLUDE, LIB, MSVCDIR, INTEL_PATH, PATH). The command line I am using with bjam is: bjam -sTOOLS=intel-win32 -sINTEL_BASE_MSVC_TOOLSET=vc7 -sPYTHON_ROOT=C:\Python Looking at the command line that bjam is executing to compile the files, it seems to be all right (paths to header files, the correct compiler, etc). numeric.cpp D:\Programming\Libraries\boost-cvs\boost\boost/type_traits/is_integral.hpp(39): error: class "boost::is_integral" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) ^ D:\Programming\Libraries\boost-cvs\boost\boost/type_traits/is_integral.hpp(39): error: class "boost::is_integral" has already been defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) ^ D:\Programming\Libraries\boost-cvs\boost\boost/type_traits/is_integral.hpp(39): error: class "boost::is_integral" has already been defi ned BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) ^ D:\Programming\Libraries\boost-cvs\boost\boost/type_traits/is_integral.hpp(39): error: class "boost::is_integral" has already bee n defined BOOST_TT_AUX_BOOL_TRAIT_CV_SPEC1(is_integral,wchar_t,true) ^ This error happens in a lot of files, besides numeric.cpp. I let it try to compile more 6 files before I gave up, since something is obviously wrong. If needed, I can post the list of files that are giving this error. Does anybody know what am I doing wrong? Regards, Nicodemus. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] date_time, lexical_cast and MSVC 7.0
Hello, Since this is my first posting to the Boost List, let me first say thanks for Boost. It looks like a great resource! My first use of Boost will be the date_time library, followed by the file_system library. Now, the reason for my posting. I am using MSVC 7.0 and am unable to compile the date_time library tests. Compiling time_parsing.hpp gives me an error in lexical_cast, where there is no output operator for the lexical_cast compiled for the function parse_delimited_time_duration.But the test regression results for date_time indicates that all tests pass for MSVC 7.0. What am I doing wrong? I sincerely appreciate any help. Thanks, Phil For what it is worth: I changed the template parameter for the lexical_cast from unsigned short to int, and everything seems to compile and all date_time tests pass. But I would prefer to use an "official" Boost release and not my own hacked version. Plus I would like to understand why my system is encountering different results than the boost regression test indicates. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review - using namespaces toselectfloatsize is simpler?
On Fri, 20 Jun 2003 17:56:51 +0200, Gennaro Prota wrote: > Yes. Just to stimulate discussion, and without any offence towards > Daniel's solution, this is an approach without the conversion function > and the operator overloads. Beware that it's completely untested. > > [snip] > > It's not so "advanced" as it might appear at first sight. Maybe the > rigmarole above, together with the comments in the alternative solution, > is of some help to realize that the basic ideas are very simple. I looked at the code and I see two problems: a) as() is not generic, static_cast() is. Why introduce a new syntax for an already known language construct? Is it just that you wanted to create some "explicit cast"? I suggested explicit casts in clc++m long time ago :) Note that in my design the template operator T() is as close to an explicit cast as you can get with todays C++ and still create a generic interface. as() is IMHO not an option as other libraries will call it convert(), explicit_cast() or whatever. b) The "single line to create a useful interface" is now splittet into more lines. Why? It's a drawback and doesn't help the design in my eyes. I actually wonder what the code tries to do better. Removing the operators is not a big deal and I don't agree they should be removed, but I guess you had something else in mind when writing this code. Could you elaborate, please? Regards, Daniel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Math constants - efficiency
On Mon, 23 Jun 2003 19:54:36 +0200, Paul A. Bristow wrote: > These are interesting results, but my enthusiasm is severely reduced by > the fact that MSVC 7.1 (Standard) chokes terminally on both versions > :-(( > > Compiling... > Frey_bench_mark_gcc.cpp > Frey_bench_mark_gcc.cpp(82) : warning C4305: 'return' : truncation from > 'double' to 'float' > Frey_bench_mark_gcc.cpp(108) : fatal error C1001: INTERNAL COMPILER > ERROR > (compiler file 'msc1.cpp', line 2701) > Please choose the Technical Support command on the Visual C++ > Help menu, or open the Technical Support help file for more > information ??? Line 108 is the static_cast< double >( pi ) for me. How can it compile the three lines before but choke on 108? I think I will still have to wait for the day MS has no surprise for us a bit longer... :) But the GCC 2.95.x ICEd on the F()() so the workaround for the MSVC may be trivial and acceptable, too. > (I note the warnings C4305: 'return' : truncation from 'double' to > 'float', but these can be removed by making the value explicitly 3.14F > and L - which I believe is 'strictly' necessary. Otherwise the compiler > might conclude it should do a truncation, which would clearly defeat > what we are trying to do. However this is a trivial nit). I know and in this toy code I don't really care :)) > Looking at your results, and the timing, and going back to the Kenniston > code produced by the previous tests - which Ed Bray can no doubt update > for us from his recent MSVC 7.1 test, I suspect that the differences are > probably due to failure to load the constant directly into a floating > point register, rather than pushing the constant onto the stack, taking > two instructions, and using a reference to it, needing yet more > instructions, and failure to optimise away (inlining) the template > function call. I actually tried to read the assembler output, but it looks weird to me. I can't read x86 assembler - only 6502 and 680x0 :)) If you like, I can send the GCC and Intel assembler output to you. Drop me a private mail if you are interested. > I hope this will produce a bit more sympathy for my attempts to provide > a variety of solutions for a variety of compilers. If the result is such > a big performance hit on widely used compilers, it is just too early for > such an advanced solution. Hm, I'm not sure I agree. Whatever will be standardizes shouldn't prevent good code, but it's not responsible for bad compilers. But there should - as I already said - be only one interface. I do agree that the GCC-folks should have a look at it. Are some of them listening here? (Gaby?) Regards, Daniel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Math constants - efficiency
These are interesting results, but my enthusiasm is severely reduced by the fact that MSVC 7.1 (Standard) chokes terminally on both versions :-(( Compiling... Frey_bench_mark_gcc.cpp Frey_bench_mark_gcc.cpp(82) : warning C4305: 'return' : truncation from 'double' to 'float' Frey_bench_mark_gcc.cpp(108) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information I am not saying that your code is wrong, but this is clearly too 'advanced' a solution to be considered immediately even for Boost. (I note the warnings C4305: 'return' : truncation from 'double' to 'float', but these can be removed by making the value explicitly 3.14F and L - which I believe is 'strictly' necessary. Otherwise the compiler might conclude it should do a truncation, which would clearly defeat what we are trying to do. However this is a trivial nit). Looking at your results, and the timing, and going back to the Kenniston code produced by the previous tests - which Ed Bray can no doubt update for us from his recent MSVC 7.1 test, I suspect that the differences are probably due to failure to load the constant directly into a floating point register, rather than pushing the constant onto the stack, taking two instructions, and using a reference to it, needing yet more instructions, and failure to optimise away (inlining) the template function call. (At bottom is the lousy instruction set and shortage of registers of course - but the processors go like stink! When you look at this sort of code, you see why FORTRAN is still popular. gcc should probably look into how seriously the benchmark is lying?) I hope this will produce a bit more sympathy for my attempts to provide a variety of solutions for a variety of compilers. If the result is such a big performance hit on widely used compilers, it is just too early for such an advanced solution. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Sunday, June 22, 2003 12:57 PM | To: [EMAIL PROTECTED] | Subject: [boost] Math constants | | | I had a small time-out and will now try to catch up with the | discussion. Before commenting on other postings, I'll show the result | of a small benchmark. The code is attached, maybe you want to verify | and post the results for your compiler(s), too :) | | MACRO: | | Intel C++ 7.1: 0.37 | GCC 2.95.3: 2.12 | GCC 3.3: 2.15 | | VARIABLE: | | Intel C++ 7.1: 0.37 | GCC 2.95.3: 0.62 | GCC 3.3: 0.61 | | FUNCTION: | | Intel C++ 7.1: 0.37 | GCC 2.95.3: 0.62 | GCC 3.3: 0.61 | | TEMPLATE: | | Intel C++ 7.1: 0.37 | GCC 2.95.3: 1.36 | GCC 3.3: 1.35 | | As you can see, good compilers like the Intel are not suffering from | any presentation scheme, the GCC (althought not a bad compiler) has | some problems. Even the best versions are still much slower than the | Intel's compiler code. The template does have some performance | penalties, but remember it is just a benchmark. In real code, I expect | the difference to be smaller, but this will depend on the use | scenario. The most direct approach (MACRO) is even worse than the | template-approach. Conclusion: The code I suggest (TEMPLATE) is not | bad in itself, nothing prevents a compiler from generating a good | result from it. This doesn't mean that all compilers do so. | | Before commenting on the benchmarks, please also look at the code | attached and note that I am well aware of the fact that all benchmarks | are lying :o) | | As a result, we might want to evaluate if users that really need | speed use fast compilers and if those compilers suffer from the | code. If someone uses the GCC and complains about speed, one might | suggest to change the compiler anyway. | | ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] posix_time to timeval conversion
Jeff Garland wrote: Ok will do. I'll add some protections or rounding for when durations support higher than microsecond resolution. I'll let you know when this gets added. Thanks a lot ! Stefan ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Boost-bugs] [ boost-Support Requests-759244 ] Gregorian date support
Support Requests item #759244, was opened at 2003-06-23 17:09 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=759244&group_id=7586 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Sergiy Yakovyn (ysv_) Assigned to: Nobody/Anonymous (nobody) Summary: Gregorian date support Initial Comment: Please add date operator+(int) const date operator-(int) const as synonyms to date operator+(date_duration) const date operator-(date_duration) const Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=759244&group_id=7586 --- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Boost-bugs mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/boost-bugs ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] posix_time to timeval conversion
S. Seefeld wrote > I'd suggest these two converters to be added: > > timeval to_timeval(const ptime &t) >... > > timeval to_timeval(const time_duration &d) >... > > the latter is especially useful as select() operates with durations, > so there is no need to convert between 1970-01-01 relative dates and > ptime... Ok will do. I'll add some protections or rounding for when durations support higher than microsecond resolution. I'll let you know when this gets added. Thx, Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Boost-bugs] [ boost-Bugs-759218 ] Gregorian dates bugs
Bugs item #759218, was opened at 2003-06-23 16:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=107586&aid=759218&group_id=7586
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sergiy Yakovyn (ysv_)
Assigned to: Nobody/Anonymous (nobody)
Summary: Gregorian dates bugs
Initial Comment:
1. I read docs about boost::gregorian::date. It has the
accessor 'greg_ymd year_month_day() const', but I
can't find 'greg_ymd' type anywhere.
2. So I use date::ymd_type instead. All looks like except
the following:
Tools.h
==
#ifndef TOOLS_H
#define TOOLS_H
#include
typedef boost::gregorian::date Date;
typedef boost::gregorian::date_period Period;
std::string DateToString(Date d);
#endif
==
Tools.cpp
==
#include
#include
#include "Tools.h"
using namespace std;
using namespace boost::gregorian;
string DateToString(Date d)
{
ostringstream os;
int m=d.month();
os<
#include
#include "Tools.h"
using namespace std;
using namespace boost::gregorian;
string DateToString(Date d)
{
ostringstream os;
os
[boost] Re: Math Constants Formal Review
Terje Slettebø wrote: From: "Daniel Frey" <[EMAIL PROTECTED]> On Sun, 22 Jun 2003 22:01:19 +0200, Terje Slettebø wrote: Another thing, are the ADD_OPERATOR macro in your code necessary? It compiles fine without it on Intel C++ 7.1. The GCC doesn't work without the operators, as it doesn't implicitly tries to satisfy float*pi_t by casting pi_t to float to use float*float. I think this is OK as the language can go for two ways: a) define float*float and use a promotion/conversion for, say, float*int. b) define several operators float*float, float*int, ... if it's b), the compiler cannot cast pi_t to float as it doesn't know whether to select float*float or float*int, thus it fails. Maybe a question for the language lawyers over at csc++ to find out what's correct. It's an odd thing, anyway. Both g++ 3.2 and MSVC 7.1 complains that there's no matching operator*. FYI: I send the question with a minimalistic example to csc++, should appear there soon. My personal feeling is that GCC/MSVC are correct, but let's see what happens at csc++... Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] posix_time to timeval conversion
Jeff Garland wrote:
I'd like to replace my code by boost::date_time, but conversion
from boost::date_time to timeval doesn't seem to be supported.
You are right, but this would make a nice addition.
I'd suggest these two converters to be added:
timeval to_timeval(const ptime &t)
{
ptime timet_start(date(1970,1,1));
time_duration diff = t - timet_start;
timeval tv;
//drop off the fractional seconds...
tv.tv_sec = diff.ticks()/time_duration::rep_type::res_adjust();
//The following only works with microsecond resolution!
tv.tv_usec = diff.fractional_seconds();
return tv;
}
timeval to_timeval(const time_duration &d)
{
timeval tv;
//drop off the fractional seconds...
tv.tv_sec = d.ticks()/pt::time_duration::rep_type::res_adjust();
//The following only works with microsecond resolution!
tv.tv_usec = d.fractional_seconds();
return tv;
}
the latter is especially useful as select() operates with durations,
so there is no need to convert between 1970-01-01 relative dates and
ptime...
Regards,
Stefan
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: [mpl] workaround needed for Borland
David Abrahams wrote: > Eric Friedman <[EMAIL PROTECTED]> writes: > > I'd apply the patch myself, but due to the heavy use of preprocessed > > headers, I'm worried I won't get it completely right. So I'll leave > > it up to Aleksey (or others) to fix. > > AFAICT, Aleksey is the only one who knows how to make modifications > to MPL correctly in the context of its preprocessing system. Aleksey, > a short README would totally solve this problem, wouldn't it? How about this one instead: f:\cvs\boost\libs\mpl\preprocessed> preprocess.py Usage: preprocess.py [] Purpose: updates preprocessed version(s) of the header(s) in "boost\mpl\aux_\preprocessed" directory Example: the following command will re-generate and update all 'apply.hpp' headers: preprocess.py all f:\cvs\boost apply.cpp ? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: [mpl] workaround needed for Borland
Eric Friedman wrote: > Aleksey (and all), > > In working on porting boost::variant to Borland, I've come across some > trouble with a bug in the compiler. > > Specfically, I'm getting "Cannot have both a template class and > function named 'bind1st'" and similarly for bind2nd. I know other MPL > headers use BOOST_MPL_AUX_COMMON_NAME_WKND to work around this bogus > report. > Fixed in the CVS now. > I'd apply the patch myself, but due to the heavy use of preprocessed > headers, I'm worried I won't get it completely right. So I'll leave it > up to Aleksey (or others) to fix. I've checked in some missing pieces for the preprocessed headers generation, so if somebody feels like doing a similar fix herself in future, she can easily do it - assuming she has Python and gcc installed. See "libs/mpl/preprocessed/preprocess.py" blurb for the details. Thanks for the report, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: iterator_adaptors.hpp - typo?
"John Torjo" <[EMAIL PROTECTED]> writes: > When creating the STATIC_CONSTANTs, was "|" what was meant, or was "||" > meant to be there, like this: > BOOST_STATIC_CONSTANT( > bool, is_input_or_output_iter > = > (boost::is_convertible::value > || > boost::is_convertible::value)); The former; some compilers have problems with ||, believe it or not. Fortunately, the sandbox iterator adaptors, which will replace the existing one shortly, usess MPL and avoids most of these issues. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem problem
> Comments? Sounds reasonably to me, but I admit that I don't really understand POSIX filesystems. I guess what I really wanted was something that would be equivalent to "rm -f file", remember that we already have the equivalent to "rm -r path". Of course I don't know how one would implement that :-) John. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: BOOST_STATIC_ASSERT - a little better
- Original Message -
From: "Pavel Vozenilek" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, June 20, 2003 12:38 PM
Subject: [boost] Re: BOOST_STATIC_ASSERT - a little better
>
> "John Torjo" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > Hi all,
> >
> > I was just thinking (actually, I needed this, while doing some coding),
> that
> > STATIC_ASSERT could get a little of the SMART_ASSERT flavour.
> >
> > What am I talking about?
> > In case a STATIC_ASSERT fails, how about dumping some data that was
> involved
> > in the expression?
> >
> SMART_ASSERT is very useful to provide context information for hard to
> reproduce errors. STATIC_ASSERT error can be reproduced reliably during
> every compilation.
True, but:
- just consider a very complicated library (like MPL, for instance), dealing
with traits, etc., and a STATIC_ASSERT fails. In case the one debugging is
not the author of the library, it might be very hard for him to actually
undrestand what happened.
- Imagine that your library is compiled on a different platform, and a
STATIC_ASSERT occurs (for instance, the other compiler is broken), and the
user that tested this is sending you the compiler output (the errors).
Wouldn't you find the more information he sent you the better it is?
Just look at the following and tell me if you knew what to do if any fails
(taken from boost libraries):
// boost/half_open_range.hpp
BOOST_STATIC_ASSERT((boost::is_same::value));
// boost/graph/connected_components.hpp
template
inline typename property_traits::value_type
connected_components(const Graph& g, ComponentMap c,
const bgl_named_params& params)
{
typedef typename graph_traits::vertex_descriptor Vertex;
function_requires< WritablePropertyMapConcept >();
typedef typename boost::graph_traits::directed_category directed;
BOOST_STATIC_ASSERT((boost::is_same::value));
// boost/graph/isomorphism.hpp
template
bool isomorphism(const Graph1& G1, const Graph2& G2, IsoMapping f,
Invariant1 invariant1, Invariant2 invariant2,
std::size_t max_invariant,
IndexMap1 index_map1, IndexMap2 index_map2)
{
// Graph requirements
function_requires< VertexListGraphConcept >();
function_requires< EdgeListGraphConcept >();
function_requires< VertexListGraphConcept >();
function_requires< BidirectionalGraphConcept >();
typedef typename graph_traits::vertex_descriptor vertex1_t;
typedef typename graph_traits::vertex_descriptor vertex2_t;
typedef typename graph_traits::vertices_size_type size_type;
// Vertex invariant requirement
function_requires< AdaptableUnaryFunctionConcept >();
function_requires< AdaptableUnaryFunctionConcept >();
// Property map requirements
function_requires< ReadWritePropertyMapConcept
>();
typedef typename property_traits::value_type
IsoMappingValue;
BOOST_STATIC_ASSERT((is_same::value));
The list could go on.
Please note that this was not in any way an offense at the authors of the
files above.
The idea is that I consider useful a little more information, in cases like
this. Of course, I'm not asking that BOOST_STATIC_ASSERT is *modified*, just
extended (with BOOST_STATIC_ASSERT1, BOOST_STATIC_ASSERT2, etc.).
What do you think?
Best,
John
>
> /Pavel
>
>
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] iterator_adaptors.hpp - typo?
Hi,
Here's some code for the validator class, in iterator_adaptors.hpp:
// line 741
// This is really a partial concept check for iterators. Should it
// be moved or done differently?
template
struct validator
{
BOOST_STATIC_CONSTANT(
bool, is_input_or_output_iter
=
(boost::is_convertible::value
|
boost::is_convertible::value));
// Iterators should satisfy one of the known categories
BOOST_STATIC_ASSERT(is_input_or_output_iter);
// Iterators >= ForwardIterator must produce real references
// as required by the C++ standard requirements in Table 74.
BOOST_STATIC_CONSTANT(
bool, forward_iter_with_real_reference
=
((!boost::is_convertible::value)
| boost::is_same::value
| boost::is_same::type&>::value));
BOOST_STATIC_ASSERT(forward_iter_with_real_reference);
};
When creating the STATIC_CONSTANTs, was "|" what was meant, or was "||"
meant to be there, like this:
BOOST_STATIC_CONSTANT(
bool, is_input_or_output_iter
=
(boost::is_convertible::value
||
boost::is_convertible::value));
...etc.
Best,
John
--
John Torjo
-- "Practical C++" column writer for builder.com.com
Freelancer, C++ consultant
mailto:[EMAIL PROTECTED]
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [sandbox] sequence_algo problem
I've run into a problem using sandbox::boost/sequence_algo/algorithm.hpp. The header uses "boost::find", but that function can't really be used, because: 1. (minor) it depends on new iterator adaptors, while I'm using sandbox with boost CVS. 2. It's not possible to use boost::find, since, as I've previously reported, some code in standard library uses unqualified 'find' and, thanks to ADL, will find not only standard find, but boost::find also. Which will be ambiguity. 3. I really don't understand what's boost::find is about. Seems like it manually unrolls search loop for random iterators. While this might be an optimization, I'm not sure it's worth the trouble in 2), especially since compiler might unroll the loop automatically. Thoughs? I think that either 1. all content of non_modifying.hpp should be moved to namespace boost::non_modifying (or even better, boost::algorithm::non_modifying), or 2. non_modifying.hpp should be removed - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Added new test file, need help testing
I added another test file for the I/O-state saving classes. It's in the main Boost CVS as "boost/libs/io/test/ios_state_unit_test.cpp". I have two compilers installed (GCC 3.1 and CodeWarrior 8). I wrote and tested the new file with CodeWarrior. But my GCC doesn't support the wchar_t part of the libraries, so I can't test with that compiler. Can other people test the file with other compilers to make sure everything is OK? I want the new file to replace the current test file there, but I want to make sure everything works. For locale experts and Metrowerks engineers: the unit test for the locale saving class has big comments about a problem with use_facet. Some book I got on IOStreams says that use_facet should do an ID check and a dynamic_cast check, but the CodeWarrior implementation seems to only do the ID check. Should CodeWarrior change to also do the dynamic-check? The standard is vague on this question. (It could just be a QoI issue; maybe there's a DR on it.) Daryle ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] Yet another patch for nonrecursive DFS
Hi Bruce, Bruce Barr wrote: > I'm glad Vladimir got me to take another look at this. > I'm submitting a new patch to replace the one > submitted on May 30. And I'm glad you're willing to polish your patch! > There are other differences between the recursive and > nonrecursive versions that, in my opinion, are good or > necessary. > > 1) The objects color, u, ei, and ei_end are only > created/destroyed once instead of at every level of > recursion. I think that for 'u', you might have two invocations of copy constructor: when pushing to the stack and when popping ;-) But that's not every level of recursion anyway. > 2) The overall number of constructions/destructions > for types Vertex and Iter is different. It's possible > for client code to depend on something like that, but > I think trying to support that sort of code is going > overboard. Agree. > Here are some pseudo-FAQ's to explain some other > details. > > Q) Why is the statement > 'stack.reserve(num_vertices(g));' commented out? > > A) Because premature optimization is bad. Anyway, > only the library user could know what the ideal > capacity of the stack vector is. num_vertices(g) > might be way too high. Maybe the argument for reserve > could be passed in as a parameter someday. > > Q) Why use nested pairs for VertexInfo instead of > tuples? > > A) Only because out_edges() returns a pair. Tuples > probably would have been just as good. There's another question: why store "u" at all. I'm guessing "source(*ei, g)" might be more efficient? I'm thinking we have some technical questions left to apply your patch. 1. It needs license from you. Either the standard one: // (C) Copyright Bruce Barr, 2003 // Permission to copy, use, modify, sell and distribute this software // is granted provided this copyright notice appears in all copies. // This software is provided "as is" without express or implied // warranty, and with no claim as to its suitability for any purpose. which, I belive, is preferred, or any one you like, which meets Boost guidelines. 2. Once you decide on 1) I'll commit your patch, making nonrecursive dfs default. I plan to retain the old version for a while, because it would be desirable to compare performance. 3. Maybe, the FAQ, either fully or partically, must be added too. That's up to you, though. Thanks, Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: tokenizer comments
Hi, > Ah... the problem is that those new additions are not documented, AFAICT ;-) > It makes it a little bit hard to understand the interface, especially since > there are no examples/tests for split functionality. Well, as I said, this stuff is quite new, documentation will follow soon, please be patient :) Currently the example usage can be seen only in tests :( Tests for split are located in $sandbox$/libs/string_algo/iterator_test.cpp I want to finish some parts of implementation beforehand and I have plans to completely rework the documentation to reflect these changes. > > > One of them is the integration with the container_traits idea proposed by > > Jeremy Siek and Thorsten Ottosen. It allows to use C-string the same way > > as any container. > > Ehmm... I see that you're using a local/modified copy of > sandbox/boost/sequence_algo/container_traits.hpp. Do you plan to intergate > those files? It would be very good idea, IMO. > They are already integrated, but there is still a need for a little bit of polishing. I have modified/extended container_traits from /sequence_algo/ to fit them into the lib. However, the contaiter_traits in the string_algo lib are not mean to be used from outside of the lib. At least not for now. I think, that they are essential for string_lib, so I asked Thorsten if I can integrate them. If my lib gets accepted, it will also act as a showcase for container_traits. Regards, Pavol ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
