a text stream which is going to be
re-tokenized by a separate preprocessor/compiler pass. In that case, it
*must* add the whitespace to prevent retokenization that yields
different tokens.
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
its spelling consists entirely of letters and underscores.
Therefore it is not subject to this replacement."
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
tweak that allows you to
tweak stuff like this:
http://www.gotdotnet.com/team/ide/
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
called
> "hidden state", which doesn't have 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
r than just one.
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ine IS_END_I(x, ...) \
IS_VARIADIC(IS_END_II x,) \
/**/
#define IS_END_II(a, b, c, d, e, f, g, h, i, j, ...) __VA_ARGS__
IS_END( a, b, c, d, END )
IS_END( END )
You can expand the END value to hundreds of commas and change IS_END_II
likewise. That, or similar pathological input, is the only
f-data" issues
mentioned above.)
Support for variadics in Chaos, as far as algorithms are concerned, is
to allow the data/state to be variadic. This is far more useful in
practice, as it gets rid of a massive about of "element access" from one
structure or another.
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
e or four
macros, each one would be reentrant, and each one would be overloaded on
lambda expression vs. user-defined macro.
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
operation.
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
nsive.
Nevertheless, I'll take a look at your code...
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
only in a license comment and not the code itself. Having 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 Mensonide
> 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
> //
d what? Or do we leave that out altogether?
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
behavior with their
> wave executable.
>
> regards,
> Faisal Vali
My 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
with 0. (Note that that alternative tokens
are not identifiers, so 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
___
Uns
true; }
if (force_non_constant(), expr) else ...
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm assuming that, because they aren't macros, they should not "expand" before
stringizing.
Finally, if C++ gets C99's inline _Pragma. Some standard pragmas could be used
to generate these tokens:
_Pragma("STDC TOKEN ,")
Which could be shortened at will
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
ACRO(x) x
MACRO( ID2( std::pair ) )
...is error prone (and dangerous). :(
Regards,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
re you to know the number of unbound commas in the
type:
#define IN(s, x) (s) x
#define OUT(x) BOOST_PP_TUPLE_REM x
#define M1(type) M2(type)
#define M2(type) OUT(type)
MACRO( IN(2, (std::pair)) )
In other words, it is a complete pain to deal with them without variadics.
*Wi
y
like #namespace/#endnamespace, but I could live with it. What I want (and what
we need) is the more general mechanism allowing named scopes. My proposal,
including import/export, would allow both the current model and the more general
model.
Paul Mensonides
_
// ABC
DETAIL::ABC // DETAIL::ABC
BOOST::INTERFACE // 123
OTHER// 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
ng the Borland configuration of
the pp-lib--which should not be using the BOOST_PP_CHECK macros--especially not
for list handling.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
processor in
simple cases. However, as complexity increases, time dilates expontentially on
EDG. Preprocessing time dilates linearly under Wave, which causes it to easily
outperform EDG when complexity increases.
Regards,
Paul Mensonides
___
Unsubsc
p-lib as
well as the examples in the reference section of the docs. In any case, it
might be the same type of thing as Borland, but only in certain context. I
can't test it, though, so I can't tell you for sure.
Paul Mensonides
___
Uns
ink they've already gotten this one before
though, so I'm not holding my breath. ;)
Thanks again for the help,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
command line
tools. The included preprocessor, cpp32.exe, produces the correct output. The
compiler proper, bcc32.exe, does 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
on.
>
> Hum... Interesting... Thanks for letting me know.
Could some 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
t is dependent on how
the policies are passed 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
___
::cout
<< typeid(f).name() // compiler crash
// i.e. not an ICE
<< &std::endl;
return 0;
}
I've been talking about this issue with Daveed Vandevoorde 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
ag type to prohibit a certain operation
from being used. Whether 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
__
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 M
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
return "01234";
}
};
int main() {
sample var;
std::cout << var[0] << var[1] << &std::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
cv-qualified
specializations would match pointers-to-cv-qualified-member-functions rather
than just cv-qualified-pointers-to-members.
[phew]
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
r it a
clarification for everyone else. As is, the four specializations that you
provided with catch any unqualified (first one) or qualified (other three)
pointer-to-member. The nested call to 'is_function' should yield true if the
pointed-to type a function type (cv-qualified or otherwise).
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
inter_to_member_function {
enum { value = false };
};
template struct is_pointer_to_member_function {
enum { value = is_same::value };
};
...since only function types are implicitly adjusted to pointer-to-function when
used as a parameter.
Regards,
Paul Mensonides
ember_function_pointer< T C::*
const volatile > { enum { value = is_function< T >::value }; };
Whoa, sorry Daniel, I missed this part, which is almost exactly the same as my
post.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- 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]&
des all the files that you want
to pre-preprocess (if that is what your getting at), run it through your
compiler's preprocessor, and then include the result file.
...but this is outside 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
out most of the stuff that makes the parser complicated. The
difficult part of the semantic analysis would still be lookup and
overloading, IMHO.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ses to an
> ellipsis, and invoking undefined behavior! :-)
It isn't invoking undefined behavior because it isn't passing non-POD
classes to an ellipsis--it isn't passing *anything* to an ellipsis. ;)
Paul Mensonides
___
Unsubscribe &
there.
The problems are not insurmountable though (with an "is_valid_expression").
You aren't dealing with entire language at this point, only an expression.
You'd need an independent expression parser that is coupled to the symbol
table.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ute rule that you don't include normal
headers inside an iteration. <---
(If I missed saying that in the docs, sorry, I'll fix it. I actually
thought that I mentioned it, but I haven't checked.)
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(tuple/elem.hpp)(repetition/repeat.hpp)(list/adt.hpp)) \
/**/
#include BOOST_PP_ANGLED_INCLUDE()
(I had BOOST_PP_QUOTED_INCLUDE as well.) I'd be happy to add such a
mechanism, but I'd like to hear what people want from the mechanism and any
thoughts on syntactic issues, etc..
Paul Mensonid
includes other files *during an iteration*,
BOOST_PP_IS_ITERATING is still defined and the other files probably won't
know how to handle it. ( is one example of this.) The
solution is simply to not include any files during a particular iteration.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ned
behaviour".
>
> Ouch, no. You will never find me agreeing on this point. This seems
> along the lines of "if I can't get it work, then it's undefined
> behavior" which is a habit we should all get out of. As Paul
> Mensonides wrote me (Paul, I hope you
h, is greatly coincidental with the
whole MPL thing and therefore amusing. ;)
> I just think this whole thing is blown way out-of-proportion, and
> worse has a self-reinforcing nature. You may not believe it, but I
> have personally bent over backwards to try
#x27;t think people are "manufacturing" arguments. They are just bringing
> up issues, seeking to discuss them, and make intelligent comments about
> ideas which they care.
My major point with what I said is that it is sometimes difficult to
distinguish religious defense of an argument from practical defense of an
argument--and both exist.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
see) his point of
> > view. Actually, that goes for everyone here, and everyone needs to
> > keep that in mind and take disagreement with a grain of salt.
>
> Exactly. In order to reach consensus, we need to have patience with
> other peoples' inattention, lack of insight, stu
as intelligent. It is also obvious that Andrei makes an
effort to be civil when he disagrees (as do many others), but I think that
sometimes he gets frustrated when people don't understand (or even see) his
point of view. Actually, 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
y more difficulty than
smart_ptr and smart_ptr.
2c,
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
erative symbol here, but I don't know if it's the same compiler or
not. If not, than whatever compiler it is needs to be added to the config
file.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
OST_PP_CONFIG_FLAGS() BOOST_PP_CONFIG_BCC()
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
// size 3
#define MAKE_SEQ_A_3(x, y, z) ((x, y, z)) MAKE_SEQ_B_3
#define MAKE_SEQ_B_3(x, y, z) ((x, y, z)) MAKE_SEQ_A_3
#define MAKE_SEQ_A_30X0()
#define MAKE_SEQ_B_30X0()
// etc.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
e writing the code. There is still
much room for improvement though
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ficant articles on the library facilities that require the user to use
more advanced techniques, but the discussion is limited to the use of the
library rather than the techniques themselves.
As I mentioned previously, feel free to contact me personally, via the Boost
list, or via the Boost-U
?
I'm not sure what you mean.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
matches the type of the parameter
> you pass, everything still works.
Okay, thanks.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
typename identity::type* = 0);
> >
> > int main() {
> > func(10);
> > return 0;
> > }
>
> 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-
wrong).
>
> Why do you say that's non-deduced? Up to the point of enable_if, it's
> standard stuff; that's how shared_ptr conversion works.
I didn't know that this was legal:
template struct identity {
typedef T type;
};
template void func(const T&
t that it wasn't
(though I could be wrong).
> }
>
> 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 t
what exactly are you trying 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
- 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
>
a
"member function type".
> GCC thinks it's illegal.
Which part? Just the existence of 'R' at all? If that is the case, than
GCC is wrong. It looks like we have a hole in the type system here. The
specialization: R C::* should catch all pointers-to-members, including
pointers-to-member-functions. Therefore, the type 'R' exists, but has no
name, and is nothing that you could specify by yourself.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ef is
> nonstandard
> operator int(id::type);
>
> ??
>
> I'd prefer it if matching void in a parameter list *were* different
> from generating one. The above prevents the use of SFINAE to generate
> restricted templated conversion operators.
I agree,
- Original Message -
From: "Paul Mensonides" <[EMAIL PROTECTED]>
> Actually, this works too:
So does this:
template struct is_ptr_to_mem_fun {
enum { value = false };
};
template struct is_ptr_to_mem_fun {
private:
template static c
- Original Message -
From: "Paul Mensonides" <[EMAIL PROTECTED]>
Actually, this works too:
template struct is_ptr_to_mem_fun {
enum { value = false };
};
template struct is_ptr_to_mem_fun {
private:
template struct helper {
enum
ned
template struct test { }; // defined
void f(void) { }
int main() {
test< &f >(); // error
return 0;
}
In other words, the "void" parameter list is fundamentally different than
"type void".
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
];
public:
enum { value = sizeof(check(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;
}
???
const for interface values though and use
enumerations for internal values (with casting if necessary).
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- 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
t 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 Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
what to call
them!
>
> They're interesting to a point, but inflexible. Any given usage is
> restricted to working on sequences of a particular length.
Yes, however, the intended purpose is as an inline definition, not as a
sequence type, and it doesn't require the code replication necessary to
support something like "mpl::vector". I'm not saying 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
I agree, but possible. This can still break any
arithmetic or logical operations that involve enumerations:
is_integer::value && is_integer::value // not constant
The only solution that I see is:
(bool)is_integer::value && (bool)is_integer::value
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
is equivalent to 'typedef enum { }
xyz'.
> Oops. X here has still external linkage, though 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
rnal linkage, and is therefore
> unusable 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
I'm quite pleased with the mechanism, as I find the linear
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
- 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.
>
- 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 PROTE
> > ( boost::is_same::value );
> > )
> >
> > In other words, just parenthesize the expressions.
>
> Or even just the macro parameter:
>
> BOOST_STATIC_ASSERT((\
> boost::is_same::value ||\
> boost::is_same::value ||\
> boost::is_same::val
is_double_::value ||
> is_string_::value );
>...etc...
>
> (That's the "usual" work-around for the comma-in-macro problem :)
>
> Regards, Daniel
You can just do this as well:
BOOST_STATIC_ASSERT(
( boost::is_same::value ) ||
( boost::is_same::value ) ||
( boost::is_same::value ) ||
( boost::is_same::value );
)
In other words, just parenthesize the expressions.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ion is needed? That's right, and that's
not the case for enum. Still, there are the issues for enum, as well.
You would have to have more than one "map_integral" with a different value
name, where the values are dependent on one another and are part of the
public interface. It
template static char check(int U::*);
template static char (& check(...))[2];
public:
static const bool value = sizeof(check(0)) == 1;
};
template const bool is_class::value;
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
t; > (although they theoretically exist).
>
> Not just theoretically. As mentioned in an earlier posting in this thread,
> BCC doesn't work well with enums, but it does work with static const.
Also,
> there's the issues pointed out by Paul Mensonides, due to the fact that
&
macro as an argument, it *could*
be considered to be in the global scope. However, I think that is partially
the purpose of the second half of bullet one above (i.e. '_U')--to
distinguish between macro identifiers and regular C++ identifiers.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
> Careful; isn't the symbol "_t" reserved to the implementation in this
context?
I thought it was only if the underscore was followed by a capital letter, as
in "_T".
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
k that this is a good use of the
pp-lib. You can achieve the effect you want easily:
template struct size_descriptor {
typedef char (& type)[I];
};
typedef size_descriptor<1>::type yes_type;
typedef size_descriptor<2>::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
- Original Message -
From: "Paul Mensonides" <[EMAIL PROTECTED]>
> Actually, this seems to be a bug in Comeau C++:
>
> #include
> #include
>
> struct A {
> enum type { x, y };
> };
>
> template struct B { };
>
> templ
- Original Message -
From: "Paul Mensonides" <[EMAIL PROTECTED]>
> Just my 2 cents.
Make that 3 cents...
In summary, enumerations are distinct types and therefore can interfere with
the rest of the language. Particularly, constant expressions, overloading,
o
;type" from the enumeration (ala 'enum
{ x, y }') you'll 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
- 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 i
- 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:
> > > &g
not a valid input:
#define MY_CONFIG_MACRO(a, b)
IS_EMPTY( MY_CONFIG_MACRO ) // error insufficient arguments
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
- Original Message -
From: "Vesa Karvonen" <[EMAIL PROTECTED]>
> By the way, I just found the following article (after I posted my proposed
> IS_EMPTY()):
>
>
http://groups.google.com/groups?q=is_empty+paul+mensonides&hl=en&lr=&ie=UTF-
8&oe=UT
- 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 Metr
uot; I don't see why they
can't be worked around though.
Paul Mensonides
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
ST_PP_IS_EMPTY_OR_1(X),
>
> I like them (and I like the implementations)!
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
t. Oops.
> By the way, I think that the copyright 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
__
1 - 100 of 158 matches
Mail list logo
