[boost] Re: A question about static_log2
Gennaro Prota: Vesa, I really appreciate your attempt but your code assumes the required number to be a power of two (it just tries 32, 64, 128, etc.). What about 48 bits unsigned long?[...] If unsigned long has 48 bits, then an n of 32 would be chosen. There are good reason to choose an n that is a power of two: 1) The initial n can be calculated quickly. It will take Theta(log(M)) steps to find a proper n when unsigned long has M (value) bits. In other words, choose_n is simple and efficient. 2) Using only powers of two for n, you will need a maximum of one extra recursion of the core algorithm. In the worst case, both algorithms need exactly as many recursions. 3) if you want to allow other than powers of two in the core algorithm, and especially if you want to make it possible to save the one recursion, you would need to complicate the algorithm considerably. Specifically, if you are not using only powers of two, 3.b) you will need to round-up when you divide n by 2, in order to have a correct algorithm (consider the case when n would be 3). 3.c) you would have to distinguish between cases when the number is higher-than-or-equal-to and lower-than 1uln, in order to save the one recursion (consider the case when n is 2, but you know that the reduced value has only 3 (rather than 4) bits). -Vesa _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
From: Aleksey Gurtovoy [EMAIL PROTECTED]
David Abrahams wrote:
It appears to be just bad luck that higher order functional
programming with function templates is impossible in C++.
My current understanding (which, admittedly, is not backed up by a
real-world experience) is that if you care about higher-orderness of your
generic algorithms, a preferred implementation construct for those
algorithms is not a function template, but a static _function object_ (a
technique used in FC++):
struct my_function_
{
template typename U
void operator()(std::string const text, U)
{
// ...
}
} my_function; // here!
For ordinary uses, the above will act just like a plain function template
(minus ADL/explicit template arguments specification):
However, it does tend to create some boilerplate code, if all you want is to
call a function template for all the types. It's similar to std::for_each,
if you want to execute arbitrary code, unless you use BLL.
Nevertheless, I've asked at comp.std.c++ why function template template
parameters aren't allowed (the posting hasn't appeared, yet).
and it will also allow one to do something like this:
std::string text(text);
mpl::for_each my_types (boost::bindvoid(my_function, text, _1));
I got error: no instance of function template boost::mpl::for_each
matches the argument list, when trying this on Intel C++. Do you have a
version of this that works?
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cstdint.hpp patch for Cray X1
The recent change to boost/cstdint.hpp for Cray systems is not appropriate for the Cray X1. It has a 16-bit short type, however there are performance penalties associated with it. OK thanks, patches applied. The following patch for cstdint.hpp sets up the appropriate typedefs for this platform. diff -u -r1.29 cstdint.hpp --- boost/cstdint.hpp 22 Jan 2003 12:12:14 - 1.29 +++ boost/cstdint.hpp 23 Jan 2003 16:32:04 - @@ -160,7 +160,16 @@ // 16-bit types ---// -# if USHRT_MAX == 0x +# if defined(__crayx1) + // The Cray X1 has a 16-bit short, however it is not recommend + // for use in performance critical code. + typedef short int16_t; + typedef short int_least16_t; + typedef int int_fast16_t; + typedef unsigned short uint16_t; + typedef unsigned short uint_least16_t; + typedef unsigned intuint_fast16_t; +# elif USHRT_MAX == 0x typedef short int16_t; typedef short int_least16_t; typedef short int_fast16_t; ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] -lrt on Mandrake 9.0
Sorry for this slightly off topic question, but I'm not a Linux user by trade. I've recently switched distributions to Mandrake 9.0, which comes with GCC 3.2 out of the box. When trying to compile Boost.Threads on this platform I encounter the following problem: Good question, every linux box I've encountered up until now has had -lrt (I thought this was part of glibc ?), and it's normally required for linking the thread lib (all the sched_* functions are in there). John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problem with regression tests
I have now run the regression tests on a Cray SV1 but it seems there is still a problem in the postprocessing stage. I get output like: I would expect to see that if you haven't filtered the bjam output through process_jam_log, double check your bin/ directory to see what output files have been generated for each target. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: math constant - generic function circle_area example.
Please send me your amended code. I had thought that the Kenniston stuff was
included in the zip uploaded, but I will check. Apologies if not.
Thanks
Paul
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Joerg Walter
Sent: Friday, January 24, 2003 12:27 AM
To: Boost mailing list
Subject: Re: [boost] RE: math constant - generic function circle_area
example.
Hi Paul,
you wrote:
I've been looking into an earlier version of the proposed math constants
before and asked myself how to implement a generic function like
templateclass T
T circle_area (const T radius) {
return math_constantsT::pi * radius * radius;
}
How should this be done?
Thanks,
Joerg
Attached is an example using Michael Kenniston's Kunning Function
constants.
Briefly
template typename T
T circle_area(const T radius)
{
// Usage example: circle_areadouble( 2.) // Explicit type double.
// or circle_area(2.F) // Implicit type float.
return boost::math::constant T, boost::math::pi_tag () * radius *
radius;
}
OK. I've tried to compile this with GCC 3.2.1 and after applying some
remedies like
for example
#ifdef LATER
// Define constant is namespaces to hold three builtin floating-point
representations.
namespace float_constants
{
constant float, pi_tag const pi;
}
namespace double_constants
{
constant double, pi_tag const pi;
}
namespace long_double_constants
{
constant long double, pi_tag const pi;
}
#endif
/for example
it compiled and executed giving the expected results. How is this solution
related to your latest (Dec. 12) upload at groups.yahoo.com/group/boost?
It compiles with MSVC 7.0 (but not 6 - see MK's original example for why
not).
(long double == double for MSVC, so long double not fully
testable/useful).
It seems to do the trick, without too many surprises. I have displayed
the
output using the 17 significant digits for double so one can see the
difference
between a float pi 3.1415927410125732 and a double pi 3.1415926535897931
(even
though only 9 are really significant for float).
cout circle_areafloat(1.) =circle_areafloat(1.) endl; //
Explicit type float.
cout circle_areadouble(1.) =circle_areadouble(1.) endl;
//
Explicit type double.
cout circle_area(1.F) =circle_area(1.F) endl; // Implicit
type
float.
cout circle_area(1.) =circle_area(1.) endl; // Implicit type
double.
cout circle_area(1.L) =circle_area(1.L) endl; // implicit
type
long double.
cout circle_areadouble(1.F) =circle_areadouble(1.F)
endl; //
Explicit over-rides implicit.
And silly types like int fail helpfully.
// cout circle_area(1) =circle_area(1) endl; // Implicit
int -
does not link!
// cout circle_areaint(1.) =circle_areaint(1.) endl; //
Explicit int - does not compile!
Output is
Test test_circle_area.cpp Thu Jan 23 00:06:28 2003
float pi = 3.14159274
double pi = 3.1415926535897931
float pi = 3.1415927410125732
circle_areafloat(1.) = 3.1415927410125732
circle_areadouble(1.) = 3.1415926535897931
circle_area(1.F) = 3.1415927410125732
circle_area(1.) = 3.1415926535897931
circle_area(1.L) = 3.1415926535897931
circle_areadouble(1.F) = 3.1415926535897931
circle_arealong double(1.) = 3.1415926535897931
circle_areafloat(2.) = 12.566370964050293
circle_areadouble(2.) = 12.566370614359172
circle_area(2.F) = 12.566370964050293
circle_area(2.) = 12.566370614359172
circle_area(2.L) = 12.566370614359172
circle_areadouble(2.F) = 12.566370614359172
boost::math::constant float, boost::math::pi_tag () 3.1415927410125732
I haven't looked at any assembler to check on efficiency, but believe/hope
from
previous examples that it will be optimal if inlined.
Does this look sensible/useful?
Only if I learn to see the relation to your latest upload (which I'm
assuming your review request is related to).
Best,
Joerg
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] threads and gcc and BSD
Don't know about other *BSD-s but GCC on OpenBSD GCC defines _POSIX_THREADS=1 when the -pthread is used. Here are the details... OK thanks, then I've disabled threading support in bsd.hpp when _POSIX_THREADS is not defined, let me know if this fixes things. Thanks, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
One is conversion to a pointer type: in this case you can have
a source expression of any integer type, but it must be constant
and have the value zero. Example:
int * p = '\0';
enum { e = 5 };
int (*pf)() = 4 % ( e - '\001');
If you use the indeterminate article a/an in the wording above
(an rvalue of type From) does it mean: all expressions of type
From or at least one expression of type From? Of course, to
exclude int-pointer-to-object convertibility one would say all
expressions, but I'm not sure whether this is ok for UDTs.
The other case is the deprecated conversion const char [N] - char*
which is valid only if the source expression is a string literal.
OK, both of those are special conversions of literals - I think we can
dismiss these by taking John Spicer's suggestion, and saying that the source
type is an lvalue of type From. (in other words is_convertible does not
detect those conversions).
- Another point that I would like to understand is where
convertibility is checked. Currently convertibility is checked in the
scope of is_convertible but is this the intent? This makes a
difference when you have e.g. a private conversion operator:
class X {
operator int(); // private
friend class Y;
};
class Y {
void f() {
is_convertibleX, int::value; // true or false??
// or error?
}
};
Now that one is just plain nasty :-( It's a similar problem to what happens
if the To type has a private constructor taking the From type, my gut
feeling is that both these cases have to be listed as undefined behaviour.
Clearly is_convertibleT,U::value must have a single value under the one
definition rule, so there can be no ambiguous context-sensitive answers.
Thanks for bringing these up, I'll try and produce some better wording over
the weekend, and then I'll see if you guys can shoot it down again :-)
John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
I think that is_convertible should be based as closely as possible on the definition in clause 4 of the standard. As has been pointed out, a problem with this is that the standard refers to a source expression, not a source type. I think this means that the definition of is_converible needs to say something like True if an lvalue of type From can be converted to type To according to 4p3 (or make it an rvalue, but you have to pick one). You could, of course, have two versions of is_convertible to handle both lvalues and rvalues. You're right, and I think that lvalue is the right choice, as it closely mirrors what the implementation does, as soon as you get into rvalues you end up with ambiguous answers due to things like the NULL pointer conversion (thanks to Genny for spotting that one). A few miscellaneous comments: - There are no expressions of reference type, so presumably a reference on the from type should be ignored (which it would based on a definition that used an expression having type From. I don't think we need to say that, although in practice any reference decoration will be ignored. Internally is_convertible will probably convert From to a reference so that it can handle abstract and function types. - There were several mentions of prohibiting abstract types. Expressions of abstract class type can be the source of an implicit conversion, however. Yes, they are only prohibited for the destination type. - There was a mention of special treatment of parameter types that are arrays. I don't think this is an issue as you are dealing with types and even if you declare a parameter of type X[], it has type X*. For function parameters yes, but 4.0 talks about initialisation, and in any case conversions take place in many contexts, not just function parameter passing, so: int a[2]; int b[2]; a = b; // invalid int[2] not convertible to int[2] I'm beginning to think that the only way to deal with this is to add array types to the list of types banned from the To parameter. Otherwise we get into the old context sensitive answer problem. Thanks, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: undo library
Ihsan Ali Al Darhi [EMAIL PROTECTED] schrieb im Newsbeitrag news:01d001c2c2ba$6af14ea0$73c721d4@h8p7o2... Can I use this library to implement multiple undo/redo in GUI applications under Windows? For example in a word processor. Yes you can. Even if the other suggested improvements of the library are left out (which might really be useful for a word-processor, especially the grouping of commands...) you can already use it. Let me give a small example: Usually you can mark text in a word processor. When typing a new key, you will certainly overwrite the selected text with the typed key (typical behaviour). Now what has to happen in this KeyPress function (probably an event)... 1. store the data in the selection - std::string 2. store the insert position (pos) and the length (len) of that string 3. create an undo-action for the insertion of the selected text and send it to the command manager (or add the undo-function via boost::bind() to the command manager's list) 4. remove text from whatever memo-field-like interface you are using 5. insert the char of the pressed key Well, what has to be in the undo-function? 1. store the char at position pos (that was the inserted char) 2. remove that char 3. insert the cut-out-string at position pos 4. select the inserted text and move the cursor at the end of that text (and scroll that text area into view) 5. signal the command manager, that you want him to store a redo-action for this That's it already. You see it's straight forward to implement this. Andreas PS: Maybe we should seperate the discussion for command manager issues and the way undo/redo-commands are represented. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] -lrt on Mandrake 9.0
trade. I've recently switched distributions to Mandrake 9.0, which comes with GCC 3.2 out of the box. When trying to compile Boost.Threads on this platform I encounter the following problem: What do you define as an out of the box install? MDK has many options. and you need to select the appropriate libraries from teh development section. Now for more useless information :-} /lib/libpthread.* and /lib/librt.* is in the glibc.rpm which will always be installed. For development you need to install the glibc-devel.rpm which will supply /usr/lib/libpthread* and /usr/lib/librt.*. This is more for consistency than anything else. /usr/lib/libpthread.so is simply a symlink to the one in /lib, and /usr/lib/librt.so is simply a linker stub which forces /lib/libpthread to be linked before /lib/librt.so. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Terje Slettebø [EMAIL PROTECTED] writes: From: Aleksey Gurtovoy [EMAIL PROTECTED] std::string text(text); mpl::for_each my_types (boost::bindvoid(my_function, text, _1)); I got error: no instance of function template boost::mpl::for_each matches the argument list, when trying this on Intel C++. Do you have a version of this that works? You need the one in the CVS, which I added recently. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] threads and gcc and BSD
From: John Maddock [EMAIL PROTECTED] Don't know about other *BSD-s but GCC on OpenBSD GCC defines _POSIX_THREADS=1 when the -pthread is used. Here are the details... OK thanks, then I've disabled threading support in bsd.hpp when _POSIX_THREADS is not defined, let me know if this fixes things. I think that a better solution would be to not define BOOST_HAS_THREADS unconditionally for GCC, and rely on _MT, _REENTRANT, _POSIX_THREADS. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] more is_convertible (and is_base_and_derived) corner cases
---BeginMessage---
Sergey P. Derevyago [EMAIL PROTECTED] wrote:
Is the following code well-formed?
---8---
#include stdio.h
struct B {};
struct D : private B {};
struct No {};
struct Yes { No no[2]; };
Yes Test(B*);
No Test(...);
int main()
{
printf(%d, sizeof(Test((D*)0))==sizeof(Yes));
}
---8---
It seems like it should not but some compilers don't agree.
You're right: This is an error. The first Test is selected
by overload resolution, but trying to bind (D*)0 to the
parameter results in an access error.
SFINAE doesn't come into play here.
Daveed
[ Send an empty e-mail to [EMAIL PROTECTED] for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
---End Message---
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
From: John Maddock [EMAIL PROTECTED] I'm beginning to think that the only way to deal with this is to add array types to the list of types banned from the To parameter. Otherwise we get into the old context sensitive answer problem. I think that no special ban list is necessary. Given the specification Returns true if and only if an lvalue of type From is convertible to To (4p3) the implication is that is_convertible should return false when To is an array type, as typedef int T[2]; T t(e); is not allowed for any e. A similar argument holds for To being abstract or function type. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [BGL] MutablePropertyGraph questions
Hi Volodya, On Tue, 10 Dec 2002, Vladimir Prus wrote: ghost Looking at BGL's MutablePropertyGraph docs I can't understand ghost two things: ghost ghost ep is an object of type G::edge_property_type ghost ghost Is that really so? Why not graph_traitsG::edge_property_type? Actually, I think it really should be edge_propertyG::type and vertex_propertyG::type. Also MutablePropertyGraph should be split into VertexMutablePropertyGraph and EdgeMutablePropertyGraph. The BGL book is more up-to-date than the online-docs, so I'd look there for the final story. If you see discrepencies between the online-docs and the book, feel free to update the html to match the book. ghost Unfortunately, this description says nothing about that concept ghost these types model. As the result, I don't know how can I ghost use 'add_edge' and 'add_vertex' as defined in MutablePropertyGraph. ghost ghost Can it be clarified? Yes, that is a problem. We need some more concepts for this. If you're dealing with an adjacency_list you know that they are nested instances of the property class, but this doesn't help generic code. I'm not sure how this could be made generic... maybe if we hade a concept that covered what the property class does (BTW, a better name for the property class would be static_alist). Also, it would be good to have a notion of what copying these objects does. Any help on solving the above problems would be welcomed! Cheers, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: math constant - generic function circle_area example.
There is a description of this in the math constants updated docs
http://groups.yahoo.com/group/boost/files/MathConstants/Math_Constants_doc_3.zip
and within the code zip
http://groups.yahoo.com/group/boost/files/MathConstants/Math_constants3.zip
there are function_constants.hpp and a testfunction_constants.cpp file
I have simply used these to provide the code I posted. And I am still offering
this code (devised by Michael Kenniston) as a possible way of presenting math
constants. (Ultimately of course, it is the value int MACRO file that is the
real source - even if not used directly, I propose to generate both files form
the same program using NTL).
Your views are most welcome because I feel that it is practical usefulness that
is the major factor in presenting these definitively accurate values.
It looks OK to me (but it needs to compile on the major platforms - I only have
MSVC 7 available, and now discount MSVC 6 because of the need for a dummy type
argument which is unacceptbaly messy for this purpose).
Paul
Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK
+44 1539 561830 Mobile +44 7714 33 02 04
Mobile mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Joerg Walter
Sent: Friday, January 24, 2003 12:27 AM
To: Boost mailing list
Subject: Re: [boost] RE: math constant - generic function circle_area
example.
Hi Paul,
you wrote:
I've been looking into an earlier version of the proposed math constants
before and asked myself how to implement a generic function like
templateclass T
T circle_area (const T radius) {
return math_constantsT::pi * radius * radius;
}
How should this be done?
Thanks,
Joerg
Attached is an example using Michael Kenniston's Kunning Function
constants.
Briefly
template typename T
T circle_area(const T radius)
{
// Usage example: circle_areadouble( 2.) // Explicit type double.
// or circle_area(2.F) // Implicit type float.
return boost::math::constant T, boost::math::pi_tag () * radius *
radius;
}
OK. I've tried to compile this with GCC 3.2.1 and after applying some
remedies like
for example
#ifdef LATER
// Define constant is namespaces to hold three builtin floating-point
representations.
namespace float_constants
{
constant float, pi_tag const pi;
}
namespace double_constants
{
constant double, pi_tag const pi;
}
namespace long_double_constants
{
constant long double, pi_tag const pi;
}
#endif
/for example
it compiled and executed giving the expected results. How is this solution
related to your latest (Dec. 12) upload at groups.yahoo.com/group/boost?
It compiles with MSVC 7.0 (but not 6 - see MK's original example for why
not).
(long double == double for MSVC, so long double not fully
testable/useful).
It seems to do the trick, without too many surprises. I have displayed
the
output using the 17 significant digits for double so one can see the
difference
between a float pi 3.1415927410125732 and a double pi 3.1415926535897931
(even
though only 9 are really significant for float).
cout circle_areafloat(1.) =circle_areafloat(1.) endl; //
Explicit type float.
cout circle_areadouble(1.) =circle_areadouble(1.) endl;
//
Explicit type double.
cout circle_area(1.F) =circle_area(1.F) endl; // Implicit
type
float.
cout circle_area(1.) =circle_area(1.) endl; // Implicit type
double.
cout circle_area(1.L) =circle_area(1.L) endl; // implicit
type
long double.
cout circle_areadouble(1.F) =circle_areadouble(1.F)
endl; //
Explicit over-rides implicit.
And silly types like int fail helpfully.
// cout circle_area(1) =circle_area(1) endl; // Implicit
int -
does not link!
// cout circle_areaint(1.) =circle_areaint(1.) endl; //
Explicit int - does not compile!
Output is
Test test_circle_area.cpp Thu Jan 23 00:06:28 2003
float pi = 3.14159274
double pi = 3.1415926535897931
float pi = 3.1415927410125732
circle_areafloat(1.) = 3.1415927410125732
circle_areadouble(1.) = 3.1415926535897931
circle_area(1.F) = 3.1415927410125732
circle_area(1.) = 3.1415926535897931
circle_area(1.L) = 3.1415926535897931
circle_areadouble(1.F) = 3.1415926535897931
circle_arealong double(1.) = 3.1415926535897931
circle_areafloat(2.) = 12.566370964050293
circle_areadouble(2.) = 12.566370614359172
circle_area(2.F) = 12.566370964050293
circle_area(2.) = 12.566370614359172
circle_area(2.L) = 12.566370614359172
circle_areadouble(2.F) = 12.566370614359172
boost::math::constant float, boost::math::pi_tag () 3.1415927410125732
I haven't looked at any assembler to check on efficiency, but believe/hope
from
previous examples that it will be optimal if inlined.
Does this look sensible/useful?
Only if I
Re: [boost] BGL: concept docs buglets
Hi Volodya, On Sun, 5 Jan 2003, Vladimir Prus wrote: ghost ghost I think that BGL concept docs are a little bit out of sync with ghost the concept cheking code. I've corrected some of problems and ghost attach a patch. Is it OK to apply it? Yes, those corrections look fine. ghost Another issue is that doc talk about MutablePropertyGraphConcept, ghost while code has LvaluePropertyGraphConcept. I'm not sure which one ghost is correct. Looks like the stuff in the code is correct and the docs are out of date. Cheers, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL bug in examine_edge(...) indijkstra_shortest_paths.hpp?
Hi Duncan, Sorry for the lagged reply. I think the problem is in the value used for zero in file_dependencies.cpp. Since we are using for comparison, I think zero should be std::numeric_limitsint::max() instead of 0. Cheers, Jeremy On Sun, 22 Dec 2002, Duncan Clarke wrote: duncan I downloaded the 1_29_0 version of Boost, compiled the file_dependencies.cpp duncan example, and when I run it, the sample program aborts after throwing duncan negative_edge in examine_edges(...) (from dijkstra_shortest_paths.cpp). duncan duncan After a little investigation, it looks to me like examine_edges(...) is duncan supposed to protect against negative edge weights. It does so by calling duncan the user-supplied comparison function to test each edge to make sure its duncan weight is greater than the user-supplied zero value. But the call in duncan examine_edges(...) is coded so that if (EdgeWeight ? 0) then throw duncan negative_edge(), where the example program uses the operator for ?. duncan Seems to me that those parameters are presented in the wrong order. duncan duncan I downloaded Boost 1_28_0 and the example compiled and ran without problems. duncan A quick diff showed that the code to test for negative edge weights is new duncan in BGL 1_29_0. duncan duncan So... is it a feature or a bug? duncan duncan I checked through all the boost newsgroups and couldn't find anything about duncan this, but I'm new to Boost, so forgive me (and point me to the resolution) duncan if this is a known problem. duncan duncan Thanks, duncan duncan Duncan Clarke duncan Computer Science and Engineering duncan University of South Carolina duncan duncan duncan -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BGL: random_access_iterator_property_map missing?
That's right. The name changed. Sorry! On Sat, 4 Jan 2003, Douglas Gregor wrote: gregod On Saturday 04 January 2003 11:53 am, Vladimir Prus wrote: gregod I was just going to use the class named in the subject. Unfortunately, gregod it can't be found anywhere. Here what grep on an up-to-date CVS tree gives: gregod gregod You probably want iterator_property_map, which takes a RandomAccessIterator gregod and is used throughout the BGL. Maybe it was once called gregod random_access_iterator_property_map? gregod gregod Doug gregod gregod gregod ___ gregod Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost gregod -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: BGL: more doc buglets
Hi Volodya, On Sun, 5 Jan 2003, Vladimir Prus wrote: ghost ghost I've come across more problems with documentation. ghost ghost 1. The docs for topological_sort say that if (u,v) edge is present, ghost then u comes before v in the topological order. I was assuming ghost that if I store the order in vector, then u will be found before ghost v. Instead, the order is reversed! This can only be learned from ghost the example at the botton -- which is the last place to look at. Yes. ghost 2. The example for the same function is wrong. The graph has a ghost 5 - 5 edge and is not DAG. libs/graph/example/topo_sort.cpp ghost fails for that reason. Right. ghost 3. Docs the the same function say that the default value of i_map ghost parameter is get(vertex_index, g). Unless I'm missing something, ghost this should be get(vertex_index_t(), g). No, I think vertex_index is fine. vertex_index_t is an enum with one value in it, namely vertex_index. See properties.hpp. ghost 4. The docs for the write_graphviz function do not mention the ghost default_writer class. I believe they should --- it's important ghost when one want to output onle edge properties. Yes. ghost 5. libs/graph/doc/PropertyGraph.html says: ghost ghost boost::property_mapG, PropertyTag::type ghost The type of the property map for the property specified by PropertyTag. ghost This type must be a model of ReadWritePropertyMap with a key type the same ghost as the graph's vertex or () descriptor type. ghost ghost edge is missing in the marked position. Right. ghost 6. I did not see anywhere the stament that property map obtained from ghost PropertyGraph are actually a kind of references into the internal ghost property map. I can conjecure this is so, but a clean statement would ghost we better. Sure. ghost It would be nice to fix those problem. In fact, I can fix most of them ghost myself, if Jeremy doesn't mind. Thanks for all these fixes! Please go ahead and check them in. Regards, Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] -lrt on Mandrake 9.0
John Maddock said: Sorry for this slightly off topic question, but I'm not a Linux user by trade. I've recently switched distributions to Mandrake 9.0, which comes with GCC 3.2 out of the box. When trying to compile Boost.Threads on this platform I encounter the following problem: Good question, every linux box I've encountered up until now has had -lrt (I thought this was part of glibc ?), and it's normally required for linking the thread lib (all the sched_* functions are in there). I got help from Alkis Evlogimenos off list, and the problem is solved. Mandrake seperates out runtime from development, and so only the runtime for glibc was installed by default. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL usage for code generation
Hugo Duncan wrote:
Including for_each.hpp on bcc561 gives
Error E2230
c:\usr\boost\boost/mpl/aux_/preprocessed/bcc/template_arity.hp
p 20: In-line data member initialization requires an integral
constant expression
Any chance of finding a fix for this? I am having problems
working through the code to see what to change.
Hmm, seem to work for me on 5.6 (__BORLANDC__ == 0x560):
Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland
F:\cvs_main8\boost\libs\mpl\test\for_each.cpp:
Warning W8012 F:\cvs_main8\boost\libs\mpl\test\for_each.cpp 82: Comparing
signed and unsigned values in function main()
I don't have access to 5.6.1, so I would need some cooperation to fix it.
Off the top of my head, can you please check if changing the offending line
from
static int const value = F::arity;
to
enum { value = F::arity };
helps at all? If it doesn't, how about the one below?
static int const value = BOOST_MPL_AUX_MSVC_VALUE_WKND(F)::arity;
(you'll need to include boost/mpl/aux_/value_wknd.hpp for that).
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL::void_t
Joel de Guzman wrote: Hi, Hi Joel, Question why is mpl::void_t an incomplete type? I suppose we are talking about 'mpl::void_'. Since we have a use case for it now, just go ahead and make it complete! (A short comment would be nice, too :). Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Deadline for the Standard Library Technical Report
The deadline for submissions of full proposals for C++ Standard Library Technical Report is the committee meeting April 7-11 in Oxford, UK. A full proposal must include proposed wording for the actual standardese to go in the TR, as well as the usual supporting material. (Note that the committee may not act on the proposal right away, or may request revisions to the wording.) If the committee sticks to its current schedule, any library proposal which doesn't make the April deadline will suffer a delay of at least two years. If anyone needs help getting a proposal ready, let me know privately. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Review results: Optional library
I've finally updated my Cygwin installation, so I was able to run bjam with gcc and experiment with the optional's Jamfile. The just committed Optional's test suite now includes failure cases. -- Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL usage for code generation
Joel de Guzman wrote:
Here's the Phoenix version:
struct my_function_
{
template typename Arg1T, typename Arg2T
struct result { typedef void type; };
template typename U
void operator()(std::string const text, U)
{
// ...
}
};
functionmy_function_ my_function; // here!
Then:
mpl::for_each my_types (my_function(text, _1));
This is way too cool! Now we only need to provide such free-standing forms
of all STL algorithms/member functions, and we will be living in a different
world:
std::vectorstd::string v;
push_back(v, text); // plain call
for_each(input, push_back(v, _1)); // currying
for_each(v, for_each(_1, print_char)); // more currying
// etc.!
Breathtaking, IMO.
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: Re: MPL usage for code generation
On Fri, 24 Jan 2003 09:17:00 -0600, Aleksey Gurtovoy [EMAIL PROTECTED] wrote:
I don't have access to 5.6.1, so I would need some cooperation to fix it.
5.6.1 is 5.6 with patch 2 applied. I *think* this is the same as kylix compiler,
though I haven't run the latter.
Off the top of my head, can you please check if changing the offending line
from
static int const value = F::arity;
to
enum { value = F::arity };
helps at all?
Making this change allows test/for_each.cpp to run correctly
Hugo
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
From: Aleksey Gurtovoy [EMAIL PROTECTED] Joel de Guzman wrote: mpl::for_each my_types (my_function(text, _1)); This is way too cool! Now we only need to provide such free-standing forms of all STL algorithms/member functions, and we will be living in a different world: std::vectorstd::string v; push_back(v, text); // plain call for_each(input, push_back(v, _1)); // currying Almost... all such uses are ambiguous. push_back(v, text) can be a plain call or bind(push_back, v, text). push_back(v, _1) could - at least in theory - also be a plain call. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BOOST_WORKAROUND question
What would be an equivalent of the following #fief, if I want to re-writte it using our new BOOST_WORKAROUND macro? // last checked with 0x561 #if defined(__BORLANDC__) __BORLANDC__ = 0x561 !defined(BOOST_STRICT_CONFIG) Here, 0x561 is the first version requiring the workaround and at the same time the last checked version (so, ideally, I would like to be able to check if it's outdated). Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problem with regression tests
At 07:04 AM 1/24/2003, John Maddock wrote: I have now run the regression tests on a Cray SV1 but it seems there is still a problem in the postprocessing stage. I get output like: I would expect to see that if you haven't filtered the bjam output through process_jam_log, double check your bin/ directory to see what output files have been generated for each target. Good advice. Also, it is a lot easier to get started if you limit initial testing to one simple test. I like to use config_info because its output helps you verify that there aren't serious configuration problems. Try running one step at a time, inspecting important outputs. * stdout and stderr from the bjam run. * The test_log.xml file output from process_jam_log. * The table files output from compiler_status. HTH, --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Re: MPL usage for code generation
Hugo Duncan wrote:
On Fri, 24 Jan 2003 09:17:00 -0600, Aleksey Gurtovoy
[EMAIL PROTECTED] wrote:
I don't have access to 5.6.1, so I would need some cooperation to
fix it.
5.6.1 is 5.6 with patch 2 applied.
Yeah, only the patch cannot be applied to an evaluation version of the
compiler (on Windows, anyway).
Off the top of my head, can you please check if changing the
offending line from
static int const value = F::arity;
to
enum { value = F::arity };
helps at all?
Making this change allows test/for_each.cpp to run correctly
Good, thank you. Fixed in the CVS now - please check if it works and report
back.
Aleksey
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] BOOST_WORKAROUND question
Aleksey Gurtovoy [EMAIL PROTECTED] writes: What would be an equivalent of the following #fief, if I want to re-writte it using our new BOOST_WORKAROUND macro? // last checked with 0x561 #if defined(__BORLANDC__) __BORLANDC__ = 0x561 !defined(BOOST_STRICT_CONFIG) Here, 0x561 is the first version requiring the workaround and at the same time the last checked version (so, ideally, I would like to be able to check if it's outdated). Here are three ways to spell it: #if BOOST_WORKAROUND(__BORLANDC__, = 0x561) \ BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x561)) #if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT(0x561) __BORLANDC__ = 0x561) #if __BORLANDC__ = 0x561 \ BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x561)) I kinda like the last one. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RE: RE: Re: MPL usage for code generation
On Fri, 24 Jan 2003 10:44:58 -0600, Aleksey Gurtovoy [EMAIL PROTECTED] wrote: Good, thank you. Fixed in the CVS now - please check if it works and report back. Aleksey, Thanks! Works. Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: undo library
Ihsan Ali Al Darhi [EMAIL PROTECTED] wrote in message 01d001c2c2ba$6af14ea0$73c721d4@h8p7o2">news:01d001c2c2ba$6af14ea0$73c721d4@h8p7o2... Can I use this library to implement multiple undo/redo in GUI applications under Windows? For example in a word processor. Undo/redo is generic mechanism that can be used for whatever purpose. Undo/redo in wordprocessors/graphics editors is the most common case. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Integrating BoostBook documentation with HTMLdocumentation
Douglas Gregor [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... -- Footer should have a revised date. I like the horizon rule, too. A generated date would be easy; a revised date isn't so easy, because it's not trivial to figure out when something used in the list changed. How 'bout a separate build step which just scans the doc source directory tree and builds an XML file of filenames modification dates. Then that file could be used to include revision dates in the docs. -- Truth, James Curran www.noveltheory.com (personal) www.njtheater.com (professional) ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Integrating BoostBook documentation with HTMLdocumentation
On Fri, 24 Jan 2003, James Curran wrote: Douglas Gregor [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... -- Footer should have a revised date. I like the horizon rule, too. A generated date would be easy; a revised date isn't so easy, because it's not trivial to figure out when something used in the list changed. How 'bout a separate build step which just scans the doc source directory tree and builds an XML file of filenames modification dates. Then that file could be used to include revision dates in the docs. Adding another build step makes me nervous. As it is, BoostBook already requires an additional tool (an XSLT processor), and if we make the build process any more complicated we will harm the chances of BoostBook adoption. [We should move this discussion over to the boost-docs list exclusively] Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_convertible corner case
On Fri, 24 Jan 2003 12:35:27 -, John Maddock
[EMAIL PROTECTED] wrote:
One is conversion to a pointer type: [..]
The other case is the deprecated conversion const char [N] - char*
which is valid only if the source expression is a string literal.
OK, both of those are special conversions of literals - I think we can
dismiss these by taking John Spicer's suggestion, and saying that the source
type is an lvalue of type From. (in other words is_convertible does not
detect those conversions).
A string literal (narrow or wide) is an lvalue.
- Another point that I would like to understand is where
convertibility is checked. Currently convertibility is checked in the
scope of is_convertible but is this the intent? This makes a
difference when you have e.g. a private conversion operator:
class X {
operator int(); // private
friend class Y;
};
class Y {
void f() {
is_convertibleX, int::value; // true or false??
// or error?
}
};
Now that one is just plain nasty :-(
Sorry. That wasn't my intention. It's just that I take the issue
seriously (as you certainly do as well). I know, it is unpleasant to
discover complications in something that seemed so simple and elegant,
but we must do it. Better discovering problems now than late, don't
you think?
It's a similar problem to what happens
if the To type has a private constructor taking the From type, my gut
feeling is that both these cases have to be listed as undefined behaviour.
Ouch, no. You will never find me agreeing on this point. This seems
along the lines of if I can't get it work, then it's undefined
behavior which is a habit we should all get out of. As Paul
Mensonides wrote me (Paul, I hope you don't mind the quotation), UB is
reasonable e.g. when diagnosing the situation is impractical (for the
compiler), or when platform differences make it difficult to choose a
single specification without penalizing some of them, not when just we
don't know what to do. In this case, I'm under the impression we are
trying to implement something within the existing language that should
actually be a built-in operator. I think the question is: do we need
is_convertible for generic programming? If so, can it be implemented
in current C++? No? Then make it an operator. I appreciate the
philosophy of C++ of avoiding putting in the core language what can be
implemented in the library but, hey, if it can't then you can't! :-)
Maybe half-ways between a built-in is_convertible operator and a
library implementation are possible: e.g. you could have two
non-member template functions:
namespace std {
typedef char (no_type)[1];
typedef char (yes_type)[2];
template typename T
struct identity { typedef T type; };
template typename To
no_type is_convertible(...);
template typename To
yes_type is_convertible(typename identityTo::type);
}
This is already a useful facility to check convertibility of
expressions. Once you have it, you can use it for types too as long as
you have an operator that, given a type, gives you the expression to
pass to std::is_convertible
std::is_convertibleTo ( expression(From) )
That's just a rough idea, of course.
Also, it would be nice to have, as syntactic sugar, a shortcut for
testing sizeof(std::is_convertible...) against sizeof(no_type) and
sizeof(yes_type), e.g.:
is_true ( std::is_convertible(char) (expression(int)) )
But then you already have two new operators (ok, is_true isn't
strictly necessary, and could be a macro ;-)), so why not making
is_convertible an operator instead? It remains however that is_true
would be handy in itself, and that I would like no_type and yes_type
to be standardized.
Clearly is_convertibleT,U::value must have a single value under the one
definition rule, so there can be no ambiguous context-sensitive answers.
Thanks for bringing these up, I'll try and produce some better wording over
the weekend, and then I'll see if you guys can shoot it down again :-)
Well, as I said the intent was quite the contrary than being
destructive. I'll look forward for the new wording :-)
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost.threads: Thread pool
Hello! Any chance of an additon of David Moores thread pool implementation to boost.threads to the next release or another implementation of some kind of thread pool concept. Also some kind of alarm or timer would be useful. Or how does the priority and wishlish for boost.threads look like. I guess cancellation is at the top but it may be the hardest nut to crack of them all. /Michel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A question about static_log2
Gennaro Prota: Vesa Karvonen: Gennaro Prota: Vesa, I really appreciate your attempt but your code assumes the required number to be a power of two (it just tries 32, 64, 128, etc.). What about 48 bits unsigned long?[...] If unsigned long has 48 bits, then an n of 32 would be chosen. And then you are not able to calculate log2 for numbers in the range [2**32, 2**48-1[ (at least). The algorithm calculates log2 correctly even for those numbers. The invariant of the core algorithm is that at the start of each recursion 1 = x xn 1uln. Regards, Vesa Karvonen _ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MPL include problem with BOOST_PP_ITERATE
I think I have found a problem with boost/mpl/list.hpp I am including files using BOOST_PP_ITERATE. One of the files that I include happens itself to include boost/mpl/list.hpp. boost/mpl/list.hpp begins #if !defined(BOOST_PP_IS_ITERATING) / header body #ifndef BOOST_MPL_LIST_HPP_INCLUDED #define BOOST_MPL_LIST_HPP_INCLUDED Because I am using BOOST_PP_ITERATE, BOOST_PP_IS_ITERATING is defined, and problems occur. I assume BOOST_PP_IS_ITERATING is checked for logic associated with preprocessed file generation. Is it possible to combine the check with a library macro that is defined when preprocessed files are generated ? Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost.threads: Thread pool
Michel André said: Hello! Any chance of an additon of David Moores thread pool implementation to boost.threads to the next release or another implementation of some kind of thread pool concept. Depends on the time frame of the next release and how fast I can finish my work on the library. If it's not in 1.30.0, it will be in 1.31.0. In the mean time, if it's important enough to you, you can track the work in progress in the thread_dev branch in CVS. Also some kind of alarm or timer would be useful. Not something in the todo hopper. Can you give a more concrete explanation of what you want, and why you think it's important for inclusion. Or how does the priority and wishlish for boost.threads look like. Right now, most of the work is being done on boost::thread itself. This includes a reference-counted implementation instead of a non-copyable implementation, the addition of attributes such as stack size/address and priority scheduling and the addition of cancellation. I'm getting close to completion of the design/implementation and will be asking for a peer review soon. Other things on the list: * Final integration of Dave Moore's classes, including thread_pool, rw_mutex and barrier. * Addition of some synchronization helper constructs, both intrusive and non. I've got general ideas and goals for this, but nothing concrete to share yet. * Addition of attibutes for other classes, such as process shared for mutex, condition, etc. All POSIX attributes will be included. * Addition of shared memory constructs. I guess cancellation is at the top but it may be the hardest nut to crack of them all. Definately going to be difficult to implement this the way we want, though the design is simple at this point. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
- Original Message - From: Gennaro Prota [EMAIL PROTECTED] It's a similar problem to what happens if the To type has a private constructor taking the From type, my gut feeling is that both these cases have to be listed as undefined behaviour. Ouch, no. You will never find me agreeing on this point. This seems along the lines of if I can't get it work, then it's undefined behavior which is a habit we should all get out of. As Paul Mensonides wrote me (Paul, I hope you don't mind the quotation), UB is reasonable e.g. when diagnosing the situation is impractical (for the compiler), or when platform differences make it difficult to choose a single specification without penalizing some of them, not when just we don't know what to do. (I don't think that he means undefined behavior as far as the compiler is concerned, but I haven't been following this thread closely so I might be wrong.) At some point, especially with things of this nature, you have to say this is valid input, and who knows what happens if you pass something else. This is especially the case when these type of traits templates are hacked up to make them work on various compilers--which makes it difficult to list invalid input. The most important issue is whether you can handle the most common and most useful cases. You can, of course, make a documented list of all things that are valid input and maybe as many things that you can think of that aren't for a strictly conforming compiler. You can also try to handle border case situations like this one if at all possible, but you can't always guarantee in the documentation that the border cases will always work with every compiler. I do, however, agree that we need more support from the language for generic programming and some type of standardized API into the compiler's type system. And I definitely think that undefined behavior is unreasonable when the situation is easily diagnosable and not platform specific. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A question about static_log2
On Fri, 24 Jan 2003 22:23:53 +0200, Vesa Karvonen [EMAIL PROTECTED] wrote: Gennaro Prota: Vesa Karvonen: Gennaro Prota: Vesa, I really appreciate your attempt but your code assumes the required number to be a power of two (it just tries 32, 64, 128, etc.). What about 48 bits unsigned long?[...] If unsigned long has 48 bits, then an n of 32 would be chosen. And then you are not able to calculate log2 for numbers in the range [2**32, 2**48-1[ (at least). The algorithm calculates log2 correctly even for those numbers. The invariant of the core algorithm is that at the start of each recursion 1 = x xn 1uln. Maybe you are confusing the value, let's call it w, calculated by choose_n with the default value used for parameter n (which is w/2 or (w+1)/2)? If unsigned long has 48 value bits your choose_n template gives 32 but then you start with n = 16! This means you can, at most, calculate a logarithm = 31 (i.e. the log of 2**32 - 1). Am I missing something? Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Deadline for the Standard Library Technical Report
Just out of curiosity, which boost libraries are likely to be proposed to the committee? On Fri, 24 Jan 2003 10:43:28 -0500, Beman Dawes wrote: The deadline for submissions of full proposals for C++ Standard Library Technical Report is the committee meeting April 7-11 in Oxford, UK. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Review results: Optional library
From: Beman Dawes [EMAIL PROTECTED] I've run the Win32 tests again, so you can see the new results. One thing that I notice is that tests that are no longer in the Jamfile are kept in the table; for example, enable_shared_from_this_test.cpp is still there, even though I've renamed it (the name was 31 chars.) The bind/mem_fn tests are listed twice, too - I've moved them to a test subdirectory with a subincluded Jamfile. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
--- Paul Mensonides [EMAIL PROTECTED] wrote: (I don't think that he means undefined behavior as far as the compiler is concerned, but I haven't been following this thread closely so I might be wrong.) [..]You can also try to handle border case situations like this one if at all possible, but you can't always guarantee in the documentation that the border cases will always work with every compiler. But John was referring to his ISO proposal, not to the boost code. Actually I did think the proposal required support on the compiler part (I haven't read it), but it seems that it is intended to be implementable as pure C++ code instead. I would go reading it, but John has announced a new version so I think its better waiting for that and forget about the old one. Genny. __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MPL include problem with BOOST_PP_ITERATE
- Original Message - From: Hugo Duncan [EMAIL PROTECTED] I think I have found a problem with boost/mpl/list.hpp I am including files using BOOST_PP_ITERATE. One of the files that I include happens itself to include boost/mpl/list.hpp. I'm not sure what you mean here. If you are iterating over a file (or section of a file) with the file-iteration mechanism. That iterated text should *never* include regular headers. E.g. if '1.hpp' uses the iteration mechanism to iterate over '2.hpp', and '2.hpp' needs the facilities from some other file (like iostream or anything else at all), '1.hpp' can include them, *not* '2.hpp'. If you want to separate concerns as much as possible, you can reference the iterated file as a normal header so it can include other facilities that are needed: // 1.hpp #ifndef ONE_HPP #define ONE_HPP #include boost/preprocessor/iteration/iterate.hpp #include 2.hpp // normal inclusion #define BOOST_PP_ITERATION_PARAMS_1 \ (3, (1, 10, 2.hpp)) \ /**/ ??=include BOOST_PP_ITERATE() // not normal at all! #endif // EOF -- // 2.hpp #if !BOOST_PP_IS_ITERATING // as normal header #ifndef TWO_HPP #define TWO_HPP #include iostream #include boost/preprocessor/repetition/repeat.hpp // etc. #endif // TWO_HPP #else // not normal at all! // use iostream and ../repeat.hpp facilities... #endif boost/mpl/list.hpp begins #if !defined(BOOST_PP_IS_ITERATING) / header body #ifndef BOOST_MPL_LIST_HPP_INCLUDED #define BOOST_MPL_LIST_HPP_INCLUDED Because I am using BOOST_PP_ITERATE, BOOST_PP_IS_ITERATING is defined, and problems occur. I assume BOOST_PP_IS_ITERATING is checked for logic associated with preprocessed file generation. It is defined when the file-iteration mechanism is iterating over a file. Its purpose is to distinguish between a normal inclusion and an iteration inclusion so that the same file can iterate over itself. When a file that is iterated includes other files *during an iteration*, BOOST_PP_IS_ITERATING is still defined and the other files probably won't know how to handle it. (boost/mpl/list.hpp is one example of this.) The solution is simply to not include any files during a particular iteration. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Deadline for the Standard Library Technical Report
On Fri, 24 Jan 2003 10:43:28 -0500, Beman Dawes [EMAIL PROTECTED] wrote: A full proposal must include proposed wording for the actual standardese to go in the TR, as well as the usual supporting material. (Note that the committee may not act on the proposal right away, or may request revisions to the wording.) If the committee requests a revision to the wording, does the library miss the deadline or is it considered presented in time anyway? If the committee sticks to its current schedule, any library proposal which doesn't make the April deadline will suffer a delay of at least two years. Is there any danger than then no other deadlines are set in the future because the committee runs out of time? Or is it obligatory that many sessions are set during the standardization path? Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL include problem with BOOST_PP_ITERATE
On Fri, 24 Jan 2003 13:53:00 -0800, Paul Mensonides [EMAIL PROTECTED] wrote: - Original Message - From: Hugo Duncan [EMAIL PROTECTED] I am including files using BOOST_PP_ITERATE. One of the files that I include happens itself to include boost/mpl/list.hpp. I'm not sure what you mean here. If you are iterating over a file (or section of a file) with the file-iteration mechanism. That iterated text should *never* include regular headers. Paul, I was not aware of that restriction - it doesn't seem to be mentioned in the docs. [Snipped example] It is defined when the file-iteration mechanism is iterating over a file. Its purpose is to distinguish between a normal inclusion and an iteration inclusion so that the same file can iterate over itself. When a file that is iterated includes other files *during an iteration*, BOOST_PP_IS_ITERATING is still defined and the other files probably won't know how to handle it. (boost/mpl/list.hpp is one example of this.) The solution is simply to not include any files during a particular iteration. This, for me, is a nuisance, as the files that I am including through ITERATE are included individualy at times, and could add header dependencies that I do not know about elsewhere. The reason for my using ITERATE is to be able to provide an extensible list of files to include as a single extension/maintenance point for my library, so having to write 2.hpp reduces the incentive to use ITERATE in the first place. I still think that this could be solved by checking something like the following in boost/mpl/list.hpp #if !BOOST_PP_IS_ITERATING || !BOOST_MPL_PREPROCESSING_MODE Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MPL include problem with BOOST_PP_ITERATE
Hugo Duncan [EMAIL PROTECTED] writes: I think I have found a problem with boost/mpl/list.hpp I am including files using BOOST_PP_ITERATE. One of the files that I include happens itself to include boost/mpl/list.hpp. Normally you shouldn't be making general #includes inside a vertical iteration loop. Why don't you just hoist the include of boost/mpl/list.hpp? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] is_abstract_baseT ?
Is there such a thing as is_abstract_baseT similar to is_polymorphicT ? Is such a thing possible? I could use it but have been unable to figrure out how to do it. Robert Ramey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL include problem with BOOST_PP_ITERATE
On Fri, 24 Jan 2003 17:01:21 -0500, David Abrahams [EMAIL PROTECTED] wrote: Hugo Duncan [EMAIL PROTECTED] writes: I think I have found a problem with boost/mpl/list.hpp I am including files using BOOST_PP_ITERATE. One of the files that I include happens itself to include boost/mpl/list.hpp. Normally you shouldn't be making general #includes inside a vertical iteration loop. Why don't you just hoist the include of boost/mpl/list.hpp? Maybe my use of ITERATE is slightly different, in that I am using it to include a LIST of files. The LIST provides a single integration point. Hoisting all the includes reduces the utility of using ITERATE. I can hoist the include of boost/mpl/list.hpp (and have done so for the moment), but I don't think that I should have to. The way I look at it, the fact that MPL uses ITERATE in its header files is an implementation convenience for MPL, and should not be visible to the user. But that's just my opinion, and I may have misunderstood how MPL is using ITERATE, and/or the purpose of ITERATE. Hugo ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL include problem with BOOST_PP_ITERATE
Hugo Duncan wrote: I think I have found a problem with boost/mpl/list.hpp I am including files using BOOST_PP_ITERATE. One of the files that I include happens itself to include boost/mpl/list.hpp. boost/mpl/list.hpp begins #if !defined(BOOST_PP_IS_ITERATING) / header body #ifndef BOOST_MPL_LIST_HPP_INCLUDED #define BOOST_MPL_LIST_HPP_INCLUDED Because I am using BOOST_PP_ITERATE, BOOST_PP_IS_ITERATING is defined, and problems occur. In general, you shouldn't include any headers _inside file iteration section_ of your header - there is just no point of doing this (and, for normal headers, no effect, expect for possible performance degradation), unless you are doing something pretty special. If you move the boost/mpl/list.hpp include from the section being iterated to a static part of the header, everything should work fine. If it doesn't please post an example of the code that causes troubles for you. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL include problem with BOOST_PP_ITERATE
Hugo Duncan wrote: Maybe my use of ITERATE is slightly different, in that I am using it to include a LIST of files. The LIST provides a single integration point. Hoisting all the includes reduces the utility of using ITERATE. OK, I see the problem now. I can hoist the include of boost/mpl/list.hpp (and have done so for the moment), but I don't think that I should have to. The way I look at it, the fact that MPL uses ITERATE in its header files is an implementation convenience for MPL, and should not be visible to the user. You have a point, here. I'll look into the issue tonight. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL include problem with BOOST_PP_ITERATE
Usage may be clearer with some code leaving out pp includes. The file models/Furnace.h includes boost/mpl/list.hpp IncludeAllModels.h #define SUBCLASS_LIST \ BOOST_PP_TUPLE_TO_LIST( \ 3, \ ( \ Slitter, \ Scalper, \ Furnace \ ) \ ) \ // List of all models #define FILE_SUFFIX .h #define FILE_PATH models/ #define LIST SUBCLASS_LIST #include ComputedInclude.h ComputedInclude.h #define LIST_SIZE BOOST_PP_LIST_SIZE (LIST) #define ITER_SIZE BOOST_PP_DEC (LIST_SIZE) #define BOOST_PP_ITERATION_LIMITS (0, ITER_SIZE) #define BOOST_PP_FILENAME_1 ComputedIncludeIteration.h #define HARPS_CI 1 #include BOOST_PP_ITERATE() #undef HARPS_CI ComputedIncludeIteration.h #define ITER BOOST_PP_ITERATION() #define THIS_ITEM BOOST_PP_LIST_AT ( LIST, ITER) #define FILE_NAME BOOST_PP_CAT (THIS_ITEM, FILE_SUFFIX) #define FULL_NAME BOOST_PP_CAT (FILE_PATH, FILE_NAME) #define FN BOOST_PP_STRINGIZE (FULL_NAME) #include FN ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
Paul Mensonides [EMAIL PROTECTED] writes: I do, however, agree that we need more support from the language for generic programming and some type of standardized API into the compiler's type system. And I definitely think that undefined behavior is unreasonable when the situation is easily diagnosable and not platform specific. I tend to agree on a moral/aesthetic level, but on a practical level we have to tread carefully. The question, can we just have an operator which produces a compile-time constant value saying whether its operand is a valid expression? has come up a few times in the committee. Each time, the implementors looked at their codebases and said oooh, that's really hard to do. I think the short form of the reason is that C++ compilers generally don't have the ability to recover from errors reliably. That may explain why your 2nd, 3rd, 4th... diagnostic messages tend to be useless gibberish ;-) So, I'd like to push for something like that but practically speaking I'm not sure how to get there. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_abstract_baseT ?
Robert Ramey [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Is there such a thing as is_abstract_baseT similar to is_polymorphicT ? Is such a thing possible? I could use it but have been unable to figrure out how to do it. I assume that you expect is_abstract_baseT to return true if and only if it is it is impossible to create an object of type T, and you must create an object of some subclass of T instead. One problem with this is that there are two very different ways of requiring the user to derive from T. The most common way is to declare type T with one or more pure virtual member functions. The other way is to declare T so that all its constructors are protected, as in boost::noncopyable. Joe Gottman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
From: David Abrahams [EMAIL PROTECTED] Paul Mensonides [EMAIL PROTECTED] writes: I do, however, agree that we need more support from the language for generic programming and some type of standardized API into the compiler's type system. And I definitely think that undefined behavior is unreasonable when the situation is easily diagnosable and not platform specific. I tend to agree on a moral/aesthetic level, but on a practical level we have to tread carefully. The question, can we just have an operator which produces a compile-time constant value saying whether its operand is a valid expression? has come up a few times in the committee. Each time, the implementors looked at their codebases and said oooh, that's really hard to do. I think the short form of the reason is that C++ compilers generally don't have the ability to recover from errors reliably. That may explain why your 2nd, 3rd, 4th... diagnostic messages tend to be useless gibberish ;-) But how does this apply to is_convertibleX, int when a private X::operator int()? Or are you discussing something else? I see no reason to make that undefined behavior. It's either false, true (Comeau says true BTW), unspecified, or ill formed, no diagnostic required - in order of preference. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
Peter Dimov [EMAIL PROTECTED] writes: From: David Abrahams [EMAIL PROTECTED] Paul Mensonides [EMAIL PROTECTED] writes: I do, however, agree that we need more support from the language for generic programming and some type of standardized API into the compiler's type system. And I definitely think that undefined behavior is unreasonable when the situation is easily diagnosable and not platform specific. I tend to agree on a moral/aesthetic level, but on a practical level we have to tread carefully. The question, can we just have an operator which produces a compile-time constant value saying whether its operand is a valid expression? has come up a few times in the committee. Each time, the implementors looked at their codebases and said oooh, that's really hard to do. I think the short form of the reason is that C++ compilers generally don't have the ability to recover from errors reliably. That may explain why your 2nd, 3rd, 4th... diagnostic messages tend to be useless gibberish ;-) But how does this apply to is_convertibleX, int when a private X::operator int()? Or are you discussing something else? See below. I see no reason to make that undefined behavior. It's either false, true (Comeau says true BTW), unspecified, or ill formed, no diagnostic required - in order of preference. Ill formed with diagnostic required was the possibility I was thinking of. You're right; undefined behavior is certainly not in the picture for this case. Never mind my brainless interjection, please ;-) -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_abstract_baseT ?
Joe Gottman [EMAIL PROTECTED] writes: Robert Ramey [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Is there such a thing as is_abstract_baseT similar to is_polymorphicT ? Is such a thing possible? I could use it but have been unable to figrure out how to do it. I assume that you expect is_abstract_baseT to return true if and only if it is it is impossible to create an object of type T, and you must create an object of some subclass of T instead. One problem with this is that there are two very different ways of requiring the user to derive from T. The most common way is to declare type T with one or more pure virtual member functions. The other way is to declare T so that all its constructors are protected, as in boost::noncopyable. And neither one is detectable without causing a compiler error, to my knowledge. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost.threads: Thread pool
Depends on the time frame of the next release and how fast I can finish my
work on the library. If it's not in 1.30.0, it will be in 1.31.0. In the
mean time, if it's important enough to you, you can track the work in
progress in the thread_dev branch in CVS.
Thanks! Will check out.
Also some kind of alarm or timer would be
useful.
Not something in the todo hopper. Can you give a more concrete
explanation of what you want, and why you think it's important for
inclusion.
As a simple way to get a function called at regular interval, something i
often use for periodic polling of connection status eg for db connections or
other periodic tasks.
A simple interface like:
struct alarm
{
alarm();
// constructor setting alarm
alarm(function0void callback, xtime alarmTime, unsigned int
intervalMsecs = 0);
// will do a cancel to ensure callback isn't called after destruction of
alarm
~alarm();
// set alarm to go off (if intervalMsecs is 0 its a one shot alarm)
void set(function0void callback, xtime alarmTime, unsigned int
intervalMsecs = 0);
// stop alarm synchrounously no active callbacks after this point
// you must be abel to cancel alarm from all threads especially from
// within the callback.
void cancel();
}
The idea is that all alarms should share on timer thread and a thread pool
and a priority queue (or maybe these things should be in an alarm_queue
class which an alarm is associated with, but there should be a system
default if an
alarm_queue class isn't given). There are some thorny issues when
implementing the alarm and alarm_queue class which is easy to get wrong
therefore I think its general purpose enough and belongs in a thread
toolbox.
Right now, most of the work is being done on boost::thread itself. This
includes a reference-counted implementation instead of a non-copyable
implementation, the addition of attributes such as stack size/address and
priority scheduling and the addition of cancellation. I'm getting close
to completion of the design/implementation and will be asking for a peer
review soon.
Is it settled wether there will be some kind of portable id (preferably
streamable) i often put thread ids in log file entries.
* Final integration of Dave Moore's classes, including thread_pool,
rw_mutex and barrier.
Great!
* Addition of shared memory constructs.
This is a needed one. Is there any preliminary sketches of what the
interface will be like?
Ok!
Another question i noted that in the current boost CVS the boost.thread only
builds a dll version of the library and no static ones, in earlier release
you only needed the dll when using tss? Is it supposed to be that way?
Regards
/michel
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost.threads: Thread pool
Michel André said: Depends on the time frame of the next release and how fast I can finish my work on the library. If it's not in 1.30.0, it will be in 1.31.0. In the mean time, if it's important enough to you, you can track the work in progress in the thread_dev branch in CVS. Thanks! Will check out. Also some kind of alarm or timer would be useful. Not something in the todo hopper. Can you give a more concrete explanation of what you want, and why you think it's important for inclusion. As a simple way to get a function called at regular interval, something i often use for periodic polling of connection status eg for db connections or other periodic tasks. A simple interface like: [ snip ] The idea is that all alarms should share on timer thread and a thread pool and a priority queue (or maybe these things should be in an alarm_queue class which an alarm is associated with, but there should be a system default if an alarm_queue class isn't given). There are some thorny issues when implementing the alarm and alarm_queue class which is easy to get wrong therefore I think its general purpose enough and belongs in a thread toolbox. Maybe you should send me a prototype implementation then. Right now, most of the work is being done on boost::thread itself. This includes a reference-counted implementation instead of a non-copyable implementation, the addition of attributes such as stack size/address and priority scheduling and the addition of cancellation. I'm getting close to completion of the design/implementation and will be asking for a peer review soon. Is it settled wether there will be some kind of portable id (preferably streamable) i often put thread ids in log file entries. Yes, though I'm still debating about whether or not the id will be seperate from the boost::thread class itself. The current CVS state has both. * Final integration of Dave Moore's classes, including thread_pool, rw_mutex and barrier. Great! * Addition of shared memory constructs. This is a needed one. Is there any preliminary sketches of what the interface will be like? Sort of. Dave Moore has been working on this, but I've not evaluated his work in any way, so can't comment on whether or not there will be design changes. Ok! Another question i noted that in the current boost CVS the boost.thread only builds a dll version of the library and no static ones, in earlier release you only needed the dll when using tss? Is it supposed to be that way? Yes. It vastly simplifies the build process (now that we have a working DLL implementation), and is the version most users have been asking for any way. I did expect to get some static about this, so let the debate begin. ;) Note, however, that it will be a little problematic to continue with a build process that provides both a forms, and that the threadmon.dll has been the source of a lot of confusion for users, so there will have to be very compelling reasons to bring this build type back. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL include problem with BOOST_PP_ITERATE
- Original Message - From: Hugo Duncan [EMAIL PROTECTED] Maybe my use of ITERATE is slightly different, in that I am using it to include a LIST of files. The LIST provides a single integration point. Hoisting all the includes reduces the utility of using ITERATE. Ah, okay, I see what your saying. You cannot use the file-iteration mechanism this way without near explicit collaboration with the files that your are including. The problems involved are not as easy to solve as you're are suggesting (see my other post in response to Aleksey). At one point in the past, however, I wrote a mechanism explicitly for including a set of files. It was intended to shorthand the process of including a lot of files from the same library. Something like: #define BOOST_PP_HEADERS \ (boost/preprocessor, (tuple/elem.hpp)(repetition/repeat.hpp)(list/adt.hpp)) \ /**/ #include BOOST_PP_ANGLED_INCLUDE() (I had BOOST_PP_QUOTED_INCLUDE as well.) I'd be happy to add such a mechanism, but I'd like to hear what people want from the mechanism and any thoughts on syntactic issues, etc.. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL include problem with BOOST_PP_ITERATE
- Original Message - From: Aleksey Gurtovoy [EMAIL PROTECTED] Hugo Duncan wrote: Maybe my use of ITERATE is slightly different, in that I am using it to include a LIST of files. The LIST provides a single integration point. Hoisting all the includes reduces the utility of using ITERATE. OK, I see the problem now. I can hoist the include of boost/mpl/list.hpp (and have done so for the moment), but I don't think that I should have to. The way I look at it, the fact that MPL uses ITERATE in its header files is an implementation convenience for MPL, and should not be visible to the user. You have a point, here. I'll look into the issue tonight. Don't bother. What Hugo is doing is a sketchy use of the mechanism precisely because of this type of problem. Even if you define a special flag macro to distinguish a certain MPL iteration from some other iteration, you are still going to have serious problems. Specifically, you'd have to rewrite all of it to reenter the file-iteration mechanism in an abstract and relative way, which means no direct references to specific iteration frames at all. This kind of thing is the purpose of the relative macros, but I cannot _evaluate_ the filename to iterate over. Therefore, I cannot abstract the depth. --- It should be considered an absolute rule that you don't include normal headers inside an iteration. --- (If I missed saying that in the docs, sorry, I'll fix it. I actually thought that I mentioned it, but I haven't checked.) Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
- Original Message - From: David Abrahams [EMAIL PROTECTED] I tend to agree on a moral/aesthetic level, but on a practical level we have to tread carefully. The question, can we just have an operator which produces a compile-time constant value saying whether its operand is a valid expression? has come up a few times in the committee. Each time, the implementors looked at their codebases and said oooh, that's really hard to do. I think the short form of the reason is that C++ compilers generally don't have the ability to recover from errors reliably. That may explain why your 2nd, 3rd, 4th... diagnostic messages tend to be useless gibberish ;-) So, I'd like to push for something like that but practically speaking I'm not sure how to get there. The problems are not insurmountable though (with an is_valid_expression). You aren't dealing with entire language at this point, only an expression. You'd need an independent expression parser that is coupled to the symbol table. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
Paul Mensonides [EMAIL PROTECTED] writes: - Original Message - From: David Abrahams [EMAIL PROTECTED] I tend to agree on a moral/aesthetic level, but on a practical level we have to tread carefully. The question, can we just have an operator which produces a compile-time constant value saying whether its operand is a valid expression? has come up a few times in the committee. Each time, the implementors looked at their codebases and said oooh, that's really hard to do. I think the short form of the reason is that C++ compilers generally don't have the ability to recover from errors reliably. That may explain why your 2nd, 3rd, 4th... diagnostic messages tend to be useless gibberish ;-) So, I'd like to push for something like that but practically speaking I'm not sure how to get there. The problems are not insurmountable though (with an is_valid_expression). You aren't dealing with entire language at this point, only an expression. And which parts of the language does that fail to drag in? Not many. Actually, not that it matters, but I think I'm misquoting the original request, which was, IIRC, tell us whether evaluating this expression should produce a compilation error. Howard knows for sure... -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
- Original Message -
From: Aleksey Gurtovoy [EMAIL PROTECTED]
Joel de Guzman wrote:
Here's the Phoenix version:
struct my_function_
{
template typename Arg1T, typename Arg2T
struct result { typedef void type; };
template typename U
void operator()(std::string const text, U)
{
// ...
}
};
functionmy_function_ my_function; // here!
Then:
mpl::for_each my_types (my_function(text, _1));
This is way too cool! Now we only need to provide such free-standing forms
of all STL algorithms/member functions, and we will be living in a different
world:
std::vectorstd::string v;
push_back(v, text); // plain call
for_each(input, push_back(v, _1)); // currying
for_each(v, for_each(_1, print_char)); // more currying
// etc.!
Breathtaking, IMO.
That was my intent. Well, as Peter noted, there's a problem
with ambiguity. Obviously, there's the namespace solution.
Once the functionftor feature will be incorporated into
LL, the curried form can be written easily as ll::for_each.
This feature has been with Phoenix since its inception. That's
why I requested people to look deeper than the cute if_[] syntax
when Phoenix was first introduced. The library is really so much
more than that.
The next step (hopefully soon) is to have the ability to wrap
classes easily so as to provide member functions in curried form,
so we can write:
for_each(c.begin(), c.end(), obj.print(_1));
Then, well can really live in a curried world.
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
On Friday, January 24, 2003, at 08:32 PM, David Abrahams wrote:
Actually, not that it matters, but I think I'm misquoting the original
request, which was, IIRC, tell us whether evaluating this expression
should produce a compilation error. Howard knows for sure...
Yes, that was my proposal, and yes, it made compiler writers very
nervous.
is_convertible is fragile. I suspect that it may end up needing
compiler support to really implement in a rock solid manner. That
being said, it is amazingly useful in its current form and I've only
bumped up against its fragility once:
struct A
{
private:
A(const A);
};
struct B
: A
{
};
char test[is_convertibleB, A::value];
On Metrowerks this gives:
Error : illegal access from 'A' to protected/private member
'A::A(const A )'
(instantiating: 'is_convertibleB, A')
main.cpp line 14 tatic const bool value =
sizeof(is_convertible_helperU::test(makeT())) == 1;
whereas on Comeau it will compile. At issue is what happens when you
pass a non-POD class through an ellipsis. We copy the class via its
copy constructor. Apparently Comeau doesn't. 5.2.2/7 says the
behavior is undefined. Apparently we make an attempt to deal with
non-POD classes in our va_arg system.
Fortunately circumstances such as the one illustrated above seem to be
rare (at least in my experience). But it is amusing (amazing?) how
many traits like tests are today passing non-POD classes to an
ellipsis, and invoking undefined behavior! :-)
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Joel de Guzman [EMAIL PROTECTED] writes:
- Original Message -
From: Aleksey Gurtovoy [EMAIL PROTECTED]
Joel de Guzman wrote:
Here's the Phoenix version:
struct my_function_
{
template typename Arg1T, typename Arg2T
struct result { typedef void type; };
template typename U
void operator()(std::string const text, U)
{
// ...
}
};
functionmy_function_ my_function; // here!
Then:
mpl::for_each my_types (my_function(text, _1));
This is way too cool! Now we only need to provide such free-standing forms
of all STL algorithms/member functions, and we will be living in a different
world:
std::vectorstd::string v;
push_back(v, text); // plain call
for_each(input, push_back(v, _1)); // currying
for_each(v, for_each(_1, print_char)); // more currying
// etc.!
Breathtaking, IMO.
That was my intent.
I'd like you to take my breath, too, but I'm not as quick as Aleksey.
I tried to compile your code but I couldn't come up with a plausible
definition for function Could you fill in some details?
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
Howard Hinnant [EMAIL PROTECTED] writes: Fortunately circumstances such as the one illustrated above seem to be rare (at least in my experience). But it is amusing (amazing?) how many traits like tests are today passing non-POD classes to an ellipsis, and invoking undefined behavior! :-) I thought there wansn't any undefined behavior there, because none of the traits actually generate or execute the code within sizeof(). I can understand it being unspecified whether you get an error due to accessibility of the c-ctor. Am I misunderstanding how the standard works in this area? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
- Original Message - From: Howard Hinnant [EMAIL PROTECTED] Fortunately circumstances such as the one illustrated above seem to be rare (at least in my experience). But it is amusing (amazing?) how many traits like tests are today passing non-POD classes to an ellipsis, and invoking undefined behavior! :-) It isn't invoking undefined behavior because it isn't passing non-POD classes to an ellipsis--it isn't passing *anything* to an ellipsis. ;) Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
- Original Message - From: David Abrahams [EMAIL PROTECTED] The problems are not insurmountable though (with an is_valid_expression). You aren't dealing with entire language at this point, only an expression. And which parts of the language does that fail to drag in? Not many. Variable declarations specifically--that removes quite a few problems from the parser implementation. But, also, declarations and definitions of all types, exception handling try and catch blocks, statements, etc.. I.e. it leaves out most of the stuff that makes the parser complicated. The difficult part of the semantic analysis would still be lookup and overloading, IMHO. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
This is way too cool! Now we only need to provide such free-standing forms
of all STL algorithms/member functions, and we will be living in a different
world:
std::vectorstd::string v;
push_back(v, text); // plain call
for_each(input, push_back(v, _1)); // currying
for_each(v, for_each(_1, print_char)); // more currying
// etc.!
Breathtaking, IMO.
That was my intent.
I'd like you to take my breath, too, but I'm not as quick as Aleksey.
I tried to compile your code but I couldn't come up with a plausible
definition for function Could you fill in some details?
A good start is libs/phoenix/test/functors_tests.cpp
and libs/phoenix/example/fundamental/sample3.cpp
There are jamfiles in there FWIW.
Here's sample3.cpp:
#include vector
#include algorithm
#include iostream
#include boost/phoenix/functions.hpp
#include boost/phoenix/primitives.hpp
using namespace std;
using namespace phoenix;
struct is_odd_ {
template typename ArgT
struct result { typedef bool type; };
template typename ArgT
bool operator()(ArgT arg1) const
{ return arg1 % 2 == 1; }
};
functionis_odd_ is_odd;
int
main()
{
int init[] = { 2, 10, 4, 5, 1, 6, 8, 3, 9, 7 };
vectorint c(init, init + 10);
typedef vectorint::iterator iterator;
// Find the first odd number in container c
iterator it = find_if(c.begin(), c.end(), is_odd(arg1));
if (it != c.end())
cout *it;// if found, print the result
return 0;
}
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
- Original Message -
From: Joel de Guzman [EMAIL PROTECTED]
A good start is libs/phoenix/test/functors_tests.cpp
and libs/phoenix/example/fundamental/sample3.cpp
There are jamfiles in there FWIW.
BTW, here's the lambda-lambda solution posed by Joel Young:
#include iostream
#include boost/phoenix/operators.hpp
#include boost/phoenix/primitives.hpp
#include boost/phoenix/composite.hpp
#include boost/phoenix/functions.hpp
//
using namespace std;
using namespace phoenix;
//
struct square_ {
template typename X
struct result { typedef X type; };
template typename X
X operator()(X x)
{
return x * x;
}
};
functionsquare_ square;
//
template typename F
struct ffx {
template typename X
struct result { typedef X type; };
ffx(F f_) : f(f_) {}
template typename X
X operator()(X x)
{
return f(f(x));
}
F f;
};
template typename F
functionffxF
doub(functionF f)
{
return functionffxF (f.op);
}
//
int
main()
{
cout doub(square)(5.0)() endl;
cout doub(doub(square))(5.0)() endl;
cout doub(doub(doub(square)))(5.0)() endl;
return 0;
}
Cheers,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_abstract_baseT ?
Robert Ramey [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Is there such a thing as is_abstract_baseT similar to is_polymorphicT ? Is such a thing possible? I could use it but have been unable to figrure out how to do it. Rani Sharoni wrote is_abstract_classT type trait (see on http://groups.google.com/groups?q=is_abstract_classhl=enlr=ie=UTF-8oe=UT F-8selm=df893da6.0207110613.75b2fe90%40posting.google.comrnum=1). It compiles on Comeau, Intel C++ 7.0 and VC++ 7.1beta. /Pavel ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
On Friday, January 24, 2003, at 09:37 PM, Paul Mensonides wrote: Fortunately circumstances such as the one illustrated above seem to be rare (at least in my experience). But it is amusing (amazing?) how many traits like tests are today passing non-POD classes to an ellipsis, and invoking undefined behavior! :-) It isn't invoking undefined behavior because it isn't passing non-POD classes to an ellipsis--it isn't passing *anything* to an ellipsis. ;) It does if the test returns false (which admittedly it didn't in my example). -Howard ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
On Friday, January 24, 2003, at 09:36 PM, David Abrahams wrote:
Howard Hinnant [EMAIL PROTECTED] writes:
Fortunately circumstances such as the one illustrated
above seem to be rare (at least in my experience). But
it is amusing (amazing?) how many traits like tests are
today passing non-POD classes to an ellipsis, and
invoking undefined behavior! :-)
I thought there wansn't any undefined behavior there, because none of
the traits actually generate or execute the code within sizeof(). I
can understand it being unspecified whether you get an error due to
accessibility of the c-ctor. Am I misunderstanding how the standard
works in this area?
Expressions in sizeof are accessed checked:
class B
{
int foo();
};
int main()
{
B b;
unsigned i = sizeof(b.foo()); // error, foo() not accessible
}
Furthermore, it is undefined to pass a non-pod to an ellipse (5.2.2/7):
int foo(...);
class B
{
public:
B();
private:
B(const B);
};
int main()
{
foo(B()); // undefined behavior
}
If you stick that in a sizeof, it is still undefined:
sizeof(foo(B()));
If you overload foo, it is still undefined:
int foo(...);
char foo(int);
At least, that is my current understanding.
Note that I am not saying that traits using ellipses are not a good
thing. I'm just exposing a non-portable corner.
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
On Friday, January 24, 2003, at 09:12 PM, Howard Hinnant wrote:
struct A
{
private:
A(const A);
};
struct B
: A
{
};
char test[is_convertibleB, A::value];
On Metrowerks this gives:
Error : illegal access from 'A' to protected/private member
'A::A(const A )'
(instantiating: 'is_convertibleB, A')
main.cpp line 14 tatic const bool value =
sizeof(is_convertible_helperU::test(makeT())) == 1;
Sorry, my example (from memory) was inaccurate:
#include msl_utility
struct A
{
};
struct B
{
private:
B(const B);
};
char test[!Metrowerks::is_convertibleB, A::value];
Error : illegal access from 'B' to protected/private member
'B::B(const B )'
(instantiating: 'Metrowerks::is_convertibleB, A')
msl_utility line 472 tatic const bool value =
sizeof(is_convertible_helperU::test(makeT())) == 1;
Haven't tried it with boost::is_convertible, but I suspect it would
have the same problem.
-Howard
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL usage for code generation
Hugo Duncan [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
On Wed, 22 Jan 2003 16:25:40 -0800, Andrei Alexandrescu
[EMAIL PROTECTED] wrote:
inline void do_my_function(string, void_) {}
template class Lst
inline void do_my_function(string s, Lst lst)
{
my_functionfrontLst::type(s);
do_my_function(s, pop_frontLst::type());
}
do_my_function(s, my_list());
This is interesting as it also gives run-time control of how much of the
list
is iterated over.
eg.
template class Lst
inline void do_my_function(string s, Lst lst)
{
if (!my_functionfrontLst::type(s))
do_my_function(s, pop_frontLst::type());
}
To add compliment to healing, an additional advantage is that you don't even
need to get for_each to compile.
Andrei
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_abstract_baseT ?
Pavel Vozenilek [EMAIL PROTECTED] wrote in message b0svlm$l1q$[EMAIL PROTECTED]">news:b0svlm$l1q$[EMAIL PROTECTED]... Robert Ramey [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Is there such a thing as is_abstract_baseT similar to is_polymorphicT ? Is such a thing possible? I could use it but have been unable to figrure out how to do it. Rani Sharoni wrote is_abstract_classT type trait (see on http://groups.google.com/groups?q=is_abstract_classhl=enlr=ie=UTF-8oe=UT This class determines whether it is possible to create an array of type T. If it is not, and T is not void, a reference, or a function, it assumes that T must be an abstract base class. The problem is that it is impossible to create an array of any type that does not have a public constructor, for instance a non-abstract singleton class. So this does not quite work. Joe Gottman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
