Re: [boost] Re: MPL usage for code generation
"Joel de Guzman" <[EMAIL PROTECTED]> writes:
> - Original Message -
> From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]>
>
>> 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):
>>
>> my_function("text", int());
>>
>> and it will also allow one to do something like this:
>>
>> std::string text("text");
>> mpl::for_each< my_types >(boost::bind(my_function, text, _1));
>
> This technique is adopted by Phoenix. With this, you can even do
> (as suggested by Joel Young):
>
> - \ \
> double - /\ f . /\ x. f(f x)
> - / \ / \
>
> struct square_ {
>
> template
> struct result { typedef X type; };
>
> template
> X operator()(X x)
> {
> return x * x;
> }
> };
This is similar to my "universal identity" suggestion from many months
back. However, "result" should be "apply" to make it an MPL
metafunction class .
Hum, that result template looks like identity, and not square. Am I
missing something? I'd have thought:
template
struct result : mpl::times {};
> function square;
>
> template
> struct ffx {
>
> template
> struct result { typedef X type; };
Mighty confused. Not
template
struct result : mpl::apply::type> {};
??
If not, what's the point of "result"?
> PS> Jaakko and I are working on the LL/Phoenix merger.
Yay! What about my tuples question?
--
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] Problem with regression tests
Hi, 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: generating html tables: Using /u/ph/troyer/boost/status/bin/bind_test.test to determine compilers Missing jam_log.xml in target "/u/ph/troyer/boost/status/bin/bind_test.test/cray/debug" Missing jam_log.xml in target "/u/ph/troyer/boost/status/bin/mem_fn_test.test/cray/debug" Missing jam_log.xml in target "/u/ph/troyer/boost/status/bin/mem_fn_void_test.test/cray/debug" Missing jam_log.xml in target "/u/ph/troyer/boost/status/bin/mem_fn_derived_test.test/cray/debug" Missing jam_log.xml in target "/u/ph/troyer/boost/status/bin/config_info.test/cray/debug" Missing jam_log.xml in target "/u/ph/troyer/boost/status/bin/array1.test/cray/debug" Missing jam_log.xml in target "/u/ph/troyer/boost/status/bin/array2.test/cray/debug" Missing jam_log.xml in target "/u/ph/troyer/boost/status/bin/array3.test/cray/debug" Missing jam_log.xml in target "/u/ph/troyer/boost/status/bin/array4.test/cray/debug" ... Can anyone help me and point me to a location where I might start looking for the problem? Matthias ___ 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]>
> 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):
>
> my_function("text", int());
>
> and it will also allow one to do something like this:
>
> std::string text("text");
> mpl::for_each< my_types >(boost::bind(my_function, text, _1));
Here's the Phoenix version:
struct my_function_
{
template
struct result { typedef void type; };
template< typename U >
void operator()(std::string const& text, U)
{
// ...
}
};
function my_function; // here!
Then:
mpl::for_each< my_types >(my_function(text, _1));
Regards,
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MPL::void_t
Hi,
Question why is mpl::void_t an incomplete type? Sometimes I need
to instantiate it. For example to signal a zero arity functor call:
typename actor_result >::type
operator()() const
{
return this->eval(void_t());
}
template
typename actor_result >::type
operator()(T0& a0) const
{
return this->eval(a0);
}
Of course I can do it differently, but it wouldn't be as clean and
generic as above. Thoughts?
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: undo library
Can I use this library to implement multiple undo/redo in GUI applications under Windows? For example in a word processor. Mohammed - Original Message - From: "Pavel Vozenilek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 24, 2003 1:15 AM Subject: [boost] Re: Re: undo library > > "Steven Mauceri" <[EMAIL PROTECTED]> wrote in message > 000f01c2c301$fca17ae0$[EMAIL PROTECTED]">news:000f01c2c301$fca17ae0$[EMAIL PROTECTED]... > > Hi Andreas, > > > [snip] > > Some things ive come across include: > > > [snip] > > Undo library may also provide features like: > - user friendly description of what is going to be undoed/redoed, > - ability to keep only N last undo steps in memory and save rest on disk > (maybe with help of an serialisation library), > - ability to group multiple undo commands to one (e.g. moves), > - ability to generate 'change log' for any given time period. > > Most of it may be implemented by specialised command manager. > > /Pavel > > > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
- Original Message -
From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]>
> 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):
>
> my_function("text", int());
>
> and it will also allow one to do something like this:
>
> std::string text("text");
> mpl::for_each< my_types >(boost::bind(my_function, text, _1));
This technique is adopted by Phoenix. With this, you can even do
(as suggested by Joel Young):
- \ \
double - /\ f . /\ x. f(f x)
- / \ / \
struct square_ {
template
struct result { typedef X type; };
template
X operator()(X x)
{
return x * x;
}
};
function square;
template
struct ffx {
template
struct result { typedef X type; };
ffx(F f_) : f(f_) {}
template
X operator()(X x)
{
return f(f(x));
}
F f;
};
template
function >
doub(function f)
{
return function >(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
PS> Jaakko and I are working on the LL/Phoenix merger.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL usage for code generation
David Abrahams wrote:
> Terje Slettebø <[EMAIL PROTECTED]> writes:
> > Perhaps it might be possible to do some compile-time/run-time lambda
> > (similar to Boost.Lambda for runtime, and MPL's lambda), so you
> > could do something like:
> >
> > mpl::for_each(my_function<_>(s));
> >
> > It would then transform the function call "my_function<_>(s)" into
> > an instantiated function object of the kind suitable for
> > mpl::for_each.
>
> I'm afraid that particular syntax won't work for this particular case,
> though. If my_function is a function template, my_function<_> is a
> function, and my_function<_>(s) calls that function.
>
> Since there are no (function template) template parameters, only
> (class template) template parameters, there doesn't appear to be any
> way to make this one particularly easy except by using the
> preprocessor to define some kind of function object.
>
> 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):
my_function("text", int());
and it will also allow one to do something like this:
std::string text("text");
mpl::for_each< my_types >(boost::bind(my_function, text, _1));
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Re: Review results: Optional library
At 02:21 PM 1/23/2003, Fernando Cacciola wrote: > >"William E. Kempf" <[EMAIL PROTECTED]> wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... >> Fernando Cacciola said: >> > "William E. Kempf" <[EMAIL PROTECTED]> wrote in message >> >> Fernando Cacciola said: >> >> However, shouldn't you be using "run" instead of >> >> "unit-test" in the Jamfile? >> >> >> > Yes :-) I was looking at the wrong examples. >> > >> > Fixed now. (could you re-test it?) >> >> $ bjam >> Jamfile: line 25: syntax error at keyword ; >> Jamfile: line 25: syntax error at keyword ; >> Jamfile: line 26: syntax error at keyword } >> Jamfile: line 26: syntax error at keyword } >> found 8 targets... >> >It looks like the syntax for the compile-fail (plus the ) is >wrong... >I've removed the fail cases altogether until I can test it myself so I >don't >abuse anymore of your time. >It runs only the ordinary test now >It should work I think. Yes, works here. I've added optional to the status/Jamfile. Always keep in mind that the jam language is whitespace sensitive. I can't tell you how many times that caught me at first, although I got used to it after awhile. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MPL usage for code generation
On Wed, 22 Jan 2003 16:25:40 -0800, "Andrei Alexandrescu" <[EMAIL PROTECTED]>
wrote:
>
> inline void do_my_function(string&, void_) {}
>
> template
> inline void do_my_function(string& s, Lst lst)
> {
> my_function::type>(s);
> do_my_function(s, pop_front::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
inline void do_my_function(string& s, Lst lst)
{
if (!my_function::type>(s))
do_my_function(s, pop_front::type());
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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
> >
> > template
> > T circle_area (const T &radius) {
> > return math_constants::pi * radius * radius;
> > }
> >
> > How should this be done?
> >
> > Thanks,
> >
> > Joerg
>
> Attached is an example using Michael Kenniston's Kunning Function
constants.
>
> Briefly
>
> template
> T circle_area(const T& radius)
> {
> // Usage example: circle_area( 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
#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
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_area(1.) = " << circle_area(1.) << endl; //
> Explicit type float.
> cout << "circle_area(1.) = " << circle_area(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_area(1.F) = " << circle_area(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_area(1.) = " << circle_area(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_area(1.) = 3.1415927410125732
> circle_area(1.) = 3.1415926535897931
> circle_area(1.F) = 3.1415927410125732
> circle_area(1.) = 3.1415926535897931
> circle_area(1.L) = 3.1415926535897931
> circle_area(1.F) = 3.1415926535897931
> circle_area(1.) = 3.1415926535897931
> circle_area(2.) = 12.566370964050293
> circle_area(2.) = 12.566370614359172
> circle_area(2.F) = 12.566370964050293
> circle_area(2.) = 12.566370614359172
> circle_area(2.L) = 12.566370614359172
> circle_area(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
[boost] Re: Re: undo library
"Andrei Alexandrescu" <[EMAIL PROTECTED]> wrote in message b0pu01$bqd$[EMAIL PROTECTED]">news:b0pu01$bqd$[EMAIL PROTECTED]... > Al Stevens has an article in a past DDJ about a generic undo/redo library, > can anyone dig it out? I recall it was interesting. > Can be purchased here: https://www.sdmediagroup.com/secure/?sid=954 and followup here: https://www.sdmediagroup.com/secure/?sid=914 /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: undo library
Al Stevens has an article in a past DDJ about a generic undo/redo library, can anyone dig it out? I recall it was interesting. Andrei ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] ublas CVS commit
Hi all, I've just committed my current ublas version to Boost CVS. Many thanks this time namely to John Maddock for his Borland related fixes (really a big patch) and to Alexei Novakov for his sparse matrix related work. Best, Joerg P.S.: I had to touch status/Jamfile once again. I've hopefully destroyed nothing ;-( ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Named Pairs
> > Look on MPL example for inherit_linear. It may have what you need. > > Well, as I said, I'm new... I can find mpl documentation, but searches > for inherit_linear came up with nothing. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/mpl/example/ inherit_linearly.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup In the above example terms, what you want would look like: typedef mpl::int_c<0> Cash; typedef mpl::int_c<0> Name; field( foobar, Cash() ) = 32.2; field( foobar, Name() ) = "Fred"; IOW, this or another way implemented: tuples are your friends. Look onto boost::tuple lib, that supply full featured tuples. Gennadiy. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Named Pairs
"Rozental, Gennadiy" wrote:
>
> First of all there are several glitches here:
> I am not sure that you allowed to use template parameter for defining
> partial specialization.
Well, is it allowed? I am new to generic programming stuff, so forgive
any stupid comments I make... If I remember right, a templated
definition is only evaluated for a specific instance... I'd think that
when it is read for an instance, that a given template paramater should
then be well defined, and that specialization using a template parameter
shouldn't be a problem or at least conceptually... I can definitely
see it being an odd case for a compiler.
> Even if above class definition is allowed foobar.var will be invalud
> cause var is a type name. So basically what you are doing is unusable.
Ok, some updated code for the class definition, hopefully it will make
more sense. Something like this didn't compile as well in visual
studio, so I didn't post that code.
template
class named_pair: pair<_T1,_T2>{
public:
template
void var();
_T1& var<_Name1>() {return First}; //VC6 dislikes these 2 lines
_T2& var<_Name2>() {return Second}; //(different return type)
};
enum{ Cash, Name };
void main(int argc, char *argv[]){
named_pair foobar;
foobar.var() = 32.2;
foobar.var() = "Fred";
}
> Look on MPL example for inherit_linear. It may have what you need.
Well, as I said, I'm new... I can find mpl documentation, but searches
for inherit_linear came up with nothing.
Maybe I should try and make my goal clearer. I wanted to be able to
define a collection of variables for use with STL that is as simple to
define as a struct. The difference being that all the useful operators
are defined... comparisons, assignments, etc...
The associative type list looks like it does exactly what I wanted, as
far as having a name to associate with retrieval of a specific
variable. But it lacks the nice default copy constructor and less than
operator.
I assume that the associative list is only a list at compile time? Does
it compile to efficient code? If so, a simple wrapper around it could
do what I wanted, and still retain whatever other special features it
has.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [jamboost] Patch for jam bug on Cray
On Wednesday, January 22, 2003, at 07:56 PM, Matthias Troyer wrote: Dear Boost Jamers, Our local Cray adminstrators (Bruno Loepfe from ETH and Olivier Byrde from Cray) found a bug in the boost jam sources. it is in the file hash.c: keyval = keyval * 2147059363 + *b++; Besides the bug fix I posted before, our Cray system administrator warned me that there are (were) machines which trap integer overflow, and where above code would not work. He proposed to use a hash function employing exclusive or operations instead. In contrast to fixing the bug for which I sent the patch, this is s however definitively not an urgent problem. It should be kept in mind however in case that we ever encounter a modern machine trapping integer overflows. Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: undo library
"Steven Mauceri" <[EMAIL PROTECTED]> wrote in message 000f01c2c301$fca17ae0$[EMAIL PROTECTED]">news:000f01c2c301$fca17ae0$[EMAIL PROTECTED]... > Hi Andreas, > [snip] > Some things ive come across include: > [snip] Undo library may also provide features like: - user friendly description of what is going to be undoed/redoed, - ability to keep only N last undo steps in memory and save rest on disk (maybe with help of an serialisation library), - ability to group multiple undo commands to one (e.g. moves), - ability to generate 'change log' for any given time period. Most of it may be implemented by specialised command manager. /Pavel ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Named Pairs
"Fredrik Blomqvist" <[EMAIL PROTECTED]> wrote in message b0pj3o$p42$[EMAIL PROTECTED]">news:b0pj3o$p42$[EMAIL PROTECTED]... > This is interesting stuff, but I think you should checkout Emily Winch's > more general compile-time associative list implementation also. > (http://groups.yahoo.com/group/boost/files/alist-feb14-02.zip seems to be > the latest) Sorry, wrong link... should be: http://groups.yahoo.com/group/boost/files/associative_list/ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Named Pairs
First of all there are several glitches here:
> template
> class named_pair{
> public:
> template
> class var{};
>
template<>?
> class var<_Name1>{
I am not sure that you allowed to use template parameter for defining
partial specialization.
> public:
> _T1 value;
> }
;?
>
template<>?
> class var<_Name2>{
public:
> _T2 value;
> }
;?
> };
>
> enum{ Cash, Name };
>
> void main(int argc, char *argv[]){
> named_pair foobar;
>
> foobar.var.value = 32.2;
> foobar.var.value = "Fred";
Even if above class definition is allowed foobar.var will be invalud
cause var is a type name. So basically what you are doing is unusable.
> }
Look on MPL example for inherit_linear. It may have what you need.
Gennadiy.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Named Pairs
This is interesting stuff, but I think you should checkout Emily Winch's
more general compile-time associative list implementation also.
(http://groups.yahoo.com/group/boost/files/alist-feb14-02.zip seems to be
the latest)
What's the status of the Emily's lib btw? Is an MPL/Boost integration under
consideration?
"Jason House" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I tried to do the following implementation in visual studio 6 to see if
> I could get a named pair class.
>
> I tried a number of approaches, but none worked with my compiler. Is my
> approach fundamentally flawed?
>
> I think that something like this would be a useful utility to have.
> Anyone have any ideas on how to improve the class?
>
>
> template
> class named_pair{
> public:
> template
> class var{};
>
> class var<_Name1>{
> public:
> _T1 value;
> }
>
> class var<_Name2>{
> _T2 value;
> }
> };
>
> enum{ Cash, Name };
>
> void main(int argc, char *argv[]){
> named_pair foobar;
>
> foobar.var.value = 32.2;
> foobar.var.value = "Fred";
> }
>
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: A question about static_log2
On Thu, 23 Jan 2003 03:26:52 +0200, "Vesa Karvonen" <[EMAIL PROTECTED]> wrote: >Hi, > >I'm sorry, but I have too little time to comment more extensively on this >subject No problem. I just have to thank you for the attention and the useful comments. Feel also free to continue the discussion when you'll have more time even if this thread is then "old", and/or to contact me by private mail. > (other duties demand attention). Below you'll find an algorithm, >that chooses a proper value of n from where to start the log2<> algorithm >presented earlier. Before resorting to the = sizeof hack I thought to several solutions. It's obvious that the value we need is just 1 + log2. So one solution would have been to use the trivial log2 = 1+log2(n/2) implementation for the initial value only, and the optimized binary search implementation for the rest. Since unsigned long are guaranteed to have at least 32 value bits, one could have done: const int initial_value = 31 + trivial_log2 (ULONG_MAX/2147483648ul) saving some thirty instantiations. Still it would give you an error with 64 bits ulongs and compilers with a small instantiation limit however, thus I gave up. > It does not depend on and it should always >produce a value that has the correct properties. 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? I'll think about the issue and see if I have anything better than this. If so I'll post it here. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Named Pairs
I tried to do the following implementation in visual studio 6 to see if
I could get a named pair class.
I tried a number of approaches, but none worked with my compiler. Is my
approach fundamentally flawed?
I think that something like this would be a useful utility to have.
Anyone have any ideas on how to improve the class?
template
class named_pair{
public:
template
class var{};
class var<_Name1>{
public:
_T1 value;
}
class var<_Name2>{
_T2 value;
}
};
enum{ Cash, Name };
void main(int argc, char *argv[]){
named_pair foobar;
foobar.var.value = 32.2;
foobar.var.value = "Fred";
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Re: Review results: Optional library
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Fernando Cacciola said: > > "William E. Kempf" <[EMAIL PROTECTED]> wrote in message > >> Fernando Cacciola said: > >> However, shouldn't you be using "run" instead of > >> "unit-test" in the Jamfile? > >> > > Yes :-) I was looking at the wrong examples. > > > > Fixed now. (could you re-test it?) > > $ bjam > Jamfile: line 25: syntax error at keyword ; > Jamfile: line 25: syntax error at keyword ; > Jamfile: line 26: syntax error at keyword } > Jamfile: line 26: syntax error at keyword } > found 8 targets... > It looks like the syntax for the compile-fail (plus the ) is wrong... I've removed the fail cases altogether until I can test it myself so I don't abuse anymore of your time. It runs only the ordinary test now It should work I think. -- Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is_convertible corner case
These are a couple of miscellaneous thoughts as well:
John Spicer wrote:
>I'm happy to voice an opinion, although I don't think I
>have anything to add that hasn't already been said.
>
>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).
- I understand that this is an informal description on John's part,
just to give us an idea, so I'm not nitpicking on the specific
wording. But it's IMHO important to consider that C++ has at least two
cases of conversions whose validity depends not on the type but on the
specific expression used (off the top of my head they are the only two
ones, but I would be cautious before stating that):
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.
- 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_convertible::value; // true or false??
// or error?
}
};
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Review results: Optional library
"William E. Kempf" <[EMAIL PROTECTED]> writes: > Fernando Cacciola said: >> "William E. Kempf" <[EMAIL PROTECTED]> wrote in message >>> Fernando Cacciola said: >>> However, shouldn't you be using "run" instead of >>> "unit-test" in the Jamfile? >>> >> Yes :-) I was looking at the wrong examples. Actually, unit-test just invokes run since 2003/01/05, so it's OK to use it. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
On Thu, 23 Jan 2003, David Abrahams wrote:
> Douglas Paul Gregor <[EMAIL PROTECTED]> writes:
>
> > On Thu, 23 Jan 2003, David Abrahams wrote:
> >> No, I mean the complexity-of-expression issue.
> >
> > Hmmm, I don't see how that issue applies.
>
> I don't know what you mean by that. Are you saying that Andrei was
> making an invalid argument? I wouldn't agree with that.
Andrei's argument was that this form for a for_each loop:
inline void do_my_function(string&, void_) {}
template
inline void do_my_function(string& s, Lst lst)
{
my_function::type>(s);
do_my_function(s, pop_front::type());
}
...
do_my_function(s, my_list());
, which he posted here:
http://lists.boost.org/MailArchives/boost/msg42374.php
is less complex than the solution you posted, which uses MPL's for_each:
http://lists.boost.org/MailArchives/boost/msg42369.php
Somewhere in reading the thread I replaced the rather simple definitions
of "func" in your message with an MPL metafunction class. Re-reading it
now, I see that the solution I'm proposing would require almost identical
code to what you posted, with the exception that:
mpl::for_each(func(s));
... would become:
for_each(my_list().begin(), my_list().end(), func(s));
Anyway, Andrei's argument is a good one, and I see that it holds against
the for_each that I'm proposing as well.
> > STL users know how to write function objects. It's not a gigantic
> > leap to write function objects with a templated function call
> > operator (at least, it isn't if you've already decided to play with
> > template metaprogramming). The rest of the syntax is inherited from
> > STL. I don't see any extra complexity here. Granted, it means
> > pulling in a lot more code than Andrei's version,
>
> And writing a lot more code.
Yes, those wretched function object->overloaded function bridges take up a
lot of space, even if they are trivial.
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: Review results: Optional library
Fernando Cacciola said: > "William E. Kempf" <[EMAIL PROTECTED]> wrote in message >> Fernando Cacciola said: >> However, shouldn't you be using "run" instead of >> "unit-test" in the Jamfile? >> > Yes :-) I was looking at the wrong examples. > > Fixed now. (could you re-test it?) $ bjam Jamfile: line 25: syntax error at keyword ; Jamfile: line 25: syntax error at keyword ; Jamfile: line 26: syntax error at keyword } Jamfile: line 26: syntax error at keyword } found 8 targets... William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cstdint.hpp patch for Cray X1
On Thursday, January 23, 2003, at 07:14 PM, Dan Gohman wrote: Hi Matthias, The reason for special-casing the Cray X1 here is so that int_fast16_t isn't defined to be short, as short has performance penalties associated with it on this platform. Hi Dan, I missed that point. Yes, you are right int_fast16_t should be int on the X1. I guess we could also define it as short on the SV1 and other machnes with 32 bit shorts. Unfortunately there is no 16 bit integer type on those machines. Matthias ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Review results: Optional library
"David Abrahams" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > "William E. Kempf" <[EMAIL PROTECTED]> writes: > > > Fernando Cacciola said: > >> I've committed "Jamfile" to libs/optional/test. > >> > >> But I can't run bjam on my Win98 configuration (long command lines > >> problem), so I can't test it. > > > > Doesn't bjam have a fix for this issue? > > For most cases, yes. > You can build bjam under Cygwin as a last resort. > Yes. I still have to finish updating my Cygwin box. Then I will be able to run bjam with at least gcc. -- Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] -lrt on Mandrake 9.0
On Thursday 23 January 2003 11:01 pm, William E. Kempf wrote: > Can anyone explain to me what's wrong on my system that -lrt isn't finding > the library? You need to install glibc-devel. Issuing "urpmi glibc-devel" as root should do it. Mandrake separates runtime and devel packages and thus if you want to do development you have to install the corresponding -devel packages. -- Alkis ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] cstdint.hpp patch for Cray X1
Hi Matthias, The reason for special-casing the Cray X1 here is so that int_fast16_t isn't defined to be short, as short has performance penalties associated with it on this platform. I can't guarantee I'll be able to test jam, but I'll let you know if I get to it. Dan On Thu, 2003-01-23 at 11:43, Matthias Troyer wrote: > Hi Dan, > > I don't think this will be needed since on the X1 USHRT_MAX should be > 0x, and thus the default version will work. Note that the patch for > the SV1 and other Crays that I submitted checks for USHRT_MAX being > 0x and thus does not apply on the X1 anyways. > > On another note, I got jam to compile on the SV1, and have submitted a > patch. Now I am running the regression tests on it. Not having access > to an X1 yet (and the 4.2 compilers don't exist for other Crays), I > can't run the tests there at the moment. Could you try to run it, once > I have patched boost for the SV1? > > Best regards, > > Matthias > > On Thursday, January 23, 2003, at 05:49 PM, Dan Gohman wrote: > > > 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. > > > > 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
[boost] Re: Re: Re: Review results: Optional library
"William E. Kempf" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > Fernando Cacciola said: > > I've committed "Jamfile" to libs/optional/test. > > > > But I can't run bjam on my Win98 configuration (long command lines > > problem), so I can't test it. > > Doesn't bjam have a fix for this issue? > Not for Windows, AFAICT. > > Could someone test the jamfile? If it works, I'l add the entry on > > status/Jamfile. > > It passes for me (well, sort of, toolset for vc7, vc71 and gcc-nocygwin > pass, while msvc fails). hmmm. I'll take a look at those on which it fails when the regressions are fully run. > However, shouldn't you be using "run" instead of > "unit-test" in the Jamfile? > Yes :-) I was looking at the wrong examples. Fixed now. (could you re-test it?) -- Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Douglas Paul Gregor <[EMAIL PROTECTED]> writes: > On Thu, 23 Jan 2003, David Abrahams wrote: > >> Douglas Paul Gregor <[EMAIL PROTECTED]> writes: >> >> > On Thu, 23 Jan 2003, David Abrahams wrote: >> >> AFAICT it >> >> doesn't solve the problem that Andrei was pointing at. >> > >> > You mean the front/pop_front issue? >> >> No, I mean the complexity-of-expression issue. > > Hmmm, I don't see how that issue applies. I don't know what you mean by that. Are you saying that Andrei was making an invalid argument? I wouldn't agree with that. > STL users know how to write function objects. It's not a gigantic > leap to write function objects with a templated function call > operator (at least, it isn't if you've already decided to play with > template metaprogramming). The rest of the syntax is inherited from > STL. I don't see any extra complexity here. Granted, it means > pulling in a lot more code than Andrei's version, And writing a lot more code. > but as one who has written that same bit of code approximately a > billion times I'm ready for a simple, familiar abstraction. Yeah, as I said I'm more comfortable with it too. >> > Just stick your third-party iterators into sequence<> and you're all set; >> > I'd expect that mpl::list, mpl::vector, etc. would just derive from >> > mpl::sequence to reduce the amount of typing in the common case. >> >> Maybe it would be better to define namespace-scope begin(), end(), >> et. al which can operate on STL and MPL sequences. > > I have two concerns with that: > 1) begin and end are already class templates in MPL > 2) There isn't much precedent for begin(container) and end(container); > there is for container.begin() and container.end() OK. I think it would be best to start by making an experimental layer on top of MPL in the sandbox. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Review results: Optional library
"William E. Kempf" <[EMAIL PROTECTED]> writes: > Fernando Cacciola said: >> I've committed "Jamfile" to libs/optional/test. >> >> But I can't run bjam on my Win98 configuration (long command lines >> problem), so I can't test it. > > Doesn't bjam have a fix for this issue? For most cases, yes. You can build bjam under Cygwin as a last resort. -- 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] cstdint.hpp patch for Cray X1
Hi Dan, I don't think this will be needed since on the X1 USHRT_MAX should be 0x, and thus the default version will work. Note that the patch for the SV1 and other Crays that I submitted checks for USHRT_MAX being 0x and thus does not apply on the X1 anyways. On another note, I got jam to compile on the SV1, and have submitted a patch. Now I am running the regression tests on it. Not having access to an X1 yet (and the 4.2 compilers don't exist for other Crays), I can't run the tests there at the moment. Could you try to run it, once I have patched boost for the SV1? Best regards, Matthias On Thursday, January 23, 2003, at 05:49 PM, Dan Gohman wrote: 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. 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] Re: Re: Review results: Optional library
Fernando Cacciola said: > I've committed "Jamfile" to libs/optional/test. > > But I can't run bjam on my Win98 configuration (long command lines > problem), so I can't test it. Doesn't bjam have a fix for this issue? > Could someone test the jamfile? If it works, I'l add the entry on > status/Jamfile. It passes for me (well, sort of, toolset for vc7, vc71 and gcc-nocygwin pass, while msvc fails). However, shouldn't you be using "run" instead of "unit-test" in the Jamfile? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: undo library
Hi Andreas,
An undo library seems to be on a boundary between patterns and library
functions, so im interested in seeing how something like an undo library
plays out.
Some things ive come across include:
- The need to keep objects utilized in doIt() alive until they leave the
undo list (this sometimes is even beyond serialization). Implementers
of command objects frequently use some type of shared_ptr to keep things
alive after use (until they fall off the undo queue).
- The need to keep things simple, as Steven Kirk noted. This competes
with the need to employ a more complex (as applications grow) command /
command-manager interface. Providing a command-base-imp might be a way
to satisfy both users.
- The ability for commands that can not support undo to inform the
manager (sending an email, committing transactions, or a developer
testing new objects are examples of commands that do not support undo).
When these commands are executed, they clear the undo-stack (this can be
augmented in a UI app with a message informing the user they are about
to execute an undoable command).
- The need to support various command managers. People may want to
extend the behavior of the undo-manager, but often start out with a
default manager (templatizing the manager's container might also be an
option).
The code below might help illustrate the suggestions mentioned above
(and by S.Kirk in the previous email) for the command class (The manager
interface is a separate discussion probably :-).
- Steve
struct command
{
virtual void doIt() = 0; // Called first time
virtual void undoIt() = 0; // Called to undo
virtual void redoIt() = 0; // Called after first time
virtual bool supportsUndo() = 0;
virtual bool supportsRedo() = 0;
virtual ~command() {}
};
struct commandBinder : public command
{
commandBinder( const boost::function &doItFn,
const boost::function &redoItFn =
&commandBinder::redoUnsupported,
const boost::function &undoItFn =
&commandBinder::undoUnsupported )
: m_doItFunction( doItFn ),
m_undoItFunction( undoItFn ),
m_redoItFunction( redoItFn ) {}
virtual void invokeCommand(
const boost::function &fn, const std::string &msg )
{
if ( fn.empty() )
throw undo_exception( msg.c_str() );
else
fn();
}
virtual void doIt()
{ invokeCommand( m_doItFunction, "" ); }
virtual void redoIt()
{ invokeCommand( m_redoItFunction, "redoIt unsupported" ); }
virtual void undoIt()
{ invokeCommand( m_undoItFunction, "undoIt unsupported" ); }
virtual bool supportsUndo() { return !m_undoItFunction.empty(); }
virtual bool supportsRedo() { return !m_redoItFunction.empty(); }
boost::function m_doItFunction;
boost::function m_redoItFunction;
boost::function m_undoItFunction;
static void undoUnsupported() {}
static void redoUnsupported() {}
virtual ~commandBinder() {}
};
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[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: gcc-Link-action .../../../libs/thread/test/bin/test_thread.test/gcc/debug/runtime -link-static/threading-multi/test_thread /usr/bin/ld: cannot find -lrt collect2: ld returned 1 exit status LD_LIBRARY_PATH=../../../libs/thread/build/bin/libboost_thread.so/gcc/debug/ runtime-link-static/shared-linkable-true/threading-multi export LD_LIBRARY_PATH g++ -static -g -pthread -o "../../../libs/thread/test/bin/test_thread.tes t/gcc/debug/runtime-link-static/threading-multi/test_thread" -L"../../../libs/t hread/build/bin/libboost_thread.so/gcc/debug/runtime-link-static/shared-linkable -true/threading-multi" "../../../libs/thread/test/bin/test_thread.test/gcc/deb ug/runtime-link-static/threading-multi/test_thread.o" "../../../libs/test/build /bin/libboost_unit_test_framework.a/gcc/debug/runtime-link-static/threading-mult i/libboost_unit_test_framework.a" "../../../libs/test/build/bin/libboost_unit_te st_framework.a/gcc/debug/runtime-link-static/threading-multi/libboost_unit_test_ framework.a" "../../../libs/test/build/bin/libboost_unit_test_framework.a/gcc/d ebug/runtime-link-static/threading-multi/libboost_unit_test_framework.a" "../../ .../libs/test/build/bin/libboost_unit_test_framework.a/gcc/debug/runtime-link-sta tic/threading-multi/libboost_unit_test_framework.a" -lrt -lboost_thread -Wl,- rpath-link,. Can anyone explain to me what's wrong on my system that -lrt isn't finding the library? William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[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. 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
Re: [boost] Re: MPL usage for code generation
On Thu, 23 Jan 2003, David Abrahams wrote: > Douglas Paul Gregor <[EMAIL PROTECTED]> writes: > > > On Thu, 23 Jan 2003, David Abrahams wrote: > >> AFAICT it > >> doesn't solve the problem that Andrei was pointing at. > > > > You mean the front/pop_front issue? > > No, I mean the complexity-of-expression issue. Hmmm, I don't see how that issue applies. STL users know how to write function objects. It's not a gigantic leap to write function objects with a templated function call operator (at least, it isn't if you've already decided to play with template metaprogramming). The rest of the syntax is inherited from STL. I don't see any extra complexity here. Granted, it means pulling in a lot more code than Andrei's version, but as one who has written that same bit of code approximately a billion times I'm ready for a simple, familiar abstraction. > > Just stick your third-party iterators into sequence<> and you're all set; > > I'd expect that mpl::list, mpl::vector, etc. would just derive from > > mpl::sequence to reduce the amount of typing in the common case. > > Maybe it would be better to define namespace-scope begin(), end(), > et. al which can operate on STL and MPL sequences. I have two concerns with that: 1) begin and end are already class templates in MPL 2) There isn't much precedent for begin(container) and end(container); there is for container.begin() and container.end() Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: MPL usage for code generation
On Thu, 23 Jan 2003 11:22:02 -0500, David Abrahams <[EMAIL PROTECTED]> wrote: > Hugo Duncan <[EMAIL PROTECTED]> writes: > > > Including for_each.hpp on bcc561 gives > > > > Error E2230 > > c:\usr\boost\boost/mpl/aux_/preprocessed/bcc/template_arity.hpp > > 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. > > Is this with the CVS or with boost 1.29.0? > I don't think Borland support was very solid at 1.29.0. > > BC551 processes for_each.hpp just fine at the moment. With current CVS. BC551 works fine for me too (with lots of warnings) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Review results: Optional library
"Beman Dawes" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > At 01:56 PM 1/22/2003, Douglas Paul Gregor wrote: > > >On Wed, 22 Jan 2003, Fernando Cacciola wrote: > >> So, what else should I do? Is there something I need to setup in order > to > >> add optional to the regression tests? > > > >You'll probably want to create a testing Jamfile > >libs/optional/test/Jamfile. The easy way to do that is to cut 'n' paste > >from, e.g., libs/filesystem/test/Jamfile and make the obvious changes. > >Then, add "subinclude libs/optional/test/Jamfile ;" to status/Jamfile and > >the Optional tests should start showing up with the next round of > >regression testing. > > Yes, but please test your lib specific Jamfile first, before changing the > status/Jamfile. > > Developers should always make sure the local Jamfile works before > subincluding it in the main Boost Jamfile. > > See the recently updated docs in more/regression.html > OK. I've committed "Jamfile" to libs/optional/test. But I can't run bjam on my Win98 configuration (long command lines problem), so I can't test it. Could someone test the jamfile? If it works, I'l add the entry on status/Jamfile. TIA -- Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "John Maddock" <[EMAIL PROTECTED]>
>> >From Peter Dimov:
>>
>> >Nope, it says nothing AFAICS. A type cannot be convertible. Only values
>> are.
>> >And you cannot say "a value of type From is implicitly convertible to To
>> >(4.0)" because you need to specify whether that value is an lvalue of
> type
>> >From or an rvalue of type From, and what do l- and r-values mean when
>> >applied to strange (array, reference, function, abstract, etc) types.
>>
>> I refer you back to 4.0p3, which talks about expressions of type T, which
>> are treated as lvalues if the type is a reference, otherwise as an rvalue.
>
> Thanks.
>
> I don't think that 4.0p3 explains everything, though. I doesn't talk about
> expressions of type T. It talks about converting an expression e to type T;
> it then explains that the result of that conversion is an lvalue when T
> ("To" in our case) is a reference type. It says that e is "used as an
> lvalue" if and only if the initialization T t(e) would have used it as an
> lvalue.
>
> This still doesn't solve the "expression of type From" problem since an
> expression can be either an lvalue or an rvalue, and there are no
> expressions of reference types, only expressions that are lvalues. Of course
> I'm not a core expert.
>
> For example, is an expression of type int[4] convertible to int[4]? To int
> (&) [4]? To int const [4]?
If it's any help, here's what John Spicer says:
> David Abrahams <[EMAIL PROTECTED]> writes:
>
>>Hi John,
>>
>>I realize there's a lot of material here, but I wonder if you wouldn't
>>mind taking a look at it all the same? We're having problems
>>understanding how to talk about the behavior of the is_convertible
>>trait from the type traits library (and standard proposal). Any
>>guidance you could give would be very helpful.
>>
I'm happy to voice an opinion, although I don't think I
have anything to add that hasn't already been said.
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.
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.
- There were several mentions of prohibiting abstract
types. Expressions of abstract class type can be the
source of an implicit conversion, however.
- 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*.
Hope this is of some use.
--
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
Hugo Duncan <[EMAIL PROTECTED]> writes: > Including for_each.hpp on bcc561 gives > > Error E2230 > c:\usr\boost\boost/mpl/aux_/preprocessed/bcc/template_arity.hpp > 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. Is this with the CVS or with boost 1.29.0? I don't think Borland support was very solid at 1.29.0. BC551 processes for_each.hpp just fine at the moment. -- 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: [Boost-docs] Integrating BoostBook documentationwith HTMLdocumentation
On Thu, 23 Jan 2003, David Abrahams wrote: > I've been watching this thread go by; kept a bunch of messages in my > inbox because I didn't know what to make of them, and now I realize I > still don't. It looks like there is going to be a big learning curve > for me; I have practically no XML/XSLT experience to begin with, not > to mention that I don't understand lots of other issues. Should I be > doing something other than sitting on the sidelines? > > -Dave You won't need to know any XSLT unless you want to introduce additional features into BoostBook. The learning curve for XML is practically nonexistant. There's a few lines of boilerplate code for identifying a particular document as a BoostBook document. From there on, it's just a matter of matching tags :). I've found XML tools to be quite good: parser error messages are generally quite obvious, and some text editors can help avoid lots of dumb mistakes. In the next few days I'll be writing a tutorial on BoostBook, describing the documentation of a small library (boost::any). That should drastically reduce the hassle of learning BoostBook, and make it feasible for others to try it out. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Douglas Paul Gregor <[EMAIL PROTECTED]> writes:
> On Thu, 23 Jan 2003, David Abrahams wrote:
>
>> Douglas Paul Gregor <[EMAIL PROTECTED]> writes:
>>
>> > Why don't we have
>> >
>> > mpl::list list_of_types;
>> > for_each(list_of_types.begin(), list_of_types.end(), f);
>> >
>> > ?
>> >
>> > Then an unqualified for_each call can handle type sequences, heterogeneous
>> > containers (e.g., tuple), and run-time sequences (e.g., vector). It's been
>> > done before, elsewhere, so why don't we do it in MPL?
>>
>> It's clever, but I'm not sure what problem it's solving.
>
> I mentioned this before and cited the paper "Static Data
> Structures: Reconciling Template Metaprogramming and Generic Programming":
> http://aspn.activestate.com/ASPN/Mail/Message/1304415
>
> The title says it all: we have generic programming and template
> metaprogramming, and they complement each other nicely, but at the barrier
> between them I feel that we have a kludge. MPL and STL are built on the
> same abstractions, with similar naming schemes and similar style, so why
> is it that at the bridge between the two we have something that looks like
> neither? I think the for_each syntax I'm referring to is a clean bridge
> between the two, because it (logically, if not in code) maps the syntax of
> STL iterators to the syntax of MPL iterators in standard algorithm calls.
> The paper I referred to gave the most compelling argument for having
> precisely the same syntax at the bridge: you can test with the run-time
> version (short compile times) and release with the compile-time version
> (short execution times): they needed only to switch the object from
> std::vector to a compile-time vector, wait for KAI C++ to grind away for
> 24 hours, and they got 171 times the performance.
OK, point taken. I think it's worth examining.
>> AFAICT it
>> doesn't solve the problem that Andrei was pointing at.
>
> You mean the front/pop_front issue?
No, I mean the complexity-of-expression issue.
>> It also has at
>> least one problem: it is intrusive on sequence types, requiring them
>> to have begin()/end() member functions. If this was the only way to
>> do it, it would break interoperability with 3rd-party type sequences.
>>
>> -Dave
>
> That's easy to fix---I was just trying to keep the example small. A few
> extra abstractions would be needed:
>
> namespace mpl {
> // Special type that for_each can pick up on
> template
> struct iterator
> {
> typedef Iterator type;
> };
>
> // Stores an MPL sequence defined by an iterator range
> template
> struct sequence
> {
> iterator begin() const { return iterator(); }
> iterator end() const { return iterator(); }
> };
>
> template
> F for_each(iterator first, iterator last, F f)
> {
> // ...
> }
> }
>
> Just stick your third-party iterators into sequence<> and you're all set;
> I'd expect that mpl::list, mpl::vector, etc. would just derive from
> mpl::sequence to reduce the amount of typing in the common case.
Maybe it would be better to define namespace-scope begin(), end(),
et. al which can operate on STL and MPL sequences.
--
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: MPL usage for code generation
Including for_each.hpp on bcc561 gives Error E2230 c:\usr\boost\boost/mpl/aux_/preprocessed/bcc/template_arity.hpp 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. Hugo ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] threads and gcc and BSD
From: "Rene Rivera" <[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... GCC 2.95.3/MinGW defines _MT=1 when -mthreads is used. GCC 2.96/Linux defines _REENTRANT=1 when -pthread is used. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
On Thu, 23 Jan 2003, David Abrahams wrote:
> Douglas Paul Gregor <[EMAIL PROTECTED]> writes:
>
> > Why don't we have
> >
> > mpl::list list_of_types;
> > for_each(list_of_types.begin(), list_of_types.end(), f);
> >
> > ?
> >
> > Then an unqualified for_each call can handle type sequences, heterogeneous
> > containers (e.g., tuple), and run-time sequences (e.g., vector). It's been
> > done before, elsewhere, so why don't we do it in MPL?
>
> It's clever, but I'm not sure what problem it's solving.
I mentioned this before and cited the paper "Static Data
Structures: Reconciling Template Metaprogramming and Generic Programming":
http://aspn.activestate.com/ASPN/Mail/Message/1304415
The title says it all: we have generic programming and template
metaprogramming, and they complement each other nicely, but at the barrier
between them I feel that we have a kludge. MPL and STL are built on the
same abstractions, with similar naming schemes and similar style, so why
is it that at the bridge between the two we have something that looks like
neither? I think the for_each syntax I'm referring to is a clean bridge
between the two, because it (logically, if not in code) maps the syntax of
STL iterators to the syntax of MPL iterators in standard algorithm calls.
The paper I referred to gave the most compelling argument for having
precisely the same syntax at the bridge: you can test with the run-time
version (short compile times) and release with the compile-time version
(short execution times): they needed only to switch the object from
std::vector to a compile-time vector, wait for KAI C++ to grind away for
24 hours, and they got 171 times the performance.
> AFAICT it
> doesn't solve the problem that Andrei was pointing at.
You mean the front/pop_front issue?
> It also has at
> least one problem: it is intrusive on sequence types, requiring them
> to have begin()/end() member functions. If this was the only way to
> do it, it would break interoperability with 3rd-party type sequences.
>
> -Dave
That's easy to fix---I was just trying to keep the example small. A few
extra abstractions would be needed:
namespace mpl {
// Special type that for_each can pick up on
template
struct iterator
{
typedef Iterator type;
};
// Stores an MPL sequence defined by an iterator range
template
struct sequence
{
iterator begin() const { return iterator(); }
iterator end() const { return iterator(); }
};
template
F for_each(iterator first, iterator last, F f)
{
// ...
}
}
Just stick your third-party iterators into sequence<> and you're all set;
I'd expect that mpl::list, mpl::vector, etc. would just derive from
mpl::sequence to reduce the amount of typing in the common case.
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] threads and gcc and BSD
[2003-01-23] William E. Kempf wrote:
>> I think I may be the one who broke a lot of the OpenBSD regression tests
>> by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration.
>> IMO this is correct (OpenBSD supports pthreads right?),
Yes it does... with the -pthread flag.
>> but it causes a
>> problem: currently the gcc config unconditionally defines
>> BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc
>> on *BSD doesn't define anything when you build with -pthread - basically
>> defining -pthread affects only the linker, so we can't detect when to
>> turn on threading support).
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...
red5of5:grafik {108} gcc -E -dM empty.c
#define __i386__ 1
#define __GNUC_MINOR__ 95
#define __unix__ 1
#define __OpenBSD__ 1
#define __GNUC__ 2
red5of5:grafik {109} gcc -E -dM -pthread empty.c
#define __i386__ 1
#define __GNUC_MINOR__ 95
#define _POSIX_THREADS 1
#define __unix__ 1
#define __OpenBSD__ 1
#define __GNUC__ 2
red5of5:grafik {110} /usr/local/gcc-3.2/bin/gcc -E -dM empty.c
#define __HAVE_BUILTIN_SETJMP__ 1
#define __OpenBSD__ 1
#define __unix__ 1
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define __GNUC_PATCHLEVEL__ 0
#define __USER_LABEL_PREFIX__ _
#define __STDC_HOSTED__ 1
#define __WCHAR_TYPE__ int
#define __WINT_TYPE__ unsigned int
#define __GNUC__ 3
#define __USING_SJLJ_EXCEPTIONS__ 1
#define __GXX_ABI_VERSION 102
#define i386 1
#define __GNUC_MINOR__ 2
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __tune_i386__ 1
#define __REGISTER_PREFIX__
#define __NO_INLINE__ 1
#define __i386 1
#define __VERSION__ "3.2"
red5of5:grafik {111} /usr/local/gcc-3.2/bin/gcc -E -dM -pthread empty.c
#define __HAVE_BUILTIN_SETJMP__ 1
#define __OpenBSD__ 1
#define __unix__ 1
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define _POSIX_THREADS 1
#define __GNUC_PATCHLEVEL__ 0
#define __USER_LABEL_PREFIX__ _
#define __STDC_HOSTED__ 1
#define __WCHAR_TYPE__ int
#define __WINT_TYPE__ unsigned int
#define __GNUC__ 3
#define __USING_SJLJ_EXCEPTIONS__ 1
#define __GXX_ABI_VERSION 102
#define i386 1
#define __GNUC_MINOR__ 2
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __tune_i386__ 1
#define __REGISTER_PREFIX__
#define __NO_INLINE__ 1
#define __i386 1
#define __VERSION__ "3.2"
-- grafik - Don't Assume Anything
-- [EMAIL PROTECTED] - [EMAIL PROTECTED]
-- 102708583@icq
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Boost-docs] Integrating BoostBook documentationwith HTMLdocumentation
I've been watching this thread go by; kept a bunch of messages in my inbox because I didn't know what to make of them, and now I realize I still don't. It looks like there is going to be a big learning curve for me; I have practically no XML/XSLT experience to begin with, not to mention that I don't understand lots of other issues. Should I be doing something other than sitting on the sidelines? -Dave -- 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
David Abrahams said: > "William E. Kempf" <[EMAIL PROTECTED]> writes: > >> John Maddock said: >>> I think I may be the one who broke a lot of the OpenBSD regression >>> tests by defining BOOST_HAS_PTHREADS in the OpenBSD platform >>> configuration. IMO this is correct (OpenBSD supports pthreads >>> right?), but it causes a problem: currently the gcc config >>> unconditionally defines >>> BOOST_HAS_THREADS, basically because we didn't know what else to do >>> (gcc on *BSD doesn't define anything when you build with -pthread - >>> basically defining -pthread affects only the linker, so we can't >>> detect when to turn on threading support). This in turn is breaking a >>> lot of libraries: mainly those that depend upon smart pointers, which >>> do internal thread synchronisation, and therefore need the -pthread >>> option in order to link correctly. >>> >>> What should we do about this? >>> >>> Option 1: >>> ~~ >>> >>> would putting: >>> >>> flags gcc CFLAGS single : -DBOOST_DISABLE_THREADS >>> ; >>> >>> fix the problem? >>> >>> Option 2: >>> ~~ >>> >>> Add >>> >>> flags gcc CFLAGS multi : -pthread -D_REENTRANT ; >>> >>> to the toolset, and stop defining BOOST_HAS_THREADS unconditionally >>> for gcc. This one may have all sorts of unexpected side effects on >>> other platforms though - even though philosophically it does seem the >>> right thing to do. >>> >>> Option 3: >>> ~~ >>> >>> Make -pthread the default build option in the gcc toolset for *BSD >>> platforms >>> >>> ~~~ >> >> Seems to me like this should be reversed. Have the config headers >> unconditionally NOT define BOOST_HAS_THREADS, and have the Jam >> toolsets define it when threading is requested. > > I don't love that idea because it ties a very boost-specific define into > the core of Boost.Build, which is really supposed to be a general build > system. How will people deal with the next such define for some other > library? Sorry, sent prematurely. The response above was meant to be about option 1, and I fully agree that it's not a good solution (and said so in the text you deleted). To finish my thoughts on the other two options... Option 2 sounds like the right solution to me, though I'm not sure about the purpose for _REENTRANT. Is it expected that users will define this on POSIX systems, or is this a define that was expected to be defined by the implementation? Option 3 would cause unecessary overhead, so doesn't sound like the right solution. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] threads and gcc and BSD
"William E. Kempf" <[EMAIL PROTECTED]> writes: > John Maddock said: >> I think I may be the one who broke a lot of the OpenBSD regression tests >> by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration. >> IMO this is correct (OpenBSD supports pthreads right?), but it causes a >> problem: currently the gcc config unconditionally defines >> BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc >> on *BSD doesn't define anything when you build with -pthread - basically >> defining -pthread affects only the linker, so we can't detect when to >> turn on threading support). This in turn is breaking a lot of libraries: >> mainly those that depend upon smart pointers, which do internal thread >> synchronisation, and therefore need the -pthread option in order to link >> correctly. >> >> What should we do about this? >> >> Option 1: >> ~~ >> >> would putting: >> >> flags gcc CFLAGS single : -DBOOST_DISABLE_THREADS ; >> >> fix the problem? >> >> Option 2: >> ~~ >> >> Add >> >> flags gcc CFLAGS multi : -pthread -D_REENTRANT ; >> >> to the toolset, and stop defining BOOST_HAS_THREADS unconditionally for >> gcc. This one may have all sorts of unexpected side effects on other >> platforms though - even though philosophically it does seem the right >> thing to do. >> >> Option 3: >> ~~ >> >> Make -pthread the default build option in the gcc toolset for *BSD >> platforms >> >> ~~~ > > Seems to me like this should be reversed. Have the config headers > unconditionally NOT define BOOST_HAS_THREADS, and have the Jam toolsets > define it when threading is requested. I don't love that idea because it ties a very boost-specific define into the core of Boost.Build, which is really supposed to be a general build system. How will people deal with the next such define for some other library? -- 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
John Maddock said: > I think I may be the one who broke a lot of the OpenBSD regression tests > by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration. > IMO this is correct (OpenBSD supports pthreads right?), but it causes a > problem: currently the gcc config unconditionally defines > BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc > on *BSD doesn't define anything when you build with -pthread - basically > defining -pthread affects only the linker, so we can't detect when to > turn on threading support). This in turn is breaking a lot of libraries: > mainly those that depend upon smart pointers, which do internal thread > synchronisation, and therefore need the -pthread option in order to link > correctly. > > What should we do about this? > > Option 1: > ~~ > > would putting: > > flags gcc CFLAGS single : -DBOOST_DISABLE_THREADS ; > > fix the problem? > > Option 2: > ~~ > > Add > > flags gcc CFLAGS multi : -pthread -D_REENTRANT ; > > to the toolset, and stop defining BOOST_HAS_THREADS unconditionally for > gcc. This one may have all sorts of unexpected side effects on other > platforms though - even though philosophically it does seem the right > thing to do. > > Option 3: > ~~ > > Make -pthread the default build option in the gcc toolset for *BSD > platforms > > ~~~ Seems to me like this should be reversed. Have the config headers unconditionally NOT define BOOST_HAS_THREADS, and have the Jam toolsets define it when threading is requested. The reasoning is how this will work/effect people using Boost in their own projects when they do not use Jam for building. But even this is an unatractive solution. William E. Kempf [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
Douglas Paul Gregor <[EMAIL PROTECTED]> writes: > Why don't we have > > mpl::list list_of_types; > for_each(list_of_types.begin(), list_of_types.end(), f); > > ? > > Then an unqualified for_each call can handle type sequences, heterogeneous > containers (e.g., tuple), and run-time sequences (e.g., vector). It's been > done before, elsewhere, so why don't we do it in MPL? It's clever, but I'm not sure what problem it's solving. AFAICT it doesn't solve the problem that Andrei was pointing at. It also has at least one problem: it is intrusive on sequence types, requiring them to have begin()/end() member functions. If this was the only way to do it, it would break interoperability with 3rd-party type sequences. -Dave -- 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
On Wed, 22 Jan 2003, David Abrahams wrote:
> I've been talking with Aleksey recently about how to improve the
> syntactic situation without losing the separation of concerns that we
> get, but we didn't come up with anything convincingly better. I think
> a long time ago the for_each parameter used to look like:
>
> class f
> {
> template
> struct apply
> {
> static void execute() {...};
> };
> };
>
> IOW, a metafunction class with a nested 'execute' function. However
> that's not really any better syntactically, it has problems carrying
> state, and it's anti-idiomatic.
Why don't we have
mpl::list list_of_types;
for_each(list_of_types.begin(), list_of_types.end(), f);
?
Then an unqualified for_each call can handle type sequences, heterogeneous
containers (e.g., tuple), and run-time sequences (e.g., vector). It's been
done before, elsewhere, so why don't we do it in MPL?
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: undo library
Hi Stefan!
Well you could implement it like this (if that works, didn't test it yet).
Although you would still need a wrapping undo_list class, to implement all
the undo/redo-relationship, the checks "is the undo-vector already empty"
etc., basically everything that's in my undo_list class already (at there
are quite a few bits). So in fact one would change the storage members and
change the interface for the user.
Instead of writing undo-classes with a constructor, an undo-function and a
redo-function (that makes 3) one would have to write two functions, that
take the appropriate parameters (so speaking in numbers, you would save 1
function).
BUT, when executing the undo-code one might want to add a redo-function to
the redo list and all shared properties/member-variables have to be copied
yourself:
void string_erase_undo(std::string& dest, int pos, std::string to_insert) {
dest.insert(pos, to_insert);
// now add the redo function
redolist.push_back(boost::bind(string_erase_redo, dest, pos,
to_insert(size)));
// questions: 1. What is redolist? does every undo/redo-function need to
know this?
//2. Do I really have to copy all the function parameters?
//3. Why do I (the undo function) have to add the redo
function? This is
// multiplying the same code (in every undo and redo
function)
}
Ok, there you see some of the problems/disadvantages of this approach.
Well, there's another minor advantage of my solution. You wouldn't be
obliged to use other libraries (even though this are boost library
elements).
Thinking it over I came to the conclusion that the derived-undo_action-class
version is the most convenient and most flexible way of doing so... but
there's surely something I forgot to think of!?
Bye - Andreas
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
"Peter Dimov" <[EMAIL PROTECTED]> writes:
> From: "David Abrahams" <[EMAIL PROTECTED]>
>>
>> I've been talking with Aleksey recently about how to improve the
>> syntactic situation without losing the separation of concerns that we
>> get, but we didn't come up with anything convincingly better. I think
>> a long time ago the for_each parameter used to look like:
>>
>> class f
>> {
>> template
>> struct apply
>> {
>> static void execute() {...};
>> };
>> };
>>
>> IOW, a metafunction class with a nested 'execute' function. However
>> that's not really any better syntactically, it has problems carrying
>> state, and it's anti-idiomatic.
>
> The state problem is easy:
>
> struct F
> {
> template void execute();
> };
Which isn't usable portably on all broken platforms, nor is it that
different from:
struct F
{
template void operator()(T) { ... };
};
it's-a-bag-'o'-tradeoffs-ly y'rs,
dave
--
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] undo library
Just one thought : couldn't much of this be achieved without having to
create your own undo classes by boost::functions and the boost::bind
library?
for example, to implement just the undo (untested code, just to give an
idea, I'm not suggesting that this wouldn't be better wrapped in an
undo_list class):
-
void string_erase_undo(std::string& dest, int pos, std::string to_insert)
{
dest.insert(pos, to_insert);
}
std::vector< boost::function > undolist;
std::string teststring = "This is a simple test of the boost undo library";
undolist.push_back(boost::bind(string_erase_undo, teststring, 10,
std::string(teststring, 10, 7));
teststring.erase(10, 7);
// to undo:
undolist.back()()
-
> Hello there!
>
> I just wanted to ask if there would be someone interested in a framework
> library for undo/redo-functionality. In other C++ groups sometimes the
> question pops up, how to implement undo-functionality. Since I've written
> such thing as part of a programm of mine and since I have it "boostenised"
> already, I would like to introduce it briefly. Please feel free to give me
> any comments about it...
>
> Basicly there are two classes: boost::undo_list and boost::undo_action,
the
> latter is an abstract base class for any undo-function you want to
> provide...
> Instead of describing all the details I'll just give a short example of
how
> one could use the library...
> //
> #include
> #include
> using namespace std;
>
> #include "undo_action.hpp" // class boost::undo_action
> #include "undo_list.hpp"// class boost::undo_list
>
> #include "myown_undoactions.hpp" // contains undo-action classes
>
> int main() {
> // 1. create the undo list somewhere
> boost::undo_list undolist;
> // 2. maybe you want to change the number of maximum undo steps
> undolist.set_maxundo(100);
>
> string teststring;
> teststring = "This is a simple test of the boost undo library";
>
> cout << "Original string: " << teststring << endl;
>
> // Ok, someone want's to remove a part of that string.
> // let's start with constructing the undo-action and adding that to
> // the undo list. The class StringEraseUndo is a user defined
> // undo class derived from undo_action
>
> // 3. create and add an undo action
>
> // NOTE: the constructor can look whatever the user wants it
> // to look like (see example at end of posting)
> undolist.add( new StringEraseUndo(10, 7,
> teststring.substr(10, 7), teststring) );
>
> // NOTE: All pointers added to the list make the objects
> // be OWNED by the list, thus the list is responsable
> // for cleaning up the memory
>
> // 4. perform the will-be-made-undone action
> // That means, let's finally delete that substring
> teststring.erase(10, 7);
> cout << "After erase: " << teststring << endl;
>
> // 5. and now let's make this undone...
> undolist.undo_last();
> cout << "After UNDO: " << teststring << endl;
>
> // 6. or re-done, if you like
> undolist.redo_last();
> cout << "After REDO: " << teststring << endl;
> };
> //
>
> Well, it is obvious that the biggest problem in using the undo-library
will
> be the implementation of the user defined undo/redo-classes.
> For the example above the class StringEraseUndo could look like this:
>
> class StringEraseUndo : public undo_action {
> public:
> // Ctor
> StringEraseUndo(std::size_t start, std::size_t size,
> const std::string& snipped, std::string& str)
> : start_(start), size_(size), snipped_(snipped), str_(str) {};
>
> virtual bool undo();
> virtual void redo();
>
> private:
> std::size_t start_;
> std::size_t size_;
> std::string snipped_;
> std::string& str_;
> };
>
> bool StringEraseUndo::undo() {
> str_.insert(start_, snipped_);
> return true;
> };
>
> void StringEraseUndo::redo() {
> str_.erase(start_, size_);
> };
>
>
> However, since the undo-classes can be whatever they want to be, including
> non-C++-standard stuff like GUI things, this library can be used in almost
> any circumstances. The Framework, that is the undo_list and the
undo_action
> classes can still be written in plain C++ without having to know anything
> about the users environment. This clearly qualifies these classes as a
> library.
>
> Sorry for the long text, but with just describing the system shortly it
> would have caused too much confusion :-)
>
> The library itself (that is the undo_action.hpp, undo_list.hpp and
> undo_list.cpp) are ready so far. Do you think this could be a useful
> addition to the boost library?
>
> Thanks for any comments!
> Bye - Andreas
>
>
> ___
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
___
Unsu
Re: [boost] Re: is_convertible corner case
From: "John Maddock" <[EMAIL PROTECTED]>
> >From Peter Dimov:
>
> >Nope, it says nothing AFAICS. A type cannot be convertible. Only values
> are.
> >And you cannot say "a value of type From is implicitly convertible to To
> >(4.0)" because you need to specify whether that value is an lvalue of
type
> >From or an rvalue of type From, and what do l- and r-values mean when
> >applied to strange (array, reference, function, abstract, etc) types.
>
> I refer you back to 4.0p3, which talks about expressions of type T, which
> are treated as lvalues if the type is a reference, otherwise as an rvalue.
Thanks.
I don't think that 4.0p3 explains everything, though. I doesn't talk about
expressions of type T. It talks about converting an expression e to type T;
it then explains that the result of that conversion is an lvalue when T
("To" in our case) is a reference type. It says that e is "used as an
lvalue" if and only if the initialization T t(e) would have used it as an
lvalue.
This still doesn't solve the "expression of type From" problem since an
expression can be either an lvalue or an rvalue, and there are no
expressions of reference types, only expressions that are lvalues. Of course
I'm not a core expert.
For example, is an expression of type int[4] convertible to int[4]? To int
(&) [4]? To int const [4]?
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] undo library
Hello there!
I just wanted to ask if there would be someone interested in a framework
library for undo/redo-functionality. In other C++ groups sometimes the
question pops up, how to implement undo-functionality. Since I've written
such thing as part of a programm of mine and since I have it "boostenised"
already, I would like to introduce it briefly. Please feel free to give me
any comments about it...
Basicly there are two classes: boost::undo_list and boost::undo_action, the
latter is an abstract base class for any undo-function you want to
provide...
Instead of describing all the details I'll just give a short example of how
one could use the library...
//
#include
#include
using namespace std;
#include "undo_action.hpp" // class boost::undo_action
#include "undo_list.hpp"// class boost::undo_list
#include "myown_undoactions.hpp" // contains undo-action classes
int main() {
// 1. create the undo list somewhere
boost::undo_list undolist;
// 2. maybe you want to change the number of maximum undo steps
undolist.set_maxundo(100);
string teststring;
teststring = "This is a simple test of the boost undo library";
cout << "Original string: " << teststring << endl;
// Ok, someone want's to remove a part of that string.
// let's start with constructing the undo-action and adding that to
// the undo list. The class StringEraseUndo is a user defined
// undo class derived from undo_action
// 3. create and add an undo action
// NOTE: the constructor can look whatever the user wants it
// to look like (see example at end of posting)
undolist.add( new StringEraseUndo(10, 7,
teststring.substr(10, 7), teststring) );
// NOTE: All pointers added to the list make the objects
// be OWNED by the list, thus the list is responsable
// for cleaning up the memory
// 4. perform the will-be-made-undone action
// That means, let's finally delete that substring
teststring.erase(10, 7);
cout << "After erase: " << teststring << endl;
// 5. and now let's make this undone...
undolist.undo_last();
cout << "After UNDO: " << teststring << endl;
// 6. or re-done, if you like
undolist.redo_last();
cout << "After REDO: " << teststring << endl;
};
//
Well, it is obvious that the biggest problem in using the undo-library will
be the implementation of the user defined undo/redo-classes.
For the example above the class StringEraseUndo could look like this:
class StringEraseUndo : public undo_action {
public:
// Ctor
StringEraseUndo(std::size_t start, std::size_t size,
const std::string& snipped, std::string& str)
: start_(start), size_(size), snipped_(snipped), str_(str) {};
virtual bool undo();
virtual void redo();
private:
std::size_t start_;
std::size_t size_;
std::string snipped_;
std::string& str_;
};
bool StringEraseUndo::undo() {
str_.insert(start_, snipped_);
return true;
};
void StringEraseUndo::redo() {
str_.erase(start_, size_);
};
However, since the undo-classes can be whatever they want to be, including
non-C++-standard stuff like GUI things, this library can be used in almost
any circumstances. The Framework, that is the undo_list and the undo_action
classes can still be written in plain C++ without having to know anything
about the users environment. This clearly qualifies these classes as a
library.
Sorry for the long text, but with just describing the system shortly it
would have caused too much confusion :-)
The library itself (that is the undo_action.hpp, undo_list.hpp and
undo_list.cpp) are ready so far. Do you think this could be a useful
addition to the boost library?
Thanks for any comments!
Bye - Andreas
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is_convertible corner case
> >Well the wording in the standardisation proposal says: > > > >"value: defined to be true only if type From is implicitly-convertible to > >type To (4.0). > > > >Which really says it all IMO (by reference to section 4.0 of the standard. > > Gulp! In the ISO proposal??? OK it needs tightening up: in particular the preconditions need specifying (To must not be a void, function, incomplete or abstract type, From must not be void), and it should probably say "value: defined to be true only if an expression of type From is implicitly-convertible to type To (4.0)." Getting the wording right is difficult, but the semantics are intended to be the same as 4.0p3. Personally I would be happy if it were a precondition that neither To nor From were void types. >It makes sense only if you want it to make sense. That is, like almost >all other cases, it depends on your definition of is_convertible, >which is exactly what we miss. The fact that I had to ask means that >the definition in the documentation is not enough, and that I must *as >a library user* go to look at the implementation to see what happens >in my special case. The problem is that even then I remain in doubt: >is this just a "chance" due to the way they have implemented it or is >it intentional? If they'll change the implementation in the future can >the value be different so that my code is unexpectedly broken? I agree, there should be no special cases, the wording should refer only to the standard, not to the implementation. >From Peter Dimov: >Nope, it says nothing AFAICS. A type cannot be convertible. Only values are. >And you cannot say "a value of type From is implicitly convertible to To >(4.0)" because you need to specify whether that value is an lvalue of type >From or an rvalue of type From, and what do l- and r-values mean when >applied to strange (array, reference, function, abstract, etc) types. I refer you back to 4.0p3, which talks about expressions of type T, which are treated as lvalues if the type is a reference, otherwise as an rvalue. John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] threads and gcc and BSD
I think I may be the one who broke a lot of the OpenBSD regression tests by defining BOOST_HAS_PTHREADS in the OpenBSD platform configuration. IMO this is correct (OpenBSD supports pthreads right?), but it causes a problem: currently the gcc config unconditionally defines BOOST_HAS_THREADS, basically because we didn't know what else to do (gcc on *BSD doesn't define anything when you build with -pthread - basically defining -pthread affects only the linker, so we can't detect when to turn on threading support). This in turn is breaking a lot of libraries: mainly those that depend upon smart pointers, which do internal thread synchronisation, and therefore need the -pthread option in order to link correctly. What should we do about this? Option 1: ~~ would putting: flags gcc CFLAGS single : -DBOOST_DISABLE_THREADS ; fix the problem? Option 2: ~~ Add flags gcc CFLAGS multi : -pthread -D_REENTRANT ; to the toolset, and stop defining BOOST_HAS_THREADS unconditionally for gcc. This one may have all sorts of unexpected side effects on other platforms though - even though philosophically it does seem the right thing to do. Option 3: ~~ Make -pthread the default build option in the gcc toolset for *BSD platforms ~~~ Any other ideas? 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: MPL usage for code generation
From: "David Abrahams" <[EMAIL PROTECTED]>
>
> I've been talking with Aleksey recently about how to improve the
> syntactic situation without losing the separation of concerns that we
> get, but we didn't come up with anything convincingly better. I think
> a long time ago the for_each parameter used to look like:
>
> class f
> {
> template
> struct apply
> {
> static void execute() {...};
> };
> };
>
> IOW, a metafunction class with a nested 'execute' function. However
> that's not really any better syntactically, it has problems carrying
> state, and it's anti-idiomatic.
The state problem is easy:
struct F
{
template void execute();
};
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
>From: "Terje Slettebø" <[EMAIL PROTECTED]> > > I can imagine something like this: > > template void Function(T)> > struct for_each; > > Possibly using overloaded class templates, as well (another possible > extension). Come to think of it, the latter wouldn't be needed here, as for_each is a function template, and they can be overloaded. :) That would allow different arity for the the function template template parameter. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: MPL usage for code generation
>From: "David Abrahams" <[EMAIL PROTECTED]> > > Terje Slettebø <[EMAIL PROTECTED]> writes: > > > > Perhaps it might be possible to do some compile-time/run-time lambda > > (similar to Boost.Lambda for runtime, and MPL's lambda), so you could do > > something like: > > > > mpl::for_each(my_function<_>(s)); > > > > It would then transform the function call "my_function<_>(s)" into an > > instantiated function object of the kind suitable for mpl::for_each. > > I'm afraid that particular syntax won't work for this particular case, > though. If my_function is a function template, my_function<_> is a > function, and my_function<_>(s) calls that function. Yes, even with function template template parameters, the syntax would have to be changed. I realised that you can't just pass the address of a function, since in this case, it's a function template. Besides, it wouldn't help to use the placeholder in that place (unless you specialised the user-supplied function, but that would be no point). The above was just to sketch the idea of it. > Since there are no (function template) template parameters, only > (class template) template parameters, there doesn't appear to be any > way to make this one particularly easy except by using the > preprocessor to define some kind of function object. Yes, I realised that later, as well. Is there any good reason for not allowing function templates as template template parameters? I think it's amazing that we got the template facility that exists, in the standard, so maybe it simply wasn't time to consider this, to avoid delaying standardisation. If this was possible, you might have done something like this, instead (using TTP): mpl::for_each(s); > It appears to be just bad luck that higher order functional > programming with function templates is impossible in C++. Well, it might be changed in a future revision of the standard, if it turns out to be practical. I can imagine something like this: template void Function(T)> struct for_each; Possibly using overloaded class templates, as well (another possible extension). Anyway, this goes beyond the topic of Boost. Regards, Terje ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: $egression tests -- no links for Win32 errors?
Beman Dawes wrote: > There are two other versions we might want to consider eliminating (KISS): > >Messages only - Shows status only for tests with warnings or failures. >Failures only - Shows status only for tests with failures. > > I never find myself looking at those. Does anyone else use them? I certainly use the Messages only view, although my primary view has become the one with differences emphasised. If we had messages only, differences emphasised, that would probably be my default I guess if I'm the only one using them though, there's no harm in letting them go. [I keep trying to find time to sneak in some more borland fixes, but every time you think the schedule has cleared...] -- AlisdairM Team Thai Kingdom ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
