[boost] [Boost.Regex] [PATCH] Make boost work better whenBOOST_NO_WREGEXis defined
The following patch fixes some compilation problems when
BOOST_NO_WREGEX is defined (as we do in LyX). These concern OpenBSD
(first hunk: when BOOST_NO_WREGEX is defined we end up including
) and something I found when trying to compile with lyxstring
(no need to define compare_string(wstring,wchar_t*)).
Note that the patch is made agaist the LyX sources, not the boost
tree.
If you want a patch that is directly applyable to boost please contact
me and I will create one.
Index: boost/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/ChangeLog,v
retrieving revision 1.33
diff -u -p -r1.33 ChangeLog
--- boost/ChangeLog 3 Mar 2003 15:53:39 - 1.33
+++ boost/ChangeLog 7 Mar 2003 17:20:09 -
@@ -1,3 +1,11 @@
+2003-03-07 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * boost/regex/v3/regex_match.hpp (string_compare): do not declare
+ a version for wstring is BOOST_NO_WREGEX is defined.
+
+ * boost/regex/config.hpp: do not try to include and
+when BOOST_NO_WREGEX is defined.
+
2003-03-03 Lars Gullik Bjønnes <[EMAIL PROTECTED]>
* update boost to version pre-1.30.0
Index: boost/boost/regex/config.hpp
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/boost/regex/config.hpp,v
retrieving revision 1.4
diff -u -p -r1.4 config.hpp
--- boost/boost/regex/config.hpp3 Mar 2003 15:53:46 - 1.4
+++ boost/boost/regex/config.hpp7 Mar 2003 17:20:09 -
@@ -125,8 +125,10 @@
// If there isn't good enough wide character support then there will
// be no wide character regular expressions:
//
-#if (defined(BOOST_NO_CWCHAR) || defined(BOOST_NO_CWCTYPE) ||
defined(BOOST_NO_STD_WSTRING)) && !defined(BOOST_NO_WREGEX)
-# define BOOST_NO_WREGEX
+#if defined(BOOST_NO_CWCHAR) || defined(BOOST_NO_CWCTYPE) ||
defined(BOOST_NO_STD_WSTRING)
+# ifndef BOOST_NO_WREGEX
+#define BOOST_NO_WREGEX
+# endif
#else
# if defined(__sgi) && defined(__SGI_STL_PORT)
// STLPort on IRIX is misconfigured: does not compile
Index: boost/boost/regex/v3/regex_match.hpp
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/boost/boost/regex/v3/regex_match.hpp,v
retrieving revision 1.1
diff -u -p -r1.1 regex_match.hpp
--- boost/boost/regex/v3/regex_match.hpp3 Mar 2003 15:53:46 - 1.1
+++ boost/boost/regex/v3/regex_match.hpp7 Mar 2003 17:20:09 -
@@ -56,8 +56,10 @@ inline int string_compare(const std::bas
{ return s.compare(p); }
inline int string_compare(const std::string& s, const char* p)
{ return std::strcmp(s.c_str(), p); }
+# ifndef BOOST_NO_WREGEX
inline int string_compare(const std::wstring& s, const wchar_t* p)
{ return std::wcscmp(s.c_str(), p); }
+# endif
# define STR_COMP(s,p) string_compare(s,p)
#endif
--
Lgb
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: possible addition to operators library
Daniel Frey wrote: > > One problem I just found with your implementation (and thus with Peter's > idiom in general) is, that is doesn't provide an operator bool(). This This sounds too hard. Of course it's not a problem where Peter used it as there obviously is no other operator int() or something. The problem only occurs when you try to create a generic component that should work with all classes. > [...] > int(). Several options come to mind: > > - Document it that the class T of bool_testable< T > shall not have any > other operators that might conflict. > - Use the above alternative implementation I showed. It is not as nice as > yours/Peter's wrt error-messages, but it works as expected. > - Convince the standard committee that "explicit operator bool" is needed > :) See: > http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&frame=right&th=d0969f0fa2460dd4&seekm=3A2D10EE.35544D0A%40aixigo.de#link1 Another alternative would be to create a selector which switches from the safe-bool-idiom to a real operator bool when appropriate. This would involve type-traits I guess and as a start we could try to detect convertability to bool of the class T. But this is IMHO not sufficient, as T might have operator int() and operator long(), so the detection will fail (ambiguous). Although this alternative would lead to the best result, I don't have a clever idea how to achieve that... Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: possible addition to operators library
Daniel Frey wrote: > > BTW: I wonder if gmane eats messages. I cannot find some messages we > exchanged when I was still in the company earlier this day. I will keep an > eye on it in case the problem remains. False alarm, gmane.org works perfectly well. I just had to fix my mail-filters :) Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Perlin noise generator
I've written a Perlin noise generator that I'd like to submit to Boost. You can get the preliminary version from: http://xultekh.net.nz/c++/boost_perlin.tgz It includes user documentation for the class and a simple test harness; I've still got to add some more documentation explaining how Perlin noise works. (There are some sketchy comments in the header describing the implementation, but they won't make much sense to readers not already familiar with the algorithm.) -- Ross Smith . [EMAIL PROTECTED] . Auckland, New Zealand Eagles may soar, but weasels never get sucked into a land war in Asia. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Does this compiler need configuring?
At 02:17 AM 3/8/2003, Daryle Walker wrote:
>> Try compiling libs/config/config_info.cpp and running it. The output
>> will tell you what the configuration looks like. It will identify the
>> platform, compiler, library, and the important macros defined for
>> each. Look for macros which are obviously wrong, such as
>> BOOST_NO_STDC_NAMESPACE.
>
>I can't compile the file; the BOOST_NO_STDC_NAMESPACE mistake results
>in a compilation error (which prevents running). How would I override
>this particular macro?
>
>I could preprocess the file, and here are the results, removing the
>macro printings that result two identical strings (which I think means
>that the macro isn't defined at all):
>
>...
>
>print_macro("BOOST_NO_STDC_NAMESPACE", "=") ;
So Howard was right - BOOST_NO_STDC_NAMESPACE is defined but shouldn't be.
Look at boost/config/posix_features.hpp, around line 38:
# ifndef __APPLE_CC__
// GCC strange "ignore std" mode works better if you pretend everything
// is in the std namespace, for the most part.
#define BOOST_NO_STDC_NAMESPACE
# endif
Note that this is inside an #if:
#if __MACH__ && !defined(_MSL_USING_MSL_C)
It looks to me like something is wrong with one or the other of these two
pieces of code. But since I know nothing of the Mac OS, I won't hazard a
guess as to the exact problem or the fix.
Mac experts?
--Beman
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: how to avoid inclusions?
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Thorsten Ottosen" <[EMAIL PROTECTED]> writes:
>
> > my code does not include , or , but it does need
> > .
> >
> > Some of the functionality of the container_traits are shown here:
> >
> >
> > template< typename C >
> > bool is_container()
> > {
> > return boost::container_traits::is_container();
> > }
>
> ...
>
> Yes, you can take an approach like this one, but it will cause false
> positives in some circumstances. If that's acceptable for your
> application, then it's a good answer.
I guess you're thinking about classes with eg. an iterator typedef.
Couldn't the procedure be improved a little by doing something
like
template< typename C >
true_t is_container( const C&, const typename C::iterator& =
typename C::iterator(),
const typename C::const_iterator& = typename C::const_iterator(),
);
That way we would reduce the likelyhood of false positives a lot. Or would
we?
regards
Thorsten
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Does this compiler need configuring?
On Saturday, March 8, 2003, at 07:28 AM, Beman Dawes wrote: So Howard was right - BOOST_NO_STDC_NAMESPACE is defined but shouldn't be. Look at boost/config/posix_features.hpp, around line 38: # ifndef __APPLE_CC__ // GCC strange "ignore std" mode works better if you pretend everything // is in the std namespace, for the most part. #define BOOST_NO_STDC_NAMESPACE # endif Note that this is inside an #if: #if __MACH__ && !defined(_MSL_USING_MSL_C) It looks to me like something is wrong with one or the other of these two pieces of code. But since I know nothing of the Mac OS, I won't hazard a guess as to the exact problem or the fix. Mac experts? I see in macos.hpp: // If __MACH__, we're using the BSD standard C library, not the MSL: #if __MACH__ That is a false statement. It was true with Pro 7, but not Pro 8. Try this instead: #include // ifdef _MSL_USING_GCC_C, we're using the BSD standard C library, not the MSL: #ifdef _MSL_USING_GCC_C -Howard ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Using weak_ptr with a hash
Joe Gottman wrote: >I just realized that it would be impossible to use weak_ptr with > any > hash. The problem is that the hash function would have to use > weak_ptr's get() method. Then if the underlying object of the > weak_ptr gets destroyed, get() will suddenly return 0 instead of the > previous pointer, so the hash function will now map the weak_ptr to a > new bucket. Is there any way to > add a member function that returns a const void * that will be > invariant > even if the underlying object of the weak_ptr has been destroyed? weak_ptr no longer has get(). You are right that currently shared_ptr and weak_ptr work as std::map keys but not as hash_map keys, and that we need to add _some kind_ of hash table support. One easy approach is to supply a "size_t hash_value() const" member function; this will allow "expert" users to use shared_ptr/weak_ptr in a hash table by creating an appropriate hash function object _and_ equivalence object (important since shared_ptr/weak_ptr equivalence isn't a == b but !(a < b) && !(b < a)). I would rather prefer to make hash_set and hash_map work "out of the box" with a shared_ptr and weak_ptr. Unfortunately, there is no standard hash_* interface yet, and the formal proposal by Matt Austern doesn't address the problem well. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] New stuff into sandbox and Yahoo files section
Hi everybody, this is just to let you know that I've now committed the new version of static_log2<> to the boost sandbox: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost-sandbox/boost-sandbox/boost/integer/static_log2.hpp and a bunch of new traits to the Yahoo files section: http://groups.yahoo.com/group/boost/files/MoreTraits.zip Besides some templates that could IMHO be useful to improve the portability of detail/limits.hpp (width<> and precision<>) there are two simple knick-knacks, const_min<> and const_max, that I would like to take the place of the analogous components in the Integer library. Here's a complete list of the zip contents: - const_max<>, const_min<> Give maximum and minimum value of a built-in integral type as integral constants. Differently from the traits already available in Boost.Integer they don't use derivation from std::numeric_limits. - has_sign<> Tells whether the type can represent negative values. Probably useful before they clarify whether numeric_limits :: is_signed tells for built-in types the same information than this, or just says whether T is one of the four signed types listed in 3.9.1 [to illustrate the difference: char is not a "signed integer type"; but it can have negative values on many implementations] BTW, there's something similar to this in detail/numeric_traits.hpp, so it could be useful at least to refactor that code (Incidentally: Dave, the comment there seem to reveal that intent was for it to work for UDTs too. Of course it doesn't even work for built-in floating points.) - padding.hpp Gives the number of bits of an integral type that do not contribute to represent the value. - promoted.hpp Gives the promoted type for an rvalue expression of integral or floating point type. Example: promoted::type // -> int promoted::type // -> int or unsigned int, //depending on the implementation - wchar_min_max.hpp Implementation detail to make up for broken libraries lacks. - unit_test.cpp/.hpp Obvious purpose. Any comments will be greatly appreciated. Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] XML Samples...
I've been trying to use the XML samples in libs/example/application/xml. They build fine, but get a runtime assert when given even the simplest xml file. Are these samples kept up to date? Here's the assert that I get: Assertion (r.is_valid()) failed in "range_run.ipp", function "set", line 132 This is on Mac OS X using CodeWarrior 8. Thanks, Michael- ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New stuff into sandbox and Yahoo files section
Gennaro Prota <[EMAIL PROTECTED]> writes: > Any comments will be greatly appreciated. "Make 'em MPL-compatible metafunctions." -Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Spirit problem with CW8 on MacOS X (was Re: [boost] XML Samples...)
Michael Burbidge wrote: > I've been trying to use the XML samples in > libs/example/application/xml. They build fine, but get a runtime > assert > when given even the simplest xml file. Are these samples kept up to > date? Here's the assert that I get: > > Assertion (r.is_valid()) failed in "range_run.ipp", function "set", > line 132 > > This is on Mac OS X using CodeWarrior 8. I assume this is a Spirit related question. Before anything else, please post Spirit support related questions to: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spirit-general Also, it would be best to write a more descriptive title. Otherwise, your post might probably be easy to miss. Ok, nuff said... The XML stuff has been tested and works with no problems on Windows and Linux. I come from the Mac but unfortunately I do not have access to a Mac and CW8 right now. Fortunately Paul Snively volunteered to check Spirit on CW8 on the Mac. You can also help out by giving us a more detailed account. For instance, what is the current state of the range (r) when the assertion fired? Please post subsequent messages to Spirit's mailing lits. Let's continue this thread there. Thank you. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
