[boost] Re: Boost.Regex compilation errors with BCB5
Marco Oman [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Mon, 25 Aug 2003 14:31:07 +1000, Chris Trengove [EMAIL PROTECTED] wrote: I had once a problem like the one described and was due to the operator|() being overloaded for an enum type. (compiler: BCB 5.5.1) Marco, Thanks for the tip. I think this is indeed the problem here. Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Regex compilation errors with BCB5
John Maddock [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] which doesn't look good at all... Oh and the problem is present in Builder 6 as well. As suggested by Marco Oman, the problem appears to be caused by overloading the various operators for the enum type, which happens in match_flags.hpp (lines 79 to 92). If these are removed for the Borland compiler, then the conflict goes away, at the cost of a bunch of Assigning int to ... warnings. Presumably, that is the main purpose of these overloads in any case (to suppress such warnings), so it might be just as well to use a pragma for this in the Borland case - assuming, of course, that the generated code is the same. Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Regex compilation errors with BCB5
John Maddock [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I can reproduce this with just:
#include vcl.h
#include locale
No boost code necessary :-(
Even worse this reproduces the error as well:
#include vcl.h
#pragma hdrstop
enum enum_t
{
one = 1,
two = 2
};
int test()
{
int a = one | two; // error
int b = one + two; // error
int c = (int)one (int)two; // OK
return a b; // OK
}
which doesn't look good at all...
Oh and the problem is present in Builder 6 as well.
No, it doesn't look good at all, but when I try the above two tests, the
compiler behaves for me (both Builder 5 and 6). I can even have
enum enum_t {
one = 1,
two = 2,
three = one | two
};
and I don't get an error. Are you using any particular compiler setting?. (I
am just creating a new Console Project in the IDE and then pasting in the
code.) Maybe there is more to this?
Chris
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Boost.Regex compilation errors with BCB5
John Maddock [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Make sure that the console app has Project uses the VCL checked when you create it. Haven't tried without it... I'm using the 5.6.4 compiler BTW. Yes, I am certainly doing this, and am also using 5.6.4 (and 5.5.1). Maybe you could email me your BPR and CPP files, and I can compare and see what is different. Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Time representation in Boost Date-Time
Jeff Garland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Ok, but you couldn't you just use date here? Well, the objects I'm dealing with CAN have time-of-day information, but mostly they do not, and this is not known until run-time. So, for the sake of a common interface, I want to use time, but simply ignore the time-of-day part when it is not needed. Interesting, you are correct it does not work. The fact is that the time interface is incorrect because like date, ptime should allow special value construction and queries directly. That's been on the todo list for awhile now to handle this right, but the fact that this doesn't even work is not good. Yes the special date values don't appear to be regarded as special when used with the counted representation. They just get combined into the single counted value, and their special-ness is lost. Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Time representation in Boost Date-Time
Jeff Garland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Yes at the moment there is really no effect because the library doesn't contain any time functions. It may not stay this way. And I agree that the polarity of this seems reversed. For my purposes, the split representation is the one I want, since I am doing a lot of conversions to and from simple dates (so that very often the time_of_day part is zero). Hence the split representation is more efficient. Also, you can use the special date observations (infinities, etc.) with the split representation, but not (I think) with the counted representation. Chris ___ 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
[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
[boost] Re: Re: Date iterators in Boost Date-Time
Jeff Garland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Sure, can do. What would you call it: merge_inclusive, earliest_latest, rename merge to union and call it merge, something else? Yes, the hardest thing is to think of a name. I don't think you can rename merge to union, since I suspect you chose merge originally because union is a keyword. In strict set terms, the proposed new function really is the union, whereas the existing merge is something else, a sort of conditional union. Maybe you can leave merge as is, and call the new thing simple_union, or union_with, to get around the keyword problem. I think I favour simple_union. Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Date iterators in Boost Date-Time
Jeff Garland [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I don't think the it is technically a union because the result draws in points in the time period that aren't part of either of the initial periods. Anyway I wrote the code as merge_inclusive so unless you have a major objection I'll leave it that way pending a better idea... Yes, of course, it is not really a union either. I think merge_inclusive is fine. Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Date iterators in Boost Date-Time
The date iterators in Boost Date-Time appear to be designed to support iteration forward in time, being modelled on the STL InputIterator. However, at times it is convenient to iterate backwards in time, and the temptation is just to use something like day_iterator ditr(date,-1); ++ditr; that is; specify a negative offset as the optional construction parameter which all four of the iterators provide. This works for all of the provided iterators except the month_iterator, and it wouldn't be too difficult to make that one work as well (by providing a subtract() method for the wrapping_int2 template used in the implementation). Are there any other issues involved in providing this support for backwards iteration? Chris Trengove ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Re: Boost.Python and BCC
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is this what you meant by not being able to use template syntax with member function pointers? Yes, this is the infamous BCC emoticon bug. The parser accepts a number of characters (in addition to ) as valid in terminating a template. An example, borrowed from Chris Uzdavinis, is that BCC will happily accept the following! vector vector vector int }:) x; Because member function pointers include an ), they are always treated as terminating any template, and so they don't compile. To my mind, this is a rather amazing bug to have been lying around so long, since you wouldn't think it would be too difficult to fix this elementary parsing error. I'm willing to jump through one or two hoops to get Borland support. In this case, the extra PP generation should be a special case for Borland, and all member_function_cast invocations should be wrapped up in a macro like BOOST_PYTHON_MEMBER_FUNCTION_CAST(target, f) which hides the horribility from users. How does that sound? That sounds OK, and I will work in that direction, but I should point out that I have yet to get any decent examples to compile. Hopefully, now that I have a solution to this problem, I will be that much closer, but one never knows. The other thing which is always in the back of my mind is the potential for the future release of Borland C++Builder 7 (whenever that is) to make a lot of these hacks unnecessary (both for Boost.Python and for other Boost libraries). Borland have announced that they are completely re-architecting their compiler for this release. Chris Trengove ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost.Python and BCC
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] You can get an idea of the intended semantics of this dance by looking at libs/python/test/member_function_cast.cpp. The idea is that if f is a member function, and its class is a base class of Target, it will be implicitly converted to a pointer-to-member of Target. Otherwise it will be left alone. We are going to drop support for CodeWarrior 7 in the next version of Boost.Python anyway, so you could reimplement those semantics with a much more straightforward interface that works with BCC. I think you should be able to make member_function_castTarget(f) work Thanks. It certainly helps to have a clearer understanding of what is going on here. I'll see if I can come up with a simpler BCC-specific approach. Chris ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Boost.Python and BCC
A question for David Abrahams (or anyone else who might have a bright idea).
I have resolved quite a few of the issues involved in porting Boost.Python
to Borland, but here is one particularly nasty problem. In
member_function_cast.hpp you have code, which after expansion at the hands
of Boost.Preprocessor, gives
template class T
struct member_function cast
{
template class S,class R
static cast_helperS, R (T::*) () stage1(R (S::*)())
{
return cast_helperS, R (T::*)()();
}
// Many more definitions of stage1() with increasing numbers of
parameters (arity).
};
Unfortunately, this runs foul of the infamous BCC emoticon bug, whereby
the ) character (and various others) will terminate the template argument
list. In the above, the compiler therefore sees cast_helperS,R
(T::*[end_of_template]. I assume that it is this bug which mandates the
special treatment for BCC in
boost/type_traits/is_member_function_pointer.hpp.
The standard workaround is to use a typedef, which in this case would be
typedef R (T::*T_mfp)();
static cast_helperS,T_mfp stage1(...)
But of course here we will need separate typedefs for each of the arities
of stage1(), and we need to define them so that they are available to the
stage1 template. It seems to me that the function overloading approach being
used here then becomes infeasible.
Any ideas?
Chris
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Re: Another borland (mis)feature detection macro
David Abrahams [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Please let me know as you find patches; I'd be very happy to see Borland supported (but, I'm afraid, reluctant to invest the effort myself). I've got fixes for most (but not all) of the issues involved in building the library. The next step is to try and build a couple of tests since (a) a lot of the code is only relevant for library usage, rather than library building, and (b) it would be good to see if any of this stuff actually runs! It's probably not worth polluting your code just yet with the Borland stuff, at least until I can get this much going. I'll keep you posted. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Another borland (mis)feature detection macro
Alisdair Meredith [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Several of the boost libraries select functionality based on the result
of some compile-time test. The result is usually stored in a
BOOST_STATIC_CONST( bool, test::value );
The current Borland compiler does not allow these values to be used as
template parameters though.
Are you referring to the compiler message
E2231 Member ... cannot be used without an object ?
For example, this is produced whenever you have something like
template class T
struct Y {
static const bool value = ...// some test here.
typedef Xvalue::type type;// X is some other template
};
I think you can get rid of the compilation error just be qualifying the use
of value. For example,
typedef XY::value::type type;
I have recently been attempting to port Boost.Python to BCC and have come
across lots of examples of this. The compilation errors all go away when the
static member is expilcitly qualified.
I also note that random/uniform_int.hpp and random/uniform_smallint.hpp have
just been patched to get around this problem, but just explictly qualifying
the member also fixes the compilation errors.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
