[boost] Re: boost::any feature request
Hi Doug,
>> Will I be able to write:
>>
>>any 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 along with the data
> you are holding. The holders would look like this:
[...]
> virtual holder* clone() = 0
> {
> holder* result = allocator.allocate(1);
> new (result) holder(value, allocator);
> return result;
> }
Aha, that's what I was trying to say, but not very clearly. Yes, *this* will
work. But... it means that if you do
any<> a1;
any a2 = a1;
Then value stored in a2 will be allocated using a1's allocator, not a2's.
Once any is created with a specific allocator, all copies will use the same
allocator, which is doubtful behaviour. In the example above, the
"fast_allocator" parameter has no effect at all.
Even if this behavior is desirable, you don't need to add template parameter
to 'any'. You can add template parameter to 'holder' only, and another
constructor, which allows to specify allocator.
- Volodya
>
> virtual void destroy() = 0
> {
> Allocator allocator(this->allocator);
> this->~holder();
> allocator.deallocate(this);
> }
> };
>
> This requires allocators to be CopyConstsructible, of course.
>
> Doug
> ___
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] VC7/Threads Warnings
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 got these warnings with Boost 1.29. I get lots of warnings like: C:\boost\boost_1_30_0\boost\thread\thread.hpp(79): warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty,_Ax>' needs to have dll-interface to be used by clients of class 'boost::thread_group' with [ _Ty=boost::thread *, _Ax=std::allocator ] and C:\boost\boost_1_30_0\boost\thread\exceptions.hpp(29): warning C4275: non dll-interface class 'std::logic_error' used as base for dll-interface class 'boost::lock_error' ___ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.cas.edu.au/ ___
Re: [boost] Re: boost::optional feature request.
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 objects). However, I would contend that the need is too specialized to warrant adding an operator<. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: boost::optional feature request.
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::optional had operator< defined > whenever operator< was defined for T. This would allow us to use > optional as the key of an associative container. I suggest the > following semantics: > > bool operator<(optional const &x, optional const &y); > > Returns: If y is uninitialized, false. If y is initialized and x is > uninitialized, true. If x and y are both initialized, (*x < *y). > > > >This results in a strict weak ordering with uninitialized > optional objects being sorted first. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [date_time] enabling microsec_clock under C++Builder
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 from problems with RDTSC mentioned elsewhere (PCI problems, CPU speed
changes, problems with >2.1GHz) ... I'm not sure when RDTSC is used as there
seems to be a bit of information indicating uniprocessor HAL's using the
real-time clock instead of RDTSC, including boost
http://lists.boost.org/MailArchives/boost/msg31392.php
Couldn't find anything definitive at MS. Others might know.
The last bit of
http://msdn.microsoft.com/msdnmag/issues/0500/hood/default.aspx seemed the
most (in)definitive google turned up.
But it seems only the multiprocessor HAL (which can run on a uniprocessor
but is not the default) supports RDTSC. If this is the case then timing
granularity will vary quite a bit per platform.
Could code RDTSC directly (note quite portable C++ ;-))
P J Naughter and J M McGuiness wrote the following code that is publicly
available but copyrighted:
http://www.thecodeproject.com/datetime/ccputicker.asp#xx1843xx
But this would need to be different for each supported compiler :-( and you
still have to calculate the processor frequency, perhaps using
QueryPerformanceCounter() on win32... :-(
#pragma optimize("",off)
void CCPUTicker::Measure()
{
if (m_bHasRDTSC)
{
volatile ULARGE_INTEGER ts;
//on NT don't bother disabling interrupts as doing
//so will generate a priviledge instruction exception
if (!m_bRunningOnNT)
{
_asm
{
cli
}
}
_asm
{
xor eax,eax
push eax
push ebx
push ecx
push edx
_emit 0x0f ; cpuid - serialise
the processor
_emit 0xa2
pop edx
pop ecx
pop ebx
pop eax
_emit 0x0f ; rdtsc
_emit 0x31
mov ts.HighPart,edx
mov ts.LowPart,eax
}
if (!m_bRunningOnNT)
{
_asm
{
sti
}
}
m_TickCount = ts.QuadPart;
}
else
{
m_TickCount=0;
}
}
#pragma optimize("",on)
m_TickCount is __int64
Regards,
Matt.
--wasting too much time
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] boost::optional feature request.
It would be nice if boost::optional had operator< defined whenever operator< was defined for T. This would allow us to use optional as the key of an associative container. I suggest the following semantics: bool operator<(optional const &x, optional const &y); Returns: If y is uninitialized, false. If y is initialized and x is uninitialized, true. If x and y are both initialized, (*x < *y). This results in a strict weak ordering with uninitialized optional objects being sorted first. Joe Gottman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] random and msvc6
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 defined for msvc6 IIRC. > >No it is not. > >Defining this macro prior to including any boost headers solves the >problem ... In my local working copy, I added: # define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS to visualc.hpp. While that changed the error messages somewhat, random_demo and random_test are still failing. When you say adding the macro "solves the problem", exactly what tests are fixed? Or did you also make some other fixes too? Did you try other regression tests? Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] random and msvc6
"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 defined for msvc6 IIRC. > > No it is not. Sorry, I guess I was thinking of VC6/STLPort4.1 Please ignore my inane drivel. > Defining this macro prior to including any boost headers solves the problem, > config/compiler/visualc.hpp does not have such define. Also as I said before > I was trying few tricks from detail/numeric_traits.hpp, and one of the > reasons why I suggested to put this define is that I've seen similar one in > there. For instance line 84 of detail/numeric_traits.hpp reads: > > #if defined(BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS) || defined(BOOST_MSVC) > && BOOST_MSVC <= 1300 Hmm. I think your patch is OK now. Of course I've been wrong at least once today already... ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Determining interest in combining_iterator
> -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 boost: the combining iterator. I can see this VERY useful to some, but probably not widely useful. Paul Paul A Bristow, Prizet Farmhouse, Kendal, Cumbria, LA8 8AB UK +44 1539 561830 Mobile +44 7714 33 02 04 Mobile mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: bad_lexical_cast
> Even a simple overloading of two functions (if we don't want to
> disturb reference binding) seems to put it in serious trouble:
>
>
> void f(int) { something... }
> void f(short) { something else... }
>
> int main() {
> int i = 0;
> f(i);
> }
int and short do not have an is_base_and_derived relationship.
This thread is getting off-topic, so I'll stop here.
Dave
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Preprocessor documentation erratum
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [date_time] enabling microsec_clock under C++Builder
> -Original Message- > On Behalf Of Beman Dawes > Sent: Tuesday, 25 March 2003 1:15 AM > 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 takes > several milliseconds to execute, it seems to me the useful resolution is > really milliseconds rather than microseconds. 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. ACE's ACE_High_Res_Timer has more info if you'd like. Info below from the header FYI. It suggests RDTSC takes 16 to 32 cycles, just add call overhead and beware of multiprocessor issues. In fact ACE has support for a few platforms you could pilfer due to its open license. Regards, Matt. /** * @class ACE_High_Res_Timer * * @brief A high resolution timer class wrapper that encapsulates * OS-specific high-resolution timers, such as those found on * Solaris, AIX, Win32/Pentium, and VxWorks. * * Most of the member functions don't return values. The only * reason that one would fail is if high-resolution time isn't * supported on the platform. To avoid impacting performance * and complicating the interface, in that case, * is used instead. * The global scale factor is required for platforms that have * high-resolution timers that return units other than * microseconds, such as clock ticks. It is represented as a * static u_long, can only be accessed through static methods, * and is used by all instances of High Res Timer. The member * functions that return or print times use the global scale * factor. They divide the "time" that they get from * by global_scale_factor_ to obtain the * time in microseconds. Its units are therefore 1/microsecond. * On Windows the global_scale_factor_ units are 1/millisecond. * There's a macro which gives the * units/second. Because it's possible that the units/second * changes in the future, it's recommended to use it instead * of a "hard coded" solution. * Dependend on the platform and used class members, there's a * maximum elapsed period before overflow (which is not checked). * Look at the documentation with some members functions. * On some (most?) implementations it's not recommended to measure * "long" timeperiods, because the error's can accumulate fast. * This is probably not a problem profiling code, but could be * on if the high resolution timer class is used to initiate * actions after a "long" timeout. * On Solaris, a scale factor of 1000 should be used because its * high-resolution timer returns nanoseconds. However, on Intel * platforms, we use RDTSC which returns the number of clock * ticks since system boot. For a 200MHz cpu, each clock tick * is 1/200 of a microsecond; the global_scale_factor_ should * therefore be 200 or 20 if it's in unit/millisecond. * On Windows ::QueryPerformanceCounter() is used, which can be a * different implementation depending on the used windows HAL * (Hardware Abstraction Layer). On some it uses the PC "timer chip" * while it uses RDTSC on others. * NOTE: the elapsed time calculations in the print methods use * ACE_hrtime_t values. Those methods do _not_ check for overflow! * NOTE: Gabe <[EMAIL PROTECTED]> raises this issue regarding * : on multi-processors, the processor that * you query for your value might not be the one * you queried for . Its not clear how much * divergence there would be, if any. * This issue is not mentioned in the Solaris 2.5.1 gethrtime * man page. * A RDTSC NOTE: RDTSC is the Intel Pentium read-time stamp counter * and is actualy a 64 bit clock cycle counter, which is increased * with every cycle. It has a low overhead and can be read within * 16 (pentium) or 32 (pentium II,III,...) cycles, but it doesn't * serialize the processor, which could give wrong timings when * profiling very short code fragments. * Problematic is that some power sensitive devices * (laptops for example, but probably also embedded devices), * do change the cycle rate while running. * Some pentiums can run on (at least) two clock frequency's. * Another problem arises with multiprocessor computers, there * are reports that the different RDTSC's are not always kept * in sync. * A windows "timer chip" NOTE: (8254-compatible real-time clock) * When ::QueryPerformanceCounter() uses the 8254 it has a * frequency off about 1.193 Mhz (or sometimes 3.579 Mhz?) and * reading it requires some time (several thousand cycles). */ ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] random and msvc6
>> 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. Defining this macro prior to including any boost headers solves the problem, config/compiler/visualc.hpp does not have such define. Also as I said before I was trying few tricks from detail/numeric_traits.hpp, and one of the reasons why I suggested to put this define is that I've seen similar one in there. For instance line 84 of detail/numeric_traits.hpp reads: #if defined(BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS) || defined(BOOST_MSVC) && BOOST_MSVC <= 1300 -Kirill ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: 1.30.0 release postmortem
> 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
Re: [boost] random and msvc6
"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 defined for msvc6 IIRC. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] random and msvc6
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 nailed down
the problem to following simple example:
template
class Works
{
BOOST_STATIC_ASSERT(!std::numeric_limits::is_integer);
};
template
class Fails
{
BOOST_STATIC_ASSERT(!std::numeric_limits::is_integer);
};
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.
I did a quick search through boost sources and found somewhat
similar code in numeric_traits.hpp, however not a single trick borrowed from
there seemed to work in this case. Should we just disable the assertion for
this particular compiler? Replacing #ifndef BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
with #if !defined(BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS) && !(defined(BOOST_MSVC)
&& BOOST_MSVC <= 1300) will solve the compile error. Is this trttd?
If there are no objections, I can make this changes and send patches to someone
willing to apply it to CVS.
Thorsten, was the error you observed on intel 7 related to
this one?
__
Kirill Lapshin
Re: [boost] Lock Classes: FINAL POST (fixed attch)
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 making comments on coding style or the > like. >From what I can see here it looks interesting, but what's really needed is a good description of the problem that it's solving with narrated examples that show how you use it to solve those problems. The little example you enclosed isn't very enlightening. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [date_time] enabling microsec_clock under C++Builder
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 Server (SP2). Cutting and pasting into a default Win32 console project in VC6 (SP4 I think) gives a result of ~0.72 on an idle machine. Regards Mark Blewett --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.445 / Virus Database: 250 - Release Date: 21/01/2003 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: 1.30.0 release postmortem
"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 stuff like making sure we >> have an active maintainer for all libraries, and getting maintainers >> to make major changes earlier in the process. >> >> The worst problem seems to me to be that our bug and patch tracking is >> totally dysfunctional. > > I would like to add an idea that I have mentioned in the past; which is that > each library have some documentation on the changes made from release to > release, at least on the order of major things happening such as features > being added or changed or deleted, so that the end user has some idea of > what is different in the new release for that library. I find the idea that > such documentation does not exist really disturbing. I believe library > implementors have to take responsibility for such documentation although I > imagine a patch tracking system would help. I added that to Boost.Python, FWIW. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
"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 bug in MS Knowledgebase: "Symptoms: The result that is returned by the QueryPerformanceCounter function may unexpectedly leap forward from time to time. This leap may represent several seconds." The MSDN article specifies what HW can cause the problem and how to work it around. /Pavel PS: my experience with this API is positive, I got resolution cca ~1 microsecond and the call overhead was tiny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 release postmortem
[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 folks are migrating from GNATS to >Bugzilla. I personally use Mantis, http://mantisbt.sourceforge.net I chose it because of it's easy of use, not it's set of feature. But so far I haven't found anything that I needed that it didn't support. And it is constantly improving, both in features and ease of use. I'd even be willing to host the bugbase for Boost if we happen to use Mantis. One question... From those previous discussions, was there some resolution as to what features are needed in a BT for Boost? -- grafik - Don't Assume Anything -- [EMAIL PROTECTED] - [EMAIL PROTECTED] -- [EMAIL PROTECTED] ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] two problems with BCB 6 and 1.30b
- Original Message -
From: "Fernando Cacciola" <[EMAIL PROTECTED]>
> > Following snippet of code fails:
> > -
> > #include
> > #include
> >
> > void foo(const boost::optional >& aux =
> > boost::optional >())
> > {}
> >
> > int main() {}
> > -
[snip]
> Hmm..
> I can't reproduce the problem here with the 1.30.0 release,
> BCB6, update 4, from within the IDE.
> Which command line options are you using?
>
The BCB flags are:
CFLAG1
= -Od -H=$(BCB)\lib\vcl60.csm -Hc -Vx -Ve -X- -r- -a8 -b- -k -y -v -vi- -tWC
\
-tWM- -c
IDLCFLAGS = -IC:\Temp\optional_test -I$(BCB)\include -I$(BCB)\include\vcl \
-IC:\Work\Editor\3pp\boost_1_30_0 -src_suffix cpp -D_DEBUG -boa
PFLAGS = -$YD -$W -$O- -$A8 -v -JPHNE -M
RFLAGS =
AFLAGS = /mx /w2 /zd
LFLAGS = -D"" -ap -Tpe -x -Gn -v
It is normal console IDE project in BCB Enterprise, using default options.
It fails with 1.30 as well here.
I may send you the whole project if you want.
/Pavel
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [date_time] enabling microsec_clock under C++Builder
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: 1.48 seconds regardless of whether it was a release or debug
build. Although I was a bit surprised the faster machine didn't cause a
larger difference.
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 wonder if these machines could be using very different timing chips,
having nothing to do with the CPU speed? That would explain why timings are
hard to reproduce from one machine to another.
Anyhow, Windows is still producing very erratic results when it comes to
timing. That's OK, as long as whatever you are trying to time takes a great
deal longer than this variable timing overhead.
--Beman
=== details ===
First time on each line - no load on CPU.
Second time, another process in a tight loop
Borland
debug 4.45899 5.93795
release 4.4701 5.96726
Metrowerks
debug 4.46496 5.90992
release 4.45852 5.95018
GCC
debug 4.44756 5.94334
release 4.50903 5.89241
Intel
debug 4.45704 5.92938
release 4.44913 5.95612
VC++ 6.0
debug 4.48012 5.9725
release 4.46184 5.91715
VC++ 7.0
debug 4.4594 5.91257
release 4.45025 5.98312
>
>#include
>#include
>int main(int argc, char* argv[])
>{
>LARGE_INTEGER Start, End, Temp;
>QueryPerformanceCounter(&Start);
>for (unsigned int i = 0; i < 100; ++i)
>{
>QueryPerformanceCounter(&Temp);
>}
>QueryPerformanceCounter(&End);
>
>LARGE_INTEGER Frequency;
>QueryPerformanceFrequency(&Frequency);
>
>double Time = (static_cast(End.QuadPart) - Start.QuadPart) /
>Frequency.QuadPart;
>std::cout << Time << std::endl;
>return 0;
>}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.0 release postmortem
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 maintainer for all libraries, and getting maintainers > to make major changes earlier in the process. > > The worst problem seems to me to be that our bug and patch tracking is > totally dysfunctional. I would like to add an idea that I have mentioned in the past; which is that each library have some documentation on the changes made from release to release, at least on the order of major things happening such as features being added or changed or deleted, so that the end user has some idea of what is different in the new release for that library. I find the idea that such documentation does not exist really disturbing. I believe library implementors have to take responsibility for such documentation although I imagine a patch tracking system would help. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.0 release postmortem
Russell Hind wrote: > 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 access to it. I > liked it. Specifically: We use BugZilla internally too, and I would describe it as 'rudimentary, but adequate'. OTOH, we have not spent much time configuring it, so there may be some unlocked potential. One nice feature (for boost) is that you can assign 'owners' to projects and sub-projects. When a bug is reported against a project it is automatically assigned to this person, -> and they get an email notifying them <- Of course this feature could rapidly become rather annoying for anyone who cannot maintain a long-term, active boost commitment. It may be that certain library writers would want to delegate bug-support to others in the community? One problem I have with BugZ is that the default layouts are not very easy to manage when you have a large number of projects (eg: one project per boost lib will already be large) Simple navigation is annoying. Of course, this can 'easily' be fixed by writing our own web pages as a front-end, to manage and direct some of the complexity, grouping projects into more manageable chunks etc. -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: exception context
Thanks, I've learnt some history of C++ :-) The dates in your document also allowed me to locate a relevant WP. For those interested: http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/wp/pdf/jan94/body.pdf As it appears, the specification of the standard exception classes underwent major changes in that year and only began to look like we know it now in January of the year after (Jan 95 working paper). Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: 1.30.0 release postmortem
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 access to it. I liked it. Specifically: All the comments are kept with the bug It is easy to refer (and hyperlink) to other bugs in comments revision history of a bug attachments for bugs Mark bugs as duplicates I've not had any experience administering a bugzilla implementation though so can't really help there. The only point they said about it was that it isn't very secure. Any one can create an account on it and start submitting bugs (AFAICR) but that isn't a problem with a project such as boost, IMHO. Which I guess its why it never bothered the Mozilla lot. HTH Russell ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] iterator_adaptors question
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? > > Sure, great idea... but please take my suggestion and try it with the > work in the sandbox. I hope that the current IA design will be > completely replaced with the new (very different) one for 1.31, and > it's important to have as many proofs-of-concept as possible to make > sure we got the interface right. OK, I'll use the sandbox version. - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] 1.30.0 release postmortem
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 migrating from GNATS to > Bugzilla. The only bug tracking systems I have experience with are commercial. However, I did run across a link for an interesting project the other day that may be worth looking into. TUTOS (http://www.tutos.org/homepage/about.html) goes beyond bug tracking and into full project management. As such, the bug tracking may be less robust than dedicated applications like Bugzilla? But it also would address other things that could make maintaining Boost much nicer for both developers and release managers. Of course, since I have no experience with this, it may be a non-start suggestion, but I thought it would at least be worth posting the link. -- William E. Kempf ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Un-named unions and Borland Internal Compiler Error
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 point it out incase anyone is > interested. > Thanks for the info! Fernando Cacciola ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] iterator_adaptors question
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 can roll a new policy class, of course. > > 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? Sure, great idea... but please take my suggestion and try it with the work in the sandbox. I hope that the current IA design will be completely replaced with the new (very different) one for 1.31, and it's important to have as many proofs-of-concept as possible to make sure we got the interface right. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Repost: [boost] Problems using iterator_adaptor withistreambuf_iterator
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 istreambuf_iterator (an > input_iterator type). The problem shows up, because the > istreambuf_iterator::operator*() > implementation of the STL I'm using returns a value_type > (char), but the dereference policy member expects to return > it a reference. > > It seems, that there should be a similar return type deduction for the > iterator_adaptor<>::operator*() function as already > implemented for the > iterator_adaptor<>::operator->() function. Regards Hartmut ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
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
Re: [boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
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 page is ok as long as you don't say > "during" stack unwinding; also I would prefer "could exit via an > exception" rather than "could throw". More-or-less: > > "Don't embed a std::string object or any other data member or base > class whose copy constructor could exit via an exception. That could > lead you straight from the point of throw to std::terminate()" > > Maybe you can also add an exclamation point as a pinch of sound > intimidation :-) I'm just too busy at the moment to make the edits, which is why I suggested you post a replacement. Often you'll find problems with suggested changes when viewed in context. Send me a replacement privately if you like. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: bad_lexical_cast
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 object o2 of
type T such that for all programs P defined in terms of T,
the behavior of P is unchanged when o1 is substituted for
o2 then S is a subtype of T."
Even a simple overloading of two functions (if we don't want to
disturb reference binding) seems to put it in serious trouble:
void f(int) { something... }
void f(short) { something else... }
int main() {
int i = 0;
f(i);
}
This is a program defined "in terms of int". Can you substitute a
short 0 (zero) to i? Also, I've never understood how one can generally
("all programs") substitute an object (rather than a type) in a
program without modifying the program itself. Maybe that's just my
ignorance. And even modifying the program, what is the supposed
substitution LSP refers to in the above case?
a) int i = (short)0;
f(i);
b) short i = 0;
f(i)
When "o1 is substituted for o2"? Where? How?
Genny.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] iterator_adaptors question
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 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? - Volodya ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 1.30.0 release postmortem
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 libraries, and getting maintainers to make major changes earlier in the process. The worst problem seems to me to be that our bug and patch tracking is totally dysfunctional. We enable the SourceForge tracking system, but then don't really use it. I never even looked at it during the release run up. When I have looked at it in the past, the fact that so many messages were anonymous meant that there was no way to ask for follow up information. It is also so far outside our current procedures that it just doesn't seem to fit. Bjorn Karlsson and I, and perhaps others, keeps private do-lists as a release nears, and nag developers who don't seem to be making fixes, but this is a hit-or-miss approach which doesn't scale up to a project the size of Boost today. The net effect is that user bug reports and patches are falling between the cracks. We need to do something about that, and do it soon so that we have a working system long before the next release. One that shows every Booster the current status of bugs and patches at any moment. 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 migrating from GNATS to Bugzilla. Thoughts? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: MSVC++ 6.0 compiler errors with 1.30.0 (mostly lexical_cast.hpp)
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; also I would prefer "could exit via an exception" rather than "could throw". More-or-less: "Don't embed a std::string object or any other data member or base class whose copy constructor could exit via an exception. That could lead you straight from the point of throw to std::terminate()" Maybe you can also add an exclamation point as a pinch of sound intimidation :-) Genny. ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] info on boostbook
"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 www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] info on boostbook
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 here: http://www.cs.rpi.edu/~gregod/boost/tools/boostbook/doc/html/ (once you've read the "Getting Started" section there, you can generate the documentation locally as well). If you have any questions/problems/etc., they are best directed to the Boost documentation list: https://lists.sourceforge.net/lists/listinfo/boost-docs Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost 1.30 - Thread lib workspace
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 for me as I have tons of libs (static libs) built with /MT (/MTd) so the final exe that will use those libs but also the boost.thread lib can not be linked. I could set the /MT (/MTd) for the boost.thread dll also, but I'm not sure if this is ok. Is it? If not, what can I do? 2) I still get 48 warnings, most of them C4275. If somebody is interested I could send the project that I created and that generates those warnings. I'm not sure if I can ignore them or if there is a way to remove them? Thanks, Viv - Original Message - From: "William E. Kempf" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, March 21, 2003 7:52 PM Subject: 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 > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Determining interest in combining_iterator
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
> values of the member iterators are supplied as
> arguments to a client-supplied n-ary functional, and
> the return value of the functional is returned. The
> combining iterator is thus a "higher-dimensional
> transforming iterator."
This sounds like a generalization of my pair iterator to tuples, combined
(sic) with a transform. See http://cplusplus.anthonyw.cjb.net/articles.html
for the code and the article ("Pairing off iterators" from Overload 51)
describing my pair iterators.
IMHO, it seems more logical to split the concept, so the grouping of the
iterators is separated from the transformation, and the existing transforming
iterator adapter can be used for that part. I would be happy to work with you
on a submission --- I have been meaning to submit my pair iterators to boost
since I wrote them.
Anthony
--
Anthony Williams
Senior Software Engineer, Beran Instruments Ltd.
Remove NOSPAM when replying, for timely response.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] info on boostbook
I'd like to learn about boostbook. Where can I find some info? Are there dtd's I can get? ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock underC++Builder
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
#include
int main(int argc, char* argv[])
{
LARGE_INTEGER Start, End, Temp;
QueryPerformanceCounter(&Start);
for (unsigned int i = 0; i < 100; ++i)
{
QueryPerformanceCounter(&Temp);
}
QueryPerformanceCounter(&End);
LARGE_INTEGER Frequency;
QueryPerformanceFrequency(&Frequency);
double Time = (static_cast(End.QuadPart) - Start.QuadPart) /
Frequency.QuadPart;
std::cout << Time << std::endl;
return 0;
}
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: [date_time] enabling microsec_clock under C++Builder
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);
> for (unsigned int i = 0; i < 100; ++i)
> {
> QueryPerformanceCounter(&Temp);
> }
> QueryPerformanceCounter(&End);
>
>LARGE_INTEGER Frequency;
> QueryPerformanceFrequency(&Frequency);
>
>double Time = (static_cast(End.QuadPart) - Start.QuadPart) /
>Frequency.QuadPart;
>
>Doesn't seem to bad to me. Can't test on any more OSes as this is all
>we have installed.
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
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
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 takes
several milliseconds to execute, it seems to me the useful resolution is
really milliseconds rather than microseconds.
It might be interesting to write a little test program and run it on
modern versions of Windows to see it this problem still exists.
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);
for (unsigned int i = 0; i < 100; ++i)
{
QueryPerformanceCounter(&Temp);
}
QueryPerformanceCounter(&End);
LARGE_INTEGER Frequency;
QueryPerformanceFrequency(&Frequency);
double Time = (static_cast(End.QuadPart) - Start.QuadPart) /
Frequency.QuadPart;
Doesn't seem to bad to me. Can't test on any more OSes as this is all
we have installed.
Cheers
Russell
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] request vc7-stlport support in regex libs
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 to the native STL when upgrading to vc7. I use STLport for a different reason -- I develop software on several platforms and want a consistent STL across all of the platforms -- so I intend to keep using STLport even though the bundled STL has been improved. This support requires two simple changes, and I don't believe either would complicate maintenance down the road. In boost/regex/v3/regex_library_include.hpp: *** regex_library_include.hpp 20 Mar 2003 19:49:39 - 1.1 --- regex_library_include.hpp 24 Mar 2003 13:50:04 - 1.2 *** *** 71,76 --- 71,81 // vc6-stlport: # define BOOST_LIB_TOOLSET "vc6-stlport" + #elif defined(BOOST_MSVC) && (BOOST_MSVC >= 1300) && (defined(__SGI_STL_PORT) || defined(_STLPORT_VERSION)) + +// vc7-stlport: + # define BOOST_LIB_TOOLSET "vc7-stlport" + #elif defined(BOOST_MSVC) && (BOOST_MSVC == 1200) // vc6: and in libs/regex/build/vc_gen.sh: *** vc_gen.sh 31 Oct 2002 16:42:31 - 1.1 --- vc_gen.sh 21 Mar 2003 20:14:17 - 1.3 *** *** 362,368 no_single="no" subdir="vc7" vc6_gen ! # # remove tmep files; --- 362,374 no_single="no" subdir="vc7" vc6_gen ! # ! # generate vc7-stlport makefile: ! is_stlport="yes" ! out="vc7-stlport.mak" ! no_single="yes" ! subdir="vc7-stlport" ! vc6_stlp_gen # # remove tmep files; Running vc_gen.sh will now generate a new file, vc7-stlport.mak, which would need to be added to the distribution. I don't know if anything needs to be done with the Jamfiles to support this configuration. I don't think there is, but I'm not comfortable with the whole Jam-based build system for boost so someone else should double-check me. Thanks, Eric ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Preprocessor documentation erratum
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
Re: [boost] Re: [date_time] enabling microsec_clock under C++Builder
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 QueryPerformanceFrequency if resolution >info is required) 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 takes several milliseconds to execute, it seems to me the useful resolution is really milliseconds rather than microseconds. It might be interesting to write a little test program and run it on modern versions of Windows to see it this problem still exists. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Un-named unions and Borland Internal Compiler Error
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Determining interest in combining_iterator
> 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 supplied as > arguments to a client-supplied n-ary functional, and > the return value of the functional is returned. The > combining iterator is thus a "higher-dimensional > transforming iterator." Sounds great. Since the functionality is a direct generalization of transform_iterator, I'd prefer to use the name transform_iterator and either (a) switch entirely to your combining_iterator implementation or (b) give transform_iterator_generator the brains to switch between your implementation and the existing implementation based on the number of iterators being adapted. Doug ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Russell Hind wrote: > Can these be used to get an actual date/time though? Or just for high > resolution timing? I've only had a brief look at them, so will read a > bit more. Oops, good point!! -- AlisdairM ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] boost::any feature request
On Mon, 24 Mar 2003, Vladimir Prus wrote:
> Say, I have
>
>std::map values;
>
> Will I be able to write:
>
>any 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 along with the data
you are holding. The holders would look like this:
struct holder_base {
virtual ~holder_base() {};
virtual holder_base* clone() = 0;
virtual void destroy() = 0;
template
struct holder : holder_base
{
holder(const T& value, const Allocator& allocator)
: value(value), allocator(allocator) {}
~holder() {}
virtual holder* clone() = 0
{
holder* result = allocator.allocate(1);
new (result) holder(value, allocator);
return result;
}
virtual void destroy() = 0
{
Allocator allocator(this->allocator);
this->~holder();
allocator.deallocate(this);
}
};
This requires allocators to be CopyConstsructible, of course.
Doug
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
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 QueryPerformanceFrequency if resolution info is required) Can these be used to get an actual date/time though? Or just for high resolution timing? I've only had a brief look at them, so will read a bit more. Cheers Russell ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] A generic tree manipulation library
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 design sorted.
A std::map would be too much overhead for my particular application (which
tends to have deep trees with few branches).
I'm aware of that. I used a std::map to show an example implementation
without worrying about the actual details.
I was also planning to write an implementation of the tree_node interface
for an n-ary tree; something like:
template< typename T, long n >
class nary_tree_node
{
public:
typedef nary_tree_node * node_pointer;
typedef nary_tree_node * iterator;
private:
node_pointer nodes[ n ];
T data;
public:
inline iterator first_child()
{
return( nodes );
}
inline iterator last_child()
{
return( nodes + n );
}
public:
inline iterator operator[]( index_type it )
{
// range checks?
// compatible index type??
return( nodes[ it ]);
}
};
The other methods and typedefs would be implemented to be consistent with
the other implementation. This was the idea: you can supply your own
implementation or use one of the tree node implementations provided.
Since you are using a binary tree node type, you can use something like:
typedef nary_tree_node< std::string, 2 > binary_node;
Finding the previous sibling or parent in my tree requires starting from
the root node (or keeping a stack of nodes visited).
Would it be more efficient to have a pointer to the parent node as well?
This would allow you to move up to the parent and then along to the next
node without having to start again from the root.
Do you have any example usage?
The trie class is an example of how to use the tree class and I have a test
program for this, but I do not have any other examples at the moment.
I wonder if it would be better to approach this from the
algorithms/iterators side and come to the containers later? I.e. what
operations do you need to do on the trees?
That is a good suggestion.
There should be an iterator for the tree node that will iterate along the
siblings; this has already been accounted for. I was also thinking about
extending this iterator to provide "up" and "down" iterator types to move up
to the parent and down to the first child. I use the names up and down so
that the types could be used in other 2D iterator types.
The tree should provide several navigational iterators:
[1] inorder_iterator: for in order traversal;
[2] preorder_iterator: for pre-order traversal;
[3] postorder_iterator: for post-order traversal;
[4] iterator: for navigating along the leaf nodes inorder.
There may be others that I have not thought of. As for the algorithms that
are to be supported, there are several points:
[1] It should be easy to use the standard algorithms with the tree
implementation wherever possible, e.g.
std::for_each(
tree.inorder_begin(),
tree.inorder_end(),
...
);
Could it be possible to use iterator adaptors like are used for containers
and the functors (with binder1st, etc.)?
As a couple of examples I need:
1. for_each() of first child at each node.
2. display all node values in the tree on stdout.
This may be possible through iterator adaptors:
std::for_each(
tl::iter::first_child( tree.preorder_begin()),
tl::iter::first_child( tree.preorder_end()),
...
);
std::for_each(
tl::iter::indentor( tree.preorder_begin()),
tl::iter::indentor( tree.preorder_end()),
...
);
NOTE: This is experimental at the moment. I do not have an implemetnation of
the above, it is just a preliminary look at a possible solution to the above
problem.
The idea for the indentor is to keep a track of the level that the iterator
is on in the depth of the tree, and provide an output method something along
the lines of:
indent according to level
output the data to the output stream
I have an implementation of some indentation technology that I have used for
my own tracing functionality. I am looking at submitting that to the boost
mailing list later this week (both the indentation stuff and the tracing
stuff), I just need to prepare it for submission.
[2] There should be specializations of the standard algorithms to provide
proper integration with the STL. The most noticable example of this would be
std::swap.
[3] There should be a whole set of algorithms that are designed to fit in
with a tree structure. An example would me tl::mirror to transform a tree to
the mirror image of itself.
-
There should be the ability to construct a tree from another tree (copying
the entire tree) or constructing it from a tree node (making that node the
root of the new tree).
BTW, I'm new to Boost. Is it normal to include all the Allocator stuff
early on when discussi
[boost] lexical_cast - an apology
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 changes (I didn't make the changes, but I pushed other people [too] hard to do so). Bjorn Karlsson ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
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 required) -- AlisdairM Team Thai Kingdom ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 milliseconds? Hmm, I'm thinking that for consistency it would probably be better to call it millisec_clock. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] spirit::rule<>::set_id()
Jon Wray wrote: > Thanks! I noticed that this change leads to different behavior when > assigning rules. Consider this code: > > typename rule_::type Identifier; > typename rule_::type Function; > typename rule_::type Predicate; > typename rule_::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. [snip] Huh? AFAICT, Function.id() == FUNCTION, Predicate.id() == PREDICATE and Variable.id() == VARIABLE. I tested this... rule, parser_context, parser_tag<1> > r1; rule, parser_context, parser_tag<2> > r2; r1 = r2; assert(r1.id() == 1); assert(r2.id() == 2); What am I missing? -- 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
Re: [boost] Determining interest in combining_iterator
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, Thomas! You might look at the Boost sandbox; Jeremy Siek, Thomas Witt and I are trying to finalize the work in the boost/iterator and libs/iterator directories to replace the current iterator adaptors. [I don't see how we'll do it at this point, but we even planned to write a TR proposal for the upcoming Oxford meeting] -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
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 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 milliseconds? Cheers Russell ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 > 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. You make a good point that this can be quite confusing. My thought would be to add an iso_year() function and some documentation instead of changing the current function. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Problem with KAI C++ and boost::type_traits
Daniel Frey <[EMAIL PROTECTED]> writes: > [Cut&paste 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 should I say: too short) labels will buy us nothing IMHO. Is > there any reason for as-short-as-possible labels? I just tried to > create a non-breaking, readable naming scheme which reflects the > current use of branches and tags, but I don't have any strong feelings > about whether it should be used or not... Me neither. I take it back. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [optional] two problems with BCB 6 and 1.30b
/*
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
> #include
>
> void foo(const boost::optional >& aux =
> boost::optional >())
> {}
>
> int main() {}
> -
>
> with error message:
> [C++ Error] Unit1.cpp(12): E2188 Expression syntax
> [C++ Error] Unit1.cpp(12): E2299 Cannot generate template specialization
> from '_STLD::pair<_T1,_T2>'
> [C++ Error] Unit1.cpp(12): E2299 Cannot generate template specialization
> from 'boost::optional'
> [C++ Error] Unit1.cpp(13): E2257 , expected
> [C++ Error] Unit1.cpp(33): E2151 Type mismatch in default value for
> parameter 'aux'
> [C++ Error] Unit1.cpp(12): E2293 ) expected
>
>
> The same code compiles OK with Intel C++ 7.0.
>
> If I use typedef it works OK with both BC++B and Intel C++:
> -
> #include
> #include
>
> typedef boost::optional > AType;
>
> void foo(AType aux = AType())
> {}
>
> int main() {}
> -
>
Hmm..
I can't reproduce the problem here with the 1.30.0 release,
BCB6, update 4, from within the IDE.
Which command line options are you using?
>
> Borland also fails with this construct:
> -
> #include
>
> int main()
> {
> boost::optional aux(0);
> if (aux && *aux == 0) {
> aux.reset(1);
> }
> }
> -
>
> with this error message:
> [C++ Error] Unit1.cpp(24): E2094 'operator&&' not implemented in type
> 'boost::optional' for arguments of type 'bool'
>
> Intel C++ 7.0 compiles and executes this snippet OK.
>
> This works in BC++B:
> -
> #include
>
> int main()
> {
> boost::optional aux(0);
> if ((!!aux) && *aux == 0) {
> aux.reset(1);
> }
> }
> -
>
This one is a known Bortland bug.
In fact, operator!() is provided precisely in order
to allow the second form (with !!) to be used when
needed.
In Borland, the safe_bool operators works only if
the optional is the only element in the boolean
expression, as in: if ( aux ) ...
Thanks for the report!
Fernando Cacciola
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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 Win32 compilers since I think this is actually part of the Win32 api. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: bad_lexical_cast
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 that point is moot. > > Well, you're the expert on this. (I thought you could catch a reference > to an exception, dynamic_cast it downwards, then use the assignment > operator. Sure, this would be a stupid thing to do, but if possible I > certainly can imagine some few misguided souls who haven't yet grokked C++ > exception handling doing so.) You can do it, but then LSP doesn't matter since you know the concrete type. >> LSP is weird anyway. What's the point of polymorphism if you're not >> going to change the behavior of the class in some observable way? If >> the derived class were transparently substitutable for the base class >> it wouldn't be much good, would it? > > I disagree here; "transparently substitutable" != "observable behaviour is > identical". Can you clearly define the difference? I don't think I've ever read a description of LSP which doesn't leave that question completely unaddressed. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Determining interest in combining_iterator
This email is to determine possible interest in a submission to boost: the combining iterator. Short Description = 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 supplied as arguments to a client-supplied n-ary functional, and the return value of the functional is returned. The combining iterator is thus a "higher-dimensional transforming iterator." Background and Current Use == The combining iterator grew out of a large software project where a math engine calculates sequences of numbers that are then used by a charting package as data input. The math eninge exposes its sequences as pairs of iterators. It happens frequently that two sequences of doubles have been calculated for some purpose, and then the sequence consisting of the quotients of the respective values is needed. Storing the quotients in a third sequence would clearly be a colossally dumb decision in terms of time-space tradeoff. Instead, the math engine exposes a combining iterator that parallel-iterates over the two given sequences and, upon dereferencing, returns the quotient of the two values at its current position. Many more situations exist in this software where a simple arithmetic expression is calculated on the fly from two or more sequences of numbers. Anectdotal Background = We started working on the software mentioned above in 1997, and we have been using the STL and generic programming paradigms from Day 1. We have used "smart iterators" as early as 1998. Back then, the idea seemed so new to me that I wrote an article about it in CUJ (CUJ September 1998). Two years later, we had accumulated so many "smart," or "custom" iterators that my friend and colleague Chris Baus and I wrote antother article about it for the 2000 C++ Template Workshop (http://oonumerics.org/tmpw00). Needless to say, from today's point of view, our smart iterators were all spit'n duct tape. It was of course the boost::iterator_adaptor (which by the way was first presented at the 2001 C++ Template Workshop, http://oonumerics.org/tmpw00) that provided the proper framework for doing this. 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. Thomas Becker Zephyr Associates, Inc. Zephyr Cove, NV __ Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! http://platinum.yahoo.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: [date_time] enabling microsec_clock under C++Builder
Given that the accuracy of Windows GetLocalTime (and GetSystemTime) is
milliseconds, perhaps a millisec_clock would be better that putting this
in the microsec_clock? It would possibly make more sense
Cheers
Russell
Russell Hind 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?
Something like this in microsec_time_clock.hpp seems to work
static time_type local_time()
{
#ifdef __BORLANDC__
SYSTEMTIME lt;
GetLocalTime(<);
date_type d = date_type(lt.wYear,
lt.wMonth,
lt.wDay);
int adjust = resolution_traits_type::res_adjust() / 1000;
time_duration_type td = time_duration_type(lt.wHour,
lt.wMinute,
lt.wSecond,
lt.wMilliseconds * adjust);
return time_type(d, td);
#else
#endif
}
Is this Ok, and would it be of interest to anyone? It could be used for
all Win32 compilers (if the adjust statement is correct) or are there
reasons why platform specific code wouldn't be wanted in the library?
We currently log a lot of error information to text files, but
sub-second times are useful. date_time currently doesn't offer this for
C++Builder, so that is why we would like something like this added.
Cheers
Russell
___
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[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?
Something like this in microsec_time_clock.hpp seems to work
static time_type local_time()
{
#ifdef __BORLANDC__
SYSTEMTIME lt;
GetLocalTime(<);
date_type d = date_type(lt.wYear,
lt.wMonth,
lt.wDay);
int adjust = resolution_traits_type::res_adjust() / 1000;
time_duration_type td = time_duration_type(lt.wHour,
lt.wMinute,
lt.wSecond,
lt.wMilliseconds * adjust);
return time_type(d, td);
#else
#endif
}
Is this Ok, and would it be of interest to anyone? It could be used for
all Win32 compilers (if the adjust statement is correct) or are there
reasons why platform specific code wouldn't be wanted in the library?
We currently log a lot of error information to text files, but
sub-second times are useful. date_time currently doesn't offer this for
C++Builder, so that is why we would like something like this added.
Cheers
Russell
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: Problem with KAI C++ and boost::type_traits
David Abrahams wrote: Daniel Frey <[EMAIL PROTECTED]> writes: And I'd prefer to have a separator for the non-releases like the '-' anywhere: v1_30-branch v1_30_0-rc1 v1_30_0 v1_30_1-rc1 v1_30_1-rc2 v1_30_1 Why? Nothing technical / serious. Just my personal taste, yours may vary :) Anything without a '-' marks a real release [Cut&paste 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 should I say: too short) labels will buy us nothing IMHO. Is there any reason for as-short-as-possible labels? I just tried to create a non-breaking, readable naming scheme which reflects the current use of branches and tags, but I don't have any strong feelings about whether it should be used or not... 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
