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?
Something like this in microsec_time_clock.hpp seems to work
static time_type
Dave Gomboc [EMAIL PROTECTED] writes:
Since you advocate elsewhere that exception classes be derived
from std::exception, the answer is because otherwise LSP would
be violated.
You can't access the derived class' assignment operator through a
pointer/reference to a polymorphic base, so
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
/*
Pavel Vozenilek [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I use Borland C++ Builder 6, update 4, STLPort 4.5.1 (provided by Borland)
and Boost is 1.30.0beta1.
Sorry for the delay...
Following snippet of code fails:
-
#include boost/optional.hpp
#include
Daniel Frey [EMAIL PROTECTED] writes:
[Cutpaste from your second post:]
I'm even inclined to do as other projects do and kill all the
underscores, waiting to deal with ambiguity until it arises. It's
going to be a *long* time before we have numbers that could conflict.
Short (or
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
Jeff Garland wrote:
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
Thomas Becker [EMAIL PROTECTED] writes:
I recently noticed that the ready-to-use boost now provide almost
everything that we use, with the exception of the combining
iterator. But this is a very important one for us, hence the
proposed submission.
Please comment.
It's a wonderful idea,
Jon Wray wrote:
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;
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
Russell Hind wrote:
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 milliseconds?
WinAPI Note: we can get a higher resolution using the
QueryPerformanceCounter API (and QueryPerformanceFrequency if resolution
info is
Boosters,
The update of lexical_cast caused quite a few headaches before the release
of 1.30.0. Rather than reiterating the reasons for squeezing the update into
1.30.0, I just want to thank the people involved for their efforts, and
apologize to all for the problems due to these last-minute
Darren Cook wrote:
I'm using new/delete currently, but was planning to use boost.Pool once my
design has settled down.
I was considering using some sort of pooling/block allocation method to
improve allocation efficiency, but was leaving that as an optimization
consideration for when I got the
Alisdair Meredith wrote:
Russell Hind wrote:
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 milliseconds?
WinAPI Note: we can get a higher resolution using the
QueryPerformanceCounter API (and
On Mon, 24 Mar 2003, Vladimir Prus wrote:
Say, I have
std::mapstd::string, boost::any values;
Will I be able to write:
anyfast_allocator a;
values[10] = a;
?
IOW, I don't think your proposal provides any means to convert between 'any'
with different allocators. And I'm not
The combining iterator is another iterator adaptor. It
holds a boost::tuple of iterators. Moving the
combining iterator in any way causes all member
iterators of the tuple to move in parallel. Upon
dereferencing the combining iterator, the dereferenced
values of the member iterators are
Line 56 of optional.hpp states that Borland ICEs if the union is
un-named. This is correct for C++Builder 5 (0x551), but C++Builder 6
Update 4 (0x564) doesn't have this problem.
Not worth removing it but just thought I'd point it out incase anyone is
interested.
Cheers
Russell
At 08:04 AM 3/24/2003, Alisdair Meredith wrote:
Russell Hind wrote:
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 milliseconds?
WinAPI Note: we can get a higher resolution using the
QueryPerformanceCounter API (and
Title: John Stationery
In the 1.30.0 release, the docs
for BOOST_PP_IF and BOOST_PP_IIF incorrectly refer to 'expr'. It looks as
though they were copied from EXPR_IIF.
john harris
trading
technologies
I'd like to request that the Visual C++ 7.0 with STLport become a supported
configuration for the regex library. Visual C++ 6.0 with STLport is already
a supported configuration. I get the feeling many people were only using
STLport with vc6 because the bundled STL was broken, and they switched
Beman Dawes wrote:
Be careful. At least with some older versions of Windows, the execution
time for some of the Windows time related API's was so large that the
useful resolution was nowhere near the apparent claimed resolution.
If a function that is supposed to measure time in microseconds
Russell Hind wrote:
Does this help?
I've just run this quickly on my PIII 800 running Win2K SP3 and worse
case for 1,000,000 calls to QueryPerformanceCounter was 1.92seconds,
usually between 1.55 and 1.65 seconds (10 runs).
LARGE_INTEGER Start, End, Temp;
QueryPerformanceCounter(Start);
Do you want the C++Builder project as well, or is this enough?
Cheers
Russell
Beman Dawes wrote:
Interesting. Could you please post the entire program as an attachment,
so I can just compile and run it without any cut-and-paste?
Thanks,
--Beman
#include windows.h
#include iostream
int
Thomas Becker [EMAIL PROTECTED] writes:
The combining iterator is another iterator adaptor. It
holds a boost::tuple of iterators. Moving the
combining iterator in any way causes all member
iterators of the tuple to move in parallel. Upon
dereferencing the combining iterator, the dereferenced
Thanks for the answer.
So, it seems that the boost.thread has to be a dll.
I've done as Dave suggested: bjam -d2 so I could made all the settings for
the dll-project
like they are done by you.
Still some problems:
1) You are using the /MD (/MDd) flag for the Runtime Library. This is a
problem
On Mon, 24 Mar 2003, Neal D. Becker wrote:
I'd like to learn about boostbook. Where can I find some info? Are there
dtd's I can get?
All of the BoostBook sources (DTD, XSL stylesheets, docs, etc.) are in
Boost CVS under tools/boostbook.
There's an HTML version of the BoostBook documentation
Neal D. Becker [EMAIL PROTECTED] writes:
I'd like to learn about boostbook. Where can I find some info? Are there
dtd's I can get?
Have you seen
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Boost_Documentation_Format
??
--
Dave Abrahams
Boost Consulting
On Sun, 23 Mar 2003 13:26:04 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
That sounds right. Would you like to post a proposed replacement (or
patch) for the page as written which addresses your points?
You embarrass me. I think the page is ok as long as you don't say
during stack unwinding;
In many ways the preparation Boost 1.30.0 went very well, and the resulting
release seems very high quality to me.
There were rough edges of course, and we'll try to make some improvements
in coming months. Mostly just procedural stuff like making sure we have an
active maintainer for all
I have a simple class, which three interesting
methods:
- current
- advance
- eof
I had a custom wrapper which converts any class which such methods (and some
typedefs) and now I want to use iterator adaptors library. What is the best
approach? I can roll a new policy class, of course.
But I
On Mon, 24 Mar 2003 07:24:38 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
I don't think I've ever read a
description of LSP which doesn't leave that question completely
unaddressed.
I've never seen a formulation of LSP which was appliable to C++.
If for each object o1 of type S there is an
Gennaro Prota [EMAIL PROTECTED] writes:
On Sun, 23 Mar 2003 13:26:04 -0500, David Abrahams
[EMAIL PROTECTED] wrote:
That sounds right. Would you like to post a proposed replacement (or
patch) for the page as written which addresses your points?
You embarrass me.
Unintended.
I think the
On Mon, 24 Mar 2003 17:03:10 +0100, Gennaro Prota
[EMAIL PROTECTED] wrote:
Maybe you can also add an exclamation point
Ahem, exclamation mark :-)
Genny.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The following message seems to be written at an 'untime', because nobody
responded, especially nobody of the maintainers. Nevertheless IMHO this
question is worth thinking about to find a resolution.
Hi all,
I have a problem while using the iterator_adaptor templates
in conjunction with a
Vladimir Prus [EMAIL PROTECTED] writes:
I have a simple class, which three interesting
methods:
- current
- advance
- eof
I had a custom wrapper which converts any class which such methods (and some
typedefs) and now I want to use iterator adaptors library. What is the best
approach? I
Russell Hind [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Line 56 of optional.hpp states that Borland ICEs if the union is
un-named. This is correct for C++Builder 5 (0x551), but C++Builder 6
Update 4 (0x564) doesn't have this problem.
Not worth removing it but just thought I'd
Beman Dawes said:
There was some discussion of a better tracking system once before, but I
really think we need to get going on this now. The problems are much
more serious.
What systems work for others in an Internet environment like Boost? Who
could act as host? I see the GCC folks are
David Abrahams wrote:
But I think the above set of operation is quite handy when one wants to
create a new input iterator. The wrapped class is also close to
Generator, with added 'eof' method. So, I wonder, if I should strive to
make something reusable, which can be added to the library?
Beman Dawes wrote:
What systems work for others in an Internet environment like Boost? Who
could act as host? I see the GCC folks are migrating from GNATS to
Bugzilla.
Another group in our company uses BugZilla for an internal project, and
I helped them out on it for a few months, and so had
Beman Dawes wrote:
In many ways the preparation Boost 1.30.0 went very well, and the
resulting release seems very high quality to me.
There were rough edges of course, and we'll try to make some
improvements
in coming months. Mostly just procedural stuff like making sure we
have an active
Russell Hind wrote:
I've just run this quickly on my PIII 800 running Win2K SP3 and worse
case for 1,000,000 calls to QueryPerformanceCounter was 1.92seconds,
usually between 1.55 and 1.65 seconds (10 runs).
I tied it on a 1.8 giga-hertz Pentium 4M, running XP Pro, with very similar
results:
- Original Message -
From: Fernando Cacciola [EMAIL PROTECTED]
Following snippet of code fails:
-
#include boost/optional.hpp
#include utility
void foo(const boost::optionalstd::pairunsigned, unsigned aux =
boost::optionalstd::pairunsigned, unsigned ())
[2003-03-24] Beman Dawes wrote:
There was some discussion of a better tracking system once before, but I
really think we need to get going on this now. The problems are much more
serious.
What systems work for others in an Internet environment like Boost? Who
could act as host? I see the GCC
Alisdair Meredith [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Russell Hind wrote:
WinAPI Note: we can get a higher resolution using the
QueryPerformanceCounter API (and QueryPerformanceFrequency if resolution
info is required)
It is (was) not completely reliable: see Q274323
Edward Diener [EMAIL PROTECTED] writes:
Beman Dawes wrote:
In many ways the preparation Boost 1.30.0 went very well, and the
resulting release seems very high quality to me.
There were rough edges of course, and we'll try to make some
improvements
in coming months. Mostly just procedural
Beman Dawes wrote:
But here is the surprise - when I ran the same test on a 2.0 giga-Hertz
Pentium 4, running Win2K SP2, it took around 4.5 seconds. See below.
I was surprised at the difference too, so tested here with a Dual 800Mhz
PIII (Dell Precision 220) running Windows 2000 Advanced
Kevin Atkinson [EMAIL PROTECTED] writes:
Feedback on the idea or implementation welcome. This code, at the moment,
does not follow boost standards. If people think it is a worthy addition
to boost I will be willing to being it up to boost standards. But for
right now please refrain from
Hi All,
I was reporting recently that random does not compile on msvc
6; I've seen another report on the list that it does not work on intel c
7 as well.
The fact that released random library fails to work on these
very popular compilers is rather sad. I did some investigation and
Lapshin, Kirill [EMAIL PROTECTED] writes:
The interesting part that it fails to compile even when there is no
instantiation of the template.
In random library this assertion is within #ifndef
BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS #endif directives.
That makes no sense. That macro is
I added that to Boost.Python, FWIW.
Date/Time and Test have it also.
Gennadiy.
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The interesting part that it fails to compile even when there is no
instantiation of the template.
In random library this assertion is within #ifndef
BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS #endif directives.
That makes no sense. That macro is defined for msvc6 IIRC.
No it is not.
-Original Message-
On Behalf Of Beman Dawes
Sent: Tuesday, 25 March 2003 1:15 AM
snip
Be careful. At least with some older versions of Windows, the execution
time for some of the Windows time related API's was so large that the
useful resolution was nowhere near the apparent
John Harris (TT) wrote:
In the 1.30.0 release, the docs for BOOST_PP_IF and BOOST_PP_IIF
incorrectly refer to 'expr'. It looks as though they were copied
from EXPR_IIF.
john harris
trading technologies
Thanks John, I'll fix it.
Paul Mensonides
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Thomas Becker
Sent: Monday, March 24, 2003 7:50 AM
To: [EMAIL PROTECTED]
Subject: [boost] Determining interest in combining_iterator
This email is to determine possible interest in a
submission to
Lapshin, Kirill [EMAIL PROTECTED] writes:
The interesting part that it fails to compile even when there is no
instantiation of the template.
In random library this assertion is within #ifndef
BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS #endif directives.
That makes no sense. That macro is
At 05:47 PM 3/24/2003, Lapshin, Kirill wrote:
The interesting part that it fails to compile even when there is no
instantiation of the template.
In random library this assertion is within #ifndef
BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS #endif directives.
That makes no sense. That macro is
It would be nice if boost::optionalT had operator defined whenever
operator was defined for T. This would allow us to use optionalT as the
key of an associative container. I suggest the following semantics:
bool operator(optionalT const x, optionalT const y);
Returns: If y is
Replying to myself sorry...
Quite right. This was related to the QueryPerformanceCounter() using the
8254-compatible real-time clock which could take several thousand cycles.
The HAL of Pentium's and above should use Intel's RDTSC (Read Time Stamp
Counter) and not suffer this problem.
Apart
Do you really want the key to an associative container to be an optional
value ? I would be hard-pressed to find a use for that.
Joe Gottman wrote:
It would be nice if boost::optionalT had operator defined
whenever operator was defined for T. This would allow us to use
optionalT as the
On Mon, 24 Mar 2003, Edward Diener wrote:
Do you really want the key to an associative container to be an optional
value ? I would be hard-pressed to find a use for that.
FWIW, the Signals library actually does this internally (although with
boost::any objects instead of boost::optional
I am using Boost Ver 1.30 just released. I built the
libraries with BJam. Now when building my code I get lots of warnings like the
following. These warnings worry me a bit because they are level 1 and 2
warnings. Is it safe to ignore these or do I need to manually set
some option? I never
Hi Doug,
Will I be able to write:
anyfast_allocator a;
values[10] = a;
?
IOW, I don't think your proposal provides any means to convert between
'any' with different allocators. And I'm not sure you can easily achieve
that
Sure you can. You just store a copy of the allocator
62 matches
Mail list logo
