[boost] Re: Problem with type_with_alignment.hpp
Hartmut Kaiser wrote: Daniel Frey wrote: Concatenating two tokens with the '##' operator, where the result isn't a new valid token results in undefined behaviour. In your sample it yields '', which is a valid token, so it is well defined. In other contexts two consecutive '' characters are always interpreted as '' and not as two single ''. That wasn't my point :) But this isn't the point here. The '' was not formend by a '##' operator but by plain consecutiveness: #define SOME_MACRO(T) T SOME_MACRO(some_class...) // expands to some_class... Exactly. But the expanded some_class... is the result of the preprocessor, so IIRC the two 's are treated as two tokens, not as one, because they weren't glued together with ##. Also, the GCC preprocessor expands the above to some_class... and I'm pretty sure that the rules for inserting spaces are exactly defined and there is not much room for interpretation. If the GCC is correct to insert spaces, then the patch is a work-around for a compiler (here: preprocessor) bug. So, what is the correct behaviour here? 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: Problem with type_with_alignment.hpp
Paul Mensonides wrote: [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Frey It isn't technically supposed to insert spaces, but it is supposed to treat them as two consecutive tokens with no whitespace separation--same [...] Thanks to both you and Aleksey for clarifying. This also convinced my colleague :) 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: CVS main trunk regression test failure
Misha Bergal wrote: The metacomm regression tests run failed last night because of the following bjam failure: boost-test(RUN) iterators : libs\multi_array\test\iterators.cpp boost-test(RUN) compare : libs\multi_array\test\compare.cpp boost-test(RUN) access : libs\multi_array\test\access.cpp boost-test(RUN) constructors : libs\multi_array\test\constructors.cpp ...patience... ...patience... don't know how to make libs!utility!test..\tie_example.cpp ...found 53858 targets... ...updating 40256 targets... ...can't find 1 target... ...can't make 50 targets... Sorry, my fault. tie_example.cpp no longer exists, as 'tie' no longer lives in 'utility'. Can you please remove the reference from the test-file? I don't have access to CVS from here, otherwise I'd do it myself. Thanks. Also, if someone wants to restore the regression tests for 'tie', I suggest they are added to 'tuple' where they belong now. As there is no need to hurry about this, it's enough to speak up and I'll place them there when I have time. A last question to the build-wizards: Would it make sense to make the build system continue if a leaf is missing? I don't see a compelling reason to stop the other regressions from running just because there is one little failure in the configuration of an otherwise unrelated test. 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: Re: Deprecation/removal of libraries
On Thu, 28 Aug 2003 16:19:24 +0200, Douglas Gregor wrote: On Thursday 28 August 2003 08:20 am, Daniel Frey wrote: utility/tie was moved to tuple, so should we remove the obsolete docs/references in utility now? Please do. Done. I also updated the Revisited ..., but there is some checksum in the HTML-source. I have no clue what it's good for, so if I broke it, please fix it and tell me how to avoid it next time :o) Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Optional, tie, and iterator_adaptor
Joel de Guzman wrote: Although I don't see this as problematic: optionalint x; if (x) foo(x); Or perhaps: optionalint x; if (!!x) foo(x); We already have an implicit conversion to safe_bool and an operator ! anyway. Keep it. There's nothing wrong with it: operator unspecified-bool-type() const; bool operator!() const; IMHO, there is something terribly wrong here because now optionalT has two interfaces. The interface of optional itself and the interface of T. If you think that optionalT can be used like T (having the value-interface), you are immediately fooled by if(x) as it doesn't check T's value. A pointer-interface is much cleaner as it gives the user a hint that he is using a wrapper and in practice, I always prefer to be a little more explicit on these things (even at the cost of an occasional * here and there) than to have silent bugs. 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: Deprecation/removal of libraries
Douglas Gregor wrote: On Thursday 28 August 2003 08:20 am, Daniel Frey wrote: utility/tie was moved to tuple, so should we remove the obsolete docs/references in utility now? Please do. OK, will do when I find some time - if nobody objects. 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] [bind] result type deduction/access?
In my current project, there are a lot of code fragments that read like
this:
result-insert( positions,
positions_.begin(),
positions_.end(),
bind( Position::serialize,
_1,
boost::cref( locale ) ) );
The scheme is always the same, all that varies is the name of the
serialized class. Thus I wanted to write a helper:
result-insert( positions,
positions_.begin(),
positions_.end(),
serializer Position ( locale ) );
But the problem is, that AFAIK I have no (documented) way to specify the
result type of such a helper function. The syntax I would imagine
basically looks like this:
template typename T
typename Bind T::serialize, _1_type,
boost::reference_wrapper const Base::Locale ::result_type
serializer( const Base::Locale locale ) {
return bind( T::serialize, _1, boost::cref( locale ) );
}
Is something like that possible? I hope so, but I guess I'm not the
expert to understand all the details involved in the bind-internals. The
above is just an idea, of course it might look different in practice.
The question is, whether we can create some mapping between the call of
the bind-function and a provider for the result type that users can
understand without looking into the code of bind itself.
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: [bind] result type deduction/access?
Mat Marcus wrote: It is not uncommon to use boost::function to hold on to the result of boost::bind. Will that work for you? Wrote it, compiled it and it worked immediately. Thanks very much! :) 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: converting Boost to other programming languages
Mohamed Iqbal wrote: For now I will cnvert three or four libraries for academia purposes but a bigger number of libraries will be ported to my new language when the commercial release is ready. I think it would be best if you convert the three or four libraries you have in mind, prepare it the way you like to redistribute/sell it and show the result to us *before* redistribution. It's easier to say: This is OK or This is not OK when we have something to look at instead of giving you a Carte Blanche. One more question: Should I mention that the original of the converted libraries is from Boost? It IMHO depends whether you port the existing library or if you take the ideas and rewrite it. Again, the difference is difficult to tell without looking at your code. 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: converting Boost to other programming languages
David Abrahams wrote: I'm afraid the license already gives him Carte Blanche. He said that he will not retain the name Boost in the ported libraries. How can he do that without removing the Copyright notice? Hence the differentiation I made between porting code or writing new code reusing the ideas. But anyway, I'm not a laywer... One more question: Should I mention that the original of the converted libraries is from Boost? It IMHO depends whether you port the existing library or if you take the ideas and rewrite it. Again, the difference is difficult to tell without looking at your code. My answer is: if it's a good port, please mention Boost. If it's junk, it has nothing to do with us ;-) The well-known: If it works, it was written by XYZ. If not, I don't know who wrote it.-disclaimer :-D 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: lexicographic: review request?
Daryle Walker wrote:
On Saturday, August 23, 2003, at 11:21 AM, Daniel Frey wrote:
a) Short-circuiting
b) Unnamed functions
Short-circuiting can only be done via compiler magic with the built-in
operator and operator||, so there's no way it can be added to
user-defined routines. Note that each step of the lexicographic
macros and ?: can - as I showed - do short-circuiting, too. User-defined
functions - as you said - can't.
comparison has a result, and that later steps are only evaluated if the
previous step didn't give a result of equivalence (well, the comparison
is skipped; each argument still has to be evaluated). You can also
Evaluation of arguments is IMO the problem.
manually check each intermediate result and code out other checks (with
if statements), which would skip unnecessary evaluations of later
components.
The point is, that Jan proposed to add something which has a hidden
overhead and I'm not sure it's a good idea. Instead of nested
if-else-cascades, the user could also write:
bool operator( const person lhs, const person rhs )
{
return
lhs.lastname != rhs.lastname ? lhs.lastname rhs.lastname :
lhs.firstname != rhs.firstname ? lhs.firstname rhs.firstname :
lhs.age rhs.age;
}
This scheme is easy to remember, (IMHO) easy to read, doesn't have
nested if's and it has short-circuiting. It's only cost which may be
removed by Jan's proposal is that it removes the redundancy in typing. A
per line-macro could do that without further problems, but I won't use
it anyway. Sometimes I prefer to see the real code, hiding something
needs a better rationale IMO. So we need some very convincing arguments
for a new utility if we have to remove the short-circuiting.
Also, you might not want to define operator. Sometimes, you just need
it in one place, e.g. std::sort( v.begin(), v.end(), /*HERE*/ );
Maybe Boost.Lamda or Boost.MPL can be used?
Sure, but if the syntax becomes too complicated, users will stick with
the if-else-way. Lambda and MPL might be too complicated for such a
small helper. I think the proposed helper was meant to have an easy
syntax, but maybe I'm reading Jan's proposal the wrong way.
I don't think you can (re#)define a keyword.
You can. But I admit that it's a stupid idea to do it, which is why I
don't honestly propose to use true()/false()-macros :)
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 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] [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: [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: Non-portable help text of operators library.
Daniel Spangenberg wrote: Since I see strong activities in overworking parts of the documentation, I would like to remember the open question concerning the help text section Separate, Explicit Instantiation [...] among the discussees I think, that we can be assume, that the current text proposes a non-standard feature and should be either removed or declared as non-portable. If you don't think that this statement holds true, please clarify why. You are correct. It's on my ToDo-list and I will take care of it along with some other changes that I would like to make to the documentation (mostly restructuring). Currently, my time doesn't permit much work on it, but if you'd like to speed things up, I suggest you supply a patch for it. Otherwise, I guess you have to wait at least until October :) 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: Non-portable help text of operators library.
Daniel Spangenberg wrote: Daniel Frey schrieb: You are correct. It's on my ToDo-list and I will take care of it along with some other changes that I would like to make to the documentation (mostly restructuring). Currently, my time doesn't permit much work on it, but if you'd like to speed things up, I suggest you supply a patch for it. Otherwise, I guess you have to wait at least until October :) Since you seem to restructure its documentation, it seems to make little sense, if I would come up with only one small section, or? It would make sense as I don't plan to remove stuff. I would like to keep a main document for the normal users and the sections which explain background information on implementation details and workarounds on sub-pages for those interested. I think that the current documentation just grew too large for a single document and most users might prefer a more brief introduction to the operators library. I'll post a proposal to the list when it's ready so everyone can check and discuss (and proof-read) it before it becomes official. 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: checked_delete / CW8
Peter Dimov wrote: It is worth mentioning that this is a confirmed bug in CW with -iso_templates on (unreferenced typedefs are incorrectly optimized out at definition time). Masking compiler bugs in this way does not help compiler writers who use Boost as a test suite. The bug is already fixed for the CW9 and all other compilers weren't affected anyway, so I thought it's pointless to add #if defined(__MWERKS__) __MWERKS__ 0x3200 to protect the new code. Also, you haven't done that for the fix for the Intel-compiler yourself, so why do you mention it now? And AFAICS if we would really be serious about the regression testing for compiler vendors, this needs to be pulled to the config-system anyway. Remember who said: Dependencies. I hate dependencies. :) 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: checked_delete / CW8
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: Peter Dimov wrote: It is worth mentioning that this is a confirmed bug in CW with -iso_templates on (unreferenced typedefs are incorrectly optimized out at definition time). Masking compiler bugs in this way does not help compiler writers who use Boost as a test suite. The bug is already fixed for the CW9 and all other compilers weren't affected anyway, so I thought it's pointless to add #if defined(__MWERKS__) __MWERKS__ 0x3200 to protect the new code. You should use BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3003)) in order to be friendly to compiler writers who want to use Boost for testing. I know, but this is exactly what Peter meant by Dependencies. I hate dependencies. IIUC and I tried to respect that. It's why I used a one-size-fits-all approach. 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: checked_delete / CW8
On Sat, 16 Aug 2003 04:11:09 +0200, David Abrahams wrote: David Abrahams [EMAIL PROTECTED] writes: Daniel Frey [EMAIL PROTECTED] writes: Hi Dave, I checked in a fix for checked_delete.hpp for the Metrowerks CW8 to CVS HEAD. It was created in cooperation with Howard and I'm positiv that it's a good one-size-fits-all solution. I don't know about your shedule for 1.30.2, but you might want to consider merging it to RC_1_30_0. I will not push this as I don't want to delay 1.30.2, having it in 1.31.0 is fine, too. Hmm, I use Pro8.3 all the time and have never seen a need for a patch to checked_delete. Ah, the regressions were in expected-failure tests? The regression depends on the compiler flags. It occurs with -iso_templates on which - according to Howard - is a good idea to use. Personally, I have no clue what it's good for... :) OK, I like your patch and I've applied it in the branch. I'm going to release tomorrow morning after the meta-comm regressions have run again. Thanks. I'll keep my fingers crossed... Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.2 ready for release?
David Abrahams wrote: http://tinyurl.com/k7vl and http://tinyurl.com/jtpd seem to contradict that. I find that very strange because I specifically Also the latter run (Win32) stops after type_traits. The utility-section seems to have disappeared. Misha, can you have a look, please? 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: Boost 1.30.1 released
On Thu, 07 Aug 2003 17:38:22 +0200, Daniel Frey wrote: David Abrahams wrote: No, it means managing the next release. Um, no, I don't feel like I can handle that. Sorry. I'm sure it's a lot of work and a big Thank You! to you for doing this job, but I think it requires knowledge which I don't have. And more time than I have, but this seems to be everybody's problem... :) Just to clarify: I don't meant to reject volunteering to the release process in general. It's just that I am sure that I would make a mess of 1.30.2 due to the tight shedule. Also, I need to learn more about some parts of boost that I don't feel comfortable with (yet). Anyway, if you really think I should/could manage a release, I suggest that I get more time and try my hands on 1.31.1 or something similar. Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost 1.30.1 released
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: What about release candidates? It wouldn't hurt to have someone else look at it before calling it a release and it's quite easy to do. All it costs is some time, but I think we should invest a few days in more stable releases. Also, it's orthogonal to scripting the release procedure. :) Regards, Daniel Are you ready to volunteer? It was quite time consuming for me to release this version. Of course a script and more instructions would've made it so much easier... I see your point. So, it's not orthognal in some way. But when we have the scripting in place, it should also be easier for you to create a release candidate. And if volunteering means downloading it and testing it, then yes, I'd do this. 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: Boost 1.30.1 released
Beman Dawes wrote: At 01:18 PM 8/5/2003, Daryle Walker wrote: I read on an eXtreme Programming Wiki web-page that the release procedure should be automated with a script. This lowers the chance that the release procedure has secret steps that only one person knows. Maybe we should strive for that. Yes. It may be easier to script everything if we move the web hosting to SourceForge, which is under active consideration. (The current procedures use some GUI steps that don't script easily, and the current host doesn't allow shell access.) What about release candidates? It wouldn't hurt to have someone else look at it before calling it a release and it's quite easy to do. All it costs is some time, but I think we should invest a few days in more stable releases. Also, it's orthogonal to scripting the release procedure. :) 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: Release Manager's Checklist added
Joerg Walter wrote: * Monitor mailing lists to verify that patches are being dealt with. Doesn't sf have a tracker for patches? * Monitor mailing lists and bug tracker to verify that bug reports are being dealt with. Doesn't sf have a tracker for bugs? Yes, to both but we aren't using them fully and/or properly. Exactly. Also, people post patches and bug reports direct to the mailing lists. That's probably wrong. They should use a tracker first and then discuss them on the mailing lists. I disagree. I think that we should try to focus information instead of spreading them around. If we use the CVS-tree for the code, the mailing list(s) for discussion and regression tests (in CVS) to track bugs, this should be enought. The regression tests are IMHO superior to bug-trackers as they provide a much better feedback and are easier to maintain. Bug-trackers are just administrative overhead in my eyes, YMMV. Let's make a small survey on what part we should keep and what might be obsoleted for the future. AFAIK the items to note are: Mandatory and IMHO not controversal: - CVS - Mailing list(s) - Website - Releases on SF Other sources: - Wiki - Yahoogroup's files-section - SF *-tracker Personally, I'd like to get rid of the latter two. The reason against the files-section is, that it was very useful in the beginning, but as we have a main- and a sandbox-CVS and we can use branches on them, there shouldn't be any need for a files-section any longer. This is also backuped by the fact that the files-section isn't used as frequently as in the beginning (AFAICS). The trackers are IMHO a problem because they require a lot of work. The current state shows that it is not maintained well, e.g. there are open bugs which are long closed in CVS, see #451535. Sure we could do better in theory, but is it worth it? Why not use regression tests to track bugs? AFAICS people pay a lot of attention to the regression tests and the whole systems work pretty well. Also, I hope that it could make the release manager's work easier to have fewer sources to track :) OK, what do others think? Am I the only one who feels uncomfortable with the SF-trackers? we need to do a certain amount of management to ensure release quality. I would like to remind you of KISS. Too much managment can also decrease quality as it might rule out some people. And I don't think that we really have a problem in tracking bugs. For features, it's up to the maintainers to handle this, but it's IMHO better to discuss this on the list and probably extend the libraries FAQ- or futute-section. No new system required :) 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: Boost 1.30.1 released
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: release candidate. And if volunteering means downloading it and testing it, then yes, I'd do this. No, it means managing the next release. Um, no, I don't feel like I can handle that. Sorry. I'm sure it's a lot of work and a big Thank You! to you for doing this job, but I think it requires knowledge which I don't have. And more time than I have, but this seems to be everybody's problem... :) 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: [regex] Escaping a search string?
Edward Diener wrote: That is a good point. However you always know what flags are passed to the regex function since they are available. That's not arguing against such a function as being part of the library itself but it is still doable by you. Furthermore you can set the flag mode you like to simplify your escaping, but of course this is not a general solution as the rest of the regular expression may require particular flags set. That's the point and that's why I am asking for a library-based function. Sure I can write one myself, but this will always be a limited version of what the library could provide. I think the conversion function should accept the same flags like regex itself. Here's a signature: template typename stringT stringT convert_to_regex_literals( const stringT s, flag_type f = regbase::normal ); I don't know whether we also need to provide traits somewhere, but I think John is the expert to answer that. (Yes, the name of the function is ugly - please find a better one :) IMHO the library is the best place to implement such a function and keep it up-to-date and consistent. If we are lucky, it's also easier than doing it as a separate function as a function which is part of the library might be able to use some internals to create an easier implementation. That is not true. One just needs to read and understand the documentation on the particular flags and what they mean. There are no secret innards which retain information about escaping characters which you can't find for yourself by testing the flags. Whatever I can do as a user, I think we've seen that I am not the only one who needs such a function and it doesn't make sense to reinvent it over and over again. Even if it's just for convenience, I think it's a desirable extension for the regex-library. 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: [regex] Escaping a search string?
Edward Diener wrote: You can turn on the literal flag type. All characters in your regular expression are treated as literals. That doesn't help. Maybe an example clarifies what I need: std::string s = 1.30.0; boost::regex r( ^(.*)\s+(?:[Vv](?:ersion)?\s+ + s + )\s*$ ); I need a way to convert 's' to '1\.30\.0', not to escape the whole regex. 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] [regex] Escaping a search string?
Hi John, Hi .*, Given that I have a string 's' from somewhere, I'd like to create a regular expression where some part must match that string. The problem is, the 's' could contain characters that have a special meaning in regular expressions. Is there some support function that can provide an escaped version of 's'? Something that transforms my.*string into my\.\*string? If there isn't, would it be possible/easy to provide one? 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: Reversed operator helpers?
Daryle Walker wrote:
On Thursday, July 31, 2003, at 9:58 AM, Daniel Frey wrote:
Daryle Walker wrote:
In boost/operators.hpp we have helper classes that can generate
operator OP from operator OP=, where OP can be +, /, ,
etc. What about types and algorithms where the non-assignment
version is easier than the assignment version? Should we have
reverse helpers?
Sounds like a good idea in general.
[snipped two possible implementations]
What about the naming of the new classes? Do you have something in mind?
I just thought up the basic idea, but nothing like the formats and
such. You've gotten ahead of me.
I started to think about it when I read your post, so I can't be that
much ahead :) Just brainstorming right now...
Also, I asked about the names because I don't have a convincing idea for
them. I thought about adding the word reverse somewhere, but that
sounds like a bad idea as it reflects some internal design of the
operators library and is thus only confusing for the user (IMHO).
When looking at the current:
class X : boost::addable X
{
X operator+=( const X );
};
I wonder if addable is a good name. I thought that the classes are named
by the operator that is provided by the user and that they add the
operators that are based on it. Like here:
class Y : boost::less_than_comparable Y
{
friend bool operator( const Y, const Y );
};
That given, the new class should be called 'addable', the current class
should probably be called 'add_assignable' or something like that. But
that would break the interface :(( Thoughts, anyone?
Do we need to prevent the user from deriving from both forms, creating
infinite loops that only show up at run-time (+ calling += calling +
calling += ...)? How shall we accomplish it without to much burden,
possibly breaking the code for weaker compilers?
Wouldn't this only happen if the user explicitly coded it that way (i.e.
the user added the OP from OP= _and_ the OP= from OP helper classes)?
I think so. But I would like to prevent the errors to show up at
run-time if I can catch them at compile-time. For weak compilers, this
extra security can be disabled, so we won't run into a
compatibility-problem with this. But this is an issue which should IMHO
be addressed at the end as it is not needed for the rest.
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: Reversed operator helpers?
David Abrahams wrote:
Daniel Frey [EMAIL PROTECTED] writes:
When looking at the current:
class X : boost::addable X
{
X operator+=( const X );
};
I wonder if addable is a good name. I thought that the classes are
named by the operator that is provided by the user and that they add
the operators that are based on it. Like here:
class Y : boost::less_than_comparable Y
{
friend bool operator( const Y, const Y );
};
That given, the new class should be called 'addable', the current
class should probably be called 'add_assignable' or something like
that. But that would break the interface :(( Thoughts, anyone?
If anything, I think it's less_than_comparable which should change.
I was just pointing out an inconsistency and the problem to find a name
for the newly proposed helpers. I think that the current names are
really intuitive (although not consistent) and that we should keep them
- if not for anything else than at least for compatibility. Still we
need to find (hopefully intuitive) names for the new helpers that Daryle
proposed. Let's make a list for possible helper class names providing
operator+= for classes that have operator+:
add_assignable (opposite semantics of above's quote)
reversed_addable (IMHO nasty, but an option anyway)
addable_assign
assign_addable
[your cool idea here :)]
--
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: Preparing 1.30.1 Release
David Abrahams wrote: lambda The fix in boost/lambda/detail/operator_return_type_traits.hpp enables you to use the lambda library with GCC 2.95.2, which wasn't possible with the 1.30.0. -- 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: Reversed operator helpers?
Daryle Walker wrote:
In boost/operators.hpp we have helper classes that can generate
operator OP from operator OP=, where OP can be +, /, ,
etc. What about types and algorithms where the non-assignment version
is easier than the assignment version? Should we have reverse helpers?
Sounds like a good idea in general. I think the naive implementation
would be something like:
T operator OP##=( T rhs, const U lhs )
{
rhs = rhs OP lhs;
return rhs;
}
OTOH I can think of a different solution:
T operator OP##=( T rhs, const U lhs )
{
T tmp( rhs OP lhs );
using std::swap;
swap( tmp, rhs );
return rhs;
}
Which might be ways faster for certain classes. Which version were you
thinking of? Which version offers a good balance in your opinion?
What about the naming of the new classes? Do you have something in mind?
Do we need to prevent the user from deriving from both forms, creating
infinite loops that only show up at run-time (+ calling += calling +
calling += ...)? How shall we accomplish it without to much burden,
possibly breaking the code for weaker compilers?
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: Several patches for Boost
David Abrahams wrote: Blast. I did that in a misguided attempt to try to get vc7 to pass the tests. It's really badly broken, though. Hopeless, if you ask me. Can't comment on the VC7, but it's not the only broken compiler. Borland seems to have a similar problem. If no one finds a work-around, the question is how to handle this. How about separated regression tests for bool_testable to indicate that everything from the 1.30.0 still works, only the new parts are not available on all compilers? 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: Several patches for Boost
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: I got Borland to work; check it out. Can't check it right now, but I will look at it when I'm back at home. If no one finds a work-around, the question is how to handle this. How about separated regression tests for bool_testable to indicate that everything from the 1.30.0 still works, only the new parts are not available on all compilers? Unfortunately, even eliminating the bool_testable stuff isn't enough to save vc7. It's totally wack. With the Borland fixes, there is no need to separate the regression tests as they are no worse than before now. Thanks. :) 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: Several patches for Boost
On Wed, 30 Jul 2003 15:40:01 +0200, David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: David Abrahams wrote: Blast. I did that in a misguided attempt to try to get vc7 to pass the tests. It's really badly broken, though. Hopeless, if you ask me. Can't comment on the VC7, but it's not the only broken compiler. Borland seems to have a similar problem. I got Borland to work; check it out. Hm, you disabled the protector. OK, this makes the test pass, but it will not protect you from wrong use as documented/expected. Maybe we should add a compile-fail-test to the regression test suite? I'll try to provide one... Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Several patches for Boost
On Wed, 30 Jul 2003 21:18:17 +0200, Daniel Frey wrote: On Wed, 30 Jul 2003 15:40:01 +0200, David Abrahams wrote: I got Borland to work; check it out. Hm, you disabled the protector. OK, this makes the test pass, but it will not protect you from wrong use as documented/expected. Maybe we should add a compile-fail-test to the regression test suite? I'll try to provide one... I added the test and modified libs/utility/test/Jamfile. From the docs I read this should be OK, but the file contains this line: # Testing Jamfile autogenerated from XML source I grepped to find an appropriate source and search the documentation, but I couldn't find anything. Hope I haven't missed something :-/ Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Non-standard feature proposed in help text of operatorslibrary??
David Abrahams wrote:
You're right.
Only WRT some limited points, but probably not in general :)
It works because the base classes of T are
associated in:
struct myclass : Xmyclass {};
I think the OP asked about explicit instantiated Xmyclass. Daniel
(Spangenberg), please correct me if I'm wrong, but you question boils
down to something like this:
namespace A
{
template typename T struct X
{
friend void operator+(T,T) {}
};
}
namespace B
{
struct Y {};
template struct A::X Y ; // explicit instantiation
}
int main()
{
B::Y a;
B::Y b;
a + b; // -- ??
}
The above code compiles fine with the GCC 2.95.2. The GCC 3.3 doesn't
find the operator (it injects it into A, not into B), the Comeau rejects
the explicit instantiation. Initially I thought that the above example
should be legal, as the standard reads in 14.6.5/1:
When a template is instantiated, the names of its friends are treated
as if the specialization had been explicitly declared at its point of
instantia-tion.
The point of instantiation is in namespace B, but after thinking about
it a bit longer and reading some more stuff from the standard, I wonder
if this can be true. The instantiation could happen in a different
translation unit, so it seems strange that the operator is found in the
same translation unit but not in different ones. Also, the Comeau
rejects the explicit instantiation as it happens inside the namespace.
14.7.2 is also pretty clear on the subject, so I think that the GCC 3.3
is correct, the Comeau should probably turn the error into a warning as
the instantiation is not illegal (AFAICS, but correct me if I'm wrong),
but probably has surprising behaviour. The GCC 2.95.2 and the operators
library is wrong, the OP's observation is correct that it uses
non-standard code. Also, I need to understand why my reading of 14.6.5/1
is wrong, or is this a DR? Should I take it to 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
[boost] Re: Non-standard feature proposed in help text of operators library??
Daniel Spangenberg wrote:
(CRTP). Provided, that this is true, I assume, that the proposed
workaround for
compilers with expensive multiple inheritance implementations should not
work on
compliant compilers, because of a violation of 14.6.5/p. 2:
As with nontemplate classes, the names of namespace scope friend
functions of a class template specialization are not visible during an
ordinary lookup unless explicitly declared at namespace scope (11.4).
Such names may be found under the rules for associated classes (3.4.2).
In a first statement, Daveed Vandevoorde also seems to assume, that the
interpretation is
correct, that [..]XT is not in general associated with T [..] (My
truncated quote from
Daveeds answer).
Concretly said, the example:
class myclass{
//
};
template struct less_than_comparablemyclass;
should not work, because less_than_comparablemyclass is not associated
I guess you missed the fact that XT in the operators library defines
operators which take T as an argument, not XT. Whether XT is
associated with T is therefore not important here, ADL matches the
operator arguments, not the class which declared the operator.
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: Non-standard feature proposed in help text of operators library??
Daniel Spangenberg wrote: No, I absolutely do understand, that XT in the operators library defines operators which take T as an argument. I hope, that my explanation meant that (my english is bad, I know). But I think, that the standard does forbid the visibiliy of the operators injected by less_than_comparablemyclass for myclass because myclass is not the associated with less_than_comparable**. Now the operators injected by less_than_comparablemyclass take myclass as arguments (those with arguments, I mean) and should noot be visible for myclass. They needn't be visible for myclass. They only need to be visible in the namespace where this happened. See 3.4.2/2: If T is a class type, its associated classes are the class itself and its direct and indirect base classes. Its associated namespaces are the namespaces in which its associated classes are defined. The namespace is what is important here, not the class. The friend-operators declared by XT are injected to the namespace as given by 14.6.2/2: As with non-template classes, the names of namespace-scope friend functions of a class template special-ization are not visible during an ordinary lookup unless explicitly declared at namespace scope (11.4). Such names may be found under the rules for associated classes (3.4.2). note the ...namespace-scope friend functions..., which to me means that the operators are not injected to XT, but to the namespace where the explicit instantiation happened. As this should be the same namespace where T lives, anything should IMHO be legal C++. At least this is how I read the standard. Regards, Daniel PS: I don't think english is our problem, but if you feel more comfortable with german you can mail me directly if you like. -- 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: Non-standard feature proposed in help text of operators library??
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: They needn't be visible for myclass. They only need to be visible in the namespace where this happened. See 3.4.2/2: If T is a class type, its associated classes are the class itself and its direct and indirect base classes. Its associated namespaces are the namespaces in which its associated classes are defined. The namespace is what is important here, not the class. The friend-operators declared by XT are injected to the namespace as given by 14.6.2/2: As with non-template classes, the names of namespace-scope friend functions of a class template special-ization are not visible during an ordinary lookup unless explicitly declared at namespace scope (11.4). Such names may be found under the rules for associated classes (3.4.2). note the ...namespace-scope friend functions..., which to me means that the operators are not injected to XT, but to the namespace where the explicit instantiation happened. As this should be the same namespace where T lives, anything should IMHO be legal C++. At least this is how I read the standard. Maybe I'm missing something in what you say, but I think they are visible for myclass, and the relevant text is in 3.4.2/2: --- If T is a template-id, its associated namespaces and classes are the namespace in which the template is defined; for member templates, the member template's class; the namespaces and classes associated ^ with the types of the template arguments provided for template type ^^^ parameters (excluding template template parameters); the namespaces in ^^ which any template template arguments are defined; and the classes in which any member templates used as template template arguments are defined. [Note: non- type template arguments do not contribute to the set of associated namespaces. ] IIUC, the 'T' that the standard mentions is the 'myclass' in Daniel Spangenberg's example. The operators provided by XT should be found in T's namespace, so it works whether 'T' is a template-id or not. I thus thought that the problem was, if 14.6.5 does what we need when explicitly instantiating XT. But maybe I'm missing something. 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: current_function.hpp extension
Peter Dimov wrote: There is currently no BOOST_HAS_CURRENT_FUNCTION since the idealistic goal has been to cover all widely used compilers one day, so that BOOST_CURRENT_FUNCTION always has a meaningful value. This may prove to be impractical, of course, but I'd certainly prefer patches that enable BOOST_CURRENT_FUNCTION to work with more compilers over just adding BOOST_HAS_CURRENT_FUNCTION. :-) Agreed that it is desirable to have this on as many platforms as possible. Also I've seen from the CVS that the Intel compiler is supported in the next version, too. So at least I no longer need it. :) OTOH a BOOST_HAS_CURRENT_FUNCTION is a very lightwave extension which doesn't prevent patches that add support for more compilers.. On the other hand, perhaps you have a use case that clearly demonstrates the need for BOOST_HAS_CURRENT_FUNCTION? I have a very small use case which might not sound very convincing: The Log-files are smaller if I know when to omit the (unknown). As the function name would appear on each log-line, and assuming an average log-line-length of 200 chars, this would be 5%. But there are a lot of other ways to switch the (unknown) on and off, I just thought that it makes sense to retrieve this information at its root. No big deal if it's not there. :) 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: current_function.hpp extension
On Sat, 19 Jul 2003 02:08:24 +0200, Pavel Vozenilek wrote: Peter Dimov [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] ... There is currently no BOOST_HAS_CURRENT_FUNCTION since the idealistic goal has been to cover all widely used compilers one day, ... On the other hand, perhaps you have a use case that clearly demonstrates the need for BOOST_HAS_CURRENT_FUNCTION? SMART_ASSERT library implements BOOST_HAS_CURRENT_FUNCTION equivalent (it would be ugly to print out the default text). Log-output again. And look at that workaround they used: Runtime-checking the values. Isn't that ugly? (No offense intended to the SMART_ASSERT-folks :) Even if it's just a small use-case, I am not the only one who would benefit from BOOST_HAS_CURRENT_FUNCTION. Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] cwpro8, too? (was: Re: Intel 7.1 bug report for boost::checked_delete?)
Peter Dimov wrote: Peter Dimov wrote: But I don't have access to Intel C++. I do now, fixed (hopefully), thanks for the report. The european, transparent mirror of the SF CVS-tree has a lag of more than 22 hours. Annoying :( The fix looks good to me (in fact I was playing with exactly the same idea) and hopefully fixes the problem for the cwpro8, too. See: http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/cs-win32_metacomm-links.html#checked_delete_test%20cwpro8 That given the comment should read some compilers instead of Intel 7 and it is not complete as a zero-sized array should also be an error (8.3.4/1), but the compiler happily accepts it in system headers, too. Regards, Daniel PS: Maybe it's my lousy english, but being called the reporter of the problem makes me feel like a user just complaining Hey, it doesn't work! instead of a developer analysing the problem and discussing fixes. I ignored it for the ADL-fix, but now it happens again :-/ -- 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] Intel 7.1 bug report for boost::checked_delete?
I've seen from the regression tests that the Intel compiler (7.1) seems to have a problem with checked_delete. I looked into it and found out what triggers the bug. Has anyone else done something similar and reported the bug to Intel or should I do it? Also, it seems possible to create a work-around for boost. I'll post a patch for discussion soon :) 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: Re: Intel 7.1 bug report for boost::checked_delete?
On Tue, 15 Jul 2003 22:22:03 +0200, Peter Dimov wrote: Daniel Frey wrote: To explain the bug a bit: When you create a small test case, you'll probably get the error from the compiler you are looking for. If you put the checked_delete in it's own header, it still works as long as you include the header with #include my_header.h but if you use #include my_header.h and compile it with -I. then the compiler magically accepts sizeof(Incomplete) with no warnings or errors and returns 0 as the size. Looks like a feature to me. Apparently some important system header does sizeof(incomplete). It's not a bug, it a feature! (tm) ;) I know they will find a convincing excuse, but that doesn't help us as we create a library which is usually used through instead of . To work around this, I added a simple STATIC_ASSERT which - for some reason - still works :) Odd, since the Intel-specific BOOST_STATIC_ASSERT is [snip] which looks pretty close to what checked_delete uses. That's correct. I don't know why it works in one case but not in the other. But we've seen stranger bugs already, haven't we? :)) +#include boost/config.hpp +#if defined(BOOST_INTEL) +#include boost/static_assert.hpp +#endif Dependencies. I hate dependencies. Do you have a better idea? Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: plans for a bugfix release ?
On Tue, 15 Jul 2003 16:26:43 +0200, David Abrahams wrote: What does everybody think about doing a 1.30.1 release RSN? I think it's too late, let's go for a 1.31.0. I think that we'll hear about problems with the 1.31.0 really soon after release and probably a 1.31.1 can follow shortly after. For 1.30.0, we IMHO missed the opportunity do to a 1.30.1 without lots of pain/work. As Beman already said there is too much in CVS to backport it to a 1.30.1. The question is, whether we learn from it for a 1.31.1 :) My 2 cents... Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Intel 7.1 bug report for boost::checked_delete?
On Tue, 15 Jul 2003 23:20:06 +0200, Peter Dimov wrote: Daniel Frey wrote: On Tue, 15 Jul 2003 22:22:03 +0200, Peter Dimov wrote: +#include boost/config.hpp +#if defined(BOOST_INTEL) +#include boost/static_assert.hpp +#endif Dependencies. I hate dependencies. Do you have a better idea? Several, like (1) using __INTEL_COMPILER for detection and (2) isolating the minimal example that results in the error we need. But I don't have access to Intel C++. (1) Look into config/compilers/intel.hpp, it's not that easy. I do have access to the Intel compiler, but of course not to all versions. And I only use Linux, thus a single platform. I simply used all the knowledge and experience compiled into the config-system as this is what it is supposed to provide, right? But I can duplicate the config's code if you want to detach checked_delete from the config system... (2) This is only included for the Intel compiler and I prefer code clarity here over duplicating strange work-around code. Actually BOOST_STATIC_ASSERT nicely encapsulates this. Or do you know of any actual problem by introducting the dependency? It's IMHO the smaller evil here... Regards, Daniel PS: While adding the comments Dave asked for, I also added a comment to my local copy about the explicit namespace qualification in checked_deleter to prevent ADL, as this is also not obvious from the code alone why it's required. Should be OK, right? :) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
Peter Dimov wrote: David Abrahams wrote: But that's only true as long as void_ is being used for internal purposes. Once you give it up to users as you suggest, it loses that correspondence, and we'll have some other internal name which has that correspondence to void. Maybe the problems are caused by overloading void_. I haven't looked at MPL recently, but as a general observation I have identified at least three uses of a void_-like entity. 1. A type parameter used to emulate a variable argument template. I use '_missing' for this purpose (leading underscore for implementation details.) templateclass A1 = _missing, class A2 = _missing, ... struct F; 2. An optional parameter that, when not supplied, has a reasonable (dependent) default. I use 'unspecified'. templateclass R = unspecified, class F ... bind(F f); 3. A type that is guaranteed to be distinct from all other useful types. 'nil' is what Lisp calls it; void_ is fine, too. From my experience it's a bad idea to have one general, user-documented type that is used as a default for variable argument templates. The problem is that when a user knows the type's name and thus the type (be it called void_, nan or whatever), he might also expect to be able to work with it like with any other type. If forming a container-type (mpl::vector, ...), it should be possible to inject the type like all other types because otherwise, well, it wouldn't be a type and the user will be surprised no matter whether you document it or not. I therefore think that each library should have an internal type that the user doesn't know about and that might then be put it into a namespace detail or something and called depending on it's semantics. Makes it easier to understand the type's role inside the library, thus increases readability and maintainability and improved orthogonality of different libraries. Also, I wonder what reasons are there to create a general type for this purpose. Avoiding code duplication doesn't sound reasonable as we only replace a single line per such class with an include. Some libraries might even need a declaration-only-type, other might needs an (empty) implementation. So, what benefit would a general type give to us? 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] Warnings about derivation without explicit access control specified
Hello, I saw a lot of new regression runs on various platforms. One obvious question: Should we remove the outdated runs? Now for the real reason of this message: One compiler (the SGI MIPSpro) complains (with a warning) about: cc-1234 CC: WARNING File = /net/cci/maurer/boost/libs/utility/operators_test.cpp, Line = 52 Access control is not specified (private by default). : boost::operatorsWrapped1T The question is: Should we, for the sake of portability, support this warning by requesting an explicit access control specifier whenever we derive? Or is such a general coding guideline inappropriate because it's too common that people omit it? At least I do this often as I think that the default is obvious and although I don't have a good reason for it, I also have no reason against it. Comments? Regards, Daniel PS: Would it make sense to have a boost bug bashing week or something to fix some more bugs/regressions? Or do we wait for users to complain and provide fixes? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl::if_ and ICE triggered on GNU g++-cvs-today
Markus Werle wrote:
A resolution with which g++ is happy again is:
struct if_
{
private:
enum { value = static_castbool(C::value) };
typedef if_c
value
, T1
, T2
almost_type_;
etc.
Does this solution have any impact on compilation time?
Most probably. I haven't measured it for this case, but from former
benchmark, I know that *every* type and *every* value counts. Well, I
calculated Apfelmännchen at compile-time, so I needed speed :))
Especially types are slow and you are adding an additional unnamed
enum-type in your code above. But there might be another solution,
although not very elegant:
struct if_
{
private:
typedef if_c
bool(C::value)
, T1
, T2
almost_type_;
...
the GCC likes it much better than the static_cast-version and you avoid
a new type. You might want to run some benchmarks for your typical
applications, though :)
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: Math Constants Formal Review
On Mon, 23 Jun 2003 15:24:54 +0200, Daniel Frey wrote: 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++... OK, I was wrong. Daveed Vandervoorde provided the reference to the standard which is quite clear IMO. I filed a bug report to GCC Bugzilla (#11357). Maybe some MS-user wants to do the same for the VC++... Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: compose_f_gxy_hxy
On Thu, 26 Jun 2003 01:08:24 +0200, Daniel Frey wrote: To complete the implementation of combined_argument_type, it would help After waking up this morning, I immediately realized that the implementation will not do what it promised. I have a better implementation right now which is about 80% finished. Before spamming the group with more and more versions, I'd just like to hear whether there is any interest in a compose_f_gxy_hxy. And sorry again for the lousy first implementation :) Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Draft of new Boost Software License
Beman Dawes wrote: At 01:10 PM 6/25/2003, Daniel Frey wrote: I think that the term used in the suggested new boost license could be a problem here. Reading the entire sentence, the phrase of the Software appears three times. Note the capitalization of Software. That makes it clear that the copyright, license, etc, reproduction requirement only applies to any Boost software, not any non-Boost portions. It doesn't matter what form the non-Boost portions are in; they aren't covered by the license. The inclusion of the of the Software phrase prevents the problem you are worried about AFAICS. Well, I hope so. I'm not a lawyer, so I can't decide. Personally, I think I understood and respect the spirit and boost and I don't fear to be sued. The problem is that lawyers have to accept it, but I think your interpretation of the Software should tame them. Thanks for clarifying. 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: compose_f_gxy_hxy
Peter Dimov wrote: You've considered bind(f, bind(g, _1, _2), bind(h, _1, _2)) right? ;-) Sure. But still compose.hpp is in itself incomplete. And it completes the standard's parts on function objects so I think it might be desirable to supply compose_f_gxy_hxy. If we take bind into account here, we could just as well remove compose.hpp completly, couldn't we? Or was this your suggestion? 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: compose_f_gxy_hxy
Aleksey Gurtovoy wrote: Daniel Frey wrote: Peter Dimov wrote: You've considered bind(f, bind(g, _1, _2), bind(h, _1, _2)) right? ;-) Sure. But still compose.hpp is in itself incomplete. And it completes the standard's parts on function objects so I think it might be desirable to supply compose_f_gxy_hxy. The standard is moving towards 'bind' - http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1455.htm. If we take bind into account here, we could just as well remove compose.hpp completly, couldn't we? We might, in a couple of years. Seriously, 'bind' is superior here; it takes some learning to switch over from the 'compose_*' family, but it's worth it. Well, I'm already using the lambda-library, so I'm no longer bound to compose_*. I just thought that completing compose.hpp might be a good idea. But if it's deprecated, this doesn't really make sense. Never mind... :) 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: Draft of new Boost Software License
Beman Dawes wrote: Thanks to Dave Abrahams, Diane Cabell, Devin Smith, and Eva Chen, we now have a pretty close to final draft of a new Boost Software License. For as many Boost libraries as possible, the plan is to replace the individual licenses with the official Boost license. Of course, the developers who hold the copyrights for each library must agree. We'll also submit the Boost license to the OSI (http://www.opensource.org/) for certification. This draft represents a lot of discussion between the lawyers and Boost moderators, and both groups are quite happy with the results. So now it's time to open it up for comments from the whole Boost community. Nice work and I appreciate it. I hope that something as a single boost license will be adopted soon. For more background, including rationale, a FAQ, and acknowledgements, see http://boost.sourceforge.net/misc/license-background.html The draft license itself is at http://boost.sourceforge.net/misc/LICENSE.txt I read the FAQ but I still have a question about the machine-executable object code generated by a source language processor. The Software we sell and distribute contains config files in XML, HTML files, documentation in various formats and other non-binary files. Even worse, some part are written in JavaScript/Java (jsp) or PHP. So there are parts that are distributed as source-code, but still it doesn't contain C++ sources. From my current understanding, this is not against the Booster's intentions and the current licenses. I think that the term used in the suggested new boost license could be a problem here. Could someone please explain why - as the FAQ put it - More detailed wording was rejected as not being legally necessary, and reducing readability. and how this covers the above case. Or is it actually intended that we cannot use boost for our project? While we are interested in comments from any Booster, we would particularly like to hear from: * Boosters for whom English isn't their primary language; is the license understandable? I'm from Germany (Old Europe, ya know ;) and I don't have problems to understand it. And I'm not an expert in real languages as you might have noticed from my other postings already :o) * Boosters (or their lawyers) from countries other than the US; do they spot any issues missed by Boost's US-centric legal team? Can't really comment on this one as I'm not a lawyer - just a laymen. * Boost developers; if there are aspects of the license that make you hesitate about adopting it, what are the issues? Sadly, yes. See above... 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] compose_f_gxy_hxy
Inspired by an article at the CUJ from Andrei Alexandrescu, I was
finally able to come up with a compose_f_gxy_hxy-adapter. I think that
it's the missing adapter to make compose.hpp complete. In the companies
production code, I needed it and used a much easier implementation with
some limitations, so it's not just a toy example.
The code attached is a first cut, tested on Intel C++ 7.1 and GCC 3.3.
The GCC 2.95.3 has problems with it I haven't solved yet (and I don't
know if it's possible at all). Anyway, I'd like to hear some comments
whether it's a good idea and should be pushed forward or if it better be
buried :)
I attached a modified compose.hpp and a new file for the same directory
where I put the type selection code, called combined_argument_type.hpp.
It needs some boostification and you need to read Andrei's article to
understand it. Really. :) Andrei's article can be found here:
http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/alexandr.htm
As I put the implementation into a separate file, it should now also be
easy for boost to provide min/max (probably in utility.hpp?) like
suggested by Andrei if requested - although I'm not totally convinced
it's a good idea as IMHO min/max should have value semantics (the
currently have AFAICS) and not reference-semantics, but that's another
story.
To complete the implementation of combined_argument_type, it would help
if mpl::vector would have 16 instead of 10 arguments, but that can be
done later if there is interest in compose_f_gxy_hxy. I currently simply
removed the first types of the type-list, I've just been lazy, so don't
wonder how this should work. It won't. :)
Comments?
Regards, Daniel
// Add some nice header here... :)
#ifndef BOOST_COMBINED_ARGUMENT_TYPE_HPP
#define BOOST_COMBINED_ARGUMENT_TYPE_HPP
#include boost/type_traits/is_convertible.hpp
#include boost/type_traits/is_const.hpp
#include boost/type_traits/remove_const.hpp
#include boost/mpl/vector.hpp
#include boost/mpl/find.hpp
#include boost/mpl/if.hpp
namespace boost {
template typename L, typename R struct combined_argument_type
{
private:
typedef mpl::vector
const bool,
const char,
const signed char,
const unsigned char,
const wchar_t,
const short,
const unsigned short cutted_types; // GRRR, vector should allow 16 elements!
typedef mpl::vector
const int,
const unsigned int,
const long,
const unsigned long,
const long long,
const unsigned long long,
const float,
const double,
const long double sorted_types;
typedef typename remove_const L ::type non_const_L;
typedef typename remove_const R ::type non_const_R;
enum {
is_const_L = ( is_const L ::value || !is_const R ::value ),
is_const_R = ( is_const R ::value || !is_const L ::value ),
pos_L = mpl::find sorted_types, const L ::type::pos::value,
pos_R = mpl::find sorted_types, const R ::type::pos::value,
l2r = is_const_R is_convertible non_const_L, non_const_R ::value,
r2l = is_const_L is_convertible non_const_R, non_const_L ::value
};
typedef typename mpl::if_ is_convertible R, L , L, R ::type T1;
typedef typename mpl::if_c ( pos_L != -1 ) ( pos_L pos_R ), R, T1 ::type T2;
typedef typename mpl::if_c l2r, R, T2 ::type T3;
public:
typedef typename mpl::if_c r2l, L, T3 ::type type;
};
} // namespace boost
#endif // BOOST_COMBINED_ARGUMENT_TYPE_HPP
/* supplementing compose function objects
* Fri Jul 16 21:01:58 MEST 1999
*/
/* The following code example is taken from the book
* The C++ Standard Library - A Tutorial and Reference
* by Nicolai M. Josuttis, Addison-Wesley, 1999
*
* (C) Copyright Nicolai M. Josuttis 1999.
* 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.
*/
// See http://www.boost.org/libs/compose for Documentation.
#ifndef BOOST_COMPOSE_HPP
#define BOOST_COMPOSE_HPP
#include functional
#include boost/combined_argument_type.hpp
namespace boost {
/**
* type nullary_function
* - as supplement to unary_function and binary_function
**/
template class Result
struct nullary_function {
typedef Result result_type;
};
/**
* ptr_fun for functions with no argument
**/
template class Result
class pointer_to_nullary_function : public nullary_functionResult
{
protected:
Result (*ptr)();
public:
pointer_to_nullary_function() {
}
explicit pointer_to_nullary_function(Result (*x)()) : ptr(x) {
}
Result
[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
[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 FU()() 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
[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.
As a next point, I'd like to clean up with some misunderstandings. In
the example I showed I included a small optimization for sin(pi/2). I
think that some people haven't really seen the comment that says:
...to solve the naming dilemma I admit that sin(pi/2) was a
stupid example in this context. I did not intend to add optimizations
to catch stupid user code. If a user writes sin(pi/2) it's not my
fault that this will get evaluated. I expect the programmer to realize
that this resolves to 1. The point is, that there are other constants,
like sqrt(2), e^(pi/4) or 1/ln(phi). The naming dilemma is that you
have to find a name that all programmers can remember. In this
context, I think that most programmers will understand these names
for the constants:
sqrt(two)
pow(e,pi/four)
one/ln(phi) // or one/log(phi)?
better than
sqrt2
ePowQuarterPi // or ePowPiDivFour?
oneDivLnPhi
Sure the above terms need to resolve to a single identifier like the
classic approach, but there is a difference: We needn't communicate
the internal names to the user as part of the interface.
We may also want to add the negative of all constants as I guess it
will come up very often that a constant C is used in a formular as
-C. But than maybe it's not needed as it will be integrated to the
formular by changing a+(-C) to a-c or something. Anyway, just another
idea/option.
Now for the operators. Paul mentioned that users want to write:
float area = pi * r * r;
I agree to that. But I also think it's reasonable to expect a user to
write
template-based code like this:
template typename T T area( const T r ) {
return pi * r * r;
}
Nothing wrong with that in my eyes. I added the operators to allow
some convenience and I don't think there will be much surprises. The
only thing the user has to remember is, that he should not assume a
constant to have a 'special' type. pi in my code is not a double or
long double. It's just an internal type that the user should not care
about. If the users uses pi in conjunction with another type, pi
behaves like that type. Or the user can static_cast pi to whatever
type he wants. But pi itself is not of a user-visible type. That
given, it's IMHO obvious that for this code:
float f;
double d;
pi * f * d;
the last line is not using pi as a double but as a float. Also, I
don't expect these mixed cases to appear very often. Most users will
probably write code using only one type. Maybe they will also use two
or more types, but they will not interfer in lots of places. Usually
this will cause conversions and thus slow down the code, so the places
where mixed arithmetics occur should be quite rare.
I don't think anyone should be surprised by the above conversion to a
float instead of a double. If you are, think about:
int i = 41;
int j = 42;
double d = 1234.56;
double result = i / j * d;
What do you expect result to be? And this problem is much worse than
the conversion problem or pi. The example code I attached (which now
works *at least* for the gcc 2.95.x and 3.x and the Intel C++ 7) also
contains another operator I forgot in the first example (+=, ...).
Some people tried to simplify the code I showed. Well, in all cases I
think they lost at least one feature and only a benchmark which shows
a significant difference would justify that (IMO).
Errors and debugging:
My code will give you a compile-time error
[boost] Re: Math Constants Formal Review
On Sun, 22 Jun 2003 03:32:52 +0200, Terje Slettebø wrote:
Having considered Kenniston's and Daniel's approach, I wonder if it's
possible to simplify it. The following uses the same approach as
Daniel's - specialisation, as it allows it to be done with just one
class for each constant, and nothing else:
--- Start ---
#include iostream
#define BOOST_DEFINE_MATH_CONSTANT(name)\ const struct name##_type\ {\
name##_type() {}\
templateclass T\
operator T() const;\
} name;
#define BOOST_MATH_CONSTANT_VALUE(name, type, value)\ template\
name##_type::operator type() const { return value; }
[snip]
--- End ---
My question is: Is there any reason why it can't be done this simple?
Yes. AFAICS wrong use of your constants with unsupported types is only
cought at link-time, not at compile-time. This is IMHO a big problem, big
enough to reject this approach. Also, I'm not sure whether it's standard
compliant code.
Regards, Daniel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Math Constants Formal Review
On Sun, 22 Jun 2003 22:01:19 +0200, Terje Slettebø wrote: Ok. So maybe an extra level of indirection, as in your code (and Kenniston's) may be preferable. I was wondering what was the point with it. :) 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. Also, I'm not sure whether it's standard compliant code. I think it is. It specialises a member. What could be the problem with this? As you say, errors are caught at link time. I think that you have to declare the specialization in the class' definition, not just outside. But I may be wrong here and I haven't checked it. Note I didn't say it's illegal, just that *I* am not sure it's legal ;) Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Math Constants Formal Review - ()s are a key issue.
Paul A Bristow wrote: Absolutely, but on the previous review, many users wanted to Keep It Simple Sir and deliberately only have (for example) double const pi - avoiding the complexity of other schemes, get warnings of conversions, difficulty during debugging, and inefficient code from older compilers. What do these users say about the STL? I bet it's too complex, difficult to debug, etc. for them :) They would chose just the plain double const files. You would just ignore them - at no cost to you! There is a cost: You have several use schemes. It's like providing another version of std::vector or std::string because some people want a more efficient version or an easier interface (which usually is only more efficient or easier in a very limited view). I don't think that it's a good idea and I'd vote no for inclusion of such a library. | 2 Avoiding paying for what you don't use, which leads to | Hm, there is some small overhead, but not much IMHO. In fact | far less than a lot of other boost libraries. :) Agreed, though don't forget there are dozens of constants, not just pi. If you don't use a constant, it never gets instantiated. Templates should ensure that the code is not bloated in this case, maybe the compile-time is affected, but not much as there is no recursion. But this needs some testing, see below. Also, two lines per constant is not too much, is it? Or with the help of a MACRO (sigh), it's just one line and has even more functionality :) For systems where every byte counts, they may be best. (For me, while generating the other files, the extra cost of generating the MACROS file is negligible). If you hate MACROs them don't use these files - at no cost to you! No! Like I already said above: I cannot write code which works for all headers the user might want to use. Are we writing a library for general use or not? If yes, then there should be only one interface. I will try to compare your proposal more carefully with Michael Kenniston's version - which seems to work efficiently and conveniently and extensibly with small enough risk of surprises about precision for novice users. As Ed Brey reported during this review, Kenniston's method files DO generate efficent code with Optimising MSVC 7.1 and gcc, not creating any code for unused constants - an important requirement. So the only cost is in compile time - which should be tolerable. However I am away from my machine at present so it may be a day or two. If you have more examples of use similar to those in the folder testFunctionConstants, containing a test.cpp with lots of comments and header functionconstants.hpp these will be helpful. the Folder pi also gives his examples of extending to handle complex. quadfloat folder gives an example of a UDT (a 128bit floating point software type). I am confident that your system also generates efficient code using an efficient compiler. But have you considered or tried debugging? Currently, I don't have time for that. Maybe at the weekend, but I can't promise. But I agree that it should be verified in practice. What I'd also like to hear is opinions from others here on the list. What do you think? 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: Math Constants Formal Review - ()s are a key issue.
Gennaro Prota wrote: On Wed, 18 Jun 2003 09:47:50 +0200, Daniel Frey [EMAIL PROTECTED] wrote: Paul A Bristow wrote: I am confident that your system also generates efficient code using an efficient compiler. But have you considered or tried debugging? Currently, I don't have time for that. Maybe at the weekend, but I can't promise. But I agree that it should be verified in practice. What should be verified? How efficient different compilers work with the template-approach I showed. I'll try to do that for the GCC 2.95 / 3.x and for the Intel compiler (v7) at the weekend, but my experience with reading x86-assembler is limited, so maybe I'll just run some benchmarks. As I don't have/use Windows, I can't verify compilers for this platform. What I'd also like to hear is opinions from others here on the list. What do you think? FWIW, I agree with everything you've said (except, maybe, the comment about debugging above). The arguments that Paul gives for his approach(es) are something beyond me. Thanks. For the arguments that Paul gives, I'd also welcome comments from the people that gave these arguments from their work/environment. I still think that this shouldn't be ignored, but I just don't really understand the reasons and I'd like to see these people comment on the code I showed. 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: Math Constants Formal Review - ()s are a key issue.
Paul A Bristow wrote:
In previous discussions, the main issues debated were:
1 Control of precision is essential,
and some users wanted to be able to use
float, double and long double at the same time.
at the same time is exactly what the separate headers approach
doesn't provide if you can only include one at a time IIUC.
2 Avoiding paying for what you don't use, which leads to
Hm, there is some small overhead, but not much IMHO. In fact far less
than a lot of other boost libraries. :)
2a MACROS provide a simple way of avoiding some cost for
constants you don't use, (Although some Boosters were opposed
to MACROs because they pollute the global namespace).
I'd like to backup the latter. With MACROs, you cannot add a 'using
namespace boost::math;' and use a plain 'pi' instead of 'BOOST_PI'.
Using MACROs is a pain and should be avoided if possible. And it's IMHO
possible in this case.
3 Efficiency
Some compilers can generate better code
from functions like double pi() { return 3.1459;}
but that this implies writing pi() instead of plain pi.
Yes!
4 Appearance
BUT Users extremely strongly prefer to write float area = pi * r * r;
So the ()s remain a MAJOR issue.
But this is exactly what my code tries to do. You write 'pi', and when
using it, all calcalations are forwarded to use the value returned from
a function (actually pi_valueT::operator()). Some magic is provided
for convenience like in the example above and you can select the type
explicitly be using a static_cast. AFAICS you get all what you are
asking for...
I see nothing wrong with your suggestions and examples,
but I don't yet understand
how your proposal helps to meet this last 'requirement'.
I don't see the problem as I think I do meet the requirement. Have I
missed something? Or is this an issue of a specific compiler's
optimization strategies? I don't think that it's to hard for a compiler
to generate good code from the code I showed, but I haven't actually
measured it (and I can't for all compilers). Do you think that the code
is inefficient or do you actually have evidence?
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: Math Constants Formal Review - is extensible.
Paul A. Bristow wrote: | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daniel Frey | Sent: Tuesday, June 10, 2003 10:18 AM | To: [EMAIL PROTECTED] | Subject: [boost] Re: Math Constants Formal Review - is extensible. | | | Paul A. Bristow wrote: | Your example is interesting. I think that providing a Macro value | allows this | sort of UDT extensions code (very like Michael Kenniston's examples). | | I fail to see how this should work. Could you elaborate a bit, please? | | My thesis that 40 decimal digits are enough is because it is enough for all | existing floating point hardware, up to 128 significands. I | believe that anyone | wanting more is likely to be using a separate 'unlimited' precision package | anyway. | | That exactly is my point: People will choose such a package, but how can | it be glued by the user to boost's constants? And to the code the user | already wrote? Taking into account that boost is intended to be some | kind of pre-standard-library, I think we should allow the extension of | constants to be used with new float-types. Using the constants in a | generic way is only possible when we have a standardized way of | accessing them. This is why I concentrated on allowing explicit casting | and the direct use as in pi*(float)(...). I don't see how the user could | use Roguewave's decimal type with Macros (or any other user defined | float-like type. And I don't think that using such a library should | result in a choice for the user to either use constants from boost with | the according interface or hope for the vendor to specify the constants | and use their interface. I imagine that any package will have some decimal digits C string to UDT conversion, for example for quad_float it is to_quad_float(const char*) so ones writes NTL::quad_float my_quad_float = to_quad_float(BOOST_PI); where BOOST_PI is defined as 3.1415926535897932384626433832794 say. I see the 40 decimal digit representations as the 'lowest common denominator'. How else do you propose? | | There is also an example of a UDT _interval_ - a 128-bit quad_float | type, used | by Victor Shoup's NTL package. But it does require using the NTL generator | program to create the exactly representable values. (See | test_quad_float.cpp | example). | I believe that interval constants are an important feature - and | quite novel. | | I don't understand that example, sorry. Thus I also miss the importance | of this feature. What exactly are interval constants? What problem are | they addressing? If you are using the interval library to calculate the intervals of areas of a circle, you need the smallest interval containing pi (as well as interval containing the radius of course). |Isn't it an orthogonal concept to constants like 'pi', | 'e', ...? Should / could it be placed into a separate library (maybe on | top of the basic constants library)? I proposed a separate file containing the interval constants (or should I say constants intervals?) | I also looked at other examples | like test_pi_interval, but I still don't understand the idea that's | behind it. All that I see is a lot of pi_f_l, pi_l_l, pi_l_u4, etc. and | this is IMHO unacceptable for generic programming. The file template_intervals_constants.hpp contains some examples of how the interval library authors and others discussions concluded that the interval values would appear to users - analogous to other intervals. Users would not see pi_f_l, pi_l_l. These are to show that the exactly representable values work OK. 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] | | Regards, Daniel | | PS: The toy-example I posted only worked for the GCC 3.x, but I extended | it a bit to make it work with the Intel compiler and with older GCCs | (2.95.x). If there is any interest, I can post it... | | -- | 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 | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- 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: Math Constants Formal Review - is extensible.
(Sorry for the first post, hit the wrong button)
Paul A. Bristow wrote:
I imagine that any package will have some decimal digits C string to UDT
conversion, for example for quad_float it is to_quad_float(const char*) so ones
writes
NTL::quad_float my_quad_float = to_quad_float(BOOST_PI);
where BOOST_PI is defined as 3.1415926535897932384626433832794 say.
I see the 40 decimal digit representations as the 'lowest common denominator'.
How else do you propose?
I think that most people are able to look up pi (and any other constant)
on the internet if they need more precision. But as shown in the example
for the Roguewave-type, it's possible to allow the user to extend the
system. If the pi_value-stuff is placed in a header called
constant_values.hpp and the definition of the variable pi itself is in
another header, the user could add a specialization for 1000 digits if
he likes. See the example I gave for 'g'. The main point in doing this
is, that you only need to change the header of your project to add a new
type, not the code where pi is used. Here in the company, we use doubles
to develop the code, the RWDecimal-class for the production system and
we might replace the latter by another type as we don't want to use
Roguewave in the future. Of course it might be a nice idea to provide a
string representation of a constant, probably as a specialization:
template struct pi_value std::string {
std::string operator()() const {
return 3.1415926535897932384626422832794;
}
};
Now we could even provide the default case for classes that have a ctor
taking a string like this:
template typename T struct pi_value {
T operator()() const {
return T( pi_value std::string ()() );
}
};
And the user is still able to specify his own version like shown:
template struct pi_value RWDecimal RWMP3Int {
const RWDecimal RWMP3Int operator()() const {
static const RWDecimal RWMP3Int value( ...1000digits... );
return value;
}
};
|Isn't it an orthogonal concept to constants like 'pi',
| 'e', ...? Should / could it be placed into a separate library (maybe on
| top of the basic constants library)?
I proposed a separate file containing the interval constants (or should I say
constants intervals?)
| I also looked at other examples
| like test_pi_interval, but I still don't understand the idea that's
| behind it. All that I see is a lot of pi_f_l, pi_l_l, pi_l_u4, etc. and
| this is IMHO unacceptable for generic programming.
The file template_intervals_constants.hpp contains some examples of how the
interval library authors and others discussions concluded that the interval
values would appear to users - analogous to other intervals. Users would not see
pi_f_l, pi_l_l. These are to show that the exactly representable values work OK.
Now I'm getting closer to it. And if it is in a separate header, it
would not mix up the above design, would 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: Math Constants Formal Review - is extensible.
Paul A. Bristow wrote: Your example is interesting. I think that providing a Macro value allows this sort of UDT extensions code (very like Michael Kenniston's examples). I fail to see how this should work. Could you elaborate a bit, please? My thesis that 40 decimal digits are enough is because it is enough for all existing floating point hardware, up to 128 significands. I believe that anyone wanting more is likely to be using a separate 'unlimited' precision package anyway. That exactly is my point: People will choose such a package, but how can it be glued by the user to boost's constants? And to the code the user already wrote? Taking into account that boost is intended to be some kind of pre-standard-library, I think we should allow the extension of constants to be used with new float-types. Using the constants in a generic way is only possible when we have a standardized way of accessing them. This is why I concentrated on allowing explicit casting and the direct use as in pi*(float)(...). I don't see how the user could use Roguewave's decimal type with Macros (or any other user defined float-like type. And I don't think that using such a library should result in a choice for the user to either use constants from boost with the according interface or hope for the vendor to specify the constants and use their interface. There is also an example of a UDT _interval_ - a 128-bit quad_float type, used by Victor Shoup's NTL package. But it does require using the NTL generator program to create the exactly representable values. (See test_quad_float.cpp example). I believe that interval constants are an important feature - and quite novel. I don't understand that example, sorry. Thus I also miss the importance of this feature. What exactly are interval constants? What problem are they addressing? Isn't it an orthogonal concept to constants like 'pi', 'e', ...? Should / could it be placed into a separate library (maybe on top of the basic constants library)? I also looked at other examples like test_pi_interval, but I still don't understand the idea that's behind it. All that I see is a lot of pi_f_l, pi_l_l, pi_l_u4, etc. and this is IMHO unacceptable for generic programming. Regards, Daniel PS: The toy-example I posted only worked for the GCC 3.x, but I extended it a bit to make it work with the Intel compiler and with older GCCs (2.95.x). If there is any interest, I can post it... -- 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: Math Constants Formal Review - is extensible.
On Sun, 08 Jun 2003 16:56:53 +0200, Paul A Bristow wrote:
You can seen an example of extending to a 'new' constant 'gamma' in the
examples testFunctionConstants/gamma_function_constants.hpp.
Either I don't understand the example or we are talking past each other. I
don't meant to extend the framework with new constants, but with
definitions of existing constants for new types. Maybe the attached
example of a small experiment of mine clarifies what I was thinking about.
Look at the Roguewave-extension for pi. If I imagine to use
boost/math_constants.hpp in the company I work, it would be encapsulated
into another header base/math_constants.h and it would provide all
constants for Roguewawve's decimal type, too. I already used the
lambda-library and tought it about the decimal type, which worked very
smooth and I was really happy to see that the library designers didn't
limited it to build-in types. A key-feature for me!
defining the constant as a 40 decimal digit string.
Roguewave's types can be used with precisions up to 1024 bits - probably
more. I don't think that a one-size-fits-all approach can work in the area
of numeric computations.
If Boosters agree that this scheme is an acceptable way to go, the the
example and guidance could be made more helpful to provide the
encouragement you rightly say is needed.
But first the overall strategy needs agreement.
Indeed. So if I still missed that the constants can be provided by the
user for their types, please let me know. Otherwise, we should find a
consensus whether such a feature is needed. I personally think it is, but
if the majority thinks it's not that important... :)
Note that the attached file is not meant to offend you in any way. It way
just a toy example and maybe you can take some ideas out of it. It's not
meant to replace your code as I think you have put a lot of ideas in it
and provide features I don't even know of :)
Regards, Daniel
---
#include iostream
using namespace std;
namespace math
{
// Generic base class for all constants
template typename T, template class class F struct constant
{
// A cast-to-anything-operator :)
template typename U operator U() const { return F U ()(); }
#define ADD_OPERATOR( OP ) \
template typename U friend U operator OP( const T lhs, const U rhs ) \
{ U nrv( static_cast U ( lhs ) ); nrv OP##= rhs; return nrv; } \
template typename U friend U operator OP( const U lhs, const T rhs ) \
{ U nrv( lhs ); nrv OP##= static_cast U ( rhs ); return nrv; }
ADD_OPERATOR( + );
ADD_OPERATOR( - );
ADD_OPERATOR( * );
ADD_OPERATOR( / );
#undef ADD_OPERATOR
};
// Here's the definition for pi for all types (can be extended by UDTs):
template typename T struct pi_value;
template struct pi_value float { float operator()() const { return 3.14; } };
template struct pi_value double { double operator()() const { return 3.1416;
} };
template struct pi_value long double { long double operator()() const {
return 3.1415927; } };
/*
// For expensive constructions, maybe this is an option:
template struct pi_value RWDecimal RWMP3Int {
const RWDecimal RWMP3Int operator()() const {
static const RWDecimal RWMP3Int value( 3.1415926535897932384626433832
);
return value;
}
};
*/
// Here's the single line to create a useful interface
struct pi_t : constant pi_t, pi_value {} pi;
// Another one:
template typename T struct pi2_value;
template struct pi2_value float { float operator()() const { return 9.87; } };
template struct pi2_value double { double operator()() const { return 9.8696;
} };
template struct pi2_value long double { long double operator()() const {
return 9.8696044; } };
struct pi2_t : constant pi2_t, pi2_value {} pi2;
// And their relationship:
pi2_t operator*( const pi_t, const pi_t ) { return pi2_t(); }
// Some obvious (?) constants:
#define CONSTANT_VALUE( name, value ) \
template typename T struct name##_value { T operator()() const { return value;
} }; \
struct name##_t : constant name##_t, name##_value {} name;
CONSTANT_VALUE( minus_one, -1 );
CONSTANT_VALUE( zero, 0 );
CONSTANT_VALUE( one, 1 );
CONSTANT_VALUE( two, 2 );
CONSTANT_VALUE( three, 3 );
CONSTANT_VALUE( ten, 10 );
#undef CONSTANT_VALUE
minus_one_t operator-( const one_t ) { return minus_one_t(); }
one_t operator-( const minus_one_t ) { return one_t(); }
zero_t operator-( const zero_t ) { return zero_t(); }
// Another one:
template typename T struct half_pi_value;
template struct half_pi_value float { float operator()() const { return 1.57;
} };
template struct half_pi_value double { double operator()() const { return
1.5708; } };
template struct half_pi_value long double { long double operator()() const {
return 1.5707963; }
[boost] RE: Math Constants Formal Review
I currently vote neither yes nor no. I just need to get a better understanding of what is intended to be included into boost from the files provided. On Fri, 06 Jun 2003 19:21:08 +0200, Paul A Bristow wrote: but I hope the review can concentrate on what emerged previously as the _really_ tricky issue of how to _present_ the values in C++, I looked at the files and I think that they need some clean ups. Also, I don't really see the concept behind it. How are the values presented and how does your way compare to other options? (Well, I basically can fiure out the first part, but without the second, I can't really understand it). Maybe you can provide some links to the key messages of the discussion that lead to it or give us a short summary. Another point I am missing is a way to extend the constants for user-defined types. Something like numeric_limits comes to mind. I think that this is a must-have feature as people that write applications that need lots of these constants are likely also using types with higher precision that the standard types provided by the language. Without a way to teach the constants-framework the new types, they will create wrappers and thus they won't use the intended boost-/standard-way to access the variables. Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: quaternion/octonion compiler errors
Hubert Holin wrote: GNU C++ 2.95.3-5 cannot find the limits standard header file (is this me?!) I'd like to know. I do not currently have access to an installed copy of this compiler, but it's one for which quite some energy was expended to make things work. AFAIK it's a known problem that the limits-header is missing for the GCC 2.95.x. I don't know if it's the official boost way of fixing this, but including boost/detail/limits.hpp instead of limits might fix this one, at least it once worked for me ;) 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: Re: quaternion/octonion compiler errors
On Wed, 28 May 2003 18:40:02 +0200, Beman Dawes wrote: At 10:10 AM 5/28/2003, Daniel Frey wrote: Hubert Holin wrote: GNU C++ 2.95.3-5 cannot find the limits standard header file (is this me?!) I'd like to know. I do not currently have access to an installed copy of this compiler, but it's one for which quite some energy was expended to make things work. AFAIK it's a known problem that the limits-header is missing for the GCC 2.95.x. I don't know if it's the official boost way of fixing this, but including boost/detail/limits.hpp instead of limits might fix this one, at least it once worked for me ;) Um... Should be boost/limits.hpp, shouldn't it? Oops. Yes. boost/limits.hpp then includes boost/detail/limits.hpp as a workaround for limits when needed, right? I just didn't noticed that as I only used it with the GCC 2.95.2. Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [lambda] gcc 2.95.2?
Hi, I was finally able to upgrade our company's boost installation from 1.25.1 to 1.30.0 last week :)) I happily tried to use it, but I ran into a small problem: The compiler we are using is still the gcc 2.95.2 with no chance for an upgrade in the foreseeable future. When I included boost/lambda/lambda.hpp, I got: /usr/include/g++/stl_deque.h:480: previous declaration `template class _Tp, class _Alloc = class allocator_Tp1, unsigned int __bufsiz = 0 deque_Tp,_Alloc,__bufsiz' ../../release/include/boost/lambda/detail/operator_return_type_traits.hpp:869: used 3 template parameters instead of 2 Is this expected? The docs say, that the lambda-lib is supposed to work for the gcc 2.96, so what's required to use it with the gcc 2.95.2? Or isn't it possible at all because the compiler is simply too old? 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: [lambda] gcc 2.95.2?
I should also mention that I have a patch which solves the problem by replacing the forward declaration of deque with a real include in boost/lambda/detail/operator_return_type_traits.hpp. Really strait-forward. But am interested in the general support of lambda for this compiler, as the problem I had will most likely occur for anyone using the gcc 2.95.2 immediately and I haven't found any other problem after the patch... 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: ENFORCE
Gennaro Prota wrote: On Thu, 8 May 2003 15:06:02 +0300, John Torjo [EMAIL PROTECTED] wrote: Unfortunately, we can't use the do-while(0) idiom, since we don't know when while(0) will be ;-) Oops, no. That's not the problem. The problem is that I read Daniel's reply out of context and too absent-mindedly :-) I thought it was something like if (false) ; else whereas he is really testing for a condition if(expr)... However, if you are going to abort at the end (or throw, but I don't want to enter in this matter) you can simply replace 'if' with 'while': But that does not give you any benefit at all, does it? The do-while-idiom is very different from the while-version you suggest. It's IMHO the only idiom that forces the user to add a semicolon, but we actually don't want to do that here. The user should be allowed to add (i) or other stuff. I think that the 'if' (or 'while', but that's not a difference) is the best we can do here. 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: Sorting list shared_ptr foo usingstd::list::sort()
HEATH DAVIS wrote:
I have experienced some difficulty with sorting lists of type:
list shared_ptr foo
[snip]
bool my_class::operator(const my_class arg)
{
return m_val arg.m_val;
}
[snip]
//sort the list
my_list.sort();
Here, you basically sort by using
shared_ptr::operator
instead of
my_class::operator
You need something like
template T struct shared_ptr_content_less
{
bool operator()( const boost::shared_ptr T lhs,
const boost::shared_ptr T rhs ) const
{
return *lhs *rhs;
}
};
and call
my_list.sort( shared_ptr_content_less my_list () );
The code is untested, but I hope you get the idea. Also, there might be
some easier way using other boost-libs to create the helper on-the-fly,
but others definitely know better than me :)
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: [type_traits] Missing include for function traits?
John Maddock wrote: Yes, I made it gcc specific, also added a similar fix for is_union, but not for has_trivial_copy which also produces these warnings. Fixes will be in cvs towards the weekend - when I get my cvs access up again (I only have limited mail access at present). Looks good. That means, I think it will do the job - not that I like the #ifdef's :) Also, IIRC, the comment from Dave seen below is lying (due to changes that happened after he wrote it). Maybe we should fix this up, too. It would IMHO lead to the removal of the #ifdef-block, but I didn't wanted to mix it up with the fix for the warnings, so I left it out for now. Not quite - the fix is required if you can't pass non-copyable types through is_convertible, and that is still true for some compilers unfortunately, even if this has been fixed for most of them... Ah, thanks. And sorry to Dave. Hm, type traits are a good example for never change a running system I guess... :)) 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: [type_traits] Missing include for function traits?
John Maddock wrote: Yes, I made it gcc specific, also added a similar fix for is_union, but not Just looked at is_union. That won't work, I guess. You need to add a typedef T cvt; or change it to BOOST_STATIC_CONSTANT(bool, value = BOOST_IS_UNION(T)); 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: Problem with KAI C++ and boost::type_traits
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: Sounds reasonable. Which makes me wonder if we shouldn't change the naming of branches a bit: We should have a branch for the development of new versions (1.30.x), let's call it DEVELOP_1_30_x. On this branch, we can now add several tags: Version_1_30_0_RC_1, Version_1_30_0_RC_2, Version_1_30_0, Version_1_30_1_RC_1, Version_1_30_1_RC_2, Version_1_30_1_RC_3, Version_1_30_1, etc. I'd prefer shorter names: v1_30-branch v1_30_0rc1 v1_30_0rc2 v1_30 ... The last one you showed is hopefully a typo. And I'd prefer to have a separator for the non-releases like the '-' anywhere: v1_30-branch v1_30_0-rc1 v1_30_0 v1_30_1-rc1 v1_30_1-rc2 v1_30_1 It's just an internal naming change that's not hugely exposed even to developers, so I don't feel strongly about it. I think it's up to Beman to decide what's best as he obviously has the most trouble with it anyway. :) 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: Problem with KAI C++ and boost::type_traits
David Abrahams wrote: I can do that. Should we start a new branch for things that would go into a hypothetical 1.30.1? My feeling is that we should just keep using the RC_1_30_0 branch, since it's already been tagged where the release was made. Sounds reasonable. Which makes me wonder if we shouldn't change the naming of branches a bit: We should have a branch for the development of new versions (1.30.x), let's call it DEVELOP_1_30_x. On this branch, we can now add several tags: Version_1_30_0_RC_1, Version_1_30_0_RC_2, Version_1_30_0, Version_1_30_1_RC_1, Version_1_30_1_RC_2, Version_1_30_1_RC_3, Version_1_30_1, etc. This would IMHO be an easy, straight-forward system which allows us to tag/create real release-candidates (like Beman already did for the current release but manually IIRC) and both the .0 version and bug-fix-versions - all in one correctly-named branch. Comments? 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: Problem with KAI C++ and boost::type_traits
Daniel Frey wrote: Sounds reasonable. Which makes me wonder if we shouldn't change the ^ Should be should, shouldn't be shouldn't ;) 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: RC_1_30_0 still broken (apologies and help!)
Aleksey Gurtovoy wrote: Daniel Frey wrote: it's still the question whether is_function could be fixed given that is_reference seems to be available for compilers without partial specialization. Sure. By all means it would be appreciated if someone contributed a comprehensive fix which would close the issue. I don't really wanted to suppose changes that defer the 1.30.0, I just tried to find a way to work around the lock-problem of SourceForge. Okay, that's good to hear :), sorry if I overreacted a bit. 1.30.0 preparation period has lasted long enough for some of us to want it to be over already. Maybe I should start to work on it now, but *not* for 1.30.0. This would give us enough time to have it in the mainline CVS to avoid time-pressure. As I don't have much time these days anyway, I think I'll try to create a fix for is_function in the next weeks. I'll not hurry as the problem is neither new nor severe. And if it works (and with some kind help ;) maybe we can fix it for 1.31.0... :) 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: RC_1_30_0 still broken (apologies and help!)
David Abrahams wrote: Andreas Huber [EMAIL PROTECTED] writes: Still looks broken over here: http://cci.lbl.gov/boost/results/1047901021/dailylog_win32_vc60 I think it's OK to revert the patch to get 1.30.0 out, but for the future, I think we should keep in mind that it's actually is_function that is broken and needs to be fixed AFAICS. The patch to is_class would work if is_function could be called with a reference, so I think it's worth to consider fixing is_function. As John is the expert, I think he can decide whether it's better to wait for the SourceForge-folks to fix the lock-problem or if it's easy enought (and thus faster) to fix is_function... 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] [type_traits] Missing comma in boost/type_traits/is_class.hpp
Andreas Huber wrote: Hi there, The subject says it all (I'm using the CVS state from 5 minutes ago)... === RCS file: /cvsroot/boost/boost/boost/type_traits/is_class.hpp,v retrieving revision 1.6 diff -r1.6 is_class.hpp 84c84 ::boost::type_traits::ice_not ::boost::is_voidT::value ::value --- ::boost::type_traits::ice_not ::boost::is_voidT::value ::value, You are right. But I suggest not just to add the comma, but to remove the #if/#else/#endif-part it is found in, as both parts are identical now. 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] [call_traits] bcc failure
David B. Held wrote:
This code fails on bcc 5.5.1:
And for the gcc, too.
template typename U
foo(boost::call_traitsU::param_type v)
{ }
There is a 'typename' missing, but that won't help AFAICS.
[C++ Error] CallTraits.cpp(20): E2285 Could not find a match for
'foo::foo(X)'
Any ideas?
The compiler has no idea how to deduce U as - depending on U -
param_type could change. What happens if two different U's would be a
valid match? IIUC the standard forbids type-deduction is these cases to
avoid non-portable code, so if any other compiler would work, it would
IMHO not be standard conformant code.
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: [call_traits] bcc failure
On Sat, 15 Mar 2003 20:15:59 +0100, David B. Held wrote: Daniel Frey [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [...] The compiler has no idea how to deduce U as - depending on U - param_type could change. [...] Oh, yes, I see. I guess call_traits is only useful when T is a class template parameter. A bit unfortunate, isn't it? I mean, it isn't very useful for function forwarding then, is it? Indeed. And I don't see any solution for your problem (except manually providing the overloads you need). Bad luck :( Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: possible addition to operators library
Daniel Frey wrote: I'm not 100% sure where the problem is, but the patches are broken for me. Can someone else please confirm this? Maybe it's my mail-program, which I know is broken, but I also tried to get the files from the ASPN archive and that failed, too. Meanwhile, you (Sam) can post them to me as a private email. Please use [EMAIL PROTECTED] for this. And please make sure that you can apply the patch-files you generated. If you need some help with the patch-command, let me know. Back here in the company, I see the patches are correct. I will find a way to forward them and look at them somewhere this evening when I find some time. Sorry for the delay. 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] Additional mailing lists
Vladimir Prus wrote: Just today, somebody was not able to find a way to subscribe to Boost.Build mailing list ([EMAIL PROTECTED]). I recall it's not the only domain-specific mailing list. There's boost-documentation, there's ml for Spirit, and, IIRC, for Boost.Python. I think it would be good to add information about additional list. I think that index.html will list Domain-specific under Boost (Developers) and Boost Users, and mailing_lists.html will contain all further information. Is this good idea? If so, I'll go ahead and add Boost.Build ml and hopefully others add more. A general question: Is it really desirable to have separate mailing lists? Maybe it's just me, but I prefer one mailing list for all discussions. Of course there are discussions I don't follow, but sometimes, you see things in an unrelated thread that can be used for the stuff you are interested in. These synergy-effects are not available when the lists are separated. I don't really bother the higher volume. IMHO two lists should work: One for general discussion and one which only has announcements for those people that are only interested in new stable versions. In the discussion list, prefixes in the subject [spirit], [lambda], [whatever] should work well and even without them a good subject is all I need. 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] Additional mailing lists
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: I don't really bother the higher volume. Well in that case you can just subscribe to all of them, no? What's the advantage to you over having 4 or 5 subscriptions? The point is, that I won't subscribe to a list if it is about a topic I'm not interested in. If OTOH these discussions happens on a list that I have for other reasons, I still see some of these messages and sometimes I can use fragments for my own work. I understand that this only works up to a certain volume, though and boost probably reached the critical mass to justify a split into several lists. Whatever will be decided, I won't have a problem with 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
Re: [boost] Update: Outstanding patches and fixes
Beman Dawes wrote: * Daniel Frey: provided a fix for some warnings in the type-traits (is_class/is_enum IIRC), John Maddock is aware of it AFAIK. Just to remove any doubts: This should not be a show-stopper. The warnings are in there for quite some time and type-traits are to complicated for quick hacks. If John needs more time for it, it's definitely OK for me if it is deferred until the next release. It's IMHO more important to get 1.30.0 out. 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] RE: bidirectional map
David Abrahams wrote: It's similar for me. It's one of those things that you don't need every day, but when you need it, you really need it. That may be why there's not more vociferous interest. Anyhow, while bidirectional maps are the most common case, they're not the most general: N-directional maps, which I've sometimes needed. I'd also be interested in a 'set' of 'tuples' with a user-defined set of 'views', where a view has its own sort-criterion and its own iterators, find-functions, etc. At least this is what I imagine but I haven't worked on it, so I don't know whether it's a realistic approach. Regards, Daniel PS: And yes, *if* you need them, you really *need* them. -- 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] Outstanding patches and fixes
Beman Dawes wrote: * Possible addition to operators library from Sam Partington Daniel Frey and Sam discussing changes. We need some discussion of it and I would like to see it in CVS and thus in the regression tests for some time. When Sam started the proposal, the branch for 1.30.0 has already happened (IIRC) and to me, this means bug-fixes only. I don't know when exactly you are planning to release 1.30.0, but if there is enough time and Sam (and others) would like to see the addition ASAP, we can try to push things a bit. Currently, it's an 1.31.0 item as far as I'm concerned. Sam, is this OK for you? * PRB with type_traits::is_member_function_pointer Would prefer John Maddock or someone else more familiar with type traits regeneration make this change. I provided a fix for some warnings in the type-traits (is_class/is_enum IIRC), John is aware of it AFAIK. Don't know whether you want to add this one to your list, though. 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] Re: Re: possible addition to operators library
Sam Partington wrote: No, I agree. You're right, much better to squint at error messages than to try and diagnose unexpected behaviour. Plus the messages I compared against were not all that bad to look at anyway, and all of them said something to the effect of can't convert class 'A' to 'int' or something. Fine. The VC issue bothers me, as I don't think I fully understand what exactly happens. Doesn't the compiler give any additional messages to explain what exactly is ambiguous for operator? Does anyone know this problem and has a work-around? Unfortunately I don't understand this. It can go in the documentation, with the work around to be : if (!!a ...) or if (a) if (...) Of course. But I was hoping for a work-around at the library-side, not at the user's side. What exactly are the overloads that the VC thinks might match? Or what type does it try to cast the expression to (instead of bool)? Finally, if we choose this route, this means that we can take the approach of providing operator! and a private operator some_number_type() while the user provides operator bool. This is more semantically correct in my opinion, anyone have any problems with this? Oh, I should have patches posted very soon. Fine. Remember that the name should probably change to reflect the corrected semantics. Something like 'bool_negatable'? But then, there is still some slight illogic here: We provide operator!, but the protector is for operator bool. Two orthogonal concepts. Would it make sense to separate them? If so, will 'bool_protector' have any value? Those people not aware of the problem of providing operator bool() will not use it, those that are aware will use Peter's safe-bool-idiom when appropriate as it gives better error messages. And where safe-bool is not applicable, you don't need a protector anyway AFAICS. Hm... thoughts? 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] Re: Re: possible addition to operators library
Sam Partington wrote:
Yes, library side fix would be much nicer. But I'm stuck on this. The
compiler is _really_ helpful here:
z:\test.cpp(37) : error C2593: 'operator ' is ambiguous
thats it! The compiler docs suggest to resolve the ambiguity you explicity
cast one or both of the arguments of the operator. But
if (static_castbool(a) ...
is even more of a mouthful. At least there's still no danger of passive
errors.
Indeed that's not very helpful. But at least - as you said - it fails to
compile so I consider it a non-issue for the operators library. It's a
VC6 problem and the users need to life with it whether or not they use
the operators library, right?
Fine. Remember that the name should probably change to reflect the
corrected semantics. Something like 'bool_negatable'?
I don't think it does. Actually I always felt that bool_testable was wrong.
After all equality_comparable provides the inequality test. And
dereferenceable provides -. So bool_testable should provide the opposite
of bool testable. i.e. operator!. If you get me :-)
Agreed.
As for whether we should seperate the two concepts, perhaps, but I don't any
occasions when I would want bool_testable and not bool_protector. Therefore
if we were to seperate them I would like bool_testable to derive from
bool_protector
bool_protector - prevents accidental conversions to int for classes with
operator bool
bool_testable - provides bool operator!(const T) AND bool_protector
templateclass T, class B = ::boost::detail::empty_base
struct bool_testable : bool_protectorT, B
{...};
But I do ask myself, is this a likely use-scenario?
I don't think so and I wasn't suggesting that it would be a good idea. I
think it's reasonable to have both things tied together. I just wanted
to mention it and see what you think. I think that it's my job as the
maintainer to try to break everything to see how robust it is (and
hopefully not to frustrate anyone). As I'm new in this area, please
correct me if I'm wrong. :)
I think we now have had a fair amount of discussion and as long as you
(or anyone else) don't find another problem, I'm looking forward for
your next patch-set. :)
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: Re: Re: possible addition to operators library
On Wed, 12 Mar 2003 20:15:31 +0100, Sam Partington wrote: I think we now have had a fair amount of discussion and as long as you (or anyone else) don't find another problem, I'm looking forward for your next patch-set. :) Attached. Hopefully not made a mess of it. :-) I'm not 100% sure where the problem is, but the patches are broken for me. Can someone else please confirm this? Maybe it's my mail-program, which I know is broken, but I also tried to get the files from the ASPN archive and that failed, too. Meanwhile, you (Sam) can post them to me as a private email. Please use [EMAIL PROTECTED] for this. And please make sure that you can apply the patch-files you generated. If you need some help with the patch-command, let me know. PS The problem I mentioned I was having with the tests was me not thinking properly. I compiled all the tests with an old set (1.29) of boost files by mistake, and lo and behold it none of them passed - amazing hey! Sorry, I'll keep my mouth shut in future. That looks very familiar to me. I'm certainly not the one who should throw the first stone here ;) Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: possible addition to operators library
On Tue, 11 Mar 2003 12:22:19 +0100, Sam Partington wrote: As for the issue below, I also have no idea how to go about automatically selecting either method. Plus I think this might introduce complexities which make the compiler's job that much harder to optimise. Could well be wrong on that though. Optimization won't bother me that much as it should all be compile-time magic. It still has to be verified but before that, we need something that we can verify. :) Essentially I think the options are to - document its unusual behaviour in the presence of other conversion operators - use the private operator int method. So if we take the plusses and minuses for each method: safe-bool: + obvious error messages (see list of error messages at end) This is from the convenience section IMHO. But it's important. - problems with classes that provide other user-defined conversions operators. A technical thing. The question is, what do we prefer? I personally prefer a technical advantage as it creates safer overall code. I am used to work with several people in a large code-base and in my experience it's always a very helpful thing if the interface of your code leads to compile-errors when misused. Documentation will help you to reject the responsibility - it won't help you to get the job done. If the compiler rejects your code and the error message itself is anything but clear, you are at least forced to work on it. That's not nice in the moment you are faced with it, but in the long term it pays. The alternative (keep the safe-bool and document it) leads to hidden bugs that are IMHO hard to find. Remember that we have a very close view to a tiny code fraction. Imagine it to be the part of a 100.000 lines project. It compiles without a warning but calls operator int() instead of operator!(). So it comes down to two things, 1) How important is it to have legible diagnostics? 2) How important is it to behave properly with other user-defined conversions? The latter will probably be the result of a colleague adding operator int() 6 month after you developed the class. What formerly worked correctly turns into a bug silently and you will - depening on your definition of operator int() not necessarily notice it in the beginning. Maybe - and we all know Murphy - it provides the correct semantics in 99.9% of all cases. That's a nice bug to trace, isn't it? But these are just my personal opinions, other opinions welcome. My gut feeling is that I'd rather have the safe-bool method, but I suspect my judgement is coloured by two things: - I never use user defined conversion operators - I use MSVC 6 as my main compiler, and not being able to do if (a !a) would bother me. The VC issue bothers me, as I don't think I fully understand what exactly happens. Doesn't the compiler give any additional messages to explain what exactly is ambiguous for operator? Does anyone know this problem and has a work-around? Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: possible addition to operators library
Daniel Frey wrote: One problem I just found with your implementation (and thus with Peter's idiom in general) is, that is doesn't provide an operator bool(). This This sounds too hard. Of course it's not a problem where Peter used it as there obviously is no other operator int() or something. The problem only occurs when you try to create a generic component that should work with all classes. [...] int(). Several options come to mind: - Document it that the class T of bool_testable T shall not have any other operators that might conflict. - Use the above alternative implementation I showed. It is not as nice as yours/Peter's wrt error-messages, but it works as expected. - Convince the standard committee that explicit operator bool is needed :) See: http://groups.google.de/groups?hl=delr=ie=UTF-8frame=rightth=d0969f0fa2460dd4seekm=3A2D10EE.35544D0A%40aixigo.de#link1 Another alternative would be to create a selector which switches from the safe-bool-idiom to a real operator bool when appropriate. This would involve type-traits I guess and as a start we could try to detect convertability to bool of the class T. But this is IMHO not sufficient, as T might have operator int() and operator long(), so the detection will fail (ambiguous). Although this alternative would lead to the best result, I don't have a clever idea how to achieve that... 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] Re: possible addition to operators library
Daniel Frey wrote: BTW: I wonder if gmane eats messages. I cannot find some messages we exchanged when I was still in the company earlier this day. I will keep an eye on it in case the problem remains. False alarm, gmane.org works perfectly well. I just had to fix my mail-filters :) 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] possible addition to operators library
Sam Partington wrote: Hi all, Hate to sound pushy, but I've no answer on this, were the patches ok? Would you like me to repost them? Or should I just drop it? No, please don't drop it. I think it's a good idea, but I haven't found the time to look at your patches closely. I will try to do so but I can't promise any shedule. Besides: I remember that the first message about the NRVO-implementation I wrote was about June 2002 and it took several months to get it accepted. Just be patient and keep reminding the group (and the maintainers of operators.hpp) from time to time :) 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: possible addition to operators library
On Fri, 07 Mar 2003 19:42:44 +0100, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: At 11:08 AM 3/7/2003, David Abrahams wrote: Sam Partington [EMAIL PROTECTED] writes: Hi all, Hate to sound pushy, but I've no answer on this, were the patches ok? Would you like me to repost them? Or should I just drop it? The code looks OK, but the submission won't be complete without patches for the docs and tests. The submission was three files, including patches for docs and tests. The only one I could find was a single patch. Can someone point to the message in the archive please? http://www.mail-archive.com/boost%40lists.boost.org/msg05908.html BTW: I wonder if gmane eats messages. I cannot find some messages we exchanged when I was still in the company earlier this day. I will keep an eye on it in case the problem remains. Sam: I looked at the patches, especially the doc. I think you should write some more, as you were influenced from your knowledge. I suggest you begin with mentioning operator bool() and what's wrong with it before presenting the solution. Think of new users that potentially don't even know that there is a problem with operator bool(). Also, if you like, you can write a brief note about why the classic solution I showed (using a private operator int() in parallel to operator bool()) is not a good solution and how yours/Peter's is better. All this can/should happen in the note you added. The note itself should be added to the index at the top and you might want to add yourself to the contributors' list at the end. Regards, Daniel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
