RE: [boost] Re: Problem with type_with_alignment.hpp

2003-09-03 Thread Paul Mensonides
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

RE: [boost] [Fun] (( a xor b )) formal review request...

2003-08-20 Thread Paul Mensonides
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

RE: [boost] Re: Files of types *.ipp are unfriendly, especiallytoMSVC ?

2003-08-14 Thread Paul Mensonides
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

RE: [boost] Fun PP lib example

2003-08-01 Thread Paul Mensonides
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

RE: [boost] PP interest in facilities for variablelengthargumentlists

2003-06-27 Thread Paul Mensonides
r than just one. Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] PP interest in facilities for variablelengthargumentlists

2003-06-26 Thread Paul Mensonides
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

RE: [boost] PP interest in facilities for variable lengthargumentlists

2003-06-26 Thread Paul Mensonides
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

RE: [boost] PP interest in facilities for variable lengthargumentlists

2003-06-26 Thread Paul Mensonides
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

RE: [boost] PP interest in facilities for variable length argumentlists

2003-06-26 Thread Paul Mensonides
operation. Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] PP interest in facilities for variable length argumentlists

2003-06-26 Thread Paul Mensonides
nsive. Nevertheless, I'll take a look at your code... Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Draft of new Boost Software License

2003-06-25 Thread Paul Mensonides
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

RE: [boost] Draft of new Boost Software License

2003-06-25 Thread Paul Mensonides
> 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 > //

RE: [boost] Draft of new Boost Software License

2003-06-25 Thread Paul Mensonides
d what? Or do we leave that out altogether? Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Re: [ANN] New Version of theWavepreprocessorlibraryreleased (Isthis a bug?)

2003-06-04 Thread Paul Mensonides
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

RE: [boost] Re: [ANN] New Version of the Wavepreprocessorlibraryreleased (Isthis a bug?)

2003-06-04 Thread Paul Mensonides
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

Re: [boost] Re: ENFORCE

2003-05-08 Thread Paul Mensonides
true; } if (force_non_constant(), expr) else ... Regards, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] ATTN: All Developers Interested in Boost.Preprocessor

2003-04-30 Thread Paul Mensonides
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

Re: [boost] PP: MSVC BOOST_PP_REPEAT + BOOST_PP_SEQ_ELEM bug

2003-04-17 Thread Paul Mensonides
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

Re: [boost] Passing template-ids as macro parameters

2003-04-17 Thread Paul Mensonides
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: [boost] Passing template-ids as macro parameters

2003-04-17 Thread Paul Mensonides
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

Re: [boost] PP lambda?

2003-04-12 Thread Paul Mensonides
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 _

Re: [boost] PP lambda?

2003-04-12 Thread 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

Re: [boost] Preprocessor documentation erratum

2003-03-24 Thread Paul Mensonides
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

Re: [boost] [Bug] boost does not compile with Sun CC

2003-03-10 Thread Paul Mensonides
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

Re: [boost] ANN: Wave - A Standard conformant C++ preprocessor (was:IntheSpirit of Challenge)

2003-03-07 Thread Paul Mensonides
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

Re: [boost] IBM preprocessor bugs (was Re: Borland C++ Builder patch4 released)

2003-03-05 Thread Paul Mensonides
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

Re: [boost] Re: Borland C++ Builder patch 4 released

2003-02-27 Thread Paul Mensonides
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

Re: [boost] Re: Borland C++ Builder patch 4 released

2003-02-27 Thread Paul Mensonides
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

Re: [boost] Re: Borland C++ Builder patch 4 released

2003-02-27 Thread Paul Mensonides
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

Re: [boost] on operator T* for array access

2003-02-05 Thread Paul Mensonides
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 ___

Re: [boost] Re: Re: is_class

2003-02-05 Thread 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

Re: [boost] Re: Array support[wasSmartPtr(Loki)-auto_ptr/movec'torissue]

2003-02-05 Thread Paul Mensonides
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 __

Re: [boost] Re: Array support [wasSmartPtr(Loki)-auto_ptr/movec'torissue]

2003-02-04 Thread 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

Re: [boost] Re: Array support [was SmartPtr(Loki)-auto_ptr/movec'torissue]

2003-02-04 Thread Paul Mensonides
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

Re: [boost] Re: Array support [was SmartPtr(Loki)-auto_ptr/movec'torissue]

2003-02-04 Thread Paul Mensonides
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

Re: [boost] Re: Re: is_class

2003-02-04 Thread Paul Mensonides
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

Re: [boost] Re: is_class

2003-02-04 Thread Paul Mensonides
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

Re: [boost] is_class

2003-02-03 Thread Paul Mensonides
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

Re: [boost] is_class

2003-02-03 Thread 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

Re: [boost] BOOST_PP_XX_INCCLUDE

2003-01-29 Thread 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]&

Re: [boost] Re: Re: MPL include problem with BOOST_PP_ITERATE

2003-01-27 Thread Paul Mensonides
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

Re: [boost] Re: is_convertible corner case

2003-01-24 Thread Paul Mensonides
out most of the stuff that makes the parser complicated. The difficult part of the semantic analysis would still be lookup and overloading, IMHO. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: is_convertible corner case

2003-01-24 Thread Paul Mensonides
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 &

Re: [boost] Re: is_convertible corner case

2003-01-24 Thread Paul Mensonides
there. The problems are not insurmountable though (with an "is_valid_expression"). You aren't dealing with entire language at this point, only an expression. You'd need an independent expression parser that is coupled to the symbol table. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Re: MPL include problem with BOOST_PP_ITERATE

2003-01-24 Thread Paul Mensonides
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

Re: [boost] Re: MPL include problem with BOOST_PP_ITERATE

2003-01-24 Thread Paul Mensonides
(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

Re: [boost] MPL include problem with BOOST_PP_ITERATE

2003-01-24 Thread Paul Mensonides
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

Re: [boost] Re: is_convertible corner case

2003-01-24 Thread Paul Mensonides
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

Re: [boost] Re: Re: Policy-based smart pointers revisisted

2003-01-20 Thread Paul Mensonides
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

Re: [boost] Re: Re: Re: Policy-based smart pointers revisisted

2003-01-20 Thread Paul Mensonides
#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

Re: [boost] Re: Re: Policy-based smart pointers revisisted

2003-01-20 Thread Paul Mensonides
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

Re: [boost] Re: Re: Policy-based smart pointers revisisted

2003-01-20 Thread Paul Mensonides
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

Re: [boost] Re: Policy-based smart pointers revisisted

2003-01-19 Thread Paul Mensonides
y more difficulty than smart_ptr and smart_ptr. 2c, Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Fw: compile problems on solaris 2.8

2003-01-16 Thread Paul Mensonides
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

Re: [boost] Fw: compile problems on solaris 2.8

2003-01-16 Thread Paul Mensonides
OST_PP_CONFIG_FLAGS() BOOST_PP_CONFIG_BCC() Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Boost.Preprocessor: Token sequence to sequenceconversionmacros.

2003-01-15 Thread Paul Mensonides
// 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

Re: [boost] Re: Boost preprocessor library

2003-01-13 Thread Paul Mensonides
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

Re: [boost] Re: Boost preprocessor library

2003-01-13 Thread Paul Mensonides
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

Re: [boost] Boost preprocessor library

2003-01-13 Thread Paul Mensonides
? I'm not sure what you mean. Paul Mensonides ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] Fun, only handled by vc6/7!

2003-01-12 Thread Paul Mensonides
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

Re: [boost] Fun, only handled by vc6/7!

2003-01-12 Thread Paul Mensonides
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-

Re: [boost] Fun, only handled by vc6/7!

2003-01-12 Thread Paul Mensonides
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&

Re: [boost] Fun, only handled by vc6/7!

2003-01-12 Thread Paul Mensonides
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

Re: [boost] Fun, only handled by vc6/7!

2003-01-12 Thread Paul Mensonides
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

Re: [boost] Function Type Typedefs in Classes, Etc.

2003-01-12 Thread 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 >

Re: [boost] Function Type Typedefs in Classes, Etc.

2003-01-12 Thread Paul Mensonides
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

Re: [boost] Fun, only handled by vc6/7!

2003-01-12 Thread Paul Mensonides
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,

Re: [boost] Function Type Typedefs in Classes, Etc.

2003-01-11 Thread Paul Mensonides
- 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

Re: [boost] Function Type Typedefs in Classes, Etc.

2003-01-11 Thread Paul Mensonides
- 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

Re: [boost] Fun, only handled by vc6/7!

2003-01-11 Thread Paul Mensonides
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

[boost] Function Type Typedefs in Classes, Etc.

2003-01-11 Thread Paul Mensonides
]; 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; } ???

Re: [boost] Metaprogramming: Using static const or enum?

2003-01-11 Thread Paul Mensonides
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

Re: [boost] Metaprogramming: Using static const or enum?

2003-01-11 Thread Paul Mensonides
- 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

Re: [boost] Metaprogramming: Using static const or enum?

2003-01-11 Thread Paul Mensonides
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

Re: [boost] Re: Re: How to do this inwithboost--assert(typeid(T)==typeid(bool) )

2003-01-11 Thread Paul Mensonides
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

Re: [boost] Metaprogramming: Using static const or enum?

2003-01-11 Thread Paul Mensonides
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

Re: [boost] Re: Metaprogramming: Using static const or enum?

2003-01-11 Thread Paul Mensonides
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

Re: [boost] Metaprogramming: Using static const or enum?

2003-01-11 Thread Paul Mensonides
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

Re: [boost] Re: Re: How to do this inwithboost--assert(typeid(T)==typeid(bool) )

2003-01-10 Thread Paul Mensonides
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

Re: [boost] Re: Re: How to do this inwithboost--assert(typeid(T)==typeid(bool) )

2003-01-09 Thread Paul Mensonides
- 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. >

Re: [boost] Re: Re: How to do this inwithboost--assert(typeid(T)==typeid(bool) )

2003-01-09 Thread Paul Mensonides
- 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

Re: [boost] Re: How to do this in withboost--assert(typeid(T)==typeid(bool) )

2003-01-09 Thread Paul Mensonides
> > ( 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

Re: [boost] Re: How to do this in with boost --assert(typeid(T)==typeid(bool) )

2003-01-09 Thread Paul Mensonides
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

Re: [boost] Re: Metaprogramming: Using static const or enum?

2003-01-09 Thread Paul Mensonides
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

Re: [boost] Re: Small thing: yes_type and no_type made public?

2003-01-09 Thread Paul Mensonides
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

Re: [boost] Metaprogramming: Using static const or enum?

2003-01-09 Thread Paul Mensonides
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 &

Re: [boost] Re: Small thing: yes_type and no_type made public?

2003-01-08 Thread Paul Mensonides
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

Re: [boost] Re: Small thing: yes_type and no_type made public?

2003-01-08 Thread Paul Mensonides
> > 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

Re: [boost] Re: Small thing: yes_type and no_type made public?

2003-01-08 Thread Paul Mensonides
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

Re: [boost] Re: Metaprogramming: Using static const or enum?

2003-01-08 Thread Paul Mensonides
- 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

Re: [boost] Re: Metaprogramming: Using static const or enum?

2003-01-07 Thread Paul Mensonides
- 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

Re: [boost] Re: Metaprogramming: Using static const or enum?

2003-01-07 Thread Paul Mensonides
;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

Re: [boost] Boost.Preprocessor: Alternatives to defined(x)

2003-01-05 Thread Paul Mensonides
- 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

Re: [boost] Boost.Preprocessor: Alternatives to defined(x)

2003-01-05 Thread Paul Mensonides
- 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

Re: [boost] Boost.Preprocessor: Alternatives to defined(x)

2003-01-05 Thread Paul Mensonides
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

Re: [boost] Boost.Preprocessor: Alternatives to defined(x)

2003-01-05 Thread Paul Mensonides
- 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

Re: [boost] Boost.Preprocessor: Alternatives to defined(x)

2003-01-05 Thread Paul Mensonides
- 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

Re: [boost] Boost.Preprocessor: Alternatives to defined(x)

2003-01-05 Thread Paul Mensonides
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

Re: [boost] Boost.Preprocessor: Alternatives to defined(x)

2003-01-05 Thread Paul Mensonides
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

Re: [boost] Boost.Preprocessor: LPAREN & RPAREN

2003-01-05 Thread Paul Mensonides
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   2   >