Re: [Boost-users] Could sprintf be replaced with snprintf?

On Tue, Dec 12, 2023 at 1:56 AM Matt Borland via Boost-users < boost-users@lists.boost.org> wrote: > > > > On Dec 11, 2023, at 8:59 PM, McGrath, Justin M > wrote: > > > > Has there been any movement on having someone else maintain ODEINT? I > don't know that I would be of much use, but I'm

Re: [Boost-users] [iostreams] When plan to move to C++20

On Fri, Feb 10, 2023 at 12:03 PM Seyyed Soroosh Hosseinalipour via Boost-users wrote: > Thanks for reply, but many of the libraries exist in boost, after some > years candidate for adding to C++ ISO, so I think if we migrate iostream to > latest standard of C++, we can candidate this library for

Re: [Boost-users] Boost 1.75.0 Release Candidate 1 -- macOS

On Wed, Dec 9, 2020 at 1:45 PM DV Henkel-Wallace via Boost-users < boost-users@lists.boost.org> wrote: > Date: Thu, 3 Dec 2020 06:54:13 -0800 > From: Marshall Clow > > > [release] Boost 1.75.0 Release Candidate 1 > > > Built fine on macOS 11.0.1 using llvm 11.0.0 > > ./b2 cxxstd=2a

Re: [Boost-users] [release] Boost 1.75.0 Release Candidate 1

On Thu, Dec 3, 2020 at 7:54 AM Marshall Clow via Boost-users < boost-users@lists.boost.org> wrote: > [release] Boost 1.75.0 Release Candidate 1 > > > The first release candidates for the 1.75.0 release are now available at: > > As always, the release managers would appreciate it if you

Re: [Boost-users] A Newbie Boost.Build with Variants Question

On Fri, Oct 23, 2020 at 2:12 PM Ryan Heniser via Boost-users < boost-users@lists.boost.org> wrote: > > Hi, > > I am building Boost 1.61 (we need this old version for other libraries) > for the first time at work with Boost.Build (b2). I have successfully built > Boost (using b2) for gcc 4.8. If I

Re: [Boost-users] [Signals2] Deprecated header warning VS2017 Boost 1.74

On Thu, Oct 22, 2020 at 1:07 PM Peter Barker via Boost-users < boost-users@lists.boost.org> wrote: > Hi, > > Just upgraded to Boost 1.74 from Boost 1.71. I'm getting a warning: > > > I'll have to #define BOOST_ALLOW_DEPRECATED_HEADERS I guess, but I'm > surprised Boost libraries are using

Re: [Boost-users] [release] Boost 1.74.0 Release Candidate 2

On Tue, Aug 11, 2020 at 11:02 AM Marshall Clow via Boost-users < boost-users@lists.boost.org> wrote: > The second release candidates for the 1.74.0 release are now available at: > > > > The SHA256 checksums are as follows: > >

Re: [Boost-users] Boost-1.71.0 upgrade issue

n', > > 'boost_filesystem', > > 'boost_thread', > > 'boost_system', > > 'boost_chrono', > > 'boost_timer', > > > > Thanks & Regards, > > Tej > > On Wed, Jul 22, 2020 at 8:54 PM Jeff Garland via Boost-users < > boost-users@lists.bo

Re: [Boost-users] Boost-1.71.0 upgrade issue

Would be helpful to see the exact link command. If you are statically linking (.a files) then order might matter. On Wed, Jul 22, 2020 at 7:00 AM Tej Kumar via Boost-users < boost-users@lists.boost.org> wrote: > Hi Team, > > Hope you guys are doing well. > > I am trying to upgrade Boost to

Re: [Boost-users] Three-way comparison operator

Scanning the change log it doesn't seem likely boost.test was updated. Also given that the feature really just arrived in clang 10 in the last month and gcc 10 isn't yet released almost no one has reacted to operator<=> yet. All that said, most stuff like boost.test that uses operators shouldn't

Re: [Boost-users] Building boost 1.72 with arm 64 bit gcc compiler

That's error coming from boost.context library build for assembly code. Don't think there's arm64 support there for gcc -- seems like it's looking for clang. Obviously if you're not using boost.context you can ignore. Not seeing an issue for this, but maybe worthy of filing a report:

Re: [Boost-users] asio and custom socket implementation

Not answering the question, but I don't know that there's documented extension points in the library for what you're wanting to do. It's surely possible, but maybe complex. I'd suggest asking for help on the asio list from https://think-async.com/. On Wed, Apr 1, 2020 at 7:11 AM Stanislav Zaikin

Re: [Boost-users] [program_options] cmake error

On Fri, Mar 27, 2020 at 11:21 AM Jeanette C. via Boost-users < boost-users@lists.boost.org> wrote: > Hey hey, > I get a cmake error about a non-existent directory from > boost::program_options, namely /include . > It only happens with the program_options library. Other libs included in > the >

Re: [Boost-users] Is iterator_facade still relevant in C++11, C++17?

I believe Zach Laine's library is the heir apparent -- it was accepted, but isn't in boost just yet. He describes some of the issues here: https://tzlaine.github.io/stl_interfaces/doc/html/boost_stlinterfaces/this_library_s_relationship_to_boost_iterator.html Jeff On Sat, Mar 14, 2020 at 2:00

Re: [boost] Re: [date_time] time_duration

On Wed, 03 Sep 2003 15:07:59 -0400, David Abrahams wrote Jeff Garland [EMAIL PROTECTED] writes: On Tue, 02 Sep 2003 19:00:42 -0400, David Abrahams wrote The fractional seconds concept is undocumented. My guess it's something like: x.fractional_seconds() == x.ticks() % seconds

Re: [boost] Re: boost::date_time::time_resolutions

On Wed, 03 Sep 2003 15:09:11 -0400, David Abrahams wrote Jeff Garland [EMAIL PROTECTED] writes: On Tue, 02 Sep 2003 19:10:03 -0400, David Abrahams wrote Where is this documented, and what is nano in the table entry below? It isn't. nano is an enum value that isn't really useful

Re: [boost] Re: [date_time] time_duration division

On Wed, 03 Sep 2003 15:10:13 -0400, David Abrahams wrote Jeff Garland [EMAIL PROTECTED] writes: Jeff G wrote: I'm thinking it would have to be defined like this Duration / Duration -- Integer I think Duration / Duration -- double would be more appropriate. I have intentionally

Re: [boost] int64_t with MSVC 7.1 'strict' /Za option

On Thu, 28 Aug 2003 19:35:57 +0100, Paul A. Bristow wrote Trying to use boost/date-time in MSVC 7.1 in 'strict' mode option /Za 'disable language extensions' it seems that boost::int64_t isn't available. After a journey through the labryinthine config modules, I have got compiling with

[boost] Warning level setting for Regression tests

Before I make this request I'd just like to thank all the boosters that have contributed to the creation of the regrssion test system and actually run regression tests. It is an essential tool for portable library development. I don't know how we got things done correctly before we had this. So

Re: [boost] Time representation in Boost Date-Time

On Tue, 19 Aug 2003 10:08:51 +1000, Chris Trengove wrote 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

Re: [boost] Re: Date iterators in Boost Date-Time

On Mon, 18 Aug 2003 16:28:22 -0400, Beman Dawes wrote FWIW, I'm both a native-speaker and familiar with convex hulls. Regardless, span sounds better to me for use in the context of a Date-Time library. Ok, span it is. Updates checked into CVS Jeff

Re: [boost] Period calculations in Boost Date-Time

On Tue, 19 Aug 2003 13:25:37 +1000, Chris Trengove wrote 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

Re: [boost] Re: Time representation in Boost Date-Time

On Wed, 20 Aug 2003 08:30:38 +1000, Chris Trengove wrote 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

Re: [boost] Re: Date iterators in Boost Date-Time

On Mon, 18 Aug 2003 06:34:35 -0500, John Fuller wrote HL7 v3, a health care application layer specification, uses the term with time intervals as an operation on a totally ordered set that produces the smallest interval that is a superset. For example, hull({[1,5], [7,10]}) == [1,10] The

Re: [boost] Re: Date iterators in Boost Date-Time

On 18 Aug 2003 11:43:26 +0200, Gabriel Dos Reis wrote Guillaume Melquiond [EMAIL PROTECTED] writes: | In the case of a 1-dimension space, connected and convex set are | equals: they are segments (or half-line or line or empty). Date | manipulated by the date-time library are in a 1-dimension

Re: [boost] Re: Date iterators in Boost Date-Time

On Sun, 17 Aug 2003 08:11:14 +0200 (CEST), gmelquio wrote I just wanted to mention that the interval library names this operation hull. It is a mathematically defined term since the operation is indeed a convex hull. Just my two eurocents, Guillaume Thanks, I like it. Precise and

Re: [boost] Re: Re: Date iterators in Boost Date-Time

On Sat, 16 Aug 2003 09:05:10 +1000, Chris Trengove wrote 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

Re: [boost] time_duration bug in Boost 1.30.0

On Mon, 4 Aug 2003 20:17:03 -0700, Stephan T. Lavavej wrote 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! Hmm, I agree that this is not nice... ...example

RE: [boost] [date_time] improvements

John - Sorry to be slow on this reply... John Torjo wrote: [1] unary operator-(time_iterator). Example: -hours(24) instead of hours(-24). (seems more straightforward) I see your point, but then don't you have to add all the other operators for consistency? Not sure that makes

Re: [boost] Support for gcc-2.95 in 1.31

On Tue, 12 Aug 2003 14:41:16 +0200, Martin Wille wrote a couple of libraries are regressing for gcc-2.95.3/Linux: date_time I've been making a number of enhancements to date-time and that has caused the test failures. The fixes for these have already been checked into CVS, so the next

RE: [boost] Re: time_duration bug in Boost 1.30.0

On Thu, 7 Aug 2003 21:53:30 +0100, Paul A. Bristow wrote I have built the date examples OK, but I am getting a compile error when trying to build the time_math.cpp example with MSVC 7.1 aka .net 2003 I:/boost_1_30_0\boost\lexical_cast.hpp(147) : error C2679: binary '' : no operator found

Re: [boost] Re: Release of 1.30.2 imminent

On Tue, 12 Aug 2003 22:15:28 -0700, Stephan T. Lavavej wrote [Dave Abrahams] If I don't hear of any new problems with the RC_1_30_0 branch I'm going to release 1.30.2 tomorrow (Wed) evening or Thursday morning. There's one little problem... it doesn't compile cleanly under -Wshadow with

Re: [boost] Date iterators in Boost Date-Time

On Tue, 12 Aug 2003 10:44:45 +1000, Chris Trengove wrote 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

RE: [boost] Re: Boost 1.31 release?

I've just installed 3.3.1 on Windows, and am getting those same four failure plus failures from: date_time/testmicrosec_time_clock (runtime failure) This is likely due to the posix API call to std::time not providing stable return values. That is, when I sample the time rapidly

Re: [boost] Re: Date iterators in Boost Date-Time

On Fri, 15 Aug 2003 12:36:52 +1000, Chris Trengove wrote I think the big issue in using random access iterators is whether you want to support the difference concept. It is relatively straightforward to implement, say year_iterator i(date(2003,1,1)); year_iterator j(date(2005,1,1));

RE: [boost] lexical_cast segfault

Stephan T. Lavavej wrote: In working with my date/time code I've encountered another problem with Boost. I can reproducibly get lexical_cast to segfault. It happens when a ...details omitted... Red Hat 9, gcc 3.3, Boost 1.30.0: You should upgrade your lexical_cast.hpp to the CVS

RE: [boost] Re: time_duration bug in Boost 1.30.0

On Sat, 9 Aug 2003 20:00:08 +0100, Paul A. Bristow wrote I suggest that I wait for the 30.1 release to be available, retest with strict mode and then mail you off-list with results from .net 2003 aka 7.1. Do you mean 1.31.0 or 1.30.2? The changes I'm speaking of are not in 1.30.2. I expect

Re: [boost] Re: time_duration bug in Boost 1.30.0

On Wed, 6 Aug 2003 10:11:20 -0700, Stephan T. Lavavej wrote [Jeff Garland] The downside of this is that when you are printing a time duration: std::cout td.hours() ':' td.minutes() ':' td.seconds(); you have to take remove the sign from the minutes and seconds. I have a third

Re: [boost] [date_time] improvements

On Mon, 4 Aug 2003 12:50:36 +0300, John Torjo wrote Told you I'd come back for more ;) Here are some more improvements I would consider useful: [1] unary operator-(time_iterator). Example: -hours(24) instead of hours(-24). (seems more straightforward) I see your point, but then don't you

RE: [boost] Preparing 1.30.1 Release -- Branch Question

Sorry to be MIA, but I wanted to add in the libs/date_time/doc/Changes.html file in the date-time docs that was not checked in when 1.30 was released... thus causing a broken link from the main page in the downloaded docs. I believe Dave hacked the website to fix this, but it was still broken in

RE: [boost] Re: Preparing 1.30.1 Release -- Branch Question

Sorry to be MIA, but I wanted to add in the libs/date_time/doc/Changes.html file in the date-time docs that was not checked in when 1.30 was released... thus causing a broken link from the main page in the downloaded docs. I believe Dave hacked the website to fix this, but it was still

RE: [boost] date_time small feature request

John Torjo wrote: I've been using date_time, and it's really cool! Thanks. However, I would have a small request: For time iterators: we have hours(), minutes(), seconds(), but no days(). Of course, instead of days(1) we can have hours(24), still I think it's more expressive to have

Re: [boost] Re: plans for a bugfix release ?

On Tue, 15 Jul 2003 19:19:08 +0200, Thomas Witt wrote David Abrahams wrote: Beman Dawes [EMAIL PROTECTED] writes: When we released 1.30.0, despite extensive pre-release testing, it went out with several prominent showstopper bugs. Don't you think we'll make the same mistake for

Re: [boost] Re: string conversion methods

I don't know about the other libraries? Is there a standard for this in boost or is it up to the libraries? Should they be commonised? Thorsten Ottosen wrote Ideally, yes. I would prefer .c_str() for const char* conversion and str() for std::string In date-time there are several

Re: [boost] local copy of the date_time doxygen reference manual

On Thu, 26 Jun 2003 11:33:19 -0400, Philip Miller wrote The date_time reference manual seems to be available only at http://www.crystalclearsoftware.com/libraries/gdtl/gdtl_ref_guide/index.html. Unfortunately, there are times when I need to look at the reference manual without an internet

RE: [boost] posix_time to timeval conversion

Jeremy Maitin-Shepard wrote: The thread library as of boost 1.30 does provide a struct xtime, which is similar to timeval, except that xtime represents a time, while timeval represents a time duration. The documentation for the thread library suggests, however, that xtime is intended as a

RE: [boost] date_time, lexical_cast and MSVC 7.0

On Wed, 25 Jun 2003 18:38:46 -0400, Beman Dawes wrote At 09:02 AM 6/24/2003, Jeff Garland wrote: ... I wonder if we should consider releasing 1.30.1 ... The Variant Library has been added, so it would be 1.31.0. And, yes, I think we should start talking about a schedule. I was thinking

RE: [boost] posix_time to timeval conversion

On Mon, Jun 23, 2003 at 06:53:28AM -0700, Jeff Garland wrote: [snip] Ok will do. I'll add some protections or rounding for when durations support higher than microsecond resolution. I'll let you know when this gets added. It seems that since 1) timeval is non-(C++) standard, and 2

RE: [boost] date_time, lexical_cast and MSVC 7.0

From: Philip Miller [EMAIL PROTECTED] Now, the reason for my posting. I am using MSVC 7.0 and am unable to compile the date_time library tests. Compiling time_parsing.hpp gives me an error in lexical_cast, where there is no output operator for the lexical_castunsigned short compiled

RE: [boost] posix_time to timeval conversion

S. Seefeld wrote I'd suggest these two converters to be added: timeval to_timeval(const ptime t) ... timeval to_timeval(const time_duration d) ... the latter is especially useful as select() operates with durations, so there is no need to convert between 1970-01-01 relative dates and

RE: [boost] Re: Managing boost dependencies

John M. wrote: The bcp utility is a tool for extracting subsets of Boost, it's useful for Boost authors who want to distribute their library separately from Boost, and for Boost users who want to distribute a subset of Boost with their application. John - Many thx for doing this, I'm sure

RE: [boost] Interest in library generating streambufs from objectswith socket-like interfaces?

Jonathon T. wrote: I have several class templates for producing standard streambufs based on classes with read, write and seek functions (or a suitable subset thereof.) I have used them successfully to access tcp connections, cryptographic routines, OLE compound documents, zip files,

RE: [boost] patch for date_time library

Synge - I have applied a fix that is equivalent to your patch. Let me know if it works. Sorry to be so slow on this... Jeff -Original Message- [mailto:[EMAIL PROTECTED] Behalf Of Synge Todo Sent: Thursday, May 29, 2003 10:15 PM Subject: [boost] patch for date_time library

RE: [boost] Re: Re: Some questions on the FSM submission

Andreas - good to see your submission. I briefly scanned it, and it looks good :-) I'm hope to find some time to play with it in earnest. Just wanted to comment on the UML/SDL comparison. I won't try to summarize and relate to the earlier points, but here are a few thoughts: 1) I have a

RE: [boost] Re: Wish list for Date-Time library

I was just repeating myself here, I guess. I was basically saying it would be nice to be able to adjust big units (like months) backwards by small units (like days). Well, you can take the iterator content and then do calculation with the date: ... date d = *date_itr; date d2 = d -

RE: [boost] [date-time] patch to microsec_time_clock.hpp

Christopher Currie wrote: Hello, Attached is a quick patch to microsec_time_clock.hpp, which in CVS fails to compile under cygwin due to a missing header file. Please let me know if theres something that Im doing wrong here. I found the bug trying to build the socket library in boost-sandbox.

RE: [boost] Problems compiling microsec_time_clock with cygwin/gcc

I get the following error when trying to compile date_time/microsec_time_clock.hpp from the current CVS with cygwin/gcc. C:/Packages/boost/work/boost/date_time/microsec_time_clock.hpp:44: parse error before `;' token I believe there are issues supporting the C interface used by the

RE: [boost] [date_time] enabling microsec_clock under C++Builder

C++Builder doesn't currently support the microsec_clock of date_time because of its standard library. Would it be possible to add code to get the time using Win32 methods as this gives millisecond times? I think this is a good addition, but we should probably make the addition for all

RE: [boost] Re: Boost version 1.30.0 released - date_time changehistory

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

RE: [boost] Re: [date_time] enabling microsec_clock under C++Builder

I think this is a good addition, but we should probably make the addition for all Win32 compilers since I think this is actually part of the Win32 api. I agree with that. Would it be better to make it a millisec_clock, or just use the microsec_clock but the resolution is only

RE: [boost] Re: Boost version 1.30.0 released - date_time changehistory

. 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

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

RE: [boost] Re: RC_1_30_0 still broken -- More lexical_cast

My patience has been exhausted. The folks that care about configuring lexical_cast for GCC 2.95.3 with the SGI library need come forward Do you mean without? The regression tests with the SGI library look fine... immediately and tell us how to

RE: [boost] RE: bidirectional map

OK, so how I ask for preliminary review? Posting a mail here? Yes, you can just ask for preliminary feedback on this list. Another thing you can do is put the code in the boost-sandbox. This helps get things into the boost structure and allows other boosters to keep up with changes as the

Re: [boost] RC_1_30_0 filesystem broken

On Sun, 16 Mar 2003 18:17:19 -0700, Victor A. Wagner, Jr. wrote it APPEARS that some library is needed. What this library is, I do NOT know. The Jamfile under libs/filesystem/build builds a library called libfs. There is a mention of this in the 'Do-List' page, but it looks like the docs

Re: [boost] RC_1_30_0 still broken -- More lexical_cast

On Sun, 16 Mar 2003 17:34:18 -0500, Beman Dawes wrote I'll go over the do-list again after dinner, but it looks like almost all problems have been cleared except for this one. I don't know if the Linux results are up to date, but it appears that we have still taken a step backward with lexical

RE: [boost] RE: bidirectional map

Well, it was my intention then to probe the Boost community for interest in the library, and my impression was it raised little impetus. Ok, well I would be interested in seeing this in boost. A project I am working on would have benefited from a birectional map and it seems like a pretty

[boost] Variant Review: variant iterators

All - I'm posting this review (with permission of the author) that was not posted on the list during the review. This review was considered as part of the library acceptance. Anyway, the review may be of interest to other variant users as it is quite detailed and implements a novel use of

Re: [boost] date_time on gcc linux

M. Andre wrote: So I guess the config isn't included in all files? According to the docs #include boost/date_time/posix_time/posix_time_types.hpp is an available header file with definitions without io. Looks like I introduced a bug here. Will fix. Thx, Jeff

[boost] Variant Library Accepted

/Message/1541664 R. Richter (private email). Thanks to all the reviewers. Jeff Garland Variant Review Manager ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Re: [boost] New release procedure?

The multiple merge thing is probably much less of an issue when working from trunk to branch, but it still could be useful to have the tag. I would call the tag merged_to_branch name. OK, I'll add that to the procedure. Does that clear up my concern? Yes, thanks. I'll aim to get the new

RE: [boost] Formal Review Requst: String Algorithm Library

Phil, On Monday 03 March 2003 23:28, Phil Nash wrote: This request seems to have been left up in the air. I know that many are busy with the release schedule, and there is an identified shortage of review managers, but it would have been nice to have at least acknowledged this request

RE: [boost] New release procedure? [was: 1.30.0 branch-for-releasecomplete]

No one disagreed with this assessment. Jeff Garland posts a partially updated set of developer procedures: http://aspn.activestate.com/ASPN/Mail/Message/1411802/release_procedures.htm At this point the discussion fragments into details and corner cases. The updated release_procedures.htm

[boost] Variant Formal Review Closed

The Variant Review is now closed. Thanks to all who participated. I will be collating the results and will post them in the next few days. Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[boost] Variant Formal Review Reminder

All - This is a reminder about the variant formal review. The review period was scheduled to end on Tuesday Feb 25th, but since we got a late start I have asked and received additional time from the review wizard. The review is now scheduled to end Sunday March 2nd. The variant library offers

RE: [boost] Re: datetime and long long

Dave A. wrote: AFAICT the logic is backwards: you should assume there's no std::abs which works on long long and use your own function by default, only using std::abs if the compiler is *known* to support that extension... if it's even worth the trouble (it'll be less code to just do

RE: [boost] Re: datetime and long long

Thanks Jeff. All tests but one now pass for VA! testmicrosec_time_clock fails for VA6 with one single failure out of 150. It works ok for VA5, though... It might be a spurious failure. As you can imagine testing clock measurements is a bit dicey. That particular test takes a bunch of

RE: [boost] Re: datetime and long long

The problem is, VA _has_ std::abs. You just need a specialization for long long then. namespace std { template long long abs(long long n) { return llabs(n); } } Don't know if this is legal, though. How about just skipping the template: #ifdef _VA_WHATEVER_COMPILER_MACRO_IS namespace

RE: [boost] datetime and long long

Take a look at bosot/date_time/compiler_config.hpp which does something similar. All we need to do to fix these regressions is add the compiler to the list of those that don't have std::abs at line 34. Based on the above, I've bump the VC++ version up to 1310 to cover version 7.1.

RE: [boost] Re: Sockets - what's the latest?

I don't know exactly what you mean by non-trivial sever and what you get from ACE/expect not to get from Boost.Socket that a non-trivial server requires? Depends on the server, CDR formatting, thread-safe queues come to mind. There are probably a few threading things as well. Of course all

Re: [boost] Any, Function, and Signals documentation

We don't want to stick all of the generated HTML into CVS (too big). If it is too big for the regular CVS, isn't it too big for the distribution too? How big is big? This is a radical idea, but maybe that's what's needed. What if we did this: 1) Create a new CVS repository ala the sandbox for

[boost] Formal Review: Variant Library

All - Today is the start of the formal review of the Variant library by Eric Friedman and Itay Maman. The review will run until Tuesday Feb. 25th. I will be serving as review manager. The variant library offers a simple, type-safe solution for manipulating an object from an inhomogeneous set

RE: [boost] Re: Sockets - what's the latest?

...various comments about ACE from various authors [...] How about borrowing ideas from ACE, but implementing them in modern C++? Or has that been discussed already? Or is the ACE framework too obsolete-C++ to be a useful design? We probably should at least consider ACE ideas.

RE: [boost] Regression tests -- A small request - seeing double onBSD

First, let me just say thanks to all the regression testers -- this is really a critical asset to boost developers. And the new summary page is very helpful and the addition of the age is very nice! I have a small request. Please send me test results for the date_time testmicrosec_time_clock

RE: [boost] Re: Sockets - what's the latest?

On Friday, February 14, 2003, at 08:38 AM, Jeff Garland wrote: So in summary, I think we should focus the Boost.Socket effort on what is currently described as 'level 1 - OS platform layer' and 'level 2 - basic connectivity layer' leaving multiplexing for later. I'm sure

Re: [boost] When to branch-for-release 1.30.0?

At Friday, 14 February 2003, you wrote: So I'm proposing we spend Saturday and Sunday trying to clear regression test problems, and then branch-for-release Monday around noon Eastern US time, (5PM UTC). Comments? Works for me Jeff ___

RE: [boost] Any interest in a stats class

Scott K wrote: Hi all, I have a small family of statistics classes which I have used from time to time. The one I use most often is simply called stats. Here's an example of it's use: ...details snipped... I'm sure there are folks interested in statistical (and other) functions. I've

RE: [boost] date_time release mode errors

execute-test ..\status\bin\testdate_iterator.test\vc7\release\runtime-link-dynamic\testda te_iterator.run == BEGIN OUTPUT == Pass :: base iterator 20020101 20020102 20020103 20020203 Pass :: day iterator -- 2 days Pass :: day iterator -- 2 days Pass :: day iterator -- 2 days FAIL

RE: [boost] Results of Cray SV1 regression tests

Another problem is that the type long long exists but is not supported by the standard library (e.g. the operator (std::ostream, long long) is not defined). Since long and long long are both 64 bit there is actually no need to ever use long long. I'll have to check why long long is used

RE: [boost] Results of Cray SV1 regression tests

Curiously the one failure for date-time was in handling of big time durations. The failure is probably an overflow problem, which can happen if you try to use a plain 32-bit integer to get nano-second resolutions and large time durations. Nano-second resolution is the default

Re: [boost] Re: Deadline for the Standard LibraryTechnicalReport

Currently I'm investigating format, Spirit and threads, but if any-one submitting libraries wants another pair of eyes looking over the submission just ask. [I've been holding back comments on smart- pointers as it has been quite busy without my help g] Here are a couple of library efforts that

RE: [boost] Previously GPL'd Code

Glenn -- Since this mail seems to have been buried in the usual wave of boost mail, I'll take a stab at it so you at least get a response - FWIW... A licensing question for everyone: Is there any problem with submitting, for possible inclusion in Boost, a library that was previously

RE: [boost] Minor question about BOOST_HAS_LONG_LONG

I've noticed that the philosophy of boost as it concerns long long is: if the type exists then use it. Since it is a non standard feature shouldn't it be used only if requested by the user (e.g. with a macro from the command line: -DBOOST_ENABLE_LONG_LONG Maybe, but you could end

RE: [boost] $egression tests -- no links for Win32 errors?

Seems like somewhere along the way we lost the failure detail for at least the Win32 regression. Any ideas when this part will be back? Jeff ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

RE: [boost] Comments on date/time library

But seriously I'm willing to add it, but I don't think I've heard a compelling use case yet... I wrote a date formatting function. This function can take a datetime, date, or time duration, and format it to text. The core however, is implemented using datetime_t. The function

RE: [boost] Comments on date/time library

Seems like there will be cases where you will want to print the 'not_a_date' value instead of throwing an exception. Without a bit more detail, however, it is unclear to me how this bears on a default constructor. You can already test a date to find out if it is not_a_date_time?

RE: [boost] $egression tests -- no links for Win32 errors?

Look at http://boost.sourceforge.net/regression-logs/cs-win32-index.html The way the tests are being run hasn't changed, but the summary is only linking to the version without links. Ah, thanks. We need to figure out exactly which versions of the tables are most useful, and which the

Re: [boost] database library?

At Tuesday, 21 January 2003, you wrote: I don't recall discussion of a rdbms access library on this list. Have there been any candidates in the past? There have been some discussions in the past, but nothing too serious. Oracle OCCI seems pretty modern and might make a good starting point -

[boost] [build/test] Testing different configurations, misc questions

I have been upgrading the Jamfiles for the date_time library have a couple questions: 1) I have a need to build tests with different compile options. For example consider the following example where the tests are the same, but the compile options are different. test-suite date_time_gregorian

RE: [boost] [build/test] Testing different configurations, miscquestions

Is there some way to do this? Yeah, just use different names for the two tests. The signature of the run rule is: run ( sources + : args * : input-files * : requirements * : name ? : default-build * ) Ok here is a snippet of my actual Jamfile. For some reason only the first of these

  1   2   >