Re: [boost] Re: plans for a bugfix release ?
David Abrahams wrote: Thanks for all the testing; the release looks pretty darned great! Just to make sure it's understood - although expected, all the green failures are still failures. Not that we can do much about them, of course. From a user POV, a darned great release would be the one for which http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/user_summary_page.html would reveal a clear green field, without any details links to check. http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_result_page.html Only one red box (intel-7.1-stlport lexical_cast)! ... which means a regression from 1.30.0 ;). To be fair, quite a few failures have been fixed (dark green cells) - http://www.meta-comm.com/engineering/resources/cvs_RC_1_30_0/developer_summary_page.html Still, it would be nice if we didn't release until _all_ regressions are fixed. Aleksey ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Mixing g++/aCC on HP-UX (was: Compiler support)
Beman Dawes wrote: At 10:04 AM 8/4/2003, David Abrahams wrote: Pascal Bleser [EMAIL PROTECTED] writes: aCC tells me that it's the same function... yuck... Agreed, it's a sick compiler You've hit the nail on the head. , but nevertheless... I will try once more using STLport, but it's not about the STL IMHO. My advice? Don't waste your time. Use GCC or some non-sick compiler for your platform, or, sadly, give up on Boost until HP gets their act together. Dave's 100% right, AFAIC. Well, if things were that simple, we would have used GCC 2.x/3.x on HP-UX as well. Unfortunately, we have to link against 3rd party C++ libraries (Tuxedo (CORBA), actually) that have been compiled with aCC (*gasp* even with the old roguewave STL - they don't even have the std namespace). This gets a little off-topic, but has anybody had any success linking together objects that have been compiled with g++ and aCC on HP-UX ? HP appears to be unresponsive, I'm afraid. It has gotten to the point where it is costing them long-time customers, but aCC still can't compile modern C++ code very well. A shame. The strange thing is that aCC isn't that bad for certain things. It has interesting warnings and good hints in its error messages. But then again, it's just some broken piece of crap when you use more advanced/modern C++ constructs, as in BOOST. -- -o) Pascal Bleser ATOS Origin/Aachen(DE) /\\ System Architect [EMAIL PROTECTED] _\_v Project Leader WLP Online Framework The more things change, the more they stay insane. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Filesystem: create_directories
Jeremy B. Maitin-Shepard wrote: On Mon, 04 Aug 2003 10:51:07 +0400 Vladimir Prus [EMAIL PROTECTED] wrote: [snip] Another option might be: create_directory_and_parents That name is longer than create_directories although it better describes the function. So, to summarize, I've no problem with the current name that I've introduced. Of other suggestions create_directory_and_parents looks best to me. ensure_directory_exists does not imply any operational semantic(i.e. the name does not say that the directory will be created. One might expect exception to be thrown if dir does not exist). demand_directory is good. One problem is that demand still does not communicate to me that something will be created. I suggested create_directory_and_parents because the current create_directories has exactly the semantics of calling create_directory incrementally on each parent directory path, then on the directory path itself. AFAICS this is not correct. create_directory will throw if the directory exists. IIUC create_directories will not. Thomas ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] time_duration bug in Boost 1.30.0
time_duration behaves highly nonintuitively. A time_duration should be
convertible to seconds by calculating td.hours() * 3600 + td.minutes() * 60
+ td.seconds(), right? Wrong!
This is the correct way to do it:
int seconds_from_time_duration(const boost::posix_time::time_duration td) {
const time_duration positive = td.is_negative() ? td.invert_sign() : td;
return (td.is_negative() ? -1 : 1)
* (positive.hours() * 3600
+ positive.minutes() * 60
+ positive.seconds()
);
}
I developed this function after being bitten by time_duration's nonintuitive
behavior. This entertaining story goes as follows:
On 2:56:15 July 21, 1969 (UTC), Neil Armstrong first set foot on the Moon.
On 0:00:00 January 1, 1970 (UTC), the Unix epoch began.
When represented as Boost times, Armstrong - Unix is a negative
time_duration.
I printed out the hours, minutes, and seconds fields of this time_duration
and got:
Hours: -3933
Minutes: 3
Seconds: 45
Adding -3933 hours to Unix gives 3:00:00 July 21, 1969. -3 minutes and -45
seconds must then be added to produce Armstrong time. But the time_duration
specifies that 3 minutes and 45 seconds should be added. Ooops.
In short, the .minutes() and .seconds() of a negative time_duration should
be negative, but are not. Since the negative sign is attached to the hours
only, the complicated above seconds_from_time_duration() function must be
used in order to avoid incorrectly converting time_durations to seconds.
I believe that there are two solutions to this bug:
1. Make all of time_duration's quantities unsigned and store whether the
time_duration is negative in a boolean. This cleanly separates storing the
direction of the time_duration from the magnitude. However, this is
undesirable because converting a time_duration to seconds would still
require (td.is_negative() ? -1 : 1) * (td.hours() * 3600 + td.minutes() * 60
+ td.seconds()). If the user forget the parentheses around the second
expression, then again the result would be correct except when the negative
time_duration has nonzero seconds or minutes.
2. If a negative time_duration is produced, all of its fields should be
negative or zero. This has the advantage of allowing easy conversion to
seconds: td.hours() * 3600 + td.minutes() * 60 + td.seconds(), which is what
a user will naturally want to write. Users may construct time_durations with
differently signed fields, but these will have well-defined meanings (just
as 1 hour 1 minute 61 seconds is equal to 1 hour 2 minutes 1 second, 1 hour
0 minutes -1 seconds is equal to 0 hours 59 minutes 59 seconds).
I believe that (2) is the correct solution and has no downsides.
Stephan T. Lavavej
http://stl.caltech.edu
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] C++ Builder 6 and Boost Generic Graph Library
awhile ago I tried to compile this simple program:
#includeboost/graph/adjacency_list.hpp
int main (){
return 0;
}
and Borland C++ Builder 6 refuse to compile.
I have track the problem and it seemed that Borland C++ builder has
problem with template partial specialization with constant. The program
below also refuse to compile
Yep, we even have a macro for it: BOOST_NO_CV_SPECIALIZATIONS, evidently
boost.graph doesn't use it.
John.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [Boost-bugs] [ boost-Bugs-783308 ] tss::set(0) leads to double-free
Bugs item #783308, was opened at 2003-08-04 22:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=107586aid=783308group_id=7586
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John V Sichi (perfecthash)
Assigned to: Nobody/Anonymous (nobody)
Summary: tss::set(0) leads to double-free
Initial Comment:
This bug only occurs on non-pthreads platforms such as
Win32 where no automatic destructor is available. I
declared a variable:
boost::thread_specific_ptrX pX;
and initialized it:
pX.reset(new X);
Later, I did
pX.reset();
Subsequently, when pX went out of scope, it tried to
delete the X instance again. It's easy to see why.
tss::set checks
if (value m_cleanup) {
update cleanup handler table
}
So if value is NULL, the original cleanup handler is
left lying around.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=107586aid=783308group_id=7586
---
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa0013ave/direct;at.aspnet_072303_01/01
___
Boost-bugs mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/boost-bugs
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Wrong version.hpp in Boost 1.30.1 download
version.hpp still claims to be version 1.30.0 -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Infinite number of parameters?
#include iostream
using namespace std;
namespace infinite
{
template typename T = void, typename U = void
struct typelist : U
{
typedef T type;
T value;
typelist(T const a, U const b) : value(a), U(b) {}
};
template
struct typelistvoid, void
{
typedef void type;
};
template typename T
struct typelistT, void
{
typedef T type;
T value;
typelist(T const a) : value(a) {}
};
typelist const begin = typelist();
}
template typename V
infinite::typelistV, void operator , (infinite::typelist const , V
const v)
{
return infinite::typelistV, void(v);
}
template typename T, typename U, typename V
infinite::typelist V, infinite::typelistT, U operator ,
(infinite::typelistT, U const t, V const v)
{
return infinite::typelist V, infinite::typelistT, U (v,
infinite::typelistT, U(t));
}
// Usage example:
template typename T, typename U
void foo(infinite::typelistT, U const i)
{
cout __PRETTY_FUNCTION__ endl;
}
int main()
{
foo((infinite::begin, true, (char *) adasd, 12367, 127.2));
}
I have not compiled it, but looks ok.
Anyway, why the two (( and )) ?
I think it's not needed.
Anyway, I'm not sure how much this generality can buy you.
I do like it, though :)
By the way, Andrei Alexandrescu had an article (about 4-5 years ago) about
inline containers. Look it up.
Best,
John
My 0,02$
Philippe
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
David Abrahams wrote:
Err, I don't get it. It seems to me that you only need the hack if
you're going to *specialize* swap. *Using* std::swap should work just
fine.
OK, that's because I was confused g
The following is really a minimal example, so I can be clearer this
time:
#include boost/shared_ptr.hpp
class empty
{
};
//#define DEMONSTRATE_BUG
# if defined( DEMONSTRATE_BUG )
namespace std
{
template
void swap( empty lhs, empty rhs )
{
}
}
# endif
int main(int argc, char* argv[])
{
boost::shared_ptrint pA( new int );
pA.reset();
return 0;
}
If we #define DEMONSTRATE_BUG the pA.reset() will cause:
[C++ Error] shared_ptr.hpp(286): E2285 Could not find a match for
'std::swap(int *,int *)'
Without the define, everything is fine.
This time it is clear that the swap specialization is nothing to do with
the shared_ptrs I want to swap. That was my misunderstanding. Creating
ANY specialization is going to trip up the borland parser.
The problem is that many boost libraries use std::swap. These are prone
to breaking the instant a user (or another of their library vendors)
makes the appropriate specialization.
The fix I am currently using looks like this in shared_ptr [line 284]
void swap(shared_ptrT other) // never throws
{
#if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x0564) )
_STL::swap(px, other.px);
#else
std::swap(px, other.px);
#endif
pn.swap(other.pn);
}
I am not submitting this as a diff yet as I am not sure this is the
'correct' patch yet, but I hope it gives the idea. A similar patch
needs to be applied everywhere in Boost std::swap is called, which could
be quite a bit of work. I am happy to go through all the libraries and
submit appropriate diffs, but first I would like agreement a patch is
appropriate, and the correct form.
The clear problems with my solution above are that
i/ the test is too wide (should be BCB = 0x0560, AND using STLport, as
well as TESTED_AT) If this is going to be applied in many places I
suggest a new defect macro in borland config.
ii/ forcing _STL::swap means the library will not see the std::swap
specializations. This is not so much a problem when swap is specialized
as an optimization, but will be more of a problem for types that are
swappable but not copyable.
iii/ any other problems that I have missed.
I have not hit problems with any other standard library templates, but
in theory this could apply to any standard algorithm prone to
specialization, such as std::less.
--
AlisdairM
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Proposed smart_handle library
John Torjo [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Indeed, but what about a wrapper for each time of handle, with a
conversion
operator()?
I have used it a couple of times.
Something like:
struct hbitmap_wrapper {
hbitmap_wrapper( HBITMAP h);
operator HBITMAP() { ... }
...
};
Then in code, instead of HBITMAP, use hbitmap_wrappers.
This approach is definitely sound, except that you need to write quite some
scaffolding (ctors etc. etc.) for each handle wrapped. With a policy you can
put the scaffolding in one place and then write only the stuff that varies.
In the particular case of handles, maybe there's not a ton to wrap there,
but if you want to be generic as the original poster suggested, you do need
to use parameterized types.
Ah, one more point that was discussed... there was much around operator-
and operator* which don't make sense for certain resources. With Loki's
SmartPtr, you can disable these two functions. Granted, the error message
would be different, such as get_reference not found as opposed to
operator* not found. Would this be a major issue?
Andrei
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
Alisdair Meredith [EMAIL PROTECTED] writes:
The fix I am currently using looks like this in shared_ptr [line 284]
void swap(shared_ptrT other) // never throws
{
#if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x0564) )
_STL::swap(px, other.px);
#else
std::swap(px, other.px);
#endif
pn.swap(other.pn);
}
I am not submitting this as a diff yet as I am not sure this is the
'correct' patch yet, but I hope it gives the idea. A similar patch
needs to be applied everywhere in Boost std::swap is called, which could
be quite a bit of work. I am happy to go through all the libraries and
submit appropriate diffs, but first I would like agreement a patch is
appropriate, and the correct form.
I'm trying to say that I think it's the wrong patch. The right patch
would put the swap specialization into _STL::.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Mutable typedefs - changing the type associated with an identifier
Hello all,
Recently, I had the following problem in some library code I maintain.
I provide users with a macro which generates fairly complex typedefs:
#define MAKE_TYPEDEF(Ident, etc) typedef complicated Identifier;
Users use the macro to define a bunch of different types, all with
identifiers of the user's choosing. Elsewhere, I need an mpl::list of the
types generated by the macro. Right now, users have to supply me with
this mpl::list. This opens the possibility for the list to get out of
sync with the MAKE_TYPEDEF()s if the user forgets to update the list when
adding a new MAKE_TYPEDEF() invocation.
I wanted to eliminate this possible source of bugs, by somehow
automatically generaring the mpl::list as a side effect of using the
MAKE_TYPEDEF macro. I want each macro invocation of MAKE_TYPEDEF to
mpl::push_front the type it declares onto the front of a typelist.
#define MAKE_TYPEDEF() ...\
typedef mpl::push_front previous_list, Ident::type new_list;
The problem is the naming of the identifiers previous_list and
new_list. Because of ODR, each invocation of MAKE_TYPEDEF needs to give a
unique identifier to new_list, and yet somehow figure out what name was
used for previous_list. The easy solution is to have the user provide
unique names and chain the list of MAKE_TYPEDEFs together. But, this is
just as error prone as having the user simply provide the mpl::list
directly.
I wanted a solution which is completely transparent to the user. Thus, I
cooked up the following, which I am calling mutable typedef.
The solution abuses the __LINE__ macro to generate unique identifier
names. A template specialization is created to mark the line number
used in the identifier. Then, when I wish to determine the name of
the identifier, a second template tests each line number going
upward from the current line until it finds the line number marked by the
specialization. Using this trick, I can create the effect of a
typedef which can be redefined, without violating ODR. Each use of the
typedef finds the nearest preceeding definition.
The code demostrating the trick appears below. The same trick can be used
to redefine integral constants as well, but I omit that code for brevity.
The main disadvantages of the approach are that it is not extremely robust
(doesn't work if line numbers change, i.e. when including files; or if
multiple mutable typedefs appear on one line), and that it requires a
large number of template instantiations if the nearest definition of the
mutable typedef is far away.
My questions for the Boost community are:
1) Is there an easier way to accomplish what is outlined in my use case
above, using preprocessor tricks or something similar?
2) Is there a way to enhance the mutable typedef trick to avoid the
large number of template instantiations?
3) Are there others interested in using this or seeing it submitted to
Boost?
Regards,
-Tom Wenisch
Computer Architecture Lab
Carnegie Mellon University
=== Example code begines here. Tested with gcc 3.3 ===
#include iostream
#include boost/preprocessor/cat.hpp
//Create the base templates for a line marker for Identifier and declare
//the struct used to search for the nearest previous occurence of the
//marker
#define DECLARE_LAST_LINE_MARKER(Identifier) \
template int N\
struct BOOST_PP_CAT(last_line_marker_,Identifier) \
: public BOOST_PP_CAT(last_line_marker_,Identifier)N-1 {}; \
template int StartAtLine \
struct BOOST_PP_CAT(find_last_line_,Identifier) \
: public BOOST_PP_CAT(last_line_marker_,Identifier) StartAtLine {} /**/
//Mark the current line
#define LAST_LINE_MARKER(Identifier) \
template struct BOOST_PP_CAT(last_line_marker_,Identifier)__LINE__ \
{ static const int value = __LINE__; } /**/
//Find the line number where the mark was last set
#define FIND_LAST_LINE_MARKER(Identifier) \
BOOST_PP_CAT(find_last_line_,Identifier)__LINE__ - 1::value /**/
//Declare the base template for a mutable typedef.
#define DECLARE_MUTABLE_TYPEDEF(Identifier) \
template int UniqueId\
struct BOOST_PP_CAT(mutable_typedef_,Identifier); \
DECLARE_LAST_LINE_MARKER(Identifier) /**/
//Set the type of mutable typedef Identifier to Type.
#define SET_MUTABLE_TYPEDEF(Identifier, Type) \
template \
struct BOOST_PP_CAT(mutable_typedef_,Identifier)__LINE__ \
{ typedef Type type; }; \
LAST_LINE_MARKER(Identifier) /**/
//Returns the type of the mutable typedef. Can be used anywhere a
Re: [boost] Re: Re: Re: Re: the boost::signal sample crashes
--- Bohdan [EMAIL PROTECTED] wrote: Because : 1. traits causes more complicated and more error prone interface. In this case errors can be caused by two incompatible thread mechanicms used in one application. BTW, have you any idea how two diffrent thread models will collaborate in one application ? And why you may want this mess ? They won't collaborate, you'll get a compile-time error, if you try. I don't think anybody requested a collaboration. 2. A lot of implementation code will be placed in headers, which damages compile perfomance VERY MUCH ... I hope you have already agreed to this point. Do you ? Have you looked at my solution? It doesn't have compile performance problems for users. 3. I haven't seen compiled application, which is working with TWO OSes or threading models at the same time. Do you ? Single/multi treaded is property of whole application, but not of it's part. Current boost::thread design is just reflection for this statement. Win32 already has two threading models that can be used in one app at the same time. They have put them there for a reason. I have seen applications that are using the both threading models. Sorry but it doesn't seem that you are making any effort at all to try to understand what I am proposing. Have you seen my proposal? Does it have any technical/peformance problems? Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: swappable user defined types and STLport libraries
David Abrahams [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Alisdair Meredith [EMAIL PROTECTED] writes:
The fix I am currently using looks like this in shared_ptr [line 284]
void swap(shared_ptrT other) // never throws
{
#if BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x0564) )
_STL::swap(px, other.px);
#else
std::swap(px, other.px);
#endif
pn.swap(other.pn);
}
I am not submitting this as a diff yet as I am not sure this is the
'correct' patch yet, but I hope it gives the idea. A similar patch
needs to be applied everywhere in Boost std::swap is called, which could
be quite a bit of work. I am happy to go through all the libraries and
submit appropriate diffs, but first I would like agreement a patch is
appropriate, and the correct form.
I'm trying to say that I think it's the wrong patch. The right patch
would put the swap specialization into _STL::.
It actually sufixes to put any 'std' extension in a nested namespace (say, stdx); then
injecting
the names in 'std'.
Fernando Cacciola
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] swappable user defined types and STLport libraries
At 09:58 PM 8/4/2003, Alisdair Meredith wrote: There is a problem with the Borland BCB6 compiler... What is the status of the Borland compiler as far as fixes and updates go? Have they announced any plans? --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Infinite number of parameters?
John Torjo wrote: [...] I have not compiled it, but looks ok. Anyway, why the two (( and )) ? Needed to generate one parameter only (typelist), otherwise foo() will need to be declared indefinitely. I think it's not needed. Maybe future compilers will create implicit typelists for foo(...) declarations. I guess this is where everything tends to. Anyway, I'm not sure how much this generality can buy you. I do like it, though :) By the way, Andrei Alexandrescu had an article (about 4-5 years ago) about inline containers. Look it up. Thanks, I'll look it up. Philippe ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Infinite number of parameters?
Brock Peabody [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That's a cool idea. It's a lot prettier than using the preprocessor. Does anyone know whether or not a language solution is being considered for this or variable class template arguments? They are considering a language solution. See this link: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2003/n1483.pdf Joe Gottman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
