Martin Wille wrote:
Aleksey Gurtovoy wrote:
Things to be done (at large):
1) Linux regressions, on RC_1_30_0. Martin, since fixing the
aforementioned
problems involved some changes in the CVS (including some jam files),
could
you please do a clean run?
Done. No regressions.
Perfect
Misha Bergal wrote:
Our results are available now.
Looking at it:
* static_assert library name got somehow replaced with libs.
This one is really nasty. We tracked it down, and it's caused by yesterday
changes in testing.jam:
RCS file: /cvsroot/boost/boost/tools/build/testing.jam,v
David Abrahams wrote:
Great! Here's a summary of my changes:
Boost Consulting is now hosting Boost CVS mirrors. See
http://www.boost.org/more/download.html
Bugs in regression reporting in subproject tests were fixed.
Tests are now run in the context of the user's PATH
For everyone's information, here's the status of 1.30.2 release preparation.
Current status:
Two outstanding problems with the win32 regressions (accidentally revealed
bug in testing.jam + unexpected failures for the intel-stlport
configuration) have been fixed. Consequently, as at this moment,
David Abrahams wrote:
Here -
http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html
Yellow cells indicate failures on the newly added tests/compilers. The
updated report tools are not in the CVS yet, we will check them in after
the
first round of
Consider the following snippet:
void show_warning( message_dialog const, user_message );
void post_command( boost::functionvoid() );
int main()
{
boost::functionvoid( user_message ) f(
bind( post_command
, ( bind( show_warning,
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
There is another variation of the idiom, sometimes called hidden
state, which doesn't have the shortcoming in the first place:
class foo
{
public:
foo();
foo(int);
int f() const;
void g
David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
For a lightly used toolset like intel-7.1 with STLPort, looks for all
the world like a config problem seems like a good enough resolution
to me.
In that case, can I release 1.30.2? I don't like having the 1.30.1
debacle hanging
Beman Dawes wrote:
Assuming I'm release manager for 1.31.0, I'm going to publish explicit
release criteria for key platform/compiler pairs. Basically, the
criteria will be 100% accounting for all failures on those
platform/compiler pairs.
While I totally support the failures markup goal, I
David Abrahams wrote:
Regarding http://tinyurl.com/jhtn: does this compiler ever need the
typename keyword? If not, perhaps we ought to define
BOOST_NO_DEDUCED_TYPENAME for all Borland versions
Any particular failure that triggered your attention?
Aleksey
David Abrahams wrote:
Martin Wille [EMAIL PROTECTED] writes:
David Abrahams wrote:
In that case, can I release 1.30.2? I don't like having the 1.30.1
debacle hanging over my head.
There are new regressions on Linux (RC_1_30_0 branch):
David Abrahams wrote:
Many are simply not going to get better; they're due to compiler bugs
which can't be worked around.
Which is totally fine. If you provide us with the list of expected
failures, these will be cleared.
All of the *_fail tests that are failing should be cleared.
Beman Dawes wrote:
(I still haven't gotten over Microsoft being the
first compiler to pass 100%. The world takes some strange twists
sometimes.)
Well, it's not like this happened by an accident, is it? It's been
explicitly stated that they are committed to this goal, and they made it
Rene Rivera wrote:
[2003-08-11] David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
Well, sure, as long as we are in agreement about having differently
named toolsets for different compiler versions/configurations, e.g.
bcc-5.5.1
bcc-5.6.4
intel-7.1-vc60
David Abrahams wrote:
Misha and Aleksey -- I think we really need to distinguish those
failures from real regressions in the chart somehow or we'll never be
able to tell where we stand.
Well, it was assumed that when adding a new compiler one should use
re-run
the regressions against
David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
I worry a little about requiring library authors not to regress on
compiler combinations they don't test with.
Well, the regressions are run daily, so testing happens. Another
question is whether library authors care
Beman Dawes wrote:
At 05:12 AM 8/11/2003, Alisdair Meredith wrote:
Aleksey Gurtovoy wrote:
While I totally support the failures markup goal, I would like to see
_the_ release criteria to include no regressions from the previous
release item as well, preferrably for all non-beta
David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
Aleksey Gurtovoy wrote:
David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
For a lightly used toolset like intel-7.1 with STLPort, looks for
all
the world like a config problem seems like a good enough
Martin Wille wrote:
The new reports are now checked into the main trunk and RC_1_30_0
branch.
Martin, if you are interested in upgrading to these, you would need to
re-generate the expected results file from the 1.30.0 tarball run - it
has
to contain more information to support the new
David Abrahams wrote:
Misha and Aleksey -- I think we really need to distinguish those
failures from real regressions in the chart somehow or we'll never be
able to tell where we stand.
Here -
http://www.meta-comm.com/engineering/resources/cs-win32_metacomm/developer_summary_page.html
Yellow
Aleksey Gurtovoy wrote:
David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
For a lightly used toolset like intel-7.1 with STLPort, looks for all
the world like a config problem seems like a good enough resolution
to me.
In that case, can I release 1.30.2? I don't like
Aleksey Gurtovoy wrote:
David Abrahams wrote:
Misha and Aleksey -- I think we really need to distinguish those
failures from real regressions in the chart somehow or we'll never be
able to tell where we stand.
Here -
http://www.meta-comm.com/engineering/resources/cs-win32_metacomm
Beman Dawes wrote:
At 11:13 PM 8/10/2003, Aleksey Gurtovoy wrote:
Beman Dawes wrote:
Assuming I'm release manager for 1.31.0, I'm going to publish explicit
release criteria for key platform/compiler pairs. Basically, the
criteria will be 100% accounting for all failures on those
David Abrahams wrote:
Douglas Paul Gregor [EMAIL PROTECTED] writes:
On Mon, 11 Aug 2003, David Abrahams wrote:
According to your chart, the following libraries are all regressing:
function
Are these real regressions or just newly-tested compilers? Can the
library
David B. Held wrote:
Hmm...ok, I'm not getting anywhere talking about it abstractly, so
I'll just say that I'm trying to figure out how to improve the policy
adaptor interface for smart_ptr. In particular, I would like to go
from this:
smart_ptrint, my_policy_, my_other_policy_ p;
to
Beman Dawes wrote:
At 07:37 AM 8/11/2003, David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
Beman Dawes wrote:
Assuming I'm release manager for 1.31.0, I'm going to publish
explicit
release criteria for key platform/compiler pairs. Basically, the
criteria
Alisdair Meredith wrote:
Aleksey Gurtovoy wrote:
While I totally support the failures markup goal, I would like to see
_the_ release criteria to include no regressions from the previous
release item as well, preferrably for all non-beta compilers that are
currently under regression
David Abrahams wrote:
Matthias Troyer [EMAIL PROTECTED] writes:
Dear Boosters,
Since some of the applications and libraries we plan on releasing soon
rely on Boost features and bugfixes that are in the CVS but not in
Boost 1.30.[012] I wonder what the plans are for the Boost 1.31.0
David Abrahams wrote:
As far as I know the CVS is in very good health at the moment.
Uhmm, I really wouldn't say so! If you look at the main trunk report -
http://www.meta-comm.com/engineering/resources/cvs_main_trunk/developer_summary_page.html,
there are lots of regressions comparing
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
Consider the following snippet:
void show_warning( message_dialog const, user_message );
void post_command( boost::functionvoid() );
int main()
{
boost::functionvoid( user_message ) f(
bind
Brian Simpson wrote:
The implementation reasoning runs like this: It seems that the problem
with
building a switch statement to implement type selection is that a switch
statement can't be built incrementally--it is a syntactic construct. (The
currently accepted solution builds an
David Abrahams wrote:
Thanks for all the testing; the release looks pretty darned great!
Just to make sure it's understood - although expected, all the green
failures are still failures. Not that we can do much about them, of course.
From a user POV, a darned great release would be the one for
Fernando Cacciola wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] escribió en el mensaje
news:[EMAIL PROTECTED]
David Abrahams wrote:
Here's an example I just cooked up of using the PP lib to solve a
classic C++ OO problem: repeated boilerplate in the definition of
Pimpl classes
David Abrahams wrote:
Paul Mensonides [EMAIL PROTECTED] writes:
Aleksey Gurtovoy wrote:
David Abrahams wrote:
Here's an example I just cooked up of using the PP lib to solve a
classic C++ OO problem: repeated boilerplate in the definition of
Pimpl classes.
There is another
David Abrahams wrote:
I have put a diff of the changes between Version_1_30_0 and RC_1_30_0
at http://www.boost-consulting.com/diffs-1-30-1.txt. These will be
the changes that go into the Boost 1.30.1 release. Will the
authors/maintainers of the following libraries please post a brief
David Abrahams wrote:
Here's an example I just cooked up of using the PP lib to solve a
classic C++ OO problem: repeated boilerplate in the definition of
Pimpl classes.
There is another variation of the idiom, sometimes called hidden state,
which doesn't have the shortcoming in the first
David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
Any reason you cannot use
http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html?
None, in particular. This table is a little weird though:
http://www.meta-comm.com/engineering/resources
Misha Bergal wrote:
Here are the results we have:
1.30.0 tarball: http://tinyurl.com/h6cx
CVS main trunk (relative to 1.30.0 tarball): http://tinyurl.com/h6d0
CVS RC_1_30_0 branch (relative to 1.30.0 tarball):
http://tinyurl.com/h6d7
(will be available in 9 hours)
CVS RC_1_30_0
Martin Wille writes:
I'll run the tests for Linux and upload them as Linux-rc-1.30.0.
They should be available in a few hours.
Can you arrange the html so that it shows regressions from the 1.30.0
release results?
Hmm, I'd have to find out how I would do that. Is there already
some
Beman Dawes wrote:
At 04:54 PM 7/16/2003, David Abrahams wrote:
Martin Wille [EMAIL PROTECTED] writes:
Hmm, I'd have to find out how I would do that. Is there already
some support for showing diffs between two versions of the test
result tables?
Yes. Beman?
I have a hack that
David Abrahams wrote:
That's because void_ is for MPL internal use only; it's not a type
you should manipulate
While I agree that _some_ user needs for a special unique type a
better handled by introducing a new one (otherwise you'll get yourself
into situation like we have right now, only in
David Abrahams wrote:
Aleksey Gurtovoy [EMAIL PROTECTED] writes:
IMO we should just stop using 'void_' for internal purposes and give it
up to users :).
I am still unsure about 'void_' being better than 'nil' or
'null' Users already have a type, 'void', which means void
Drazen DOTLIC wrote:
Hello,
Hi Drazen,
I've recently discovered that mpl provides all the functionality
I was previously using from loki, so I decided to switch. There
is one small thing driving me crazy, and I was wondering if I
missed something...
I was using loki's TypeAtNonStrict
Markus Werle wrote:
Hi!
Hi Markus,
Though Intel C++ compiles this without complaint
gcc fails with ICE on this code snippet, which is
preprocessor output of boost code:
struct void_ {};
template
bool C
, typename T1
, typename T2
struct if_c
{
typedef T1
Thomas Wenisch wrote:
Hi,
Hi Thomas,
First of all, thanks for the report.
for_each seems to be unable to deal with empty lists, or lists that
are built by push_front on an empty list. However, vectors work
fine. Here is code which demonstrates the problem. Replacing list with
vector
Eric Friedman wrote:
Aleksey (and others),
Hi Eric,
I'm working on getting variant to compile under MSVC 6, but I've come
across what seems to be an ETI problem that needs a workaround.
However, I'm not sure what is the most appropriate way to make the fix.
The most common way to deal with
Daniel Frey wrote:
To complete the implementation of combined_argument_type, it would
help if mpl::vector would have 16 instead of 10 arguments,
Just do #include boost/mpl/vector/vector20.hpp and use 'vector16'.
Aleksey
___
Unsubscribe other
Daniel Frey wrote:
Peter Dimov wrote:
You've considered
bind(f, bind(g, _1, _2), bind(h, _1, _2))
right? ;-)
Sure. But still compose.hpp is in itself incomplete. And it completes
the standard's parts on function objects so I think it might be
desirable to supply
Peter Dimov wrote:
Beman's approach, where unexpected failures were automatically
determined by comparing the current run with aprevious run, seems to
cope better with this scenario, and requires no manual input.
Does it? What if the previous run was a total failure - what the next
one is
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
Peter Dimov wrote:
Also, please note that I don't mind the _developer summary_ being
aggressive in its pass/fail reports. There are no expected
failures there as far as I'm concerned. Every failure needs to be
reported in red, with pass-fail
Drazen DOTLIC wrote:
Hi,
Hi Drazen,
My company is using boost and we would very much like to use variant
library immediately and not wait for the next official release of
boost. Now, we know that this might not be sensible, but we are ready
to take the risk. At the same time, we don't want
David Abrahams wrote:
AFAICT, Aleksey is the only one who knows how to make
modifications
to MPL correctly in the context of its preprocessing
system. Aleksey,
a short README would totally solve this problem, wouldn't it?
How about this one instead:
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
Well, check out the latest developer report -
http://boost.sourceforge.net/regression-logs/developer_summary
_page.html!
Intel-7.1 is misconfigured. ADL is disabled but
BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP is not set. That is why
Peter Dimov wrote:
We just need to agree on the configuration, here. Currently, we run
Intel 7.1 in MSVC 6.0 compatibility mode, and Beman probably has his
configured for 7.0. I am not sure which configuration is more common
in the real world - assuming that this is the criterion we want
Beman Dawes wrote:
The other possibility is that Intel changed something in their 7.1
update. I'm planning to install that update in a day or two; we'll
see if it breaks the Win32 regression tests.
We upgraded to 7.1 a couple of days ago, so
Eric Friedman wrote:
Aleksey (and all),
In working on porting boost::variant to Borland, I've come across some
trouble with a bug in the compiler.
Specfically, I'm getting Cannot have both a template class and
function named 'bind1st' and similarly for bind2nd. I know other MPL
headers
David Abrahams wrote:
Eric Friedman [EMAIL PROTECTED] writes:
I'd apply the patch myself, but due to the heavy use of preprocessed
headers, I'm worried I won't get it completely right. So I'll leave
it up to Aleksey (or others) to fix.
AFAICT, Aleksey is the only one who knows how to
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
Peter Dimov wrote:
The summaries are nice, but the red broken thing on the user page
may be too intimidating,
When will show the actual status, it shouldn't be (it doesn't yet,
since some cooperation from library authors is needed - please
Peter Dimov wrote:
Aleksey Gurtovoy wrote:
... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648
are available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
* developer summary page -
http
Gennaro Prota wrote:
On Wed, 18 Jun 2003 10:01:58 -0500, Aleksey Gurtovoy
[EMAIL PROTECTED] wrote:
... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648
are available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
Vladimir Prus wrote:
Aleksey Gurtovoy wrote:
... as per
http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are
available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
* developer summary page -
http
Rene Rivera wrote:
[2003-06-18] Aleksey Gurtovoy wrote:
as per
http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are
available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
* developer summary page -
http
[EMAIL PROTECTED] (Greg Comeau) wrote:
On a more general note... what are the regression results for?
Who is supposed to be their readers?
What information is one supposed to gleam from perusing them?
What should one walk away from them knowing or saying?
FWIW, I tried to answer these here -
... as per http://article.gmane.org/gmane.comp.lib.boost.devel/20648 are
available from here:
* user summary page -
http://boost.sourceforge.net/regression-logs/user_summary_page.html
* developer summary page -
http://boost.sourceforge.net/regression-logs/developer_summary_page.html
Please
Hi Eric,
First of all, thanks for the report!
Eric Friedman wrote:
I've found that mpl::is_sequence fails to operate correctly on
certain types under MSVC7.
To be precise, on class types that have a member named 'begin' that is
not a typename.
I haven't tested extensively, but there
Vladimir Prus wrote:
There've been a fair amount of suggested changes, many of which are
documented on Wiki [1], and since the author himself keeps track of
the issues, I won't reiterate them here - except for stressing the
need for
a) extensively reworked and extended documentation,
to comment on
the final version.
Once again, thanks to the author and all the reviewers.
Aleksey Gurtovoy
Command Line Config Review Manager
[1]
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Program_Optio
ns_Library_Pages
The formal review of Vladimir Prus' Command Line Config library is now at
an end. A summary and conclusion will follow shortly.
Thanks to everyone who responded,
Aleksey Gurtovoy
___
Unsubscribe other changes: http://lists.boost.org/mailman
Hi Andreas,
[...]
An attempt at an easy-to-use FSM library that supports
well-maintainable and code-expressive machines of almost any size and
does not require a code generator can be found in the fsm directories
in the boost-sandbox and here:
Beman Dawes wrote:
One possible short-term fix might be to run the MPL tests separately,
and post them as a separate table.
That's what we plan to do, although format of the table probably going
to be different - please see below.
Long term, some kind of hierarchical approach might help with
Eric Friedman wrote:
I apologize if this has already been asked, but why aren't the
libs/mpl/test sources included in regresssion testing? I know some
tests are missing and some are perhaps as robust as they might be,
but it seems some testing is better than no testing.
Definitely, and
Ralf W. Grosse-Kunstleve wrote:
While compiling certain Boost.Python regression tests (e.g. args.cpp) gcc
3.3
complains about some typedefs being private. Attached is a trivial patch
which
fixes the problem. OK to commit to CVS?
Yep, the patch is OK - gcc is right, and there is no point in
I just restored the lost revisions for these three headers:
boost/config/platform/win32.hpp
boost/config/stdlib/stlport.hpp
boost/filesystem/convenience.hpp
and, comparing what is probably the most recent before-the-disk-crash CVS
snapshot to the current CVS state, it seems that
Christopher Currie wrote:
While in theory I agree with Aleksey, I tried David's suggestion of
inhibiting in-class static constant initialization. This single change
eliminatated all but one of the remaining problems I've had compiling
the tests for type_traits (there's still an assertion
David Abrahams wrote:
the following fails to compile. Should it?
--
#include boost/mpl/vector.hpp
#include boost/mpl/push_back.hpp
namespace mpl = boost::mpl;
typedef mpl::vectorint[1], int[2], int[3], int[4], int[5], int[6],
int[7], int[8], int[9], int[10] v10;
typedef
Beman Dawes wrote:
... various backup suggestions
SourceForge already makes the entire Boost CVS tarball available every
night, and several Boosters download it daily.
Oh, good. There is no such thing as too much backup.
(At least I hope they do - I have no way of telling if they are
Aleksey Gurtovoy wrote:
'int_' (and other integral constant wrappers) needs to provide a
definition
for its '::value' member for the
!defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION) case.
I will fix it in a few days.
Done in the main trunk now.
Aleksey
Jaap Suter wrote:
Hi,
Hi Jaap,
I apologize, but once again I'm unable to get a lambda
expression working with the MPL.
The code works fine with the Intel and GCC compiler. On MSVC I get the
following error:
error C2039: 'lhs_index' : is not a member of 'boost::mpl::argN'
It's
Andreas Huber wrote:
Hi Aleksey,
Hi Andreas,
Sorry for the late reply, got too many things on my plate.
I've stumbled over ETI again. Browsing through MPL I have found
different ways to circumvent it. In my case the following workaround
seems to be sufficient:
template class State
Jaap Suter wrote:
Hi,
Hi Jaap,
In some of my MPL-using code I needed set-based functionality. So I wrote
a
function that does an insertion into an ordered list of constants.
However,
it seems that if I compare a list created from a bunch of constants to an
explicit list, they don't end up
Daniel Frey wrote:
Still looks broken over here:
http://cci.lbl.gov/boost/results/1047901021/dailylog_win32_vc60
I think it's OK to revert the patch to get 1.30.0 out,
Which patch? John said the changes that caused the disturbance were
never intended to be checked in.
but for the
Beman Dawes wrote:
Both the main trunk and RC_1_30_0 are working fine for me as
of Sunday 6PM US Eastern time.
If you look into error messages for 'is_class_test.cpp' on MSVC 6.5/7.0,
you'll see that they are not; the new failures are getting masked by the
fact that earlier the test failed at
Beman Dawes wrote:
Here is the current list. The second and third items look to me like
showstoppers.
They are.
Aleksey
* [Boost.Regex] [PATCH] Fix GCC 3.3 warnings from Lars Gullik Bjønnes.
Awaiting response from John Maddock.
(Since this one just eliminates warnings, the release
Aleksey Gurtovoy wrote:
Oh, I see. But wait, it seems that it's still there - I can
update from the CVS, but I cannot check in the fix:
cvs server: [18:53:47] waiting for johnmaddock's lock in
/cvsroot/boost/boost/boost/type_traits
FYI, I submitted a SourceForge support request
Beman Dawes wrote:
* [config] BOOST_DEDUCED_TYPENAME
Status currently unknown. John? Aleksey?
Dave will take care of it after the release. It's not urgent in any way.
Aleksey
___
Unsubscribe other changes:
Markus Schöpflin wrote:
currently, the is_member_func_test fails for VACPP6 with the
following error messages:
snip
When looking at is_mem_fun_pointer_impl.hpp it looks like the
Metrowerks compiler has the same problem. Could anyone please add
a check for __IBMCPP__ =600 at line 345
Markus Schöpflin wrote:
Aleksey, thanks for the instructions. Could you tell me which PP you
used to generate the file before? I would like to minimize the diff
as much as possible?
VC 7.1, IIRC, but it shouldn't matter much because the header uses file
iteration PP technique, and for most
Andreas Huber wrote:
Hi Aleksey
Hi Andreas,
Sometimes I have to pass an abstract class to mpl::aux::msvc_eti_base.
On MSVC7.0 the compiler complains with the following error:
d:\Data\boostCvsRoot\boost\boost\mpl\aux_\is_msvc_eti_arg.hpp(48) :
error C2259: 'boost::mpl::inherit2T1,T2' :
Aleksey Gurtovoy wrote:
If one of the developers could at least comment on this I might give it
another try. Otherwise I estimate it would take me weeks to
reverse-engineer what is happening here.
Ralf, I will definitely look into it tonight and get back to you.
OK, I've checked in a fix
Ralf W. Grosse-Kunstleve wrote:
OK, I'll wait for a word from Aleksey. If he is happy I'll heck in
the eight patches, both into the trunk and the RC_1_30_0 branch.
Yep, they all look good to me.
Aleksey
___
Unsubscribe other changes:
Ralf W. Grosse-Kunstleve wrote:
I've checked in all my patches. I couldn't fully test the C_1_30_0
branch because Aleksey's recent fixes are not there yet.
Aleksey, please let me know when the fixes are available on the
branch.
They there now.
Aleksey
Ralf W. Grosse-Kunstleve wrote:
This requires active participation by the developers. We've spent a
lot of time setting up the auto-builds to enable developers to see
immediately when their changes break portability. We've also made a
major effort cleaning up 1.29.0. That seemed like a good
David Abrahams wrote:
I was just getting ready to propose a new config macro called
BOOST_ARG_DEPENDENT_TYPENAME based on this test:
struct id { typedef int type; };
template class T struct foo;
template class T
void f(T)
{
typedef footypename T::type y;
Andreas Huber wrote:
Aleksey just did a big round of renaming before the first official
release of MPL (including changes like int_c - int_, and placeholder
- placeholders); I believe that placeholder.hpp is obsolete and
should have been removed from CVS. In this case we could keep it for
Andreas Huber wrote:
P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms (on
conforming compilers I'd expect it to call mpl::identity) or should I
#ifdef my way around it?
Yep, it's intentionally written in the way so that you don't have to #ifdef
in your code.
Aleksey
Sorry for confusion, the reply below obviously belongs to a different
thread.
Aleksey Gurtovoy wrote:
Andreas Huber wrote:
P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms
(on
conforming compilers I'd expect it to call mpl::identity) or should I
#ifdef my way around
Andreas Huber wrote:
Hi Aleksey all other metaprogramming gurus
Hi Andreas,
The attached code compiles just fine with MSVC7.1 but MSVC7.0 once more
has
its problems. This time I'm quite sure it has nothing to do with MPL,
instead VC7.0 seems to get confused and reports the following:
Trey Jackson wrote:
Just started using boost::bind, like it a lot.
I'm playing around with a little work crew,
which just queues up data, then calls the function
on them later.
[...]
I'd like to be able to do something like:
,
| work_crew??? mycrew(bind(X::f, x, _1, _2));
Trey Jackson wrote:
template class DataType, class FunctionType =
boost::function1void,
DataType
class work_crew {
std::listDataType queue_;
FunctionType engine_;
public:
work_crew(FunctionType const tocall);
void add(DataType d) { queue_.push_front(d); };
Attached is an implementation of 'boost::tuples::apply' function template,
providing one with a possibility of function application on a tuple of
arguments:
#include boost/tuple/tuple.hpp
#include boost/tuple/apply.hpp
using namespace boost;
void f(int, char const*);
int
1 - 100 of 177 matches
Mail list logo
