Re: [boost] stlport gcc support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 20 August 2003 02:02, Trey Jackson wrote: It appears that stlport is only used with gcc 2.95.3 (and in Windows with Intel's C++ compiler and MS C++ 6.0). Is boost moving away from supporting stlport? Or are the regressions not being run for some other reason? 1. GCC3 has a stdlibrary that deserves its name. Using STLport for the one that came with earlier versions isn't necessary anymore. 2. Leaving out the early beta-versions of GCC (3.0, 3.1), there is no support for the 3.x branch in any official STLport release. People are actively working on it though, see the forum on stlport.org. Uli -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Qx0bwVdGSYi8Mq8RAiIMAJ9IqzfKAV1w4SYhRlduDIwEnhsn1wCdE5Zu 6blDoZrf8ur579so4Fo6QVY= =b1JW -END PGP SIGNATURE- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: stlport gcc support
Russel Hill [EMAIL PROTECTED] writes: Martin Wille wrote: I'm currently considering adding gcc-3.3.1/stlport to the tests. Since we are using boost/stlport/gcc-3.3.1... 1) What kind of resources does it take to run the regression tests? Speaking of our regression test (http://tinyurl.com/kkns): We have 2GHz Pentium IV with 512MB of memory. Clean run (delete old results, get sources from CVS, run regression tests), creating reports and uploading the results takes about 4 hours. Maintenance-wise you will have to put some time into: * Eliminating regressions on tested compiler/platforms. See below. * Installing new compiler releases/service packs as they are released by vendors. * Running the regressions on main trunk and in the release times also on the release branch. 2) Would it be helpful if we ran them? Could the community make use of our test results? How? Well, I cannot answer for the whole community. Looking at the big picture: 1. Regression test results are used by release managers as release criteria. 2. Regression test results are used by boost developers to see how their code compiles and runs on the compilers/libraries/systems not available to them. 3. Regression test results are used by the boost users to see boost support of specific compiler/platform. See Aleksey Gurtovoy's posting on this subject at http://article.gmane.org/gmane.comp.lib.boost.devel/20648 Now, what could be done by regression maintainers to better support these use cases? IMHO: * Publishing the results of regression runs for released versions of Boost (1). * Continuous regression testing (2,3). * More compilers/environments (3), but see http://article.gmane.org/gmane.comp.lib.boost.devel/23533 for the issues involved. * Tracking the regressions history (1,2). Would it be helpful if you ran them *now*? * From my standpoint: it would be nice to know that if we were temporarily unable to run tests for one reason or another - there would somebody else who can provide that service (Actually, currently we are the second Windows regression test runners, first is Beman Dawes) * From the users standpoint: it would be nice to have the regression test runs for their compiler/platform combination. * From the release manager/library authors standpoint: they should not be left alone figuring out all config and other problems just based on the fact that somebody is running the regression tests on this particular configuration. Thanks for asking, I hope my answer helps. -- Misha Bergal MetaCommunications Engineering ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] stlport vc++ (was RE: [boost] stlport gcc support)
People are actively working on it though, see the forum on stlport.org. It seems, adding STLport/any recent gcc version to the tests makes only limited sense at the moment. I'm inclined not to add such a configuration, now. Additionally, Visual C++ 7.1 (aka .NET 2003) also comes with decent (working) implementation of standard library, and considering the dynamics of new STLPort versions (quite slow lately), I don't see a point in using STLPort any more for newer MS compilers. VC 6 is another story as STLPort is the only sane standard library implementation. Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Boost-announce] Boost 1.30.2 is released
Daryle Walker [EMAIL PROTECTED] writes: On Tuesday, August 19, 2003, at 11:56 AM, David Abrahams wrote: This release was managed by Dave Abrahams with the generous and dedicated help of Aleksey Gurtovoy and Misha Bergal of Meta-Communications, Inc., and of Martin Wille. We expect this to be the last release in the 1.30.x chain; see our CVS repository or its mirrors for new developments expected to appear shortly in 1.31.0. Changes from this release have been incorporated into the main trunk, right? Most, but not all. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Filesystem portable path rationale and use-cases
David Abrahams [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] writes: Brian Gray [EMAIL PROTECTED] wrote: Should we (do we?) have some spreadsheet enumerating various filesystem features, quirks, and limitations for whatever systems we can find, and using that as a reference regarding how to organize features like paths, file references, forks, or whatever else? It might help us to back out of the code and re-examine the problem domain regardless of the current state of Boost. I've been thinking that maybe the best way to provide for portable paths is to have a bunch of flags that you can set. So when you push something onto Beman's singleton stack, you can, for example, set the NTFS and VMS flags if you only care about those filesystems. However, that makes it difficult to extend to customized portability restrictions. That might require some kind of function stack within each element of the singleton stack. Then you can push the NTFS and VMS checkers onto that stack within the stack. I _really_ hope we don't have any singleton stack which affects path validation. It sounds like a nightmare for any application involving threads. I think I finally understand what the problems with multiple threads are. You are worried that one thread's portability checking will be changed midstream by another thead. Sounds hairy. So one solution is to make the portability checking local to a thread. I don't have a feel for how to implement that, and it does seem to introduce complexity where it isn't always needed. Regards, Walter Landry [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Regressions in CVS HEAD
Hello, I'd like to inform you about regressions in the current state of CVS wrt Linux (see http://tinyurl.com/k36t). Boost.CRC: crc_test regresses for gcc-3.1 and gcc-3.2.3 Boost.Date_Time: almost all tests regress for gcc-2.95.3 testperiod regresses for intel-7.1 Boost.Graph: graph regresses for gcc-2.95.3 Boost.Multi_Array 50% of the tests regress for gcc-2.95.3-stlport-4.5.3 Boost.Random all tests regress for gcc-2.95.3 Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: xml library
On Sun, 17 Aug 2003 22:45:34 +0200, Wojtek Surowka wrote: I think that what is still missing in Boost is a library for reading and writing XML files. I have such a library, though in rather preliminary ... If there will be an interest, I can submit the library code and extend it. I am interested (I like the interface) and would like to test it. Cédric. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] stlport gcc support
Martin Wille wrote: Yes, that is why I didn't add more STLport configurations to the tests, yet. However, STLport's support for debugging is certainly an interesting feature to use for many developers. So, there would still be good use for STLport with recent gcc versions. This is exactly our situation. Our target applications actually run on an embedded coldfire board. At this point, we're constrained to a gcc-2.95 derived toolchain, no stlport, and no boost ... on the target platform. As time allows, we will be looking into the later toolchain and uClinux distributions. For now we use STLport to support our development environment, simulation, and testing. STLport assertion failures are fairly rare occurrances, but well worth the investment when they do happen. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem portable path rationale and use-cases
On Tue, 2003-08-19 at 19:49, Brian Gray wrote: On Tuesday, August 19, 2003, at 12:35 AM, Yitzhak Sapir wrote: My feeling from all these examples is that a path string is inherently specific to the system for which it was specified, and can't really be ported to anywhere else. Much like a string is usually inherently specific in its encoding to the system-specified encoding. However, the filesystem library can provide a portable way to manipulate this system specific path, much like the string library provides a portable way to manipulate the system-specific encoded string. In view of this, why try for a portable path at all? This may have been covered already, but I would go further and assert that the very concept of a string path is non-portable. It does not have to be. It is legal on both Windows and *nix'es to have spaces in paths and filenames. This does not make it a good thing. I like that when I create paths that they are portable and I can use this to validate user input as well. When I have to traverse existing paths then I expect to have to use native paths. /ikh ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Filesystem portable path rationale and use-cases
Walter Landry [EMAIL PROTECTED] writes: David Abrahams [EMAIL PROTECTED] wrote: Walter Landry [EMAIL PROTECTED] writes: Brian Gray [EMAIL PROTECTED] wrote: Should we (do we?) have some spreadsheet enumerating various filesystem features, quirks, and limitations for whatever systems we can find, and using that as a reference regarding how to organize features like paths, file references, forks, or whatever else? It might help us to back out of the code and re-examine the problem domain regardless of the current state of Boost. I've been thinking that maybe the best way to provide for portable paths is to have a bunch of flags that you can set. So when you push something onto Beman's singleton stack, you can, for example, set the NTFS and VMS flags if you only care about those filesystems. However, that makes it difficult to extend to customized portability restrictions. That might require some kind of function stack within each element of the singleton stack. Then you can push the NTFS and VMS checkers onto that stack within the stack. I _really_ hope we don't have any singleton stack which affects path validation. It sounds like a nightmare for any application involving threads. I think I finally understand what the problems with multiple threads are. You are worried that one thread's portability checking will be changed midstream by another thead. Sounds hairy. So one solution is to make the portability checking local to a thread. I don't have a feel for how to implement that You'd need TLS, IIUC a limited resource that I wouldn't want to spend on this. and it does seem to introduce complexity where it isn't always needed. Absolutely; IMO the whole issue of portable representations and portability checking needs to be rethought in the context of use cases. I do believe there's a satisfactory simple approach in there somewhere. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] number64 proposal
You might also like to look at the highly refined NTL by Victor shoup at www.shoup.net/ntl This has been used to calculate very accurate math constants, for example. And provides a fairly simple way of providing both C++ quad (128-bit) and arbitrarily higher precision too. However I suspect that the requirement for 'infinite' precision FP is limited and that this and/or other packages will meet most peoples rather special needs. Boostification is not a trivial task I have discovered :-( Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Philippe A. Bouchard | Sent: Tuesday, August 19, 2003 12:14 PM | To: [EMAIL PROTECTED] | Subject: [boost] number64 proposal | | | Hi there, | | Like I mentionned before, it would be great for Boost to have an | infinite precision floating point number. You can see an example here: | http://members.lycos.co.uk/keithmbriggs/doubledouble.html. Of course, the | doubles could be replaced by long doubles, a muldiv() could be easily added, | the exponents could be increased as well, etc. | | Maybe someone can ask how to calculate trigonometric functions with less | precise versions and so on. It would be really great for Boost to have this | user-defined precision because I am pretty sure research centers will be | interested. | | | | Philippe | | | | ___ | Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Insufficient significant digits using lexical_cast
| -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Spangenberg | Sent: Tuesday, August 19, 2003 9:25 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Insufficient significant digits using lexical_cast | | I think, the correct solution would be the usage of a constant, similar to | DECIMAL_DIG, which is provided from C99 on. 5.2.4.2.2 says: | | number of decimal digits, n, such that any floating-point number | in the widest | supported floating type with pmax radix b digits can be rounded to a | floating-point | number with n decimal digits and back again without change to the value, | | pmax log10 b if b is a power of 10 | Ceil(1 + pmax log10 b) otherwise | | DECIMAL_DIG 10 | | | My personal opinion is: Extend the DECIMAL_DIG definition for any | floating point type, | similar to digits10 I agree (and indeed have previously and now suggested) that adding to numeric_limits:: would be the best solution. But for the time being to 'fix' lexical cast, I think my suggestion, perhaps with Daryle's refinement to warn if not IEE754, is at least better than the existing formula. I will make a further suggestion when I get a moment to test it. 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
Re: [boost] Build help for OS X
FWIW: I am using gcc 3.3.1 compiled from scratch with sources from gcc.gnu.org under OS X. This works with full optimization (gcc 3.3 did not). I didn't see your other messages, but I hope this is relevant: I had serious trouble with multiple initializations of a static variable in the Boost.Python library. Somehow I got it to work after hours of trial-and-error. See boost/libs/python/src/converter/registry.cpp, BOOST_PYTHON_CONVERTER_REGISTRY_APPLE_MACH_WORKAROUND. It could be that the std::cout std::flush trick is the main trick, I am not sure, I only know it works the way you see it. --- Paul Hamilton [EMAIL PROTECTED] wrote: I managed to get my stuff built using all shared libraries on OS X, but I came across the following problems: - I had to hack boost/format/feedargs.hpp to remove the static variable (I have explained in other posts why). - I am going to work around this by only having a single include point for format.hpp, but it will limit my further use of this. - I sent a message earlier about changing this code so that is does something a lot simpler than it does, and it fixes my problem. Any thoughts about that? - I had to turn off optimization and inlines for the release build because I was getting a bunch of non-virtual thunk errors in the link. - I will test with the latest build from Apple to see if this goes away, since when I googled I received lot's of this is a compiler bug, turn off optimization messages. But in the meantime, rather than needing to hack darwin-tools.jam to turn off inlining/optimization, how do you change these for the default build? I tried this in my Jamfile: dll cppxmlobjlib : $(XMLOBJ_PATH)/$(CPP_SOURCES).cpp lib../libs/cpppersistxmllib lib../libs/cpppersistlib lib../libs/cppreflectlib : sysinclude$(BOOST_ROOT) find-libraryexpat optimizationoff inliningoff : debug release ; But it gives me a warning saying that optimizationoff is not compatible with optimizationfull. How do you override those defaults? Paul. - Paul Hamilton pHamtec P/L - Software Makers http://www.phamtec.com/ mailto:[EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. - ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] BOOST_MESSAGE
I am using the unit test framework on Solaris 5.8 using workshop 6 I can't get BOOST_MESSAGE to print anything. You need to set a log level to messages. By default it's all_errors. You could do it like this: your program name --log_level=messages If you always want to use above log level you could set an environment variable BOOST_TEST_LOG_LEVEL. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Problem using bjam with g++ 3.2
Hi, This is my first attempt to build Boost 1.30.2 on FreeBSD with gcc 3.2 installed. I have the compiler installed as gcc32 and g++32. These names are found as commands, so that I can simply type $ g++32 hello.cc or $ g++ hello.cc and have the same source file compiled either by gcc 3.2 or by gcc 2.95 (the default installation on my system). This is quite convenient for me. Now, coming to Boost. I would like to use gcc 3.2 to build Boost. I was able to build jam with this compiler version by hacking build.sh in the tools/build/jam_src directory. My problem is how to subsequently tell bjam to use g++32 instead of g++ to build libraries. The command: $ tools/build/jam_src/bin.freebsd/bjam -sTOOLS=gcc builds Boost using the default gcc and g++ compilers. Following the docs, I tried to do: $ tools/build/jam_src/bin.freebsd/bjam -sTOOLS=gcc -sGXX=g++32 -sGCC=gcc32 but I can see that still the default versions are used. I guess I'm doing something the wrong way. Any help will be greatly appreciated. -- Maciej Sobczak http://www.maciejsobczak.com/ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::format on gcc2.96?
Gavin Doughtie a écrit : I've been struggling to get boost::format to work on gcc 2.96 and having some awful compile issues. I can't use STL port since I need to link with libraries built against the standard GCC stl. Is there a compatibility flag or something I can set to make this work? A specific error dump is below. Apologies in advance for the direct email. What is the appropriate list/group for questions like this in the future? Direct email is not a problem for me (as long as I dont recevive too many of them in a day :), I dont know about Dave. The best place to continue discussion on the subject of adding compatibility for gcc 3.0 to format is the boost developper list, [EMAIL PROTECTED] First, I'd like to know : is there absolutely no way you could upgrade to more recent gcc-3.x ? I think the standard-conformance of g++ got so much better with the 3.x versions, that any C++ programmer would have to consider upgrading, sooner or later. I dont see supporting gcc-2.95 as a very important point, now that so many compilers become -at last- close enough to the C++ standard, to require much much less time spent in writing worthless workarounds. The C++ standard library shipped with gcc-2.95 (see P.S.) has many issues, and making format to compile with it would require too many workarounds (eg., almost each template function signature would have to be modified..) to be implemented as #ifdef's in the main header files. Though, I could modify the set of headers to work specifically with gcc-2.95, but even then I think adding those files to boost repository might bring more clutter than worth. (also, to compile with gcc-2.95, I'd have to remove locale support, as well as wchar suppport, rather than spending hours finding how to have them work -if at all possible- with this gcc's library). So this could be a possible solution if this is fine for your needs, and you really, really can't switch to g++-3.x. Best regards, -- Samuel PS : I talk about gcc-2.95 rather than 2.96 as I dont have such a compiler available on my system. I believe gcc-2.96 is a redhat-shipped version of gcc (which gcc's team made clear they do not support, as they never released it), roughly similar to the gcc-2.95,which I know about, and which I have access to on my debian system. I think it is safe to assume the issues with gcc-2.96 are the same with the ones I observed with gcc-2.95 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Insufficient significant digits using lexical_cast
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of Daniel Spangenberg
| Sent: Tuesday, August 19, 2003 9:25 AM
| To: [EMAIL PROTECTED]
| Subject: [boost] Re: Insufficient significant digits using lexical_cast
In the absence of a C99 or numeric_limits significant decimal digits value
(and don't forget what is needed is effectively an 'unrounded' value with some
'noisy' guard digits at the end, not just digits10)
some tests show that the following
if(std::numeric_limitsTarget::is_specialized
std::numeric_limitsTarget::radix == 2)
{
stream.precision(2 + std::numeric_limitsTarget::digits * 301/1000);
}
else if(std::numeric_limitsSource::is_specialized
std::numeric_limitsSource::radix == 2)
{
stream.precision(2 + std::numeric_limitsSource::digits * 301/1000);
}
uses the correct number of significant decimal digits for ALL builtin bool,
char, int and floating point types:
And a loopback test like:
l == lexical_castT(lexical_caststring(l))
is true (correct) for at least some selected values - and I wager a couple of
beers for all non-NaN non-Inf values ;-).
Possibly a comment warning of possible trouble here would be helpful?
// if neither specialized, or unusual radix, then use default stream precision
of 6?
// Warning: a loopback like
// l == lexical_castT(lexical_caststring(l)) may be false
I believe a test radix == 2 is appropriate because is_iec599 (IEEE754) would
fail for integer types, which actually work correctly with the above formula.
Paul
Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
mailto:[EMAIL PROTECTED]
For the curious I used:
template typename T bool test(T l)
{
cout l ' ';
string sl = lexical_caststring(l);
cout sl ' ';
T ll = lexical_castT (sl);
cout ll
(l == lexical_castT(lexical_caststring(l)))
// Convert type T to string and back to T.
endl; // eg for long 2147483647 2147483647 2147483647true
return (l == lexical_castT(lexical_caststring(l)));
} // test
template typename T bool tests()
{
if (numeric_limits T ::is_specialized)
{
cout numeric_limits T ::digits ' ' numeric_limits T ::digits10
' ' 2 + std::numeric_limitsT::digits * 301/1000
endl;
}
else
{
cout Not specialized! endl;
}
return // for a few sample values.
test T (numeric_limits T ::max()) // max
test T (T(1)) // unity
test T (T(0)) // zero
test T (T(-1)) // -1
test T (numeric_limits T ::min()); // min
} // tests
and
testsbool ();
testschar ();
testsunsigned char ();
testsshort ();
testsunsigned short ();
testsint ();
testslong ();
testsunsigned long ();
testsfloat ();
testsdouble ();
testslong double ();
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] enable_if formal review ?
Hi Boosters, We submitted enable_if for formal review in July. The library does not seem to be on the review queue, and maybe it is not worth a full review. There was a kind of unofficial mini review after our submission, which brought up a few issues: 1. Whether to make enable_if MPL-aware or not. In the submitted version, the first parameter of the enable_if template is boolean, whereas some Boosters wanted it to be a type containing a boolean member constant named value. The latter plays better with MPL, and in some cases can avoid instantiating branches of conditional expressions (shortcircuiting). Close to consensus was reached that both versions of enable_if should be supported; naming was not decided on Dave Abrahams's suggestion was to use the name enable_if for the MPL-aware version, and enable_if_c for the version taking the boolean template parameter. We plan to adopt this naming convention. 2. Enable_if_lazy Some comments were against the name enable_if_lazy. We plan to change it to lazy_enable_if, particularly if the enable_if and enable_if_c naming convention is approved. 3. disable_if The submission included the disable_if template. The same functionality can be achieved with enable_if by negating the condition, and so someone asked it to be removed. On the other hand, there was opposition to its removal. We plan to keep disable_if for convenience. 4. Non-SFINAE compilers Dave has an implementation of enable_if which defaults to being always enabled for compilers that do not support SFINAE. We do not think this is the right approach, and believe that attemts to use enable_if on a compiler that does not support SFINAE, should cause an immediate error. 5. Non-partial specialization compilers Are there any compilers that support SFINAE but do not support partial specialization? If not, we plan to use partial specialization in our implementation. Do other Boosters think an official review is necessary, or what will the process be? The submitted version is in the sandbox: boost/utility libs/utility and in the Files section at YahooGroups. Note that none of the changes discussed above are currently in the code. Cheers, Jaakko Jeremiah ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: enable_if formal review ?
Jaakko Jarvi wrote: The submitted version is in the sandbox: boost/utility libs/utility and in the Files section at YahooGroups. Note that none of the changes discussed above are currently in the code. I think the current license is unacceptable. 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
[boost] Re: enable_if formal review ?
In our last exciting episode Daniel Frey wrote: Lines: 21 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 Jaakko Jarvi wrote: The submitted version is in the sandbox: boost/utility libs/utility and in the Files section at YahooGroups. Note that none of the changes discussed above are currently in the code. I think the current license is unacceptable. Did the boost license discussion lead to a result? Is there now on offical Boost License? Jaakko ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: switch-based runtime type selection (for variant)
Eric, I've been too lazy to reply. From: Eric Friedman [EMAIL PROTECTED] Subject: Re: switch-based runtime type selection (for variant) Date: Thu, 14 Aug 2003 02:09:41 -0400 Brian Simpson wrote: Eric, It sounds like you've become convinced that the switch is, indeed, worth the effort? [snip] Thanks for the explanation. Still, I would like to put forward a couple of considerations. These are comparatively subjective: 1) The runtime_type_selected_invoker component is implemented independent of variant. Two benefits deriving from this approach are: a) variant becomes a client rather than a collaborator in the usage of the functionality. The practical differences? A three-argument function call rather than a six-argument call dependent on two supporting typedefs. Generally I might agree with this argument, but I disagree in this instance because of the the heavy use of templates invovled. Thus, even if the visitation mechanism were in a separate header, any changes will require any code dependent on variant.hpp to be recompiled. So with that given, I'm not sure what other advantages there would be (apart from perhaps a slightly-simplified invocation in variant's raw_apply_visitor implementation). And, I agree, that's no significant advantage. b) Distribution decisions can be made separately for the two. One that I thought of was preprocessing. If someone wants to distribute preprocessed versions of code, he can make one decision for variant and another for rtts. I actually do agree with this. Accordingly, I've factored apply_visitor_impl into a separate detail header. And I do plan to look into preprocessing at some point... Cool! 2) An interesting characteristic of your approach is that it results in the generation of extra cases which should never be executed. There seems to be some extra complexity involved in implementing these extra cases. The implementation I propose does not suffer this problem. (Don't these extra cases seem like constructing a foundation with the cracks built-in? I know that the correctness of the class should make it impossible to ever fall in, but it still makes me nervous.) If you don't have to worry about how to implement extra cases, you can spend more time implementing more visible stuff! Hmm... If the variant class is not correct then a more reliable visitation mechanism isn't going to help anything (and may potentially mask any problems). Furthermore, there have been assertions in forced_return (and now apply_visitor_impl itself) to catch obviously broken implementations. So I guess this point could work either way, but I don't know if its worth changing anything now as a result. (Please reply if you disagree.) This reply does not indicate disagreement. If this component was not currently under development and I was not intensely interested in it, I wouldn't know enough about the implementation to be worried. Accordingly, I intend to forget the aforementioned worries. I have some features that I'd like to see added, yet, but I'll try to come up with proofs of concept before requesting them. As it stands, variant is a powerful component. --Brian _ bGet MSN 8/b and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Fun] (( a xor b )) formal review request...
Inspired by a thread over at comp.std.c++, I suggest the following MACRO
for inclusion into Boost. Please discuss :)
//
// A logical xor operator for C++.
//
// Create a macro for the following syntax: ((a xor b)). Note that
// the bracket are part of the syntax and shall not be removed!
// The macro guarantees left-to-right evaluation, a sequence point
// between the evaluation of 'a' and 'b', conversion of the
// parameters to bool and a boolean result.
#define BOOST_DETAIL_XOR(x) !static_castbool(x):static_castbool(x)
#define xor )?BOOST_DETAIL_XOR(
// Usage:
#include iostream
using namespace std;
struct B
{
operator bool() const { return true; }
B operator!() const { return B(); }
};
int main()
{
B a, b;
// Oops...
cout ( a != b ) endl;
cout ( a ? !b : !!b ) endl;
// Works, but long, ugly syntax and repeating 'b':
cout ( a ? !static_castbool(b) : static_castbool(b) ) endl;
// Cool?
cout (( a xor b )) endl;
}
Regards, Daniel
PS: No, don't take this too serious :o)
--
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
[boost] Re: Re: Time representation in Boost Date-Time
Jeff Garland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ok, but you couldn't you just use date here? Well, the objects I'm dealing with CAN have time-of-day information, but mostly they do not, and this is not known until run-time. So, for the sake of a common interface, I want to use time, but simply ignore the time-of-day part when it is not needed. Interesting, you are correct it does not work. The fact is that the time interface is incorrect because like date, ptime should allow special value construction and queries directly. That's been on the todo list for awhile now to handle this right, but the fact that this doesn't even work is not good. Yes the special date values don't appear to be regarded as special when used with the counted representation. They just get combined into the single counted value, and their special-ness is lost. Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [Fun] (( a xor b )) formal review request...
#define xor )?BOOST_DETAIL_XOR( FYI, you cannot legally define xor because it is specifically *not* an identifier--even to the preprocessor. This is the primary difference between keywords and textual alternative tokens. 2.5/2 - In all respects of the language, each alternative token behaves the same, respectively, as its primary token, except for its spelling. E.g. #define ^ is invalid, and therefore #define xor is invalid. 16.1/4 (note #137) - An alternative token (2.5) is not an identifier, even when its spelling consists entirely of letters and underscores. Therefore it is not subject to this replacement. Regards, Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Fun] (( a xor b )) formal review request...
Paul Mensonides wrote: #define xor )?BOOST_DETAIL_XOR( FYI, you cannot legally define xor because it is specifically *not* an identifier--even to the preprocessor. This is the primary difference between keywords and textual alternative tokens. I admit that I forgot that 'xor' is an alternative token (which should better be called bitxor, but anyway). But according to the Boost guidelines, my macro has to be called BOOST_XOR anyway (boostification). Or how about alternatives like 'eor', 'lxor', 'logicxor', you-name-it...? 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
[boost] Re: enable_if formal review ?
Jaakko Jarvi [EMAIL PROTECTED] writes: In our last exciting episode Daniel Frey wrote: Lines: 21 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 Jaakko Jarvi wrote: The submitted version is in the sandbox: boost/utility libs/utility and in the Files section at YahooGroups. Note that none of the changes discussed above are currently in the code. I think the current license is unacceptable. Did the boost license discussion lead to a result? Is there now on offical Boost License? Pretty much. See http://www.boost-consulting.com/boost/more/license_info.html or boost/more/license_info.html in your CVS tree. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: enable_if formal review ?
Jaakko Jarvi [EMAIL PROTECTED] writes: 4. Non-SFINAE compilers Dave has an implementation of enable_if which defaults to being always enabled for compilers that do not support SFINAE. We do not think this is the right approach, and believe that attemts to use enable_if on a compiler that does not support SFINAE, should cause an immediate error. Can you justify that choice a bit? In the applications where I've used it, no-op behavior provides good gradual degradation in functionality (I don't have a strong opinion though). -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Build help for OS X
FWIW: I am using gcc 3.3.1 compiled from scratch with sources from gcc.gnu.org under OS X. This works with full optimization (gcc 3.3 did not). I am using gcc 3.1 which is the current version with the development tools that I have on my Mac OS X. It's good to know what I have in store :-) I didn't see your other messages, but I hope this is relevant: I had serious trouble with multiple initializations of a static variable in the Boost.Python library. Somehow I got it to work after hours of trial-and-error. See boost/libs/python/src/converter/registry.cpp, BOOST_PYTHON_CONVERTER_REGISTRY_APPLE_MACH_WORKAROUND. It could be that the std::cout std::flush trick is the main trick, I am not sure, I only know it works the way you see it. Were you getting the ld: common symbols not allowed with MH_DYLIB output format error? Paul. - Paul Hamilton pHamtec P/L - Software Makers http://www.phamtec.com/ mailto:[EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. - ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
