Re: [boost] BGL: random_access_iterator_property_map missing?
Douglas Gregor wrote: On Saturday 04 January 2003 11:53 am, Vladimir Prus wrote: I was just going to use the class named in the subject. Unfortunately, it can't be found anywhere. Here what grep on an up-to-date CVS tree gives: You probably want iterator_property_map, which takes a RandomAccessIterator and is used throughout the BGL. Maybe it was once called random_access_iterator_property_map? Thanks, Doug, that's what I was looking for. And docs really call it random_access_iterator_property_map (in libs/graph/doc/using_property_maps.html). I wonder if Jeremy's around to fix that. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BGL: concept docs buglets
I think that BGL concept docs are a little bit out of sync with
the concept cheking code. I've corrected some of problems and
attach a patch. Is it OK to apply it?
Another issue is that doc talk about MutablePropertyGraphConcept,
while code has LvaluePropertyGraphConcept. I'm not sure which one
is correct.
- Volodya
? boost/graph/ChangeLog
Index: boost/graph/graph_concepts.hpp
===
RCS file: /cvsroot/boost/boost/boost/graph/graph_concepts.hpp,v
retrieving revision 1.30
diff -u -r1.30 graph_concepts.hpp
--- boost/graph/graph_concepts.hpp 18 Jan 2002 03:12:23 - 1.30
+++ boost/graph/graph_concepts.hpp 5 Jan 2003 09:18:24 -
@@ -217,6 +217,15 @@
G g;
};
+ template class G
+ struct VertexAndEdgeListGraphConcept
+ {
+void constraints() {
+ function_requires VertexListGraphConceptG ();
+ function_requires EdgeListGraphConceptG ();
+}
+ };
+
// Where to put the requirement for this constructor?
// G g(n_vertices);
// Not in mutable graph, then LEDA graph's can't be models of
Index: libs/graph/doc/BidirectionalGraph.html
===
RCS file: /cvsroot/boost/boost/libs/graph/doc/BidirectionalGraph.html,v
retrieving revision 1.5
diff -u -r1.5 BidirectionalGraph.html
--- libs/graph/doc/BidirectionalGraph.html 24 Jun 2002 16:37:02 - 1.5
+++ libs/graph/doc/BidirectionalGraph.html 5 Jan 2003 09:18:24 -
@@ -144,7 +144,7 @@
PRE
template lt;class Ggt;
- struct BidirectionalGraph_concept
+ struct BidirectionalGraphConcept
{
typedef typename boost::graph_traitslt;Ggt;::in_edge_iterator
in_edge_iterator;
Index: libs/graph/doc/VertexAndEdgeListGraph.html
===
RCS file: /cvsroot/boost/boost/libs/graph/doc/VertexAndEdgeListGraph.html,v
retrieving revision 1.3
diff -u -r1.3 VertexAndEdgeListGraph.html
--- libs/graph/doc/VertexAndEdgeListGraph.html 1 Nov 2001 17:22:28 - 1.3
+++ libs/graph/doc/VertexAndEdgeListGraph.html 5 Jan 2003 09:18:24 -
@@ -52,7 +52,7 @@
P
PRE
template lt;class Ggt;
- struct VertexAndEdgeListGraph
+ struct VertexAndEdgeListGraphConcept
{
void constraints() {
function_requireslt; VertexListGraphConceptlt;Ggt; gt;();
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
Aleksey Gurtovoy [EMAIL PROTECTED] writes: David Abrahams wrote: Aleksey Gurtovoy [EMAIL PROTECTED] writes: So, now the question is, how to name the adaptor? :) Does 'unroll_args' sound right/good enough? Neat idea! How about unary or unaryize? I like the latter, but it doesn't appear to be a word; unarize is not a word either, but at least google finds a couple of them :). On a second thought, I am not sure if it's a good choice. Does apply unarizeF, listint,long ::type convey the discussed meaning for you? OK, I have two new ideas: on_arg_seq with_arg_seq I like the first one, though many people use on_... for something very different in event-driven code. The second one has some Lisp/Scheme tradition behind it, I believe... just in the with_... naming convention. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] is the link-fail test working correctly in the regressiontests?
That sounds like a smart move. It should be easy enough if we can encode that feature into the toolsets. Can you take care of that part of the job? If so, it would be very easy for me to update testing.jam and we'd be done. Not easily, I don't currently have access to those compilers (although the options used for EDG based compilers are documented in EDG's generic docs): we really need to get some more regression tests running. Maybe we need some platform/compiler-dependent configuration which chooses the appropriate criterion for success. It's not unreliable at all, it's the exact negative of a run test. It allows a negative to be tested: that if a feature macro is *not* set, then a failure should occur if it is set, otherwise we are possibly mis-configured. My point is that it might easily report false successes when something else is wrong, e.g. you just made a typo in a variable name. Which is true for all compile-fail tests as well. Yes. All I'm saying is that a regular run-fail test has stricter requirements. Simple typos that just create compilation errors will not allow them to succeed. That's why I don't want to replace run-fail with your compile/link/run fail... ...although now the only expected failure tests we have left are compile-fail. So I don't know what to do with the others. Actually this is less of a problem here (for config tests), because we would expect the tests to build and run on some platforms, so the tests get tested in both directions (that there are some platforms were they should build and do so, and others where they should not and don't do so). I'm still very confused about this one, but I have an inkling of what might be going on. I can understand how you could make a config test which would want to be (compile-fail|run-success), and I can understand how you could use return-code-inversion to make it (compile-faile|run-fail), but I can't understand what kind of useful test could be (compile-faile|link-fail|run-fail). Let me try again. We have a series of config regression tests (one per macro), and taking feature macros for example each can be tested in two directions: The macro is defined in our config: verify that the test code compiles, links, and runs. The macro is not defined in our config: verify that trying to compile+link+run fails at some point (otherwise we could enable this feature). For example consider BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE, there are three reasons why we might not want to set this: 1) the function is not present in the headers (code doesn't compile, because the API is unsupported). 2) the function is present but linking fails (it's in the header but not the library - probably the toolset is set up wrongly for multithreaded code, or some other such problem) 3) compiling and linking succeeds, but the function doesn't actually work (it's a non-functioning stub), this situation does actually seem to be occurring on some platforms leading to deadlocks when creating and using recursive mutexes, the test doesn't currently test for this, but should do so if I can figure out how :-( To conclude then, if BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE is not set, then I want to be able to verify that the test code does not compile+link+run, otherwise the test should fail because the macro should have been set. I hope that's making sense now, John Maddock http://ourworld.compuserve.com/homepages/john_maddock/index.htm ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] is the link-fail test working correctly in theregression tests?
John Maddock [EMAIL PROTECTED] writes:
That sounds like a smart move. It should be easy enough if we can
encode that feature into the toolsets. Can you take care of that part
of the job? If so, it would be very easy for me to update testing.jam
and we'd be done.
Not easily, I don't currently have access to those compilers (although the
options used for EDG based compilers are documented in EDG's generic docs):
we really need to get some more regression tests running.
I believe it's -tused you're referring to, isn't it?
Actually this is less of a problem here (for config tests), because
we would expect the tests to build and run on some platforms, so the
tests get tested in both directions (that there are some platforms
were they should build and do so, and others where they should not
and don't do so).
I'm still very confused about this one, but I have an inkling of what
might be going on. I can understand how you could make a config test
which would want to be (compile-fail|run-success), and I can
understand how you could use return-code-inversion to make it
(compile-faile|run-fail), but I can't understand what kind of useful
test could be (compile-faile|link-fail|run-fail).
Let me try again. We have a series of config regression tests (one per
macro), and taking feature macros for example each can be tested in two
directions:
The macro is defined in our config: verify that the test code compiles,
links, and runs.
The macro is not defined in our config: verify that trying to
compile+link+run fails at some point (otherwise we could enable this
feature).
Right... but I'm still a little confused. I don't think you actually
want to test in two directions. Presumably you want to have a
single test which checks that the macro is set appropriately, no?
For example consider BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE, there are three
reasons why we might not want to set this:
1) the function is not present in the headers (code doesn't compile, because
the API is unsupported).
2) the function is present but linking fails (it's in the header but not the
library - probably the toolset is set up wrongly for multithreaded code, or
some other such problem)
I'm not convinced that a failure at this stage should make the test
succeed if it's just reflecting a problem with the toolset.
3) compiling and linking succeeds, but the function doesn't actually work
(it's a non-functioning stub), this situation does actually seem to be
occurring on some platforms leading to deadlocks when creating and using
recursive mutexes, the test doesn't currently test for this, but should do
so if I can figure out how :-(
To conclude then, if BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE is not set, then I
want to be able to verify that the test code does not compile+link+run,
otherwise the test should fail because the macro should have been set.
I hope that's making sense now,
Now it sounds like you're not testing in two directions. Oh, I see:
that otherwise does not refer to the case where
BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE is set; that's handled
differently. What I still don't understand is how you're going to
write the Jamfile for this test, since the test type has to be
determined based on the value of the macro -- 'any-fail' if it's not
set and 'run' if it's set -- and there's no provision for that sort of
feedback from header files into the build system.
Maybe you're planning to build two tests?
#if BOOST_HAS_FEATURE BOOST_EXPECT_FAIL
# error
#elif !BOOST_HAS_FEATURE !BOOST_EXPECT_FAIL
int main() { return 0; }
#else
// test code here
#endif
And then build two tests with the same source code: a 'run' test, and
an 'any-fail' test with defineBOOST_EXPECT_FAIL ??
-Dave
--
David Abrahams
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] std::wstring exists on GCC 3.2?
Hi. I've tried to compile something which uses std::wstring on GCC 3.2 (MinGW), but I get the following error at link-time: undefined reference to `std::basic_stringwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::basic_string()' Using std::string works fine. Doesn't GCC 3.2 support wide character strings? BOOST_NO_STD_WSTRING isn't set for it. Is there any other way, using Boost.Config, that I can detect this? Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] bounded multiset
I'm in a need of a container, which: - is sorted - has iterators which are not invalidated on 'insert' - keeps no more than k elements. If more elements are inserted, the smallest ones should be erased. I'm considering writing a wrapper over std::multiset for this purpose. But before I start, I wanted to ask if anybody knows existing solution. TIA, Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost license
Yitzhak Sapir [EMAIL PROTECTED] writes: D A while ago there was a call for license reviews. Various licenses were listed at: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_License for review. The STLPort license, which is available at: http://www.stlport.org/doc/license.html was not listed (or at least does not seem to be). Since it seems the spirit of boost is to provide libraries more in the spirit of open source stl, I thought that this license might be more suitable than others, and in any case deserves to be reviewed or listed among possible licenses as well. The license is composed of several parts, some of which are the result of earlier licenses in the history of STL. The STLPort portion seems more open as it seems to make no requirement regarding non-STLPort documentation. Hi Yitzhak, That's a great idea. Why don't you just add it to the list and do the review? Thanks, Dave -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bounded multiset
Vladimir Prus [EMAIL PROTECTED] writes: I'm in a need of a container, which: - is sorted - has iterators which are not invalidated on 'insert' - keeps no more than k elements. If more elements are inserted, the smallest ones should be erased. I'm considering writing a wrapper over std::multiset for this purpose. But before I start, I wanted to ask if anybody knows existing solution. If you don't really need iterator stability, and pointer/reference stability works instead, you might use a bounded heap of pointers to items stored in a deque. -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] std::wstring exists on GCC 3.2?
Terje Slettebø [EMAIL PROTECTED] writes: | Hi. | | I've tried to compile something which uses std::wstring on GCC 3.2 (MinGW), | but I get the following error at link-time: Gcc 3.2 have wstring... could the problem be how MinGW is configured? -- Lgb ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: is the link-fail test working correctly in theregression tests?
David Abrahams wrote: ...although now the only expected failure tests we have left are compile-fail. So I don't know what to do with the others. Could we introduce a third result. Pass and fail we know, 'error' would the test could not actually be run. This would reflect a compile fail for link/runtime tests, missing/corrupt files for compile tests (perhaps due to CVS corruption) and probably a couple more corner cases I haven't thought about yet. -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost.Preprocessor: LPAREN RPAREN
Hi, I have never used these two macros, but is the following code, from boost/preprocessor/punctuation/paren.hpp, correct? # /* BOOST_PP_LPAREN */ # # define BOOST_PP_LPAREN() ( # # /* BOOST_PP_RPAREN */ # # define BOOST_PP_RPAREN() ( 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. Best regards, Vesa Karvonen _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] bounded multiset
David Abrahams wrote: Vladimir Prus [EMAIL PROTECTED] writes: I'm in a need of a container, which: - is sorted - has iterators which are not invalidated on 'insert' - keeps no more than k elements. If more elements are inserted, the smallest ones should be erased. I'm considering writing a wrapper over std::multiset for this purpose. But before I start, I wanted to ask if anybody knows existing solution. If you don't really need iterator stability, and pointer/reference stability works instead, you might use a bounded heap of pointers to items stored in a deque. After more thought, I believe that I can get along with priority queue in which top is modifiable (e.g. which stores pointers). The only problem is that I don't know any existing bounded priority queue/heap classes. Those by Dietmar Kuehl are all unbounded. - Volodya ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] std::wstring exists on GCC 3.2?
From: Lars Gullik Bjønnes [EMAIL PROTECTED] Terje Slettebø [EMAIL PROTECTED] writes: | I've tried to compile something which uses std::wstring on GCC 3.2 (MinGW), | but I get the following error at link-time: Gcc 3.2 have wstring... could the problem be how MinGW is configured? It could be. It doesn't recognise std::wcout, either. I'm using Dev-Cpp, using MinGW, with default configuration, and I haven't found any configuration setting for wide character support. When using --ver, it does say 3.2. Does anybody else have experience with wide characters on MinGW? Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] [MPL] naming question
David Abrahams wrote: thought, I am not sure if it's a good choice. Does apply unarizeF, listint,long ::type convey the discussed meaning for you? No, but I'm not sure that unroll_args does either. unroll_args doesn't, in fact, unroll arguments. It's a metafunction adapter. Unroll is usually used with loops, not arguments. But that might be the best name we can come up with. When I did this sort of thing on the runtime side, I called it pack/unpack. What about unpack_args? -Dave -- Some little people have music in them, but Fats, he was all music, and you know how big he was. -- James P. Johnson ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost.Preprocessor: Alternatives to defined(x)
Hi, A typical use of the C preprocessor is to use object-like macros as flags for controlling code expansion: #if defined(OBJECT_LIKE_MACRO) EXPANDED_IF_DEFINED #else EXPANDED_IF_NOT_DEFINED #endif The OBJECT_LIKE_MACRO is usually defined either in some configuration header, or it may be defined on the command line. Most definitions are either empty: #define OBJECT_LIKE_MACRO or expand to 1: #define OBJECT_LIKE_MACRO 1 The above technique has a couple of problems. First of all, it can be difficult to read, because preprocessor directives look very different from ordinary C/C++ code. Furthermore, similar, but not exactly same, conditional blocks (the above example is simplistic) may need to be used in several places and it is quite tedious and verbose to make and use a parameterized usable conditional block using the above base technique. Preprocessor macros make parameterization and use easier. Unfortunately there is no direct way to test, in a macro, whether some arbitrary macro is defined. Usually the following tedious and verbose technique is used instead: #if defined(OBJECT_LIKE_MACRO) # define OBJECT_LIKE_MACRO_BOOL 1 #else # define OBJECT_LIKE_MACRO_BOOL 0 #endif // ... BOOST_PP_IF(OBJECT_LIKE_MACRO_BOOL, EXPANDED_IF_DEFINED, EXPANDED_IF_NOT_DEFINED) Ideally, we would have a predicate is_defined(NAME) that could be used in a macro: BOOST_PP_IF(is_defined(OBJECT_LIKE_MACRO), EXPANDED_IF_DEFINED, EXPANDED_IF_NOT_DEFINED) Unfortunately, it seems impossible to implement is_defined() using only macros in the general case. In particular, consider the following macro definition: #define X X Fortunately we do not necessarily need a complete is_defined() predicate. In most cases we only have to detect if a NAME becomes empty or the token 1 when expanded. It seems possible to say the following: BOOST_PP_IF(BOOST_PP_IS_EMPTY_OR_1(OBJECT_LIKE_MACRO), EXPANDED_IF_DEFINED, EXPANDED_IF_NOT_DEFINED) I'd like to propose adding suitable predicate macros, in particular BOOST_PP_IS_EMPTY(X), BOOST_PP_IS_1(X), BOOST_PP_IS_EMPTY_OR_1(X), to the Boost Preprocessor library to help detect whether flag like macros are defined. These macros would make it easier to move some logic from unusable #if blocks into usable macros. Best regards, Vesa Karvonen ... // The following has been tested only on GNU cpp. #include boost/preprocessor/cat.hpp #include boost/preprocessor/control/iif.hpp #include boost/preprocessor/logical/bitor.hpp #include boost/preprocessor/tuple/elem.hpp // `x' shall either expand to become empty or expand to a part of // identifier or numeric literal token. #define BOOST_PP_IS_EMPTY(x)\ BOOST_PP_IS_EMPTY_DO(x BOOST_PP_IS_EMPTY_HELPER) #define BOOST_PP_IS_EMPTY_DO(tuple_contents)\ BOOST_PP_TUPLE_ELEM(2,1,(BOOST_PP_##tuple_contents)) #define BOOST_PP_BOOST_PP_IS_EMPTY_HELPER 1, 1 #define BOOST_PP_IS_EMPTY_HELPER , 0 // `x' shall expand to a part of identifier or numeric literal token. #define BOOST_PP_IS_1(x)\ BOOST_PP_IS_EMPTY(BOOST_PP_CAT(BOOST_PP_IS_1_HELPER_,x)) #define BOOST_PP_IS_1_HELPER_1 // `x' shall either expand to become empty or expand to a part of // identifier or numeric literal token. #define BOOST_PP_IS_EMPTY_OR_1(x)\ BOOST_PP_IIF(BOOST_PP_IS_EMPTY_DO(x BOOST_PP_IS_EMPTY_HELPER),\ 1 BOOST_PP_EMPTY,\ BOOST_PP_IS_1)(x) // The following is test code #include boost/preprocessor/facilities/empty.hpp #define EMPTY 0 : BOOST_PP_IS_EMPTY(__cplusplus) 1 : BOOST_PP_IS_1(__cplusplus) 0 : BOOST_PP_IS_EMPTY(NOT_EMPTY) 0 : BOOST_PP_IS_1(NOT_EMPTY) 1 : BOOST_PP_IS_EMPTY(EMPTY) 0 : BOOST_PP_IS_EMPTY(whatever) 1 : BOOST_PP_IS_EMPTY(BOOST_PP_EMPTY()) 1 : BOOST_PP_IS_EMPTY_OR_1(BOOST_PP_EMPTY()) 1 : BOOST_PP_IS_EMPTY_OR_1(1) 0 : BOOST_PP_IS_EMPTY_OR_1(A) _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Filesystem Library mini-review
At 10:02 AM 1/5/2003, Peter Dimov wrote: From: Beman Dawes [EMAIL PROTECTED] At first glance eliminating the dependency on path seems like a win, but I'm worried about the future. I think there is at least some chance that path can be expanded to include the ability to handle wide character names. That's an excellent point, and I'm glad that wide paths aren't completely out of the question! I had a conversation with Bill Plauger, Howard Hinnant, and several other library implementors at the last C++ committee meeting, and we agreed on a possible approach to the conversion problem. Conversions between wide and narrow names has always been the hold up. No one has been willing to step forward and say Of all the possible ways to do the conversion, here is how libraries should do it. So we might actually see some progress over the next few months. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Preprocessor: LPAREN RPAREN
- Original Message - From: Vesa Karvonen [EMAIL PROTECTED] Hi, I have never used these two macros, but is the following code, from boost/preprocessor/punctuation/paren.hpp, correct? # define BOOST_PP_RPAREN() ( Yeah, I fixed it. 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 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Preprocessor: Alternatives to defined(x)
- Original Message - From: David Abrahams [EMAIL PROTECTED] Vesa Karvonen [EMAIL PROTECTED] writes: I'd like to propose adding suitable predicate macros, in particular BOOST_PP_IS_EMPTY(X), BOOST_PP_IS_1(X), BOOST_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: Alternatives to defined(x)
- Original Message - From: Vesa Karvonen [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 they can't be worked around though. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: is the link-fail test working correctly intheregression tests?
Alisdair Meredith [EMAIL PROTECTED] writes: David Abrahams wrote: ...although now the only expected failure tests we have left are compile-fail. So I don't know what to do with the others. Could we introduce a third result. Pass and fail we know, 'error' would the test could not actually be run. This would reflect a compile fail for link/runtime tests, missing/corrupt files for compile tests (perhaps due to CVS corruption) and probably a couple more corner cases I haven't thought about yet. I'm afraid implementing this feature looks very difficult to me. Patches welcome, of course! -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Preprocessor: Alternatives to defined(x)
- 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 they can't be worked around though. Vesa, I can get it to work on VC and Metrowerks if I alter the semantics slightly. Namely by doing this: #define IS_ZERO(x) IS_ZERO_I( CHECK x () ) // ... #define CHECK() 1 The semantic change is that 'x' must not be a function-like macro. What do you think? Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Preprocessor: Alternatives to defined(x)
Paul Mensonides [EMAIL PROTECTED] writes: Vesa, I can get it to work on VC and Metrowerks if I alter the semantics slightly. Namely by doing this: #define IS_ZERO(x) IS_ZERO_I( CHECK x () ) // ... #define CHECK() 1 The semantic change is that 'x' must not be a function-like macro. What do you think? I think that rules out most of the use-cases Vesa was interested in addressing with this :( -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Preprocessor: Alternatives to defined(x)
Vesa Karvonen [EMAIL PROTECTED] writes: David Abrahams: Paul Mensonides: The semantic change is that 'x' must not be a function-like macro. What do you think? I think that rules out most of the use-cases Vesa was interested in addressing with this :( Well, it does rule out some use-cases, and it is not ideal to have such limitations, but it should still be useful for testing whether an object-like macro, such as an include guard, or a config macro, has been defined. I think that there are many uses for the macro. How can you use a macro which only tells you if a function-like macro is defined to tell you if an object-like macro is defined? If we could do that, couldn't you implement your original intended semantics? -- David Abrahams [EMAIL PROTECTED] * http://www.boost-consulting.com Boost support, enhancements, training, and commercial distribution ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Preprocessor: Alternatives to defined(x)
- Original Message - From: David Abrahams [EMAIL PROTECTED] Well, it does rule out some use-cases, and it is not ideal to have such limitations, but it should still be useful for testing whether an object-like macro, such as an include guard, or a config macro, has been defined. I think that there are many uses for the macro. How can you use a macro which only tells you if a function-like macro is defined to tell you if an object-like macro is defined? No, it only tells you if an object-like macro is defined or not. If a function-like macro is passed into the function, it will more than likely result in an attempted call of the macro with insufficient arguments--which is illegal. I.e. this would be fine: #define MY_CONFIG_MACRO IS_EMPTY( MY_CONFIG_MACRO ) // 1 ...while this is 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)
- 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-like macro. ^^^ [...] How can you use a macro which only tells you if a function-like macro is defined to tell you if an object-like macro is defined? If we could do that, couldn't you implement your original intended semantics? Well, yes. It could be used for testing whether an object-like config macro has been defined. Actually, since it is not currently possible (portable) to pass around empty parameters, it really shouldn't make much difference that function-like macros may not be tested. That is why I said the semantic change was minor. The major difference is that it disallows passing any function-like macro that takes any arguments into the IS_EMPTY macro. It can still be used to test object-like macros. 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 Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Boost.Preprocessor: Alternatives to defined(x)
- 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 because of VC and Metrowerks though, but rather because of Borland, Sun, IBM, etc.. The root problem is this: x TEST_MACRO If 'x' is the name of a function-like macro, those preprocessors will effectively concatenate 'x' to 'TEST_MACRO'. This makes it impossible to use extended semantics that allow you to pass a function-like macro. In any case, I implemented everything and put it in the CVS: #include boost/preprocessor/facilities/is_1.hpp #include boost/preprocessor/facilities/is_empty.hpp #include boost/preprocessor/facilities/is_empty_or_1.hpp Vesa, I just used my own copyright stuff, since I didn't know what to use otherwise. If you want me to change it, let me know what you want me to change it to. Paul Mensonides ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: UTF library available for review
Alberto Barbati wrote: * a comprehensive test suite (with Jamfile) I almost forgot! The test suite requires the filesystem library. Special thanks to Beman Dawes for it! Alberto ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
