[boost] Re: Insufficient significant digits using lexical_cast
On Sunday, August 17, 2003, at 10:33 PM, Paul A. Bristow wrote: [SNIP] But you are right that it would be better to check that numeric_limits::digits exists and isn't something silly before using the formula. With all the built-in floating point types it should be fine, and for other (well) User defined floating point types too. (I will look at this). [TRUNCATE] I think you need to check numeric_limits::radix since your algorithm had a base-2-to-10 conversion (the type may not actually be binary!). The algorithm was based off a paper about IEEE-754; if IEEE-754 is a requirement, you may have to check for that too (via numeric_limits::is_iec559). Remember that even the built-in floating-point types aren't guaranteed to match IEEE-754! Daryle ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: POSIX, gcc, Comeau, Boost.Test, glibc
My understanding is that Boost.Config should take care about these issues. Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in case if there is no support for POSIX interfaces. Could you report the value of that flag in case of compilation failures you are expiriencing. Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Release notes for 1.30.2
Aleksey Gurtovoy wrote: Below are the remaining changes that need to be commented on: martin_wille * tools/build/intel-linux-tools.jam: need -lrt, always intel-linux-tools: added rt to FINDLIBS in order to make the clock_gettime() function available (backport of a patch in CVS HEAD) Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Date iterators in Boost Date-Time
En réponse à Paul A. Bristow [EMAIL PROTECTED]: But as Michael Caine said Not a lot of people know that - so I trust you will explain what it does too for the benefit of us mere non-mathematical mortals! Paul I'm not sure to understand. Do you want me to explain what a convex hull is or to explain what the function of the date-time library is supposed to do? I suppose it's the first, since the second is what started this subthread. A connected set is a set for which each couple of points are connected by a path itself included in the set (all the points are reachable from all the points). A convex set is a connected set with linear paths (all the points can be reached from all the other points by following a segment). The convex hull of a set is the smallest convex superset of it. For example, given three points in the plane, the convex hull is the filled triangle defined by these points. In the case of a 1-dimension space, connected and convex set are equals: they are segments (or half-line or line or empty). Date manipulated by the date-time library are in a 1-dimension space (the real line) and periods are segments (non-empty bounded convex sets). So when you have two periods, the smallest period enclosing these two is also the convex hull of them. Hence the name I suggested. I hope it makes sense. Regards, Guillaume ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: POSIX, gcc, Comeau, Boost.Test, glibc
Gennadiy Rozental wrote: My understanding is that Boost.Config should take care about these issues. Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in case if there is no support for POSIX interfaces. Could you report the value of that flag in case of compilation failures you are expiriencing. BOOST_HAS_SIGACTION gets defined to an empty string for como, gcc -ansi -U_GNU_SOURCE and for icc -D__STRICT_ANSI__. Boost.Config uses _POSIX_VERSION to determine wether sigaction() is available. The presence of _POSIX_VERSION doesn't indicate wether the POSIX API has actually been enabled. If we want to use Boost.Config to take care of this then Boost.Config also has to check wether POSIX has been enabled. This would be a very tedious task. glibc uses a plethora of flags to enable POSIX, other implementations probably will also add some flags. Regards, m ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
Guillaume Melquiond [EMAIL PROTECTED] writes: | In the case of a 1-dimension space, connected and convex set are | equals: they are segments (or half-line or line or empty). Date | manipulated by the date-time library are in a 1-dimension space (the | real line) and periods are segments (non-empty bounded convex | sets). So when you have two periods, the smallest period enclosing | these two is also the convex hull of them. Hence the name I suggested. that is fine for some mathematically oriented mind. However, it is a terrible name. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
The current approach is clearly too restrictive and isn't satisfactory.
Beyond the problems you mention, there really isn't a single standard for
portability. Even 8.3 names aren't portable to systems which don't allow
periods in names. A whole family of checkers is needed, giving various
degrees of portability. Some should be supplied with the library, but
users
also need to be able to provide their own.
[...]
boost/filesystem/path.hpp added this:
typedef bool (*is_portable_test)( string candidate );
class scoped_portability_policy : noncopyable
{
public:
explicit scoped_portabiity_policy( is_portable_test f );
~scoped_portabiity_policy();
};
I'm not sure 'portability' is the right word here.
Since it can be overridden by the user, maybe a better name would be:
is_legal_name_test - and the user can override it to suit its needs.
I don't quite like is_portable_test, since I assume there is only
one 'portability', not more (at least, this is what I think, when
discussing portability). For instance, when talking about a portable name,
I assume there is a clear definition of what that means to everybody
(and I don't assume users could/should override that ;).
That said, instead of a scoped portability policy, which will go rather
bad with thread-safety, maybe, just a simple
set_legal_name_policy( is_legal_name_test f); would look better.
Users would (should) set this in main(), while there are no more threads,
and it could play nicely with thread-safety as well.
Best,
John
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: POSIX, gcc, Comeau, Boost.Test, glibc
My understanding is that Boost.Config should take care about these issues. Boost.Test rely on BOOST_HAS_SIGACTION flag. It should not be defined in case if there is no support for POSIX interfaces. Could you report the value of that flag in case of compilation failures you are expiriencing. BOOST_HAS_SIGACTION gets defined to an empty string for como, gcc -ansi -U_GNU_SOURCE and for icc -D__STRICT_ANSI__. Boost.Config uses _POSIX_VERSION to determine wether sigaction() is available. The presence of _POSIX_VERSION doesn't indicate wether the POSIX API has actually been enabled. If we want to use Boost.Config to take care of this then Boost.Config also has to check wether POSIX has been enabled. This would be a very tedious task. glibc uses a plethora of flags to enable POSIX, other implementations probably will also add some flags. My gut feeling is that checking for _POSIX_C_SOURCE would probably be the standard conforming way to handle this, but is likely to break on some systems. Could we not just add define_POSIX_C_SOURCE=200112 to the test library's requirements? On the other hand, I notice that the requirement to specify this, is only for conforming C applications, nothing is mentioned about other languages (if we're being picky about this). John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: POSIX, gcc, Comeau, Boost.Test, glibc
At 05:13 AM 8/18/2003, Gennadiy Rozental wrote: Boost.Config uses _POSIX_VERSION to determine wether sigaction() is available. The presence of _POSIX_VERSION doesn't indicate wether the POSIX API has actually been enabled. If we want to use Boost.Config to take care of this then Boost.Config also has to check wether POSIX has been enabled. This would be a very tedious task. glibc uses a plethora of flags to enable POSIX, other implementations probably will also add some flags. It would be very tedious to repeat this check in every place that needs to rely on POSIX API. I think the Boost.Config is the very place to make a fix. Could you submit a patch for the compilers you know about? Our Boost.Config maintainer will need to varify and admit it in though. I agree with Gennadiy. The detection code should be concentrated in Boost.Config rather than repeated in multiple libraries. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost Consluting mirror .... problem?
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: C:\Projects\boost.bcbjam -sTOOLS=vc7.1 C:\Projects\boost.bc\tools/build\boost-base.jam: line 2320: parse error at keyword ( C:\Projects\boost.bc\tools/build\boost-base.jam: line 2320: parse error at keyword ) libs\date_time\build\Jamfile:31: in load-jamfiles rule dll unknown in module C:\Projects\boost.bc\tools/build\allyourbase.jam:1620: in SubInclude C:\Projects\boost.bc\tools/build\allyourbase.jam:1212: in subinclude Jamfile:4: in load-jamfiles C:\Projects\boost.bc\tools\build\bootstrap.jam:15: in boost-build C:\Projects\boost.bc\boost-build.jam:17: in module scope At Sunday 2003-08-17 21:37, you wrote: when I do the checkout from: Boost Consulting is now hosting Boost CVS mirrors. See http://www.boost.org/more/download.html You might try using the hourly tarball instead. Temporary bugs do creep into CVS from moment-to-moment, and the CVS mirror is usually a day behind the tarball. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: uClibc and Boost
Jeff Gray [EMAIL PROTECTED] writes: David Abrahams wrote: Jeff, this is a very Python-specific problem. You'll probably have better luck posting on the C++-sig: http://www.boost.org/more/mailing_lists.htm#cplussig Thanks David, that is probably a better forum. I hadn't read closely enough to realise this is the developer's list only. You're welcome. Incidentally, you might also try Python-list (comp.lang.python) since there's much in your question that's not even specific to Boost. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: checked_delete / CW8
Peter Dimov wrote: It is worth mentioning that this is a confirmed bug in CW with -iso_templates on (unreferenced typedefs are incorrectly optimized out at definition time). Masking compiler bugs in this way does not help compiler writers who use Boost as a test suite. The bug is already fixed for the CW9 and all other compilers weren't affected anyway, so I thought it's pointless to add #if defined(__MWERKS__) __MWERKS__ 0x3200 to protect the new code. Also, you haven't done that for the fix for the Intel-compiler yourself, so why do you mention it now? And AFAICS if we would really be serious about the regression testing for compiler vendors, this needs to be pulled to the config-system anyway. Remember who said: Dependencies. I hate dependencies. :) 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] Re: xml library
I'd be interested in such library. I think that boos::xml library should be using boost::spirit for parsing XML streams. I have now hand-coded parser. I'm actually more interested whether the interface of the library is ok, so I think I'll submit the current version, and I'll try to switch the implementation to spirit, if it fits there. Regards, Wojtek ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: checked_delete / CW8
Daniel Frey [EMAIL PROTECTED] writes: Peter Dimov wrote: It is worth mentioning that this is a confirmed bug in CW with -iso_templates on (unreferenced typedefs are incorrectly optimized out at definition time). Masking compiler bugs in this way does not help compiler writers who use Boost as a test suite. The bug is already fixed for the CW9 and all other compilers weren't affected anyway, so I thought it's pointless to add #if defined(__MWERKS__) __MWERKS__ 0x3200 to protect the new code. You should use BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3003)) in order to be friendly to compiler writers who want to use Boost for testing. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: xml library
I have been using expat for a while, and wrapping it in C++ classes. It's a very capable parser and supports lot's of stuff. My parser stuff is just done with a switch statement (since it's event driven), but it would be nice if you could use expat, but then register your element handlers to get called. This would be a cool design. I think it could get too complicated. The base difference between registered handlers design, and iterators design, is that in the former the parser has control, and in the latter the client code has control. I think that because of that fact it can be rather complicated to build iterator access based on handlers. But the other way around it is easy. I don't think I could actually use the iterator design that you have, since I need to handle the nesting of tags, so I need to know when I am started and finished a tag. I also need to know the normal CDATA or comments that just came through. Is this possible with the iterator idea? All of it is possible. CDATA support is available now. Comments are not supported yet. Nesting of tags is supported in the following way: if you have an iterator i, then ++i moves to the next thing on the same level. If i points to an element, then you can iterate through its contents with i-begin() and i-end(). I'll submit the library in short time, and you are very welcome to make experiments with it. Regards, Wojtek ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: checked_delete / CW8
Daniel Frey wrote: Peter Dimov wrote: It is worth mentioning that this is a confirmed bug in CW with -iso_templates on (unreferenced typedefs are incorrectly optimized out at definition time). Masking compiler bugs in this way does not help compiler writers who use Boost as a test suite. The bug is already fixed for the CW9 and all other compilers weren't affected anyway, so I thought it's pointless to add #if defined(__MWERKS__) __MWERKS__ 0x3200 to protect the new code. Also, you haven't done that for the fix for the Intel-compiler yourself, so why do you mention it now? Because the two cases are different. In the Intel case, the compiler deliberately allows certain (not really uncommon) broken code in headers, presumably in order to compile some broken system header. In the Metrowerks case our tests exposed a compiler bug that wasn't deliberately coded in. Had our headers been fixed beforehand, the compiler bug wouldn't have been caught. Thanks for listening. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
HL7 v3, a health care application layer specification, uses the term with time intervals as
an operation on a totally ordered set that produces the smallest interval that is a superset.
For example, hull({[1,5], [7,10]}) == [1,10]
The unabridged specification part II available on Dr. Schadow's page http://aurora.regenstrief.org/v3dt/
gives nice examples.
On Sunday, August 17, 2003, at 05:13 PM, Paul A. Bristow wrote:
But as Michael Caine said Not a lot of people know that - so I trust you will
explain what it does too for the benefit of us mere non-mathematical mortals!
Paul
| -Original Message-
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED]
| Sent: Sunday, August 17, 2003 7:11 AM
| To: Boost mailing list
| Subject: Re: [boost] Re: Date iterators in Boost Date-Time
|
|
| En réponse à Jeff Garland [EMAIL PROTECTED]>:
|
| I just wanted to mention that the interval library names this
| operation hull.
| It is a mathematically defined term since the operation is indeed a
| convex hull.
|
| Just my two eurocents,
|
| Guillaume
|
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: XMLUI (was Re: Re: UI++)
May I come with a bit of scepticism? There's already XUL (see http://xulplanet.com for a start, and http://www.mozilla.org/catalog/architecture/xul/ for more details). I think Mozilla folks put some effort into it, so I wonder if XMLUI offers something new/better? I would say that targets of these two projects are somewhat different. XML UI (IIUC) will support static definition of the layout and functionality in the C++ source code itself, while XUL defines layout (and some functionality) in the external XML file. It's like compile time (XMLUI) vs run-time (XUL). If you ask me, latter is a better approach if done right, but it is very hard to make all this portable. Drazen ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::filesystem file restrictions
At 05:43 AM 8/18/2003, John Torjo wrote:
The current approach is clearly too restrictive and isn't satisfactory.
Beyond the problems you mention, there really isn't a single standard
for
portability. Even 8.3 names aren't portable to systems which don't
allow
periods in names. A whole family of checkers is needed, giving various
degrees of portability. Some should be supplied with the library, but
users
also need to be able to provide their own.
[...]
boost/filesystem/path.hpp added this:
typedef bool (*is_portable_test)( string candidate );
class scoped_portability_policy : noncopyable
{
public:
explicit scoped_portabiity_policy( is_portable_test f );
~scoped_portabiity_policy();
};
I'm not sure 'portability' is the right word here.
Since it can be overridden by the user, maybe a better name would be:
is_legal_name_test - and the user can override it to suit its needs.
I don't quite like is_portable_test, since I assume there is only
one 'portability', not more (at least, this is what I think, when
discussing portability). For instance, when talking about a portable
name,
I assume there is a clear definition of what that means to everybody
(and I don't assume users could/should override that ;).
That said, instead of a scoped portability policy, which will go rather
bad with thread-safety, maybe, just a simple
set_legal_name_policy( is_legal_name_test f); would look better.
Users would (should) set this in main(), while there are no more threads,
and it could play nicely with thread-safety as well.
Yes. Plus there are some other issues.
The actual interface would include boost::filesystem::path constructors
which take an additional argument to explicitly specify a name checker
function. In working out use cases, it seems that temporary overrides of
the default function are best handled via these constructors. That leaves
only the case of wishing to permanently replace the default function, and
the simpler approach you are talking about would be better for that.
For safety, such a set_legal_name_policy() would use the
write-once-before-read idiom to avoid a dangerous global variable. (I'm
actually thinking of name_check for the type, and set_name_check for
the function name.)
I'm about to post a message asking for opinions on the details of the
policy function pointer or object.
--Beman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: checked_delete / CW8
David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: Peter Dimov wrote: It is worth mentioning that this is a confirmed bug in CW with -iso_templates on (unreferenced typedefs are incorrectly optimized out at definition time). Masking compiler bugs in this way does not help compiler writers who use Boost as a test suite. The bug is already fixed for the CW9 and all other compilers weren't affected anyway, so I thought it's pointless to add #if defined(__MWERKS__) __MWERKS__ 0x3200 to protect the new code. You should use BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3003)) in order to be friendly to compiler writers who want to use Boost for testing. I know, but this is exactly what Peter meant by Dependencies. I hate dependencies. IIUC and I tried to respect that. It's why I used a one-size-fits-all approach. 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] [Filesystem] Exact type of name checking function?
In discussions about being able to specify a function to check the validity of path element names, a simple function pointer has been used: typedef bool (*name_check)( const std::string name ); Alternately, boost::function could be used. The boost::function docs mention several advantages over function pointers; the advantage that might particularly apply is that: Boost.Function allows arbitrary compatible function objects to be targets (instead of requiring an exact function signature). That can be a really powerful advantage in some applications, but usage of name checking in boost::filesystem seems likely to be limited to very simple cases where plain function pointers will do just fine. I'd also like to avoid the dependency on an additional library, since Boost regression test reporting breaks if boost::filesystem::path breaks. So unless someone comes forward with a killer argument, a simple function pointer will be used. Comments? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
On Mon, 18 Aug 2003 06:34:35 -0500, John Fuller wrote
HL7 v3, a health care application layer specification, uses the term
with time intervals as
an operation on a totally ordered set that produces the smallest
interval that is a superset.
For example, hull({[1,5], [7,10]}) == [1,10]
The unabridged specification part II available on Dr. Schadow's page
http://aurora.regenstrief.org/v3dt/
gives nice examples.
John -
Thanks for this pointer. I've changed the name to hull in CVS so it will be
nice to have some examples. This is one of the more interesting public
specifications of time related concepts I've seen -- matches up quite well
with many of the concepts in the library :-)
Jeff
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
On 18 Aug 2003 11:43:26 +0200, Gabriel Dos Reis wrote Guillaume Melquiond [EMAIL PROTECTED] writes: | In the case of a 1-dimension space, connected and convex set are | equals: they are segments (or half-line or line or empty). Date | manipulated by the date-time library are in a 1-dimension space (the | real line) and periods are segments (non-empty bounded convex | sets). So when you have two periods, the smallest period enclosing | these two is also the convex hull of them. Hence the name I suggested. that is fine for some mathematically oriented mind. However, it is a terrible name. Here is how I explain it: Combines two periods and any gap between them such that start = min(p1.start, p2.start) end = max(p1.end , p2.end) Or graphically: [---p1---) [---p2---) result: [---p3--) Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Filesystem] Exact type of name checking function?
Beman Dawes wrote: In discussions about being able to specify a function to check the validity of path element names, a simple function pointer has been used: typedef bool (*name_check)( const std::string name ); Alternately, boost::function could be used. The boost::function docs mention several advantages over function pointers; the advantage that might particularly apply is that: Boost.Function allows arbitrary compatible function objects to be targets (instead of requiring an exact function signature). That can be a really powerful advantage in some applications, but usage of name checking in boost::filesystem seems likely to be limited to very simple cases where plain function pointers will do just fine. I'd also like to avoid the dependency on an additional library, since Boost regression test reporting breaks if boost::filesystem::path breaks. So unless someone comes forward with a killer argument, a simple function pointer will be used. Comments? I disagree. You have a magnificent implementation in boost::function, which can be bound to many different callback types, and yet you don't want to use it simply to reduce a dependency. Why restrict the end-user to a global function and go back to C++ programming of years ago simply because you are afraid of being dependent on another implementation ? My callback function may well be dependent on another class within which I may be using the boost::filesystem, and to now have to fool around with global functions instead of allowing a class member function to handle the callback is archaic. Why create event handling and callbacks via boost::function, boost::bind, and boost::signals if Boost implementors themselves don't want to use these ideas when they create their libraries ? It's a rhetorical question but it is well-meant. Give the end-user the widest possible latitude, and just bite the bullet of what you need to do to make your library as effective as it can be. That's my opinion, for what it is worth. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Beman Dawes [EMAIL PROTECTED] writes: Yes. Plus there are some other issues. The actual interface would include boost::filesystem::path constructors which take an additional argument to explicitly specify a name checker function. In working out use cases, it seems that temporary overrides of the default function are best handled via these constructors. That leaves only the case of wishing to permanently replace the default function, and the simpler approach you are talking about would be better for that. For safety, such a set_legal_name_policy() would use the write-once-before-read idiom to avoid a dangerous global variable. (I'm actually thinking of name_check for the type, and set_name_check for the function name.) I'm about to post a message asking for opinions on the details of the policy function pointer or object. This starts to align with what I've been thinking. Every path object could maintain a chain of checkers, and combinations of path objects (e.g. via operator/) would use the union of the checkers of their components, so that checking would never become less-restrictive silently. Of course, though I think this goes against the grain of the library, I believe the default checker should always be the for the native platform. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: checked_delete / CW8
Daniel Frey [EMAIL PROTECTED] writes: David Abrahams wrote: Daniel Frey [EMAIL PROTECTED] writes: Peter Dimov wrote: It is worth mentioning that this is a confirmed bug in CW with -iso_templates on (unreferenced typedefs are incorrectly optimized out at definition time). Masking compiler bugs in this way does not help compiler writers who use Boost as a test suite. The bug is already fixed for the CW9 and all other compilers weren't affected anyway, so I thought it's pointless to add #if defined(__MWERKS__) __MWERKS__ 0x3200 to protect the new code. You should use BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3003)) in order to be friendly to compiler writers who want to use Boost for testing. I know, but this is exactly what Peter meant by Dependencies. I hate dependencies. IIUC and I tried to respect that. I think that's a bit extreme. If people refuse to use BOOST_WORKAROUND because it creates a dependency on a single header file, it will undermine what we are trying to achieve with it. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Filesystem] Exact type of name checking function?
Beman Dawes [EMAIL PROTECTED] writes:
In discussions about being able to specify a function to check the
validity of path element names, a simple function pointer has been
used:
typedef bool (*name_check)( const std::string name );
Alternately, boost::function could be used. The boost::function docs
mention several advantages over function pointers; the advantage that
might particularly apply is that:
Boost.Function allows arbitrary compatible function objects to be
targets (instead of requiring an exact function signature).
That can be a really powerful advantage in some applications, but
usage of name checking in boost::filesystem seems likely to be limited
to very simple cases where plain function pointers will do just
fine. I'd also like to avoid the dependency on an additional library,
since Boost regression test reporting breaks if
boost::filesystem::path breaks.
So unless someone comes forward with a killer argument, a simple
function pointer will be used.
Comments?
FWIW, Boost.Function is overkill for many simple cases. This might
be a case where the FS library should just provide a class with a
virtual function:
struct checker
{
virtual ~checker() {}
virtual bool operator()( std string const ) = 0;
shared_ptrchecker next; // suggested.
};
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Filesystem] Exact type of name checking function?
Edward Diener wrote: Beman Dawes wrote: In discussions about being able to specify a function to check the validity of path element names, a simple function pointer has been used: typedef bool (*name_check)( const std::string name ); Alternately, boost::function could be used. [...] I prefer that we have a good understanding of the semantics first, which I admit I do not. Comments? I disagree. You have a magnificent implementation in boost::function, which can be bound to many different callback types, and yet you don't want to use it simply to reduce a dependency. [...] The problem is that merely including boost/function.hpp may render the filesystem library unusable on some compilers, even if alternative name checkers are never used. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Filesystem] Exact type of name checking function?
David Abrahams wrote:
FWIW, Boost.Function is overkill for many simple cases. This might
be a case where the FS library should just provide a class with a
virtual function:
struct checker
{
virtual ~checker() {}
virtual bool operator()( std string const ) = 0;
shared_ptrchecker next; // suggested.
};
Boost.Function makes things simpler for the user.
enum check_type { check_posix, check_windows, ... };
bool my_name_checker(std::string const s, check_type t);
Compare
bind(my_name_checker, _1, check_posix)
against
struct my_name_checker_: public checker
{
check_type t_;
my_name_checker_(check_type t): t_(t) {}
bool operator()( std::string const s)
{
return my_name_checker(s, t_);
}
};
It is still possible to substitute a homegrown functionbool(string) (or
functionbool(char const *)) equivalent for portability reasons, of course.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
Jeff Garland [EMAIL PROTECTED] writes: | On 18 Aug 2003 11:43:26 +0200, Gabriel Dos Reis wrote | Guillaume Melquiond [EMAIL PROTECTED] writes: | | | In the case of a 1-dimension space, connected and convex set are | | equals: they are segments (or half-line or line or empty). Date | | manipulated by the date-time library are in a 1-dimension space | (the | real line) and periods are segments (non-empty bounded convex | | sets). So when you have two periods, the smallest period enclosing | | these two is also the convex hull of them. Hence the name I suggested. | | that is fine for some mathematically oriented mind. However, it is a | terrible name. | | | Here is how I explain it: Oh, I'm myself a Geometer and I understand the terminology and have a good mental picture of it. But if we were after accurate, descriptive and mathematically oriented terminology, I can throw geodesic arc for this particular case (and I may even attempt to justify it from General Relativity point of view :-). The point of my previous remark is that it is one thing to justify a a name from a mathematically oriented point of view, it is another to name a software entity designed for brother audience; and even for a mathematical audiance I doubt it would be a good name in the case under consideration. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.2 status
Martin Wille wrote: Aleksey Gurtovoy wrote: Things to be done (at large): 1) Linux regressions, on RC_1_30_0. Martin, since fixing the aforementioned problems involved some changes in the CVS (including some jam files), could you please do a clean run? Done. No regressions. Perfect, thank you! I've got all the notes too, so will check in the updated 'index.htm' shortly. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Global vars
Well,
I've tried to work through the solutions to:
ld: common symbols not allowed with MH_DYLIB output format
Which are basically -fno-common on the compile line of each file, but
apart from the fact that tihs doesn't actually work in this case (we
still get the error), it's not really a very good idea.
Does anybody have any suggestions for working around this code:
namespace boost {
namespace io {
namespace detail {
namespace {
templateclass Tr, class Ch inline
void empty_buf(BOOST_IO_STD basic_ostringstreamCh,Tr os) {
static const std::basic_stringCh, Tr emptyStr;
os.str(emptyStr);
}
};};};};
The correct thing to do with this code (for all platforms) is to not
rely on the global variable common stuff (which is new to me, and
seems a bit of a hack), but actually do this code correctly, which
means removing the global variable.
What problem is the code above trying to solve?
If i just do this (which i have done to get my stuff working), there
seems to be no prob:
#ifdef MACHACK
templateclass Tr, class Ch inline
void empty_buf(BOOST_IO_STD basic_ostringstreamCh,Tr os) {
extern const std::basic_stringCh, Tr emptyStr;
os.str(emptyStr);
}
#else
#define empty_buf(_os_) (_os_).str();
#endif
Wouldn't the above two lines achieve basically the same thing (although
I know we hate macros, but since empty_buf is only actually used 3
times in the entire project, could all of the:
empty_buf(oss);
be replaced with:
oss.str();
This would save a whole lot of grief and eliminate this fairly ugly
global variable.
Comments?
-
Paul Hamilton
pHamtec P/L - Software Makers
http://www.phamtec.com/
mailto:[EMAIL PROTECTED]
The information transmitted is intended only for the person or entity
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this in error, please contact the sender and delete the
material from any computer.
-
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
how about span ? At Monday 2003-08-18 02:43, you wrote: Guillaume Melquiond [EMAIL PROTECTED] writes: | In the case of a 1-dimension space, connected and convex set are | equals: they are segments (or half-line or line or empty). Date | manipulated by the date-time library are in a 1-dimension space (the | real line) and periods are segments (non-empty bounded convex | sets). So when you have two periods, the smallest period enclosing | these two is also the convex hull of them. Hence the name I suggested. that is fine for some mathematically oriented mind. However, it is a terrible name. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Global vars
Paul Hamilton wrote:
Well,
I've tried to work through the solutions to:
ld: common symbols not allowed with MH_DYLIB output format
Which are basically -fno-common on the compile line of each file, but
apart from the fact that tihs doesn't actually work in this case (we
still get the error), it's not really a very good idea.
Does anybody have any suggestions for working around this code:
namespace boost {
namespace io {
namespace detail {
namespace {
templateclass Tr, class Ch inline
void empty_buf(BOOST_IO_STD basic_ostringstreamCh,Tr os) {
static const std::basic_stringCh, Tr emptyStr;
os.str(emptyStr);
}
};};};};
Did you try to remove the static const?
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Filesystem] Exact type of name checking function?
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
FWIW, Boost.Function is overkill for many simple cases. This might
be a case where the FS library should just provide a class with a
virtual function:
struct checker
{
virtual ~checker() {}
virtual bool operator()( std string const ) = 0;
shared_ptrchecker next; // suggested.
};
Boost.Function makes things simpler for the user.
enum check_type { check_posix, check_windows, ... };
bool my_name_checker(std::string const s, check_type t);
Compare
bind(my_name_checker, _1, check_posix)
against
snip
So I left out a few bits:
struct checker_impl_base
{
virtual ~checker() {}
virtual bool operator()( std string const ) const = 0;
};
template class F
struct checker_impl : checker_impl_base
{
checker_impl(F const f)
: m_f(f) {}
bool operator()( std string const s ) const
{
return m_f(s);
}
};
struct checker
{
template class F
checker(F const f)
: m_impl(new checker_implF(f))
{}
bool operator()( std string const s ) const
{
return (*m_impl)(s);
}
shared_ptrchecker_impl_base m_impl;
shared_ptrchecker_impl_base m_next; // suggested.
};
Still smaller (and probably a little more portable) than
Boost.Function.
It is still possible to substitute a homegrown functionbool(string) (or
functionbool(char const *)) equivalent for portability reasons, of
course.
I guess that's done now?
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [Filesystem] Exact type of name checking function?
David Abrahams wrote:
Peter Dimov [EMAIL PROTECTED] writes:
David Abrahams wrote:
FWIW, Boost.Function is overkill for many simple cases. This might
be a case where the FS library should just provide a class with a
virtual function:
struct checker
{
virtual ~checker() {}
virtual bool operator()( std string const ) = 0;
shared_ptrchecker next; // suggested.
};
Boost.Function makes things simpler for the user.
enum check_type { check_posix, check_windows, ... };
bool my_name_checker(std::string const s, check_type t);
Compare
bind(my_name_checker, _1, check_posix)
against
snip
So I left out a few bits snip
That's all very nice but one of the reasons, as I understand it, for
boost::function and boost::bind is so the end-user has the benefit of
defining his callback as he sees fit and not have it more rigidly dictated
by the implementation. That is the main reason I support such a callback for
boost::filesystem checking for pathname validity; it gives the end-user
maximum flexibility while letting the internals of boost::filesystem deal
with the result of the callback as it sees fit. Inevitably, somewhere down
the road, programmers will say that the callback system is too rigid for
their needs, no matter how simple is seems as if it should be now. With
boost::function such a complaint is very close to impossible. I am not
trying to create more work for the implementor, only suggesting that the
most flexible callback implementation done now will save possibly more work
in the future and be beneficial to end-users.
I am a bit surprised that Boosters themselves do not seem to want to support
one of their own key libraries. Maybe because I am used to the C++ extension
callback and event systems invented by Microsoft and Borland for their
frameworks, anything less or more restricted seems primitive to me. That is
why I am quite happy with the excellent work done on boost::function,
boost::bind, and boost::signals by their implementors.
The latter reminds me to ask, although off-subject for this thread, why
boost::signals wasn't submitted for TR1. The C++ standard library sorely
needs an event model and boost::signals is a good one with kudos to Mr.
Gregor.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: | how about span ? when read as the period of time spanned by these two, I can make sense of it, even not as a mathematician :-) Well, I don't know how it sounds to native speakers. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Release of 1.30.2 imminent
Fernando Cacciola wrote:
Recently, Jens Maurer changed the guard at function scope
from:
#ifndef __GNUC__
to
#ifndef BOOST_NO_STDC_NAMESPACE
and honestly, I didn't looked much at it as I should.
BOOST_NO_STDC_NAMESPACE is documented to relate to C names,
but swap is a C++ name so I don't think such macro
should be used here.
The CVS change of optional.hpp:1.10 is definitely incorrect,
because STDC_NAMESPACE refers to C names, not C++ names.
Sorry.
However, just reverting the patch will make gcc-3.3
non-functional, because std::swap(int,int) (for example)
is not going to be found.
I've checked in a better fix to the main branch. optional_test.cpp
now works with gcc 2.95, gcc 3.0 and gcc 3.3 on Linux.
Please test on other platforms and (optionally) transport
the fix to the 1.30.0 CVS branch.
Jens Maurer
RCS file: /cvsroot/boost/boost/boost/optional.hpp,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- optional.hpp14 Mar 2003 12:56:01 - 1.9
+++ optional.hpp9 Jul 2003 23:13:40 - 1.10
@@ -296,7 +296,8 @@
}
else if ( !!x !!y )
{
-#ifndef __GNUC__
+#ifndef BOOST_NO_STDC_NAMESPACE
+// allow for Koenig lookup
using std::swap ;
#endif
swap(*x,*y);
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
I suggested it because we write software for people who run multiple experiments with rest periods between the data collection sessions. They seem to use the word span to specify the approximate duration of the series of tests. These experiments were conducted over a span of 3 weeks. Then again, Americans are notorious for abuse of the language, but around University of Arizona's Neural Systems, Memory Aging Lab it would certainly be understood. At Monday 2003-08-18 11:39, you wrote: Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: | how about span ? when read as the period of time spanned by these two, I can make sense of it, even not as a mathematician :-) Well, I don't know how it sounds to native speakers. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
It also has the advantage of being similar to the use of makespan as the time from the start time of the first job to the completion time of the last job in job scheduling problems. On Monday, August 18, 2003, at 02:18 PM, Victor A. Wagner, Jr. wrote: I suggested it because we write software for people who run multiple experiments with rest periods between the data collection sessions. They seem to use the word span to specify the approximate duration of the series of tests. These experiments were conducted over a span of 3 weeks. Then again, Americans are notorious for abuse of the language, but around University of Arizona's Neural Systems, Memory Aging Lab it would certainly be understood. At Monday 2003-08-18 11:39, you wrote: Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: | how about span ? when read as the period of time spanned by these two, I can make sense of it, even not as a mathematician :-) Well, I don't know how it sounds to native speakers. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: There oughta be a law ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [Filesystem] Exact type of name checking function?
At 02:08 PM 8/18/2003, Edward Diener wrote: ... one of the reasons, as I understand it, for boost::function and boost::bind is so the end-user has the benefit of defining his callback as he sees fit and not have it more rigidly dictated by the implementation. That is the main reason I support such a callback for boost::filesystem checking for pathname validity; it gives the end-user maximum flexibility while letting the internals of boost::filesystem deal with the result of the callback as it sees fit. Inevitably, somewhere down the road, programmers will say that the callback system is too rigid for their needs, no matter how simple is seems as if it should be now. With boost::function such a complaint is very close to impossible. I am not trying to create more work for the implementor, only suggesting that the most flexible callback implementation done now will save possibly more work in the future and be beneficial to end-users. Edward, If we loaded Boost.Filesystem up with every feature which would be beneficial to some user at some future time, it would be full of caches, allocators, path translators, vast numbers of compound operations, file system virtualizers, generation dataset emulators, partitioned dataset emulators, and a lot of other stuff. Some, like wide-character path names, I'd dearly love to add. Everything on that list is useful, sometimes very useful. But if all those features were added, the library would almost certainly become so difficult to learn and use that it would no long meet its primary goal of being able to perform portable script-like [file and directory] operations from within C++ programs. Maybe enough real-world use cases will arise to make it worthwhile to add boost::function (or several other Boost libraries which might bring quite a lot to the table.) But it needs a stronger justification that just that it might benefit some users. Boost::function is also something that could be added later without breaking existing code, AFAICS. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::filesystem file restrictions
At 10:59 AM 8/18/2003, David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: Yes. Plus there are some other issues. The actual interface would include boost::filesystem::path constructors which take an additional argument to explicitly specify a name checker function. In working out use cases, it seems that temporary overrides of the default function are best handled via these constructors. That leaves only the case of wishing to permanently replace the default function, and the simpler approach you are talking about would be better for that. For safety, such a set_legal_name_policy() would use the write-once-before-read idiom to avoid a dangerous global variable. (I'm actually thinking of name_check for the type, and set_name_check for the function name.) I'm about to post a message asking for opinions on the details of the policy function pointer or object. This starts to align with what I've been thinking. Every path object could maintain a chain of checkers, and combinations of path objects (e.g. via operator/) would use the union of the checkers of their components, so that checking would never become less-restrictive silently. That is more machinery than is needed. It would be a nice design for a system that had to revisit elements, but for that isn't required here. When I was first working with designs for error checking, I tried a lot of similar schemes. Eventually I realized that treating name validity as an invariant established at construction was much simpler and performed quite well. It doesn't require keeping a chain of checkers. It performs the checking at the point in the calling program where knowledge of what is valid is present. Of course, though I think this goes against the grain of the library, I believe the default checker should always be the for the native platform. Because the native platform may support several different file systems within the same directory tree, it isn't possible to perform a full and correct lexical (inspection of the name only) check for the native platform. You in effect have to try the path and see if the operating system accepts it. What the lexical level name check done by class path is trying to do is early detection of gross naming errors. A specific example might help. Say you are working on a Linux platform. It supports a really wide range of characters in names. But you know the code sometimes will run on Windows, so you would like to check automatically that some directory tree you create doesn't violate Windows naming conventions. You do this by specifying a Windows name checker (which disallows a bunch of special characters). This will prevent your program from inadvertently using the special characters that Windows always disallows. Now when the program actually runs on a Windows box, a native path may be given (say by operator input) as the root, and then the relative portions your program adds get tacked on. If the operator supplied root happens to be a CD ISO-9660 file system, your carefully chosen relative names may fail, because the ISO-9660 names are way more restricted that general Windows names. In that case, the attempt at early detection was a failure; the name checker did no good. But a lot of real-world errors will be detected early, so I don't see the name checking as a failure. It just is a partial check, not an iron-clad guarantee. A useful axillary mechanism, but not the main show. But because it can't be an iron-clad guarantee, I'd prefer not to build an even mildly complex mechanism to support it. Particularly since some programmers will disable it anyhow. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
At 03:18 PM 8/18/2003, Victor A. Wagner, Jr. wrote: At Monday 2003-08-18 11:39, you wrote: Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: | how about span ? when read as the period of time spanned by these two, I can make sense of it, even not as a mathematician :-) Well, I don't know how it sounds to native speakers. FWIW, I'm both a native-speaker and familiar with convex hulls. Regardless, span sounds better to me for use in the context of a Date-Time library. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Date iterators in Boost Date-Time
Beman Dawes [EMAIL PROTECTED] writes: | At 03:18 PM 8/18/2003, Victor A. Wagner, Jr. wrote: | | At Monday 2003-08-18 11:39, you wrote: | Victor A. Wagner, Jr. [EMAIL PROTECTED] writes: | | | how about span ? | | when read as the period of time spanned by these two, I can make | sense of it, even not as a mathematician :-) | | Well, I don't know how it sounds to native speakers. | | FWIW, I'm both a native-speaker and familiar with convex | hulls. Regardless, span sounds better to me for use in the context | of a Date-Time library. Great! We're in violent agreement. -- Gaby ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Release of 1.30.2 imminent
Jens Maurer [EMAIL PROTECTED] escribió en el mensaje news:[EMAIL PROTECTED] Fernando Cacciola wrote: Recently, Jens Maurer changed the guard at function scope from: #ifndef __GNUC__ to #ifndef BOOST_NO_STDC_NAMESPACE and honestly, I didn't looked much at it as I should. BOOST_NO_STDC_NAMESPACE is documented to relate to C names, but swap is a C++ name so I don't think such macro should be used here. The CVS change of optional.hpp:1.10 is definitely incorrect, because STDC_NAMESPACE refers to C names, not C++ names. Sorry. However, just reverting the patch will make gcc-3.3 non-functional, because std::swap(int,int) (for example) is not going to be found. I've checked in a better fix to the main branch. optional_test.cpp now works with gcc 2.95, gcc 3.0 and gcc 3.3 on Linux. Please test on other platforms and (optionally) transport the fix to the 1.30.0 CVS branch. Jens Maurer Actually, I had fix it for RC_1_30_0 already. If the release goes OK, I think I should merge my fix back to the main trunk. Thanks anyway. Fernando Cacciola ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Beman Dawes [EMAIL PROTECTED] writes:
At 10:59 AM 8/18/2003, David Abrahams wrote:
Beman Dawes [EMAIL PROTECTED] writes:
Yes. Plus there are some other issues.
The actual interface would include boost::filesystem::path
constructors which take an additional argument to explicitly specify a
name checker function. In working out use cases, it seems that
temporary overrides of the default function are best handled via these
constructors. That leaves only the case of wishing to permanently
replace the default function, and the simpler approach you are talking
about would be better for that.
For safety, such a set_legal_name_policy() would use the
write-once-before-read idiom to avoid a dangerous global
variable. (I'm actually thinking of name_check for the type, and
set_name_check for the function name.)
I'm about to post a message asking for opinions on the details of the
policy function pointer or object.
This starts to align with what I've been thinking. Every path object
could maintain a chain of checkers, and combinations of path objects
(e.g. via operator/) would use the union of the checkers of their
components, so that checking would never become less-restrictive
silently.
That is more machinery than is needed. It would be a nice design for a
system that had to revisit elements, but for that isn't required here.
When I was first working with designs for error checking, I tried a
lot of similar schemes. Eventually I realized that treating name
validity as an invariant established at construction was much simpler
and performed quite well. It doesn't require keeping a chain of
checkers. It performs the checking at the point in the calling program
where knowledge of what is valid is present.
Sure. The question is:
path x('foo/bar', portable_check);
path y('baz', native_check);
path z = x/y; // Which checks are made?
path q = z/y; // which checks are made?
Of course, though I think this goes against the grain of
the library, I believe the default checker should always be the for
the native platform.
Because the native platform may support several different file systems
within the same directory tree, it isn't possible to perform a full
and correct lexical (inspection of the name only) check for the native
platform. You in effect have to try the path and see if the operating
system accepts it. What the lexical level name check done by class
path is trying to do is early detection of gross naming errors.
Sure; I just don't want to have to be explicit about anything just to
say I'm doing native path manipulation, since I believe that's the
90% case. I don't want to be stopped by irrelevant portable path
considerations nor uglify my code to avoid it.
A specific example might help. Say you are working on a Linux
platform. It supports a really wide range of characters in
names. But you know the code sometimes will run on Windows, so you
would like to check automatically that some directory tree you
create doesn't violate Windows naming conventions. You do this by
specifying a Windows name checker (which disallows a bunch of
special characters). This will prevent your program from
inadvertently using the special characters that Windows always
disallows.
Now when the program actually runs on a Windows box, a native path
may be given (say by operator input) as the root, and then the
relative portions your program adds get tacked on. If the operator
supplied root happens to be a CD ISO-9660 file system, your
carefully chosen relative names may fail, because the ISO-9660 names
are way more restricted that general Windows names.
In that case, the attempt at early detection was a failure; the name
checker did no good. But a lot of real-world errors will be detected
early, so I don't see the name checking as a failure. It just is a
partial check, not an iron-clad guarantee. A useful axillary
mechanism, but not the main show.
No argument.
But because it can't be an iron-clad guarantee, I'd prefer not to
build an even mildly complex mechanism to support it. Particularly
since some programmers will disable it anyhow.
You need to define sensible semantics for path combinators then.
Oh, and disabling is easy:
path z = path(x, no_check)/path(y, no_check);
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Insufficient significant digits using lexical_cast
Agreed - but what do we do if NOT is_iec559? Give up? #error Can only work with IEEE 754! Or choose a massive amount of decimal digits? eg 40? Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 mailto:[EMAIL PROTECTED] | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Daryle Walker | Sent: Monday, August 18, 2003 7:05 AM | To: Boost | Subject: [boost] Re: Insufficient significant digits using lexical_cast | | | On Sunday, August 17, 2003, at 10:33 PM, Paul A. Bristow wrote: | | [SNIP] | But you are right that it would be better to check that | numeric_limits::digits exists and isn't something silly before using | the formula. With all the built-in floating point types it should be | fine, and for other (well) User defined floating point types too. (I | will look at this). | [TRUNCATE] | | I think you need to check numeric_limits::radix since your algorithm | had a base-2-to-10 conversion (the type may not actually be binary!). | The algorithm was based off a paper about IEEE-754; if IEEE-754 is a | requirement, you may have to check for that too (via | numeric_limits::is_iec559). Remember that even the built-in | floating-point types aren't guaranteed to match IEEE-754! | | Daryle | | ___ | Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost | | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: boost::filesystem file restrictions
David Abrahams wrote: Sure; I just don't want to have to be explicit about anything just to say I'm doing native path manipulation, since I believe that's the 90% case. I don't want to be stopped by irrelevant portable path considerations nor uglify my code to avoid it. I agree except that IMO the 90+% case is I'm doing generic path manipulation which is portable path format (x/y, not x\y or x:y) but no constraints on charset except of course '/' and '\0'. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] garbled boostboc output in online docs
The Header section in the following pages is garbled. Looks like a bunch of missing newlines. http://www.boost.org/doc/html/any.reference.html http://www.boost.org/doc/html/function.reference.html -Jeremy -- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: [EMAIL PROTECTED] C++ Booster (http://www.boost.org) office phone: (812) 855-3608 -- ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Date iterators in Boost Date-Time
Thanks - it does now make sense, but since (mercifully!) time is only 1-dimensional, I find the span suggestion more intuitive. Paul PS This explanation could usefully be added to the interval library documentation. I was puzzled why the word 'hull' was used. | -Original Message- | From: [EMAIL PROTECTED] | [mailto:[EMAIL PROTECTED] Behalf Of Guillaume Melquiond | Sent: Monday, August 18, 2003 8:36 AM | To: Boost mailing list | Subject: RE: [boost] Re: Date iterators in Boost Date-Time | | | En réponse à Paul A. Bristow [EMAIL PROTECTED]: | | But as Michael Caine said Not a lot of people know that - so I trust | you will explain what it does too for the benefit of us mere | non-mathematical | mortals! | | Paul | | I'm not sure to understand. Do you want me to explain what a convex hull is or | to explain what the function of the date-time library is supposed to do? I | suppose it's the first, since the second is what started this subthread. | | A connected set is a set for which each couple of points are | connected by a path | itself included in the set (all the points are reachable from all the | points). A | convex set is a connected set with linear paths (all the points can be reached | from all the other points by following a segment). The convex hull of a set is | the smallest convex superset of it. For example, given three points in the | plane, the convex hull is the filled triangle defined by these points. | | In the case of a 1-dimension space, connected and convex set are equals: they | are segments (or half-line or line or empty). Date manipulated by the | date-time | library are in a 1-dimension space (the real line) and periods are segments | (non-empty bounded convex sets). So when you have two periods, the smallest | period enclosing these two is also the convex hull of them. Hence the name I | suggested. | | I hope it makes sense. | | Regards, | | Guillaume | ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: [Filesystem] Exact type of name checking function?
Beman Dawes wrote: At 02:08 PM 8/18/2003, Edward Diener wrote: ... one of the reasons, as I understand it, for boost::function and boost::bind is so the end-user has the benefit of defining his callback as he sees fit and not have it more rigidly dictated by the implementation. That is the main reason I support such a callback for boost::filesystem checking for pathname validity; it gives the end-user maximum flexibility while letting the internals of boost::filesystem deal with the result of the callback as it sees fit. Inevitably, somewhere down the road, programmers will say that the callback system is too rigid for their needs, no matter how simple is seems as if it should be now. With boost::function such a complaint is very close to impossible. I am not trying to create more work for the implementor, only suggesting that the most flexible callback implementation done now will save possibly more work in the future and be beneficial to end-users. Edward, If we loaded Boost.Filesystem up with every feature which would be beneficial to some user at some future time, it would be full of caches, allocators, path translators, vast numbers of compound operations, file system virtualizers, generation dataset emulators, partitioned dataset emulators, and a lot of other stuff. Some, like wide-character path names, I'd dearly love to add. Everything on that list is useful, sometimes very useful. You are confusing the use of choosing a callback method with adding a new feature. If you are already determined to add a callback method, as a new feature, to allow the end user to specify what is a valid filepath name, why not use the callback method which is already a part of the Boost libraries ? Of course you can choose a simpler, less flexible callback method if you like. But I truly don't see how that can be better from a design point of view than allowing the user to pass in a boost::function as his callback. I am not advocating using boost::function because its there. I'm advocating using it because it cleanly solves what you want to do: allow the user to pass a callback method to you to determine the valid filepath name. Nor do I understand the overhead involved. However you design boost::filesystem to use your callback, the callback pointer, if you will, will get passed into some functionality, you will store it away somewhere, and later when your functionality has to determine whether or not a filepath name is valid, you grab the pointer from wherever you have stored it and call the callback function for an answer. What is the difference whether the pointer is some variation of C++ function pointers or is a boost::function, which can encompass them all ? To your internal design it should be the same. But to the end user boost::function gives him the maximum flexibility of binding in whatever he likes. So where is the downside to using it over some more constrained method ? Surely secreting away a boost::function is just as easy as doing so for any specific type of callback pointer. And calling a callback function through boost::function is likewise. The only thing I can think of is that you don't want boost::filesystem to rely on this other implementation at all. Fine, if it isn't as portable as boost::filesystem is and using it will reduce your portability, I can understand that. But boost::function will almost certainly be in the next C++ standard, and C++ compilers are catching up to standard C++. So I expect that compilers in the near future will do so too. I used boost::function and boost::bind to provide event handling in my own library for VC6, one of the least compliant libraries around. So it is really hard to believe that any compiler that can't use boost::function and boost::bind, with all the excellent workarounds that the implementors of those created to get around compiler weaknesses, is worthy of being targeted by boost::filesystem. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Time representation in Boost Date-Time
The documentation notes that BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG controls the choice of the internal time representation, between the split (32 bit integer + 64 bit integer) and counted (64 bit integer only) varieties. The documentation also suggests that the split representation is the default. However, my impression is that out of the box you wind up with the counted representation, unless you manually define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG for yourself (which is not all that convenient). I note that the file posix_time_config.hpp contains the lines //Remove the following line if you want 64 bit millisecond resolution time //#define BOOST_GDTL_POSIX_TIME_STD_CONFIG which perhaps really should read //Remove the following line if you want 64 bit millisecond resolution time #define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG The Jamfile DOES define this variable for building libboost_date_time, but the apparent inconsistency doesn't matter since there are no time functions in the library anyway. Chris Trengove ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] garbled boostboc output in online docs
On Monday 18 August 2003 06:04 pm, Jeremy Siek wrote: The Header section in the following pages is garbled. Looks like a bunch of missing newlines. http://www.boost.org/doc/html/any.reference.html http://www.boost.org/doc/html/function.reference.html -Jeremy Where would you like to see the newlines? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::filesystem file restrictions
Peter Dimov [EMAIL PROTECTED] writes: David Abrahams wrote: Sure; I just don't want to have to be explicit about anything just to say I'm doing native path manipulation, since I believe that's the 90% case. I don't want to be stopped by irrelevant portable path considerations nor uglify my code to avoid it. I agree except that IMO the 90+% case is I'm doing generic path manipulation which is portable path format (x/y, not x\y or x:y) but no constraints on charset except of course '/' and '\0'. Works for me. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: garbled boostboc output in online docs
Subject: Re: garbled boostboc output in online docs ^ Pretty funny.-^ Jeremy Siek [EMAIL PROTECTED] writes: The Header section in the following pages is garbled. Looks like a bunch of missing newlines. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Period calculations in Boost Date-Time
I have some concerns about the implementation of the period concept, as
given in period.hpp. First of all, the documentation (for, say, date_period)
talks of the constructor
date_period(date begin,date last)
as creating a period as [begin,last). But really what is meant here is that
the last parameter is actually going to become the end of the period.
This is clear from the implementation in period.hpp, which is
templateclass point_rep, class duration_rep
inline
periodpoint_rep,duration_rep::period(point_rep begin, point_rep end) :
begin_(begin),
last_(end - duration_rep::unit())
{}
In the other words, the last_ member is initialised by backing up one unit
of time from the end.
I think there are two errors in the implementation of the period class,
perhaps caused by this confusion between last and end.
1) is_null() is implemented as
return last_ = begin;
which means that a period of length 1 is judged as being null. The correct
implementation should be
return end() = begin;
or
return last begin;
2) operator() is implemented as
return (last_ = rhs.begin_);
and this should be
return (end() = rhs.begin_);
or
return (last_ rhs.begin_);
Also, I think that the implementation would be simpler and more efficient if
_end was chosen as the data member, rather than _last. As presently
implemented, there are quite a few calls to end(), which involves
calculating
last_ + duration_rep::unit();
each time. I believe that if _end is chosen as the data member, then the
entire class can be implemented without any such calculations. The only one
would be in the implementation of last() itself, which would become
templateclass point_rep, class duration_rep
inline
point_rep periodpoint_rep,duration_rep::last() const
{
return end_ - duration_rep::unit();
}
Chris Trengove
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: garbled boostboc output in online docs
Guess that would be a curiously recurring email subject line ;) On Monday, August 18, 2003, at 08:15 PM, David Abrahams wrote: Subject: Re: garbled boostboc output in online docs ^ Pretty funny.-^ ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] garbled boostboc output in online docs
Hi Doug, Hmm, I just viewed it with a different browser (Apple's Safari instead of and old version of Netscape on a Sun) and now I see lots of newlines (there were none before). Is this a case of non-portability of a html tag, or a bug in Netscape? Cheers, Jeremy On Monday, August 18, 2003, at 07:28 PM, Douglas Gregor wrote: On Monday 18 August 2003 06:04 pm, Jeremy Siek wrote: The Header section in the following pages is garbled. Looks like a bunch of missing newlines. http://www.boost.org/doc/html/any.reference.html http://www.boost.org/doc/html/function.reference.html -Jeremy Where would you like to see the newlines? Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Global vars
Peter Dimov wrote: Did you try to remove the static const? Not sure if this would achieve the same effect as the code is trying to get done. I think it's a static const so that the the compiler will optimize it out and just init the string. Paul. - Paul Hamilton pHamtec P/L - Software Makers http://www.phamtec.com/ mailto:[EMAIL PROTECTED] The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. - ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
