it is not subject to this replacement.
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
stuff like this:
http://www.gotdotnet.com/team/ide/
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
the shortcoming in the first place:
Dave, do you still think this would be a good example to add to the
docs?
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
...
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
BOOST_PP_VA_.
A bit more on this part, the problem with implementing an algorithm on
top of another algorithm like you do in your code, is that it makes the
algorithm incapable of recursing in contexts where the algorithm calls
some user-defined macro, such as a predicate or operation.
Regards,
Paul
is reentrant (i.e. recursive).
Under the Chaos model, defining algorithms that operate like you mention
above is pretty easy. Each one would require about three or four
macros, each one would be reentrant, and each one would be overloaded on
lambda expression vs. user-defined macro.
Regards,
Paul
of element access from one
structure or another.
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
IS_END_II
likewise. That, or similar pathological input, is the only way that you
can do this without undefined behavior in the absence of well-defined
token-pasting.
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman
My preference is for there to be a single license file in the
boost root
directory, and each file covered include a link. So a source
code file
might contain something like:
// (C) Jane Programmer, 2003
//
// See www.boost.org/license for license terms and conditions
//
// See
the
license in the file itself also...
[sorry, sent too soon]
...makes the text subject to tools like find and replace which can
alter copyright and is undetectable by the compilation process.
Regards,
Paul Mensonides
___
Unsubscribe other changes: http
this doesn't apply to them.) Finally, yielding
the expression 0. The fourth pass finally evaluates the expression,
which should evaluate to false.
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi
executable does the same thing, so it is indeed a bug. I'm sure
Hartmut will fix this shortly.
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
; }
if (force_non_constant(), expr) else ...
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Aleksey Gurtovoy wrote:
Paul Mensonides wrote:
Yep, they do - that's why I named it BOOST_PP_REPEAT +
BOOST_PP_SEQ_ELEM bug.
That is what I figured, but I wanted to make sure that the (a, b, c)
wasn't causing a problem--which it shouldn't be anyway. I'll look
at this later when I have time
with them without variadics.
*With* variadics, however, you can do a little better.
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
( ID2( std::pairint, int ) )
...is error prone (and dangerous). :(
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
// 123
A::MACRO // 123
B::MACRO // B::MACRO
What do you think?
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
John Harris (TT) wrote:
In the 1.30.0 release, the docs for BOOST_PP_IF and BOOST_PP_IIF
incorrectly refer to 'expr'. It looks as though they were copied
from EXPR_IIF.
john harris
trading technologies
Thanks John, I'll fix it.
Paul Mensonides
fixed planned for
1.30.0 proper?
Are you certain that this is 1.30? This should already be fixed. In
particular, the Sun preprocessor should be using the Borland configuration of
the pp-lib--which should not be using the BOOST_PP_CHECK macros--especially not
for list handling.
Paul Mensonides
one that has this compiler please test something for me? I'm hoping
that a preprocessor bug got fixed (though it isn't listed).
#define A() 1
#define B(m) m 2
B(A)
It should expand to A 2, but will probably expand to A2.
Thanks in advance,
Paul Mensonides
not. In other words, the behavior is/was
different with the separate preprocessor vs. the integrated preprocessor.
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
of the pp-lib. I'd still need the
same hacked configuration for Sun and IBM (they have similar bugs), but at least
Borland's wouldn't need it.
Please do submit a bug report. I think they've already gotten this one before
though, so I'm not holding my breath. ;)
Thanks again for the help,
Paul
or not that flag type exists is detectable.
Therefore, static assertions can be used to prevent certain operations from
compiling in a way that is non-intrusive to all other unrelated policies.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org
for the last couple
weeks, so EDG is aware of the issue.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
into the smart pointer template (i.e. through one
parameter as a typelist (or similar) or through multiple parameters with
defaults or through multiple parameters with arbitrary ordering).
Paul Mensonides
___
Unsubscribe other changes: http
-to-members.
[phew]
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
::endl;
return 0;
}
The same applies to the standing problem of operator-*().
2c.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Greg Colvin wrote:
At 07:25 PM 2/4/2003, Paul Mensonides wrote:
...
If an implicit conversion to the pointed-to type is provided, there
is no need to overload the subscript operator:
...
The same applies to the standing problem of operator-*().
2c.
Yep. More reasons why I prefer
Howard Hinnant wrote:
Custom deleter policy + implicit conversion policy - converting
constructors - converting assignment operators == smart pointer that
handles arrays.
A custom deleter policy could prevent the use of converting ctors and
assignment.
Paul Mensonides
{ value = false };
};
templateclass R, class C struct is_pointer_to_member_functionR C::* {
enum { value = is_samevoid (R), void (R*)::value };
};
...since only function types are implicitly adjusted to pointer-to-function when
used as a parameter.
Regards,
Paul Mensonides
- Original Message -
From: Hugo Duncan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, January 29, 2003 12:23 PM
Subject: [boost] BOOST_PP_XX_INCCLUDE
On Mon, 27 Jan 2003 12:42:14 -0800, Paul Mensonides [EMAIL PROTECTED]
wrote:
#define BOOST_PP_HEADERS \
(...), /* i.e
the scope of the pp-lib can automate because it
requires a separate build step to produce the preprocessor equivalent of a
pre-compiled header.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on this point. This seems
along the lines of if I can't get it work, then it's undefined
behavior which is a habit we should all get out of. As Paul
Mensonides wrote me (Paul, I hope you don't mind the quotation), UB is
reasonable e.g. when diagnosing the situation is impractical
and the other files probably won't
know how to handle it. (boost/mpl/list.hpp is one example of this.) The
solution is simply to not include any files during a particular iteration.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org
BOOST_PP_ANGLED_INCLUDE()
(I had BOOST_PP_QUOTED_INCLUDE as well.) I'd be happy to add such a
mechanism, but I'd like to hear what people want from the mechanism and any
thoughts on syntactic issues, etc..
Paul Mensonides
___
Unsubscribe other changes
mentioned it, but I haven't checked.)
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
at this point, only an expression.
You'd need an independent expression parser that is coupled to the symbol
table.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
undefined behavior! :-)
It isn't invoking undefined behavior because it isn't passing non-POD
classes to an ellipsis--it isn't passing *anything* to an ellipsis. ;)
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman
. The
difficult part of the semantic analysis would still be lookup and
overloading, IMHO.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
, that goes for everyone here, and everyone needs to
keep that in mind and take disagreement with a grain of salt.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
the latter problem.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
to an acceptable extent _with_ design.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
() BOOST_PP_CONFIG_BCC()
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- Original Message -
From: Edward Diener [EMAIL PROTECTED]
I don't see any organizational principle in the documentation for
explaining
the various macros in the Boost preprocessing library. Would someone
please
point me in the right direction ?
I'm not sure what you mean.
Paul
to contact me personally, via the Boost
list, or via the Boost-Users list if you need help, and I will be happy to
help as I am able.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
in a parameter list *were* different
from generating one. The above prevents the use of SFINAE to generate
restricted templated conversion operators.
I agree, it would be nice if it was legal, but I don't think it is. The
void parameter list is not of type void.
Paul Mensonides
- Original Message -
From: Paul Mensonides [EMAIL PROTECTED]
I can't tell what EDG thinks it is, but whatever it is, it's not a
function type.
EDG treats it like a special type of function type. For instance, trying
to
apply const to it yields a applying const to a function-type
to restrict? The implicit conversion from
some type to the type you are defining or conversion of the type you are
defining to only a selected few types?
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
).
}
The parser chokes on the first '' inside the parens.
I was going to try attacking it from the other direction, by defining
a conversion operator.
Interesting. It was a herculean effort though!
Paul Mensonides
___
Unsubscribe other changes: http
know that this was legal:
templateclass T struct identity {
typedef T type;
};
templateclass T void func(const T, typename identityT::type* = 0);
int main() {
func(10);
return 0;
}
Paul Mensonides
___
Unsubscribe other changes: http
;
}
Sure, T is deducible due to the first argument.
Cool, I learn something every day. I assume, though, that if I attempted to
actually use the second parameter it would become non-deducable, right?
Paul Mensonides
___
Unsubscribe other changes: http
pass, everything still works.
Okay, thanks.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
as template parameters.
The program you give compiles and runs without errors.
Oops, my mistake.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
of course you don't
know its linkage name and thus cannot refer it from another
translation unit.
Yeah, my mistake. Sorry!
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
that it's super
great overall. I'm merely saying that it amuses me, and I like it. ;)
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
have to be cast
first. Likewise, this would put the cast burden on users of the
library--particularly other libraries that use Boost. That is a bad policy.
As I said before, though, the point is moot because compilers are so
disparate in this area. At this point, we *have* to use both.
Paul
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
Paul Mensonides [EMAIL PROTECTED] writes:
Well, yes. If you do that, however, it removes one of the primary
reasons
to use enumerations, which is for the syntactic convenience. The
only
reason left to use enums
(with casting if necessary).
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
static char ( check(...))[2];
public:
enum { value = sizeof(checkR(0)) != 1 };
};
struct X { };
int main() {
std::cout
is_ptr_to_mem_fun int X::* ::value ' '
is_ptr_to_mem_fun int (X::*)(void) ::value std::endl;
return 0;
}
???
Paul Mensonides
is fundamentally different than
type void.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- Original Message -
From: Paul Mensonides [EMAIL PROTECTED]
Actually, this works too:
templateclass T struct is_ptr_to_mem_fun {
enum { value = false };
};
templateclass R, class C struct is_ptr_to_mem_funR C::* {
private:
templateclass, class struct helper
typelist implementation neat, and I've never seen anything like that
implementation. The template classes fold_left and fold_right are not
even metafunctions in any normal sense. I wouldn't know what to call them!
Paul Mensonides
___
Unsubscribe other
parenthesize the expressions.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- Original Message -
From: David B. Held [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, January 09, 2003 1:16 PM
Subject: [boost] Re: Re: How to do this in
withboost--assert(typeid(T)==typeid(bool) )
Paul Mensonides [EMAIL PROTECTED] wrote in message
000901c2b823$1e7f4aa0
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
Paul Mensonides [EMAIL PROTECTED] writes:
Which could be even shorter yet if we could get away with template
template parameters.
We can and do.
How would you imagine it would be spelled with TTP?
You asked
r1::type yes_type;
typedef size_descriptor2::type no_type;
...or something similar, which solves the problem once and for all.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
was followed by a capital letter, as
in _T.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
get a compile-time error for attempting to use an unnamed
type as a template argument.
Just my 2 cents.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on this file (and probably a few
others as well) is incorrect (I don't recall creating it for Housemarque).
CVS shows that this file was first committed by Paul.
I fixed these as well.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org
)!
I like the implementations too. Unfortunately, it won't work on cl (and
likely mwcc). I'll need to hack the implementations up a bit.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
be worked around though.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- Original Message -
From: Paul Mensonides [EMAIL PROTECTED]
Vesa, I hack this up so it works on all compilers and then add it to the
CVS. The main problem is that the implementation relies on expansion
order.
That is another name for VC and Metrowerks bugs. I don't see why
) // error insufficient arguments
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- Original Message -
From: Vesa Karvonen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, January 05, 2003 3:45 PM
Subject: Re: [boost] Boost.Preprocessor: Alternatives to defined(x)
David Abrahams:
Paul Mensonides:
The semantic change is that 'x' must not be a function
- Original Message -
From: Paul Mensonides [EMAIL PROTECTED]
Anyway, I might still be able to make the original ideal work with VC and
Metrowerks. (You wouldn't believe how sick I am of those two compilers!)
Give me some time
Actually it is not possible anyway. Not necessarily
the difference between (a) and (a, b), etc With variadics I can
count the arguments.
I suppose it's possible to generate the code I need using BOOST_PP_WHILE,
but IMO that solution wouldn't be as conceptually nice and intuitive as
the
above.
Paul Mensonides
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
Paul Mensonides [EMAIL PROTECTED] writes:
- Original Message -
From: David Abrahams [EMAIL PROTECTED]
Yeah. I have no problem with access protection where it prevents
unintentional misuse and improves
a
range starting from zero, you can use BOOST_PP_SEQ_FIRST_N instead of
BOOST_PP_SEQ_SUBSEQ which will be more efficient yet.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
:).
For the time being, try BOOST_PP_SEQ_FIRST_N. If that doesn't work for now,
I'll get on it immediately.
I didn't know about it (which is exactly why I should have some regression
tests for this). I thought I tested everything, but I must have missed
this. Suffice to say, it *can* work.
Paul
better even though it isn't bulletproof. The implementation itself
is reusable, it doesn't change the usage syntax, and at least it's obvious
that the parameter is not supposed to be used. Maybe BOOST_HIDE_DEFAULT?
templateclass T, BOOST_HIDE_DEFAULT class U = T struct XYZ { };
2c
Paul Mensonides
) \
)\
); \
BOOST_CHECK_EQUAL(a, b)\
/**/
Regards,
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
into the category of not the original intent. That
includes inheritance, overloading, etc., etc... Once you start doing heavy
metaprogramming the aesthetic ideal starts to lose its shine.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman
;
};
I guess that's what happens when you descend into the ethertype dimension of
exception specifications.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
, and the second will break the
pp-lib altogether (it relies on multiple inclusion of the same file).
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
custom stuff for certain things for
optimization purposes. It isn't the pp-lib that has the problem, it is
parts of the MPL.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
? Where is that coming from?
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
in that header? If so, they should be
undefined. If not, why on earth are they named B#? Here's a workaround
will really fix Boost:
#define T 0
;)
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
and
represents an acceptable dependency, but in this particular case,
it's overdoing it--IMHO.
Yeah, it's kinda heavyweight. Since you and Gennaro agree, I think
I'll opt out unless someone argues strongly for it.
It *is* the more fun way to do it.
Paul Mensonides
. :)
Thanks for the levity, Terje. ;) All it takes is a little talk about VB or
Pascal to give me a good grin (although I do wish C++ had nested functions).
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
though. ;)
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
, it is simple to detect whether or not the symbol
passed is a known name or not, and issuing an error is easy if it is in
the macro expansion rather than in the expression.) ...But this was just
for amusement anyway. ;)
Paul Mensonides
___
Unsubscribe other
find a way to make:
BOOST_WORKAROUND(__SUNPRO_CC, BOOST_CURRENT_VERSION(0x530))
work?
I'm not sure what you mean here. You mean overloading BOOST_WORKAROUND to
cause an error (or warning) if you use BOOST_CURRENT_VERSION? That's no
problem at all.
Paul Mensonides
disable it with -w-zdi or -w-8082)
Does it yield true or false? I.e. what happens here:
#if 1 / 0
section 1
#else
section 2
#endif
I don't see how it could logically choose, since 1 / 0 makes no sense.
Paul Mensonides
___
Unsubscribe other changes
).
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- Original Message -
From: Paul Mensonides [EMAIL PROTECTED]
I'm not sure what you mean here. You mean overloading
BOOST_WORKAROUND to cause an error (or warning) if you use
BOOST_CURRENT_VERSION? That's no problem at all.
I mean that
#if BOOST_WORKAROUND
of possibilities. Consider my other list
bogus.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(or library) capabilities.
It is possible to make it generate a warning or an error if a compiler
version is higher than the specification. Of course, you also don't have to
use the preprocessor to do this sort of thing.
Paul Mensonides
___
Unsubscribe
As long as the symbols used are known, it is no problem to pull the symbol
off the beginning (or end) of the expression.
Paul Mensonides
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1 - 100 of 110 matches
Mail list logo
