[boost] using date-time library
Hi, I am trying to use the date-time library of boost. However, I come into a lot of linking problems. In boost_1_29_0/libs/date_time/test, gcc testgregorian_calendar.cpp -I/home/tony/work/boost_1_29_0/ -lstdc++ It gives many linking problems, such as, /tmp/ccMBFqqI.o: In function `main': /tmp/ccMBFqqI.o(.text+0x154): undefined reference to `boost::date_time::gregorian_calendar_baseboost::date_time::year_month_day_baseunsigned long, unsigned short, unsigned short, unsigned long::day_of_week(boost::date_time::year_month_day_baseunsigned long, unsigned short, unsigned short const)' /tmp/ccMBFqqI.o(.text+0x23a): undefined reference to `boost::date_time::gregorian_calendar_baseboost::date_time::year_month_day_baseunsigned long, unsigned short, unsigned short, unsigned long::day_of_week(boost::date_time::year_month_day_baseunsigned long, unsigned short, unsigned short const)' I have tested with both gcc3.02 and gcc2.96 under Red Hat 7.2 Did I do anything wrong? Thank you. Tony ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
Darren Cook wrote: I wanted something like the call stack that shows in python or java when an uncaught exception occurs; if you're also suggesting a snapshot of local vars/parameters then I'll be in heaven and may never need to fire up a debugger again :-). This is exactly NOT what I am interested in though!! For me this is a function of debugger/tools. I specifically want to build up context for a human-readable message to explain why some process failed to the user of the software. The difference is error-handling as opposed to bug-tracking, and it could be there are two libraries (maybe relying on a common subset of behaviour) lurking here. I'm not sure which of these two problems Trevor was proposing to address, but think it is important such a distinction is made early. -- AlisdairM Team Thai Kingdom ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Boost version 1.30.0 released - date_time changehistory
While we're on the subject of broken links, the link to date_time change history doesn't work from the boost home page http://www.boost.org/libs/date_time/doc/Changes.html Really sorry about this. I have checked it in and attached it for those that want to patch 1.30. Just add the attached into libs/date_time/doc. JeffTitle: Boost Date-Time Library Documentation Boost Date-Time Change History Overall Index Changes from Boost 1.29 to 1.30 (date_time 1.00 to 1.01) Notice: The interface to the partial_date class (see date_algorithms) was changed. The order of construction parameters was changed which will cause some code to fail execution. This change was made to facilitate more generic local time adjustment code. Thus instead of specifying partial_date pd(Dec,25) the code needs to be changed to partial_date pd(25, Dec); TypeDescription Feature Added new experimental feature for Daylight Savings Time calculations. This allows traits based specification of dst rules. Feature Added new interfaces to calculate julian day and modified julian day to the gregorian date class. See boost::gregorian::date. Feature Add new interface to calculate iso 8601 week number for a date. See boost::gregorian::date. Feature Add an iso 8601 time date-time format (eg: MMDDTHHHMMSS) parsing function. See Class ptime for more information. Feature Added a length function to the period template so that both date_periods and time_periods will now support this function. Bug Fix Split Jamfiles so that libs/date_time/build/Jamfile only builds library and /libs/date_time/libs/test/Jamfile which runs tests. Bug Fix Fixed many minor documentation issues. Bug Fix Removed the DATE_TIME_INLINE macro which was causing link errors. This macro is no longer needed in projects using the library. Bug Fix Added missing typedef for year_iterator to gregorian_types.hpp Bug Fix Fixed problem with gregorian ostream operators that prevented the use of wide streams. Bug Fix Tighten error handling for dates so that date(2002, 2, 29) will throw a bad_day_of_month exception. Previously the date would be incorrectly constructed. Reported by sourceforge bug: 628054 among others. Last modified: Sun Feb 9 10:41:53 MST 2003 by Jeff Garland 2000-2002 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Safety of shared_ptr
Hello
I have now added the following custom cast operator into my copy of
shared_ptr class:
#ifdef DARK_FORCE
operator shared_ptrconst T()
{
return reinterpret_castshared_ptrconst T (*this);
}
#endif // DARK_FORCE
and hence the following code compiles easily:
void Foo(boost::shared_ptrconst myClass vp_Param)
{
}
boost::shared_ptrmyClass vl_MyTest_ptr(new myClass());
Foo(vl_MyTest_ptr);
In theory I believe that the compiler should be able to perform the cast
from shared_ptrmyClass to shared_ptrconst myClass of it's accord as
easily as it should handle cast 'myClass*' to 'myClass const *'.
Any comments?
Apart from the fact that in theory this makes for undefined behaviour, I
suspect that since all shared_ptr code is in headers and the only
difference between the classes is the 'const', there is actually no
practical difference between them and hence it is safe.
Only possibility to worry about I think could be the multithreaded
support.
Can anyone device a code that would fail with such DARK_FORCE operator?
Martin
-Original Message-
From: Raoul Gough [mailto:[EMAIL PROTECTED]
Sent: 19 March 2003 10:43
To: [EMAIL PROTECTED]
Subject: [boost] Re: Safety of shared_ptr
Martin Bosticky [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi
Me and my colleagues have come across an issue when using a
shared_ptr.
void myFunction(shared_ptrmyClass const vp_Pointer)
{
vp_Pointer-call any non-const function
}
i.e. a const shared_ptr doesn't prevent anyone from changing the
contents to which the pointer points. This makes sense as it behaves
like a normal pointer.
That's the idea.
However, how can I pass a shared pointer into a function such that
the
data can not be modified? i.e. how can I pass an equivalent of
myClass
const * ?
I tried static casting to shared_ptrconst myClass which works but
causes a new constructor to be called which means I loose the
efficiency
of passing by reference.
This would be the right way to do it.
Any comments of suggestions would be greatly appreciated.
If you really have a performance problem here (so you're probably
counting processor cycles) you can always try reinterpret_cast :-)
shared_ptrmyClass ptr (new myClass);
my_function (reinterpret_castshared_ptrmyClass const (ptr));
Of course, this uses undefined behaviour, but it is reasonable to
assume that the const/non-const representations are actually
identical. I wouldn't do it myself, but then I don't have to count
processor cycles, either.
--
Raoul Gough
see http://home.clara.net/raoulgough/ for my work availability
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] using date-time library
gcc testgregorian_calendar.cpp -I/home/tony/work/boost_1_29_0/ -lstdc++ It gives many linking problems, such as, /tmp/ccMBFqqI.o: In function `main': /tmp/ccMBFqqI.o(.text+0x154): undefined reference to `boost::date_time::gregorian_calendar_baseboost::date_time::year_month_day_baseunsigned long, unsigned short, unsigned short, unsigned long::day_of_week(boost::date_time::year_month_day_baseunsigned long, unsigned short, unsigned short const)' /tmp/ccMBFqqI.o(.text+0x23a): undefined reference to `boost::date_time::gregorian_calendar_baseboost::date_time::year_month_day_baseunsigned long, unsigned short, unsigned short, unsigned long::day_of_week(boost::date_time::year_month_day_baseunsigned long, unsigned short, unsigned short const)' I have tested with both gcc3.02 and gcc2.96 under Red Hat 7.2 Did I do anything wrong? Thank you. Yes, with 1.29 you will need to link in libboost_date_time.a and make sure the DATE_TIME_INLINE is defined. There is some description in the docs about this. If you upgrade to 1.30 you can drop the DATE_TIME_INLINE defines. Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Boost version 1.30.0 released - date_time changehistory
Jeff Garland [EMAIL PROTECTED] writes: While we're on the subject of broken links, the link to date_time change history doesn't work from the boost home page http://www.boost.org/libs/date_time/doc/Changes.html Really sorry about this. I have checked it in and attached it for those that want to patch 1.30. Just add the attached into libs/date_time/doc. I just patched the website. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: using date-time library
Tony Cheung wrote: I am trying to use the date-time library of boost. However, I come into a lot of linking problems. I experienced similar things too when attempting to use it. Did I do anything wrong? Thank you. In order to get it to work I included a file that contained the following: #include boost/date_time/posix_time/posix_time.hpp #include boost/date_time/gregorian_calendar.ipp #include libs/date_time/src/gregorian/greg_month.cpp #include libs/date_time/src/gregorian/greg_weekday.cpp I have removed the Microsoft-specific pragma declerations I was using to remove the warnings that were generated by compiling the library with VC7. -rhd- _ Overloaded with spam? With MSN 8, you can filter it out http://join.msn.com/?page=features/junkmailpgmarket=en-gbXAPID=32DI=1059 ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] call_traitsint::value_type
-Original Message- From: Eric Niebler [mailto:[EMAIL PROTECTED] The way call_traits is currently implemented, call_traitsint::value_type is an int, not an int. This is the correct behavior. If you are storing an int and want to return it by value, you will return an int . Also, it runs contrary to standard practice. In several places in the standard library value_type is assumed to be a value, not a reference. For instance, std::stack is defined as : Standard containers place additional restrictions on their value_types, such as Assignable, which references do not satisfy. A value_type is not a concept, per se. Is this an oversight in call_traits? Look at the Examples table in the call_traits documentation. If this is not the behavior you want, use call_traitsint (or, generically, call_traitsremove_referenceT::type). Or just an unfortunately named typedef? call_traits was originally designed to help the implementation of compressed_pair. So the name value_type was used because it was the natural name for the type of the members within compressed_pair. i.e., if you wanted to declare a variable that could hold the requested value, it would be of type value_type. The value_type member since then has become commonly used as a return type for those types of values. I agree, it is an unfortunately named typedef. -Steve ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.0 - problem with filesystem lib
Russell Hind wrote: I had the same problem with C++Builder 6 when first using the filesystem library. The default builds for filesystem are single threaded. If your application is multi-threaded, then you need to re-build the filesystem library with multi-threading (it uses mutexes somewhere (I think from smart_ptr but can't remember)). That is certainly a poor default choice for the borland compiler. The 'typical' borland user will be using the shipped VCL class library, and this is requires MT builds. Single-threaded is an exceptional condition, rather than the norm, on this platform. If MT builds are not to be global defaults, could we at least patch the jam files to use multithreading on Borland? -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] call_traitsint::value_type
[EMAIL PROTECTED] writes: From: Eric Niebler [mailto:[EMAIL PROTECTED] Is this an oversight in call_traits? Look at the Examples table in the call_traits documentation. If this is not the behavior you want, use call_traitsint (or, generically, call_traitsremove_referenceT::type). Or just an unfortunately named typedef? call_traits was originally designed to help the implementation of compressed_pair. So the name value_type was used because it was the natural name for the type of the members within compressed_pair. i.e., if you wanted to declare a variable that could hold the requested value, it would be of type value_type. The value_type member since then has become commonly used as a return type for those types of values. I agree, it is an unfortunately named typedef. The whole traits blob anti-pattern design of call_traits is unfortunate, IMO. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Bidirectional map preliminary submission
First of all, congratulations to all for the new 1.30.0 baby.
I've boostified my bimap library so that it can be more easily
reviewed. Now bimap lives into namespace boost and some
metastuff have been removed in favor of utilities already
provided by Boost itself.
The bimap.hpp header has been uploaded to the Files Section,
under the folder bimap. A sample test is provided as well as
a draft of the documentation, coming from the one I wrote for
CodeProject.
All suggestions and comments are most welcome. I feel that
in its present form boost has no severe barriers to be accepted,
but I'm sure there's lots of room for improvement. In preparation
for critiques, I've compiled a list of several hot topics that may arise
during the prelminary review:
1. Syntax and semantics
Since bimap follows as closely as possible the interface of std::map,
there's little IMHO to add or remove from here. The added constraint
of bidirectionality imposes some behavior that diverges from regular
maps, though. I don't think there's an alternate way to handle the
following
issues:
* operator[], when used for inspection on a non-existent value, throws
bimap_base::value_not_found. std::maps, on the other hand, automatically
insert a default value. This I cannot do in bimap, since it would
violate
the bidirectionality.
* bimap_base::duplicate_value is thrown whenever an assignment is
attempted to a value already present in the bimap: this again stems from
the preservation of the bidirectionality invariant.
2. Pollution of namespace boost.
Apart from bimap, the following types and functions are already defined
inside boost namespace:
* direct_pair
* inv_pair
* make_inv_pair
* bimap_base
* prebimap
* bimap_equal_types
* bimap_different_types
* prebimap_identity
Apart from bimap_base and possibly make_inv_pair, I'd like to have all
of these
defined in an auxiliary namespace, but MSVC++, which is my work
compiler,
chokes at one point or another when tyring to do so.
3. Nonconformances
To the best of my knowledge, there are two non-conformances in the code:
* It is assumed that for these two classes (in simplified form here):
templatetypename A,typename B
struct direct_pair
{
A first;
B second;
};
templatetypename C,typename D
struct inv_pair
{
D second;
C first;
};
it is asummed, I was saying, than a direct_pairA,B can be
reinterpret_cast'ed
to a inv_pairC,D (and vice versa) whenever A=D and B=C. I cannot
imagine
how on earth this couldn't be so for any conceivable compiler, but I'm
afraid a
strict interpretation of the standard does not guarantee this.
* offsetof() is used for non-POD types. The types on which it is used
are
arguably simple enough to be treated as POD (no virtual methods or
anything), but
then again the standard bans it. G++ complains at this, an ugly
workaround has
been applied for this case.
I'd like to know whether these two points could prevent bimap from
entering
Boost, or, in the contrary, they can be tolerated. Standard workarounds
are most
welcome, of course.
3. Compiler support
The version submitted works for MSVC++6.0sp5 and GNU CC 3.2 (cygwin).
Non-boost bimap also worked for the follwing:
* VC++ 7.0 (aka .NET)
* GNU GCC 3.0, 3.0.2, 3.0.4 (Linux 2.4.18, SunOS 5.8)
* GNU GCC 3.1 (Linux 2.4.18, SunOS 5.8)
* GNU GCC 3.2 (Cygwin 1.3.18-1, Linux 2.4.18, SunOS 5.8), 3.2.1 (Linux
2.4.18,
SunOS 5.8)
* Metrowerks CodeWarrior 8.3 (Mac OS 9.2.2, Mac OS X 10.2.3)
As only minor changes have been made, I guess all of these will still
merrily
compile the thing. Strictly speaking, though, I haven't tested it.
4. Compiler workarounds
There's non-surprising worarounds to cope with several well known
defficiencies
of MSVC++. For GNU CC, the illegal use of offsetof has been masked with
a dubious workaround; more interestingly, there's a compiler bug with
respect
to a constructs I call memberspaces (see
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-traildatabase=gccpr=9159
for details). This has been fixed in a satisfactory manner (IMHO).
Finally,
CodeWarrior seems to have a hard time with some dependent typenames, the
patches applied might deserve some thinking over.
Regards,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] RPMS?
Is anyone working on RPMS for 1.30.0? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] spirit documentation bug
Dave Gomboc wrote: Section Portability 8. Intel 7.0VisualAge C++ 5.02 should be split into two lines. Thanks for the various doc-bug reports. Duly noted. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
Greg Colvin wrote: std::exception used to have a why() member that returned the list of exceptions leading to the one caught. Is that part of what you want? Not exactly. I'm not too bothered about the history of the exceptions, I'm simply concerned with formatting useful error messages for users. In order to describe an error usefully/accurately you need as much context as possible, so such messages are most usefully described/formatted as the exception propogates. If you defer all message-formatting until some outer catch block you need to also leak sufficient implementation detail and knowledge to form that message. In the ideal library, such context information is only accumulated during exception propogation, and would not interfere with the exception handling system at all (no catch blocks, some sort of RAII/ScopeGuard-like object) To that extent, all that is really needed is a known stringstream per thread of execution, and some way to defer diagnostic generation unless an exiting the block due to exception propogation. To an extent, rather than missing why() I am looking for a replacement for what() as well!! Among other things I hear that can cause problems for localising error messages (something else this scheme should address) although I am lucky enough not to have to deal with such problems myself. -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost 1.30 - Thread lib workspace
Hi all, I'm using the boost version 1.30 release, on Win2k and the VC7.1 compiler. I'm porting a big application from Unix to Windows. Because for all the modules within this app I created a VC++ workspace I would like to do the same for the thread library from boost. For this I did the following steps: 1) Create with VC7.1 a Static library application without Precompiled header 2) Add to this lib the source files (from boost_1_30_0\libs\thread\src): 3) Set the right paths of the project for finding the includes 4) Build the lib My questions/problems are: 1) Are ok the above steps that I have done? Is it ok that I created it as a static lib (this is how I would like to have it)? 2) Are there any preprocessor flags that I have to add to the project? If yes from where can I find out which should I set? 3) I got a lot of warnings like: xtime.cpp(75) : warning C4273: 'boost::xtime_get' : inconsistent dll linkage. Actually there are 119 warnings like this one (C4273 and C4275). Why do I get these warnings? Is there a way to eliminate them? Should I be worried about them? 4) Actually I'm using the thread lib from boost, just because it seems that it is used by spirit when adding the SPIRIT_THREADSAFE flag. Looking a little through the boost source files comments I saw that by default the Windows native threads are used. But the threads created specifically by the application are posix threads so for them I used the pthread-win32 lib. Can I have problems because there will be both types of threads? I hope that somebody can help me on these issues ... Thanks a lot in advance, Viv ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: exception context
The idea of the why() member was to preserve context when one exception gets caught and a different one gets thrown, so you could walk back the chain of why()'s asking what() and where(). I bring it up just as a design that might be worth resurrecting if it meets your needs. On Friday, Mar 21, 2003, at 09:24 America/Denver, Alisdair Meredith wrote: Greg Colvin wrote: std::exception used to have a why() member that returned the list of exceptions leading to the one caught. Is that part of what you want? Not exactly. I'm not too bothered about the history of the exceptions, I'm simply concerned with formatting useful error messages for users. In order to describe an error usefully/accurately you need as much context as possible, so such messages are most usefully described/formatted as the exception propogates. If you defer all message-formatting until some outer catch block you need to also leak sufficient implementation detail and knowledge to form that message. In the ideal library, such context information is only accumulated during exception propogation, and would not interfere with the exception handling system at all (no catch blocks, some sort of RAII/ScopeGuard-like object) To that extent, all that is really needed is a known stringstream per thread of execution, and some way to defer diagnostic generation unless an exiting the block due to exception propogation. To an extent, rather than missing why() I am looking for a replacement for what() as well!! Among other things I hear that can cause problems for localising error messages (something else this scheme should address) although I am lucky enough not to have to deal with such problems myself. -- AlisdairM ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Boost version 1.30.0 released - date_time change history
I read on the date_time change history about a new function for calculating ISO 8601 week number. I should note that this week number is rather useless without the corresponding year number. ISO 8601 week-based year is not always the same as the actual year. For example, 2nd January 1999 is week 53 of year 1998 (not 1999!). 30th December 1997 is week 01 of year 1998 (not 1997!). (examples taken from the C99 standard) My experience is that people often forget about this important fact and thus introduce bugs that may be not be catched until such situation really happens in life. To force library users consider this thing, I think that gregorian::date::week_number should return a pair: week number and week-based year number. Another option would be to just add a separate function for calculating week-based year number, however in my opinion it is less desirable because of reasons mentined above. In any case, providing week number without providing week-based year number is undesirable. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: call_traitsint::value_type
The way call_traits is currently implemented, call_traitsint::value_type is an int, not an int. This is the correct behavior. If you are storing an int and want to return it by value, you will return an int . This is some new usage of the term by value with which I'm not familiar. When I return an int, I call that return by reference. ;-) I don't doubt that there is a use for the current implementation. What I'm saying is that calling it value_type is wrong because that term is used already in standard C++, and with a different meaning. call_traits::value_type should be like iterator_traits::value_type -- a non-const, non-reference that can be used to store temporary variables in algorithms and whatnot. I suspect that this is the more common usage scenario (-- blind asseriton), and it is the behavior people would expect. Since there is a need, as you say, for a typedef that can be used to store a type T and/or return it, perhaps there should be a different typedef, like member_type or return_type (or both!). Eric ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 1.30.0 Random fails to compile on MSVC 6
Hi All,
I posted this question on boost.users list but did not get
any response.
My first attempt to switch my project from boost 1.29 to
1.30 failed miserably due to compilation errors in random library.
Simple
#include boost/random/mersenne_twister.hpp
#include boost/random/normal_distribution.hpp
int main() {return 0;}
Fails with lots of error messages:
I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/uniform_01.hpp(44)
: error C2275: 'std::numeric_limits`template-parameter258'::is_integer'
: illegal use of this type as an expression
I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/uniform_01.hpp(95) : see reference to
class template instantiation 'boost::uniform_01UniformRandomNumberGenerator,RealType'
being compiled
I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/uniform_01.hpp(44)
: error C2027: use of undefined type 'STATIC_ASSERTION_FAILURE'
I:\SW\EXTERNAL\BOOST_1_30_0\boost/static_assert.hpp(29) : see declaration of
'STATIC_ASSERTION_FAILURE'
I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/uniform_01.hpp(95) : see reference to
class template instantiation 'boost::uniform_01UniformRandomNumberGenerator,RealType'
being compiled
I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/normal_distribution.hpp(49)
: error C2275: 'std::numeric_limits`template-parameter258'::is_integer'
: illegal use of this type as an expression
I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/normal_distribution.hpp(131) : see
reference to class template instantiation
'boost::normal_distributionUniformRandomNumberGenerator,RealType,`template-parameter260''
being compiled
I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/normal_distribution.hpp(49)
: error C2027: use of undefined type 'STATIC_ASSERTION_FAILURE'
I:\SW\EXTERNAL\BOOST_1_30_0\boost/static_assert.hpp(29) : see declaration of
'STATIC_ASSERTION_FAILURE'
I:\SW\EXTERNAL\BOOST_1_30_0\boost/random/normal_distribution.hpp(131) : see
reference to class template instantiation
'boost::normal_distributionUniformRandomNumberGenerator,RealType,`template-parameter260''
being compiled
__
Kirill Lapshin
Re: [boost] RPMS?
I have built SRPMS for RH8 for boost1.30.0. They required just minor modifications to the spec files. Where should I upload them? ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: call_traitsint::value_type
-Original Message- From: Eric Niebler [mailto:[EMAIL PROTECTED] The way call_traits is currently implemented, call_traitsint::value_type is an int, not an int. This is the correct behavior. If you are storing an int and want to return it by value, you will return an int . This is some new usage of the term by value with which I'm not familiar. When I return an int, I call that return by reference. ;-) I'm using the term by value to mean an abstract concept. Let me see if I can rephrase my point of view: If you store an int, you are storing a number. If you store an int , you are storing a modifiable reference to a number that is located somewhere else. If you store int , and return int, you have not transferred the by value abstract concept -- that is, the return value is just a number, not a modifiable reference to a number located elsewhere. [ In this case, you have lost value, so to speak. Heh, heh... :) ] Whereas, if you store an int, then you can return by value (int) or by reference (int ). I don't doubt that there is a use for the current implementation. What I'm saying is that calling it value_type is wrong because that term is used already in standard C++, and with a different meaning. call_traits::value_type should be like iterator_traits::value_type -- a non-const, non-reference that can be used to store temporary variables in algorithms and whatnot. Again, Standard practice generally doesn't apply here, since they just ignore references completely. I think that std::vectorint ::value_type -- if it existed -- would be int . My point is that if an algorithm wanted to work with a type that is either a reference or non-reference, then it *should* use call_traitsT::value_type for all temporary variables. And in this case, the int would be the correct type. E.g., if an algorithm existed that would return one of the values in a hypothetical container of references, would you want it to return int or int ? I suspect that this is the more common usage scenario (-- blind asseriton), and it is the behavior people would expect. Most generic software I'm familiar with follows the Standard guideline of do not use with reference types. There are a few exceptions to this rule, e.g., compressed pair. These reference-friendly components have made up the rules as they go, in the way that made the most sense to the authors at the time... :) Since there is a need, as you say, for a typedef that can be used to store a type T and/or return it, perhaps there should be a different typedef, like member_type or return_type (or both!). I agree with this totally; I like the idea of two names other than value_type. However, I think that they should both resolve to the same type (currently value_type). -Steve ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RPMS?
At 01:11 PM 3/21/2003, Neal D. Becker wrote: I have built SRPMS for RH8 for boost1.30.0. They required just minor modifications to the spec files. Where should I upload them? Should that be part of the regular Boost distribution, and thus live in CVS? If so, would you be willing to maintain it? Sorry if that is a completely dumb question - I have no knowledge of what an SRPM is, and only a vague second-hand knowledge of RPM. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
I downloaded 1.30.0 and tried to build my project. I got a few errors that seem to be in boost, primarily in lexical_cast. Also, weak_ptr.hpp uses bad_weak_ptr without including boost/detail/shared_count.hpp anywhere. I can fix that by including it in my code. These are the warnings in lexical_cast.hpp. Because I treat warnings as errors, these pretty much keep me from using this version of boost. C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(74) : warning C4512: 'no_lexical_conversionclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,long' : assignment operator could not be generated C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(193) : see reference to class template instantiation 'boost::detail::no_lexical_conversionclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,long' being compiled N:\Source\FontSetupUI.cpp(232) : see reference to function template instantiation 'class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __cdecl boost::lexical_cast(long)' being compiled C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(74) : warning C4512: 'no_lexical_conversionclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,double' : assignment operator could not be generated C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(193) : see reference to class template instantiation 'boost::detail::no_lexical_conversionclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,double' being compiled N:\Source\FontSetupUI.cpp(410) : see reference to function template instantiation 'class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __cdecl boost::lexical_cast(double)' being compiled C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(74) : warning C4512: 'no_lexical_conversiondouble,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ' : assignment operator could not be generated C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(193) : see reference to class template instantiation 'boost::detail::no_lexical_conversiondouble,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ' being compiled N:\Source\FontSetupUI.cpp(500) : see reference to function template instantiation 'double __cdecl boost::lexical_cast(class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar )' being compiled C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(147) : warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning) C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(146) : while compiling class-template member function 'bool __thiscall boost::detail::lexical_streamclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,long::operator (const long )' C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(147) : warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning) C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(146) : while compiling class-template member function 'bool __thiscall boost::detail::lexical_streamclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,double::operator (const double )' C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(147) : warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning) C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(146) : while compiling class-template member function 'bool __thiscall boost::detail::lexical_streamdouble,class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ::operator (const class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar )' ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Bidirectional map preliminary submission
A bidirectional map is something I've wanted a good implementation of
for a while. I have one that has some terrible performance in memory
and speed, but does what I need in its current context. Having a better
one would be great, so I applaud your submission.
1. Syntax and semantics
Since bimap follows as closely as possible the interface of std::map,
there's little IMHO to add or remove from here. The added constraint
of bidirectionality imposes some behavior that diverges from regular
maps, though. I don't think there's an alternate way to handle the
following
issues:
* operator[], when used for inspection on a non-existent value, throws
bimap_base::value_not_found. std::maps, on the other hand, automatically
insert a default value. This I cannot do in bimap, since it would
violate the bidirectionality.
This is the right choice, I think.
* bimap_base::duplicate_value is thrown whenever an assignment is
attempted to a value already present in the bimap: this again stems from
the preservation of the bidirectionality invariant.
Likewise. No problem here.
2. Pollution of namespace boost.
Apart from bimap, the following types and functions are already defined
inside boost namespace:
[snap]
Apart from bimap_base and possibly make_inv_pair, I'd like to have all
of these
defined in an auxiliary namespace, but MSVC++, which is my work
compiler,
chokes at one point or another when tyring to do so.
That's odd. Lots of boost libraries use boost::detail or
boost::library_name::detail for implementation details. This shouldn't
be a problem with MSVC++.
3. Nonconformances
To the best of my knowledge, there are two non-conformances in the code:
* It is assumed that for these two classes (in simplified form here):
templatetypename A,typename B
struct direct_pair
{
A first;
B second;
};
templatetypename C,typename D
struct inv_pair
{
D second;
C first;
};
it is asummed, I was saying, than a direct_pairA,B can be
reinterpret_cast'ed
to a inv_pairC,D (and vice versa) whenever A=D and B=C.
Ugh. I know that this is almost certainly going to never be a problem,
but I don't like it, even if just for the fact that it . Can you
summarize why this is necessary? Perhaps we can find a solution which
doesn't require it.
I have taken just a brief look at the code, and I think I understand
the driving motivation for this: You wanted the following behavior:
(in a bm where 1 = 2 )
bm.from.find(1)-first = 1;
bm.from.find(1)-second = 2;
bm.to.find(2)-first = 2;
bm.to.find(2)-second =1;
Right? Is there some other behavior that this machinery enables that
I'm missing?
Two comments: One is, both the memberspaces and the public data in the
pair's could benefit from properties being part of C++. There's a
thread on comp.std.c++ about properties right now, and you might
consider contributing this use to that discussion.
Second, I'm not sure that this motivation is strong enough to make me
want the whole kit and kaboodle of the direct_pair, inv_pair, and
everything that you've set up. I don't really mind having to know which
way my bimap is going and remember that I have to use the right thing;
most bimap uses that I can imagine involve mostly bm.from[x] and
bm.to[y] which always take care of that for me.
And, one thing I would like to see very much from a bimap is that it
should be naturally generalizable to an N-map, where N of the elements
are independent keys, having additional M elements of unkeyed data,
carried along (M being 0 or 1 is good enough, given tuples, but general
M would be nice syntactic sugar). Your implementation and particularly
the direct_pair/inv_pair stuff seems antagonistic to such a
generalization.
Your implementation also leads to a tremendous amount of duplicated or
near-duplicated code in the from and to memberspaces.
* offsetof() is used for non-POD types. The types on which it is used
are
arguably simple enough to be treated as POD (no virtual methods or
anything), but
then again the standard bans it.
Again, can you summarize why this is necessary, rather than using (say)
a pointer-to-member? It looks like you're using it to recover the
containing class from the memberspaces, is that right?
George Heintzelman
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
On Fri, 21 Mar 2003 10:06:45 -0700, Greg Colvin [EMAIL PROTECTED] wrote: The idea of the why() member was to preserve context when one exception gets caught and a different one gets thrown, so you could walk back the chain of why()'s asking what() and where(). I bring it up just as a design that might be worth resurrecting if it meets your needs. Do you have pointers to the old std::exception specification, with where() and why() members? PS: I declare myself out of this vague discussion. Just curious about those ones :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost 1.30 - Thread lib workspace
vc said: Hi all, I'm using the boost version 1.30 release, on Win2k and the VC7.1 compiler. I'm porting a big application from Unix to Windows. Because for all the modules within this app I created a VC++ workspace I would like to do the same for the thread library from boost. For this I did the following steps: 1) Create with VC7.1 a Static library application without Precompiled header 2) Add to this lib the source files (from boost_1_30_0\libs\thread\src): 3) Set the right paths of the project for finding the includes 4) Build the lib My questions/problems are: 1) Are ok the above steps that I have done? Is it ok that I created it as a static lib (this is how I would like to have it)? Not if you make use of thread_specific_ptr in any of your code. Note also that the next version of Boost.Threads will be doing this internally for boost::thread itself... so a static build won't really be possible with that release. 2) Are there any preprocessor flags that I have to add to the project? If yes from where can I find out which should I set? Just make sure you're linking to the multi-threaded C RTL. 3) I got a lot of warnings like: xtime.cpp(75) : warning C4273: 'boost::xtime_get' : inconsistent dll linkage. Actually there are 119 warnings like this one (C4273 and C4275). Why do I get these warnings? Is there a way to eliminate them? Should I be worried about them? You'll have to add code to $BOOST_ROOT/boost/thread/detail/config.hpp to not define BOOST_THREAD_DECL when building a static library. 4) Actually I'm using the thread lib from boost, just because it seems that it is used by spirit when adding the SPIRIT_THREADSAFE flag. Looking a little through the boost source files comments I saw that by default the Windows native threads are used. But the threads created specifically by the application are posix threads so for them I used the pthread-win32 lib. Can I have problems because there will be both types of threads? I wouldn't expect problems, but you can compile Boost.Threads with pthreads-win32 if you want (at least with this version... the next release probably won't work with this configuration, and I have to admit that I've not tested this build variant in quite a while). Look at $BOOST_ROOT/libs/thread/build/threads.jam to see how to do this. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RPMS?
Beman Dawes said: At 01:11 PM 3/21/2003, Neal D. Becker wrote: I have built SRPMS for RH8 for boost1.30.0. They required just minor modifications to the spec files. Where should I upload them? Should that be part of the regular Boost distribution, and thus live in CVS? If so, would you be willing to maintain it? Sorry if that is a completely dumb question - I have no knowledge of what an SRPM is, and only a vague second-hand knowledge of RPM. Until we have a more formal installation solution, I think the SRPM's spec file should reside in CVS. It would also be nice to have other installation options as well, such as Debian packages (sorrry, not totally familiar with the terminology to use), BSD ports, Gentoo ports, Windows installers, etc. We just need champions willing to submit and maintain each of these. Before anything's actually added, however, maybe we should discuss things a bit either here or on the Boost Install list. -- William E. Kempf ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MSVC++ 6.0 compiler errors with 1.30.0(mostlylexical_cast.hpp)
John Swartzentruber wrote: I downloaded 1.30.0 and tried to build my project. I got a few errors that seem to be in boost, primarily in lexical_cast. Also, weak_ptr.hpp uses bad_weak_ptr without including boost/detail/shared_count.hpp anywhere. I can fix that by including it in my code. weak_ptr.hpp includes shared_ptr.hpp, which in turn includes detail/shared_count.hpp. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: exception context
EXCEPT.DOC Description: MS-Word document On Friday, Mar 21, 2003, at 11:51 America/Denver, Gennaro Prota wrote: On Fri, 21 Mar 2003 10:06:45 -0700, Greg Colvin [EMAIL PROTECTED] wrote: The idea of the why() member was to preserve context when one exception gets caught and a different one gets thrown, so you could walk back the chain of why()'s asking what() and where(). I bring it up just as a design that might be worth resurrecting if it meets your needs. Do you have pointers to the old std::exception specification, with where() and why() members? PS: I declare myself out of this vague discussion. Just curious about those ones :-) Genny. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
From: John Swartzentruber [EMAIL PROTECTED] I downloaded 1.30.0 and tried to build my project. I got a few errors that seem to be in boost, primarily in lexical_cast. Also, weak_ptr.hpp uses bad_weak_ptr without including boost/detail/shared_count.hpp anywhere. I can fix that by including it in my code. These are the warnings in lexical_cast.hpp. Because I treat warnings as errors, these pretty much keep me from using this version of boost. In the reported output there are two warnings, both level 4 warnings, which are more or less remarks. That's why they are disabled in the lexical_cast unit tests. They are: C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(74) : warning C4512: 'no_lexical_conversionclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,long' : assignment operator could not be generated This is due to that it stores a const std::string object, describing the exception. no_lexical_cast is the concrete exception type returned, and it inherits from bad_lexical_cast. The reason it stores a string object, rather than using a static string member (since the information is the same for all objects of it), is that MSVC 6 couldn't handle that static initialisation. Ironic, huh? :) A simple way to fix this is to make the string object non-const, although there's really no reason for it to be assigned to, as all objects are the same. C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(147) : warning C4800: 'void *' : forcing value to bool 'true' or 'false' (performance warning) C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(146) : while compiling class-template member function 'bool __thiscall This uses the implicit conversion from pointer to bool, and one could probably avoid the warning with an explicit cast. An alternative to the above is: #pragma warning(disable: 4512 4800) :) Regards, Terje ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Bidirectional map preliminary submission
Hi George
- Original Message -
From: George A. Heintzelman [EMAIL PROTECTED]
Date: Friday, March 21, 2003 7:38 pm
Subject: Re: [boost] Bidirectional map preliminary submission
[stuff deleted]
2. Pollution of namespace boost.
Apart from bimap, the following types and functions are already
defined inside boost namespace:
[snap]
Apart from bimap_base and possibly make_inv_pair, I'd like to
have all
of these
defined in an auxiliary namespace, but MSVC++, which is my work
compiler,
chokes at one point or another when tyring to do so.
That's odd. Lots of boost libraries use boost::detail or
boost::library_name::detail for implementation details. This
shouldn't
be a problem with MSVC++.
Yes, I think I've got to work more on this. I'm having
confusing errors dealing with globl swap functions when
pushing these auxiliary classes in inner namespaces.
3. Nonconformances
To the best of my knowledge, there are two non-conformances in
the code:
* It is assumed that for these two classes (in simplified form
here):
templatetypename A,typename B
struct direct_pair
{
A first;
B second;
};
templatetypename C,typename D
struct inv_pair
{
D second;
C first;
};
it is asummed, I was saying, than a direct_pairA,B can be
reinterpret_cast'ed
to a inv_pairC,D (and vice versa) whenever A=D and B=C.
Ugh. I know that this is almost certainly going to never be a
problem,
but I don't like it, even if just for the fact that it . Can you
summarize why this is necessary? Perhaps we can find a solution
which
doesn't require it.
I have taken just a brief look at the code, and I think I
understand
the driving motivation for this: You wanted the following behavior:
(in a bm where 1 = 2 )
bm.from.find(1)-first = 1;
bm.from.find(1)-second = 2;
bm.to.find(2)-first = 2;
bm.to.find(2)-second =1;
Right? Is there some other behavior that this machinery enables
that
I'm missing?
Yes, that's exactly the reason behind the direct_pair/inv_pair
trick.
Two comments: One is, both the memberspaces and the public data in
the
pair's could benefit from properties being part of C++. There's a
thread on comp.std.c++ about properties right now, and you might
consider contributing this use to that discussion.
Will look it up, thanx.
Second, I'm not sure that this motivation is strong enough to make
me
want the whole kit and kaboodle of the direct_pair, inv_pair, and
everything that you've set up. I don't really mind having to know
which
way my bimap is going and remember that I have to use the right
thing;
most bimap uses that I can imagine involve mostly bm.from[x] and
bm.to[y] which always take care of that for me.
I think you're a little misguided here; in fact, one should
never use direct_pairs or inv_pairs: they have been defined
so that you can treat each memberspace (viewed in isolation)
as a regular map, save the one-to-one constraint. Consider
this example:
bimapint,string bm;
bm.to.insert(make_pair(hello,1));
The code sees bm.to as a map from string to int in the same
way as bm.from is a map from int to string. You don't have
to invoke inv_pairs here at all, an std::pair is gladly accepted
and internally converted to an inv_pair with no extra cost
(hence the reinterpret_cast stuff). The morale is: given
a bimapA,B bm you can treat bm.from in all respects as a
std::mapA,B and bm.to as a std::mapB,A.I hope I made
myself clear enough.
And, one thing I would like to see very much from a bimap is that
it
should be naturally generalizable to an N-map, where N of the
elements
are independent keys, having additional M elements of unkeyed
data,
carried along (M being 0 or 1 is good enough, given tuples, but
general
M would be nice syntactic sugar). Your implementation and
particularly
the direct_pair/inv_pair stuff seems antagonistic to such a
generalization.
I'm afraid bimap is so strongly tied to the interface of
std::map that your proposed container could hardly be built
as a generilzation of it. BTW I'm working in a container like
you propose (modelled after set rather han map), but it'll take
long and won't resemble bimap at all.
So, IMHO bimap has to be regarded as the end of the road in
generalizing std::maps (unless someone with a brilliant mind
finds otherwise).
Your implementation also leads to a tremendous amount of
duplicated or
near-duplicated code in the from and to memberspaces.
* offsetof() is used for non-POD types. The types on which it is
used are
arguably simple enough to be treated as POD (no virtual methods or
anything), but
then again the standard bans it.
Again, can you summarize why this is necessary, rather than using
(say)
a pointer-to-member? It looks like you're using it to recover the
containing class from the memberspaces, is that right?
Yes, that's it. I don't really know how to use a
pointer-to-member
Re: [boost] Problem with KAI C++ and boost::type_traits
Matthias Troyer [EMAIL PROTECTED] writes: Dear Boosters, Unfortunately we could not test 1.30 extensively and thus found a problem with the current Boost sources just after a release. When trying to compile the filesystem library with KAI C++ we encounter a problem in boost/type_traits/is_base_and_derived.hpp It seems that the workaround is needed also for KCC, since otherwise we get the error message line 126: error: expression must have (pointer-to-) function type BOOST_STATIC_CONSTANT(bool, value = Looking at the #if before this version I find: !BOOST_WORKAROUND(__EDG_VERSION__, = 238) 0 // The EDG version number is a lower estimate. // It is not currently known which EDG version // exactly fixes the problem. KAI C++ version 4.0f has an __EDG_VERSION__ of 243 but this still fails. Can 238 here be changed at least to 243? I can do that. Should we start a new branch for things that would go into a hypothetical 1.30.1? My feeling is that we should just keep using the RC_1_30_0 branch, since it's already been tagged where the release was made. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Problem with KAI C++ and boost::type_traits
Matthias Troyer [EMAIL PROTECTED] writes: Dear Boosters, Unfortunately we could not test 1.30 extensively and thus found a problem with the current Boost sources just after a release. When trying to compile the filesystem library with KAI C++ we encounter a problem in boost/type_traits/is_base_and_derived.hpp Uh, wait... It seems that the workaround is needed also for KCC, since otherwise we get the error message line 126: error: expression must have (pointer-to-) function type BOOST_STATIC_CONSTANT(bool, value = Looking at the #if before this version I find: !BOOST_WORKAROUND(__EDG_VERSION__, = 238) 0 ^ Where did this come from?--^ And furthermore, the code inside #if !BOOST_WORKAROUND(...) is all NON-workaround code, so the workaround _is_ being used for all versions 238 and lower. So I think you're going to have to analyze the problem and the fix again. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost 1.30 - Thread lib workspace
vc [EMAIL PROTECTED] writes: My questions/problems are: 1) Are ok the above steps that I have done? Is it ok that I created it as a static lib (this is how I would like to have it)? 2) Are there any preprocessor flags that I have to add to the project? If yes from where can I find out which should I set? 3) I got a lot of warnings like: xtime.cpp(75) : warning C4273: 'boost::xtime_get' : inconsistent dll linkage. Actually there are 119 warnings like this one (C4273 and C4275). Why do I get these warnings? Is there a way to eliminate them? Should I be worried about them? The easy way to find out what you need to do is to compile the library and run the tests through bjam using the -d+2 option, which will print all the command lines (use -n if you don't want to execute any build commands, and -a if you want to ensure you see all build commands). Then you can make your VC project do exactly the same things. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem with KAI C++ and boost::type_traits
David Abrahams wrote: I can do that. Should we start a new branch for things that would go into a hypothetical 1.30.1? My feeling is that we should just keep using the RC_1_30_0 branch, since it's already been tagged where the release was made. Sounds reasonable. Which makes me wonder if we shouldn't change the naming of branches a bit: We should have a branch for the development of new versions (1.30.x), let's call it DEVELOP_1_30_x. On this branch, we can now add several tags: Version_1_30_0_RC_1, Version_1_30_0_RC_2, Version_1_30_0, Version_1_30_1_RC_1, Version_1_30_1_RC_2, Version_1_30_1_RC_3, Version_1_30_1, etc. This would IMHO be an easy, straight-forward system which allows us to tag/create real release-candidates (like Beman already did for the current release but manually IIRC) and both the .0 version and bug-fix-versions - all in one correctly-named branch. Comments? 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: Problem with KAI C++ and boost::type_traits
Daniel Frey wrote: Sounds reasonable. Which makes me wonder if we shouldn't change the ^ Should be should, shouldn't be shouldn't ;) 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: Bidirectional map preliminary submission
Joaquín Mª López Muñoz wrote: 1. Syntax and semantics Since bimap follows as closely as possible the interface of std::map, there's little IMHO to add or remove from here. The added constraint of bidirectionality imposes some behavior that diverges from regular maps, though. I don't think there's an alternate way to handle the following issues: * operator[], when used for inspection on a non-existent value, throws bimap_base::value_not_found. std::maps, on the other hand, automatically insert a default value. This I cannot do in bimap, since it would violate the bidirectionality. What about when operator[] is used for an assignment to a unique value? I have to imagine that there are scenarios where inserting a temporary value wouldn't be all that bad. Is it possible to make this a policy of some kind? Or possibly an template parameter to a default value generator function? The template parameter could default to a function that throws the exception... * bimap_base::duplicate_value is thrown whenever an assignment is attempted to a value already present in the bimap: this again stems from the preservation of the bidirectionality invariant. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
Terje Slettebø [EMAIL PROTECTED] writes: C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(74) : warning C4512: 'no_lexical_conversionclass std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar ,long' : assignment operator could not be generated This is due to that it stores a const std::string object, describing the exception Are you saying that you have defined an exception with a std::string member? That's VERY bad! Throwing that exception can lead directly to termination! What's wrong with char const*? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] RPMS?
At 01:58 PM 3/21/2003, William E. Kempf wrote: Until we have a more formal installation solution, I think the SRPM's spec file should reside in CVS. It would also be nice to have other installation options as well, such as Debian packages (sorrry, not totally familiar with the terminology to use), BSD ports, Gentoo ports, Windows installers, etc. We just need champions willing to submit and maintain each of these. Before anything's actually added, however, maybe we should discuss things a bit either here or on the Boost Install list. Yes, I'd like to see that discussion restarted. The Boost Install list would be the place to hold it. As a result of just going through the release process, I've been thinking about install issues some more. For those who would like to participate, the place to subscribe to that list is http://lists.boost.org/mailman/listinfo.cgi/boost-install. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RPMS?
Yes, I'd like to see that discussion restarted. The Boost Install list would be the place to hold it. While we on topic: why don't we have references to these minor lists anywere. I could not find it not on main site, nor on lists.boost.org (which I presume should mention all lists related to boost)? Gennadiy. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] spirit::rule::set_id()
Thanks! I noticed that this change leads to different behavior when
assigning rules. Consider this code:
typename rule_ScannerT, IDENTIFIER::type Identifier;
typename rule_ScannerT, FUNCTION::type Function;
typename rule_ScannerT, PREDICATE::type Predicate;
typename rule_ScannerT, VARIABLE::type Variable;
Identifier = lexeme_d[token_node_d[(alpha_p | '_' | '$') *(alnum_p
| '_' | '$')]];
Function = Identifier;
Predicate = Identifier;
Variable = Identifier;
value.id().to_long() used to return FUNCTION, PREDICATE, or VARIABLE,
but it now returns IDENTIFIER. There's an easy, cut-and-paste
workaround:
Function = lexeme_d[token_node_d[(alpha_p | '_' | '$') *(alnum_p |
'_' | '$')]];
Predicate = lexeme_d[token_node_d[(alpha_p | '_' | '$') *(alnum_p |
'_' | '$')]];
Variable = lexeme_d[token_node_d[(alpha_p | '_' | '$') *(alnum_p |
'_' | '$')]];
Anyone have a better suggestion?
Jon
-Original Message-
From: Joel de Guzman [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 20, 2003 6:01 PM
To: Boost mailing list; Spirit
Subject: Re: [boost] spirit::rule::set_id()
Jon Wray wrote:
What happened to spirit::rule::set_id()? It was in Spirit 1.5.1,
but it's
missing from 1.6.0. The doc still refers to it (see the very bottom
of
http://www.boost.org/libs/spirit/doc/rule.html).
Giovanni Bajo wrote:
I might be dumb, but I read in the documentation that each rule should
have a member called set_id() to modify the parser ID. Now, looking
into the code that method does not exist. Not only that, but there is
not even a member holding the parser_id, it's just computed on the fly
through a policy, which means that it is impossible to modify at
runtime.
No, you are not dumb. This is a documentation oversight.
The only way I found was:
ruleT, parser_context, parser_tagAST::ID_INTERFACE
interf;
This is correct. Pardon the oversight. The change was done so as to have
a consistent interface for rules, subrules and grammars. Following the
precept that the user should not pay for features she does not need,
the member variable was taken out in favor of a static constant. The
additional member variable is not needed in many cases.
which is quite bloated, especially since I have to do this for many
many rules. So, where is the missing set_id() member?
In the meantime, this is the way to do it. You can write a simple
metaprogram to ease the typing (pun?). Example:
template typename ScannerT, in ID
struct rule_
{
ruleScannerT, parser_context, parser_tagID type;
};
Then:
rule_T, AST::ID_INTERFACE::type interf;
Sometime in the future, the interface to rules will be made easier such
that the optional template arguments can be passed in arbitrary
sequence.
Hope this helps. Again pardon the oversight.
--
Joel de Guzman
joel at boost-consulting.com
http://www.boost-consulting.com
http://spirit.sf.net
___
Unsubscribe other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] MSVC++ 6.0 compiler errors with 1.30.0 (mostlylexical_cast.hpp)
From: David Abrahams [EMAIL PROTECTED]
Terje Slettebø [EMAIL PROTECTED] writes:
C:\Program Files\Boost\boost_1_30_0\boost/lexical_cast.hpp(74) :
warning
C4512: 'no_lexical_conversionclass std::basic_stringchar,struct
std::char_traitschar,class std::allocatorchar ,long' : assignment
operator could not be generated
This is due to that it stores a const std::string object, describing the
exception
Are you saying that you have defined an exception with a std::string
member? That's VERY bad! Throwing that exception can lead directly
to termination!
You mean if the exception itself throws during construction or copying?
I've tried the program below on Intel C++ 7.0 and MSVC 6, and I haven't got
it to call terminate(). It may be that it doesn't handle exceptions
correctly, though.
#include iostream
#include string
#include stdexcept
class Exception : public std::runtime_error
{
public:
Exception() : std::runtime_error(Exception)
{ throw std::runtime_error(Construction); }
Exception(const Exception ) : std::runtime_error(Exception (copied))
{ throw std::runtime_error(Copy); }
};
int main()
{
try
{
throw Exception();
}
catch(const std::exception e)
{
std::cout Exception - e.what() '\n';
}
catch(...)
{
std::cout Unknown exception\n;
}
}
As it stands, it prints Exception - Constructor, as it throws an exception
in the constructor of the Exception exception. If the throw-statement in the
constructor is commented out, it prints Exception - Exception, apparently
not invoking the copy constructor when throwing the exception (which it's
allowed to).
What's wrong with char const*?
You mean storing the string as a character array? Sure, that's possible, and
I see that STLPort do it, and it's probably safer, as you say. It does mean
you have to specify the maximum string length in advance, though. As
no_lexical_conversion what() prints out the source and target types, it
may truncate long type names.
Regards,
Terje
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
